Seligman, Erik wrote: > Don't forget that we may see this code in a module that has default > clocking defined-- so in that case, I think Adam's code would be fine. Just to clarify 16.14.5, does that mean that the rules for concurrent assertions in procedural code should include a rule of the form: If there is no clocking event in the event list of the procedural block then the default clocking must match the clocking of the assertion. I didn't see a rule of that form which is why I am now confused. It certainly seems that the existing text does not allow Adam's example. For "initial" processes, the clocking rule is defined (kind of) but in that case, do we also have an implied rule that the default clocking must match the assertion? I was assuming "no" and that the assertion clock is the only one that matters in the context of an initial procedure. Is my assumption there correct? This does have a substantial bearing on whether dealing with the complexity of deferral is needed. It is definitely much more complex to define deferral in this context than in the simpler context of a zero-time glitch. This would really need to be able to describe non-zero time "clock period" glitching and the impact of that on assertion state and which assertions are "killed". In the deferred assertion context this was relatively simple to describe since it was "all or nothing". Here, I think it is much more touchy since there may be already evaluating instances of the assertion at later steps that we can't kill; it is only the "pending" ones. As Steven just noted (beat me to the "send"), my assumption about all of this was that concurrent assertions in procedural code were not intended to be used in combinational scenarios. I think this needs to be clarified asap. Gord. > (Not to mention the fact that with the new procedural triggering method, > we may want to relax the requirement that concurrent asserts need a > triggering clock.) So I think he's right, we need to think about this > situation. > > In our verbal discussions last week, I believe we briefly suggested > treating concurrent asserts in multiply-trigggered procedures like the > new deferred assertions (see proposal 2005): if the same procedure is > triggered again in the same time step, it flushes any current > triggerings of assertions in that procedure. > > > -----Original Message----- > From: owner-sv-sc@server.eda.org [mailto:owner-sv-sc@server.eda.org] On > Behalf Of Gordon Vreugdenhil > Sent: Monday, May 05, 2008 1:18 PM > To: Adam Krolnik > Cc: sv-sc@server.eda.org; sv-ac@server.eda.org > Subject: Re: [sv-sc] Re: ConcurrentAssertNewProposal > > Adam, > > Is this actually legal code as is? I thought that the clock inference > rules of 16.14.5 (P1800 Draft 5) would make this illegal since there is > no "clock" event control on the always block. > > Gord. > > > > Adam Krolnik wrote: >> Good morning; >> >> As part of this discussion, don't forget assertions in combinatorial >> procedural logic. E.g. >> >> property r3; >> @(posedge mclk)(q != d); >> endproperty >> >> always @(*) >> begin >> if (a) >> begin >> d2 = d1; >> assert property (r3); >> ... >> end >> end >> >> Since the process above may run more than once, the assertion may need > >> to be stopped due to the presence of new values that cause it to no > longer be triggered. >> >> >> Thanks. >> >> -- >> Soli Deo Gloria >> Adam Krolnik >> Director of Design Verification >> VeriSilicon Inc. >> Plano TX. 75074 >> Co-author "Assertion-Based Design", "Creating Assertion-Based IP" >> >> >> -- >> This message has been scanned for viruses and dangerous content by >> *MailScanner* <http://www.mailscanner.info/>, and is believed to be >> clean. > > -- > -------------------------------------------------------------------- > Gordon Vreugdenhil 503-685-0808 > Model Technology (Mentor Graphics) gordonv@model.com > > -- -------------------------------------------------------------------- Gordon Vreugdenhil 503-685-0808 Model Technology (Mentor Graphics) gordonv@model.com -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Mon May 5 14:09:23 2008
This archive was generated by hypermail 2.1.8 : Mon May 05 2008 - 14:09:49 PDT