Subject: OVL suggestions
From: David Lacey (dlacey@rsn.hp.com)
Date: Mon May 06 2002 - 11:15:11 PDT
Here are the ideas that have been submitted for improving OVL. We will
discuss them at our meeting on Thursday.
David
===============================================================================
1. "window" assertions - It needs to be clarified what is exactly meant
by a "window" in the three window assertions, assert_window,
assert_win_unchange, and assert_win_change. The win_unchange and
win_change assertions continue checking the test expression through the
last cycle of the check, while the assert_window stops checking
immediately upon hitting the end_event condition. I think the best
solution to this inconsistency is to add a parameter to these assertions
that lets the user select if the assertion should check the test
expression during the last cycle. Setting the parameter to a 0 would not
check on the last cycle, while settting it a 1 would check the last
cycle.
2. assert_transition modification - Chris Raehl, simulation user of the
assert_transition, modified the assertion to work in a more intuative
fashion. The modified assertion is attached. Here is his description of
why the change was needed:
Basically, if I move from state A to state B on a clock edge, the new
assertion compares the second state to the next_state from the clock
before the edge, and the old one compares it to the next_state of the
clock after the edge. Since the states are latched, the new way makes
more sense, because it was the value of signals BEFORE the edge that
determined the state we're in now, not the value of the signals now that
we're in the new state.
This simple case is "I am in state A. If signal Y gets pulsed for one
clock, I will move to state B, and if signal Z gets pulsed for one
clock, I will move to state C." The problem is that once the assertion
sees that you're not in state A anymore, the data it is looking at to
decide if you're in the right state is a clock old.
I think the new assertion is the way that assert_transition is currently
documented, and the old assertion is broken according to the
documentation. Looking at the example in the docs, it is perfectly
possible to make the assertion fail if on one clock count == 4'd9 and
sel_09 == 1'b1, but on the next clock count == 4'd0 and sel_09 has gone
back to 1'b0. The old assertion implies that sel_09 has to be held high
an additional clock while the logic does not.
3. assert_handshake limitations - assert_handshake seems like a very
useful assertion at first glance. But when you actually do try to use
it, it seems a bit too specific to be useful in a lot of situations.
There are a lot of parameters to configure the assertion to check for
different situations, but the requirement that there must be only one
outstanding req before an ack comes become limiting for many pipelined
handshaking buses. Pretty much all handshaking buses that I've seen
have the ability to handle multiple in-flight messages at the same time.
Because of this, assert_handshake cannot be used because of it's
serial nature. The first transaction must complete before a new
transaction must start. This topic also spills over into the next topic
that I'll discuss.
4. "pipelined" assertions - One of the few things I've picked out from
Adam Krolink's discussions on future assertion languages is the concept
of "pipelined" assertions. This is where assertions have the ability to
overlap without the use of some external logic. So there would be only
one implementation of an assertion, but there might be several
outstanding instances of this one assertion tracking different
occurences. This ties in with the assert_handshake, in which there are
multiple outstanding reqs that correspond to different transactions. If
there are 3 un-answered reqs, there are three "instances" of the same
assertion. The first ack that is received will close off the first
instance of the assertion, and so on. This may be a more difficult
addition to the OVL, and we may have to wait for a future assertion
language before we see this type of check.
5. assertion that contains state - These might fall into the realm of a
protocol type checker, and might also be beyond the bounds of what the
OVL is intended to be. I've written some small assertions that keep
some sort of value within the assertion that can be checked against at a
later time. The basic idea is that when a start_event occurs a given
value is captured. Than when an end_event occurs at a later time,
another value is checked against the stored value. If these values
match then the assertion passes, but if the values do not match, the
assertion fires. I've just recently implementated the assertion and
started using it. So I'm not absolutely sure if this is the correct
implementation of my idea or if it is truely useful in the situations
that I had intended. I've attached the files to this email.
This archive was generated by hypermail 2b28 : Mon May 06 2002 - 11:16:21 PDT