RE: [sv-ac] RE: AC 296

 
> >I thought that we agreed that triggered would not be allowed
> in sequences.
> What is the rationale for that? It seems that triggered is,
> as discussed, smae as ended except for persistence.
> Actually, IMHO, the LRM could have merged the two into the
> triggered only.

That I agree - perhaps it should have been one thing. But I am under the
impression that ended cannot be removed now.
I also believe that the rationale for the two differences was that ended is
valid only at the clock tick time step and not anywhere else as used in
sequences (like endpoint in PSL), and triggered transforms sequence into a
persistemnt event (boolean), like any other event e.triggered This is usable
at any time, but would be false except in the reactive and following
region(s) in the time step of the clock tick if the sequence ended in that
time step. I.e., it could not be read anymore by the sequences.
 But this is mmy interpretation of why it is as it is and I was not on the
original committee.

It would seem to me that to resolve the duality cleanly, it might be simpler
to allow ended only in sequences (with $past or other clocked system tasks)
and triggered outside sequences but include disable iff as it is
"asynchronous".
This is why I proposed the separation.
At least it is easier to remember - use triggered wherever event can be used
with triggered, and use ended in sequences. So there I go again... :-)

ed

>
> >But then neither would $past on it.
> Since I am not a developer, I do not fully understand the
> implementation intricacies. But tapping from my VHDL
> knowledge on implicit signals, if a
> sequence_instance.triggered is treated as an implicit signal
> (or variable), then you can do a $past on it. The $past of a
> past endpoint is very useful.
>
> >But I do not see why not to use $past(qT.ended) in a
> sequence instead.
> There we go again! If an ended endpoint has visibility in
> the Observe region only, how can you have observability in
> the $past of this ended enpoint? It would seem more logical
> that the triggered is more meaningful for $past (e.g.,
> $past(qT.triggered) than $past(qT.ended).
>
>
> >Also, the sequences to which ended is applied must have a clock.
> Can the clock come fromt the property where the ended or
> triggered is used?
>
> Ben Cohen
> >
> >Ed
> >
> >
> >> -----Original Message-----
> >> From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On
> Behalf Of
> >> VhdlCohen@aol.com
> >> Sent: Friday, November 12, 2004 1:39 PM
> >> To: Adam Krolnik; "Kulshrestha, Manisha"
> >> Cc: sv-ac@eda.org
> >> Subject: Re: [sv-ac] RE: AC 296
> >>
> >> I would like to add the following is also legal:
> >> That was not clear in the LRM.
> >> $past(sequence_instance.triggered)
> >> For example, ALL LEGAL:
> >> // sequence a then b
> >> sequence qT; a ##1 b; endsequence : qT
> >>
> >> // sequence a then b then don't care sequence qTended; a
> ##1 b ##1
> >> `true; endsequence : qTended
> >>
> >> // property example:
> >> property P1; @ (posedge clk) k |-> $past(qT.triggered);
> endproperty
> >> : P1 property P2; @ (posedge clk) k |-> qTended.ended;
> endproperty
> >> : P2
> >>
> >> Ben Cohen
> >>
> >>
> >> In a message dated 11/12/2004 12:17:22 PM Eastern Standard
> Time, Adam
> >> Krolnik <krolnik@lsil.com> writes:
> >>
> >> >
> >> >
> >> >Good morning all;
> >> >
> >> >It may be best to provide a table listing the legal contexts
> >> for each
> >> >of the methods in question (.ended, .matched, .triggered)
> >> and any others if necessary.
> >> >
> >> >There is a fine line between .ended and .triggered and users will
> >> >appreciate a summary of the legal contextx for each.
> >> >
> >> >contexts include:
> >> >
> >> > wait / @()
> >> > sequences/properties
> >> > disable
> >> > argument to sequence/property
> >> > local variable rhs
> >> >
> >> >
> >> >others?
> >> >
> >> >
> >> >
> >> > Adam Krolnik
> >> > Verification Mgr.
> >> > LSI Logic Corp.
> >> > Plano TX. 75074
> >> > Co-author "Assertion-Based Design"
> >> >
> >> --------------------------------------------------------------
> >> ---------------
>
>
> --
> --------------------------------------------------------------
> ---------------
> Ben Cohen Trainer, Consultant, Publisher (310) 721-4830
> http://www.vhdlcohen.com/ vhdlcohen@aol.com Author of
> following textbooks:
> * Using PSL/SUGAR for Formal and Dynamic Verification 2nd
> Edition, 2004 isbn 0-9705394-6-0
> * Real Chip Design and Verification Using Verilog and VHDL,
> 2002 isbn 0-9705394-2-8
> * Component Design by Example ", 2001 isbn 0-9705394-0-1
> * VHDL Coding Styles and Methodologies, 2nd Edition, 1999
> isbn 0-7923-8474-1
> * VHDL Answers to Frequently Asked Questions, 2nd Edition,
> isbn 0-7923-8115
> --------------------------------------------------------------
> ----------------
>
Received on Sat Nov 13 08:40:20 2004