Subject: Re: [sv-ec] Proposals for EXT-7
From: Arturo Salz (Arturo.Salz@synopsys.com)
Date: Tue Nov 11 2003 - 11:20:03 PST
Adam,
See my comments below.
Arturo
----- Original Message -----
From: "Adam Krolnik" <krolnik@lsil.com>
To: "Arturo Salz" <Arturo.Salz@synopsys.COM>
Cc: <sv-ec@eda.org>; <sv-ac@eda.org>
Sent: Tuesday, November 11, 2003 7:53 AM
Subject: Re: [sv-ec] Proposals for EXT-7
Hi Arturo;
I have a few comments on the proposal EXT-7, reacting to sequences.
1. In your example in 8.10.1 "Sequence events", you use a sequence with a clocking
event specified. Sequences do not specify a clocking event, unless they are a
multi-clock sequence. I will check on whether this is an eratta or the desired
functionality.
If this functionality is desired, you simply need to rewrite the sequence as a
property. I presume your proposal of a sequence instance being used as an
event expression for event detection would include properties also.
This functionality existed at some point and may have been removed later.
The LRM contains numerous examples with clocked sequences. Page 160 of
of 3.1a-draft1 includes about 10 examples of clocked sequences, plus a
paragraph that explicitly discusses how unclocked sequences inherit the clock.
Pages 183 -184 include several more examples. Upon closer examination of the
BNF, it does appear that clocked sequences are not syntactically allowed, but I can
see no reason for such a restriction. I think this is definitely an errata, namely to
make the BNF consistent with the text and examples.
I think that forcing users to write a sequences as a property, when they do intend
a sequence, is unwarranted (although the semantic difference here is minimal).
The proposal for expect (in 17.15) explicitly excludes properties for two reasons:
1) Properties can already trigger an action by asserting a property that
triggers an event as part of the pass_code.
2) Properties may succeed vacuously and I believe the intent of an expect
is to wait for non-vacuous success. In this sense, the end-point of a property
may not be well defined. As currently written, the expect unblocks when the
first attempt matches. This would have to change if non-vacuous success
were to be excluded.
Would you also include a sequence/property instance with formal arguments specified?
Since sequences and properties can contain arguments that are passed to an instance
of the element, it would be good to be able to pass arguments instead of having to
declare a new specific event. E.g.
sequence abc(a, b, c);
...
endsequence
...
begin
@(abc(x, y, z)) $display("Saw the sequence using, x, y, z.");
...
Vs.
sequence my_abc;
abc(x, y, z);
endsequence
...
begin
@(my_abc) $display("Saw the sequence my_abc.");
...
The proposal does not disallow sequence arguments. The BNF construct I used is
sequence_instance, which does allow arguments.
If the proposal seems to imply otherwise then we should fix that.
3. In section 8.11, "Level-sensitive sequence controls." you introduce a new
method, "triggered". I would like to see this merged into one of the existing
methods, "ended" or "matched" ("ended" being the preferred one.) Otherwise, we
need to explain why "triggered" is different than "ended".
The "triggered" method is not new per-se; it was introduced for named events. It is
new in this context of sequences.
I have no objections to merging this triggered semantics with .ended (or perhaps
.matched), provided that it can be done cleanly and unbiguously. Surrendra explained
to me that .ended is only defined witin the context of a sequence but not outside (in the
procedural code that instantiates the some sequence) so I avoided the controversy by
re-using the event concept.
Also, I would be interested in seeing a method indicating how many started and not
terminated threads are being executed for a property/sequence. In the OVL library,
the OVA library and many of my protocol examples, one wants to start a property
once based on a starting sequence. With the ability to know how many threads of
a sequence/property have been started, one can use to directly prevent more threads
from executing. E.g. (<started> is an example name of this method.)
sequence flush_acknowledged;
<starting a flush> & flush_acknowledged.<started> == 0)
...
endsequence
The number of executing threads is important because some protocols limit the
number of starts of a transaction. By directly supporting this functionality,
it makes these properties much easier to read and create.
I have no preference on the name at this time.
This is an additional enhancement that goes beyond my original proposal.
I believe that this enhancement falls in the category of "assertion query" methods,
that is, methods that retrieve important information about a sequence or property
instance. For example, the start time associated with a successful match, the
length (duration in cycles) of the property or of a particular branch, etc... If you are
going to go down that path, I'd like to see a more generalized approach that would
be very valuable for assertion-based coverage.
4. Section 17.15 "The expect statement"
This statement appears to me to be equivalent to the procedural assertion statement.
Consider this comparison.
expect ( @(posedge clk) a ##1 b ##1 c)
else $error("Sequence of a,b,c failed.");
assert property (@(posedge clk) a ##1 b ##1 c)
else $error("Sequence of a,b,c failed.");
One difference you note is that the expect statement blocks, while the
assertion statement does not.
Yes. That is one important difference. The other difference is the match on first attempt
semantics, which a property assertion does not have. Another semantic difference is
that the sequence within the expect terminates after the success or failure, whereas a
property assertion continues to execute.
The expect statement seems best suited for program blocks as the statements
after the expect execute in the reactive region. This is okay because the program
block executes in the reactive region, so later code is not any different.
In verilog blocks, however the code does not execute in the reactive region and thus
you have a partial change of time with this statement. Included with this time change
comes a change of variable/signal values that can be confusing to the user.
Correct. This feature should be used with care, and mostly in a propgram block.
Thanks Arturo;
Adam Krolnik
Verification Mgr.
LSI Logic Corp.
Plano TX. 75074
Co-author "Assertion Based Design"
This archive was generated by hypermail 2b28 : Tue Nov 11 2003 - 11:27:49 PST