Re: [sv-ac] RE: Call to vote: Due September 26 (resend with the correct Mantis number)

Hi, Erik & Dimitry -

First - Dimitry's question about Makefiles - if I understand correctly,
you are correct that adding embedded and "deferred" (??) assertions
(assuming both are in the RTL code) would cause a synthesis Makefile to
needlessly re-trigger. Harry Foster and I have now been recommending the
placement of concurrent assertions in a separate bind-file. Assertions
can be added and modified in the separate bind-file as often as
necessary without touching the RTL source code; hence, a synthesis
Makefile would only have dependencies on the RTL source files and not
the assertion bind files. It has proven to be a popular recommendation
among design engineers who have seen the recommendation.

Erik - apologies but since I have not been included in the reflector
discussion, could you tell me why an engineer would want to place a
concurrent assertion into an always_comb block like this? Is it just to
get the assertion close to the RTL code? (I am guessing that the example
below is contrived since I see no reason to place this concurrent
assertion into this combinational block)

I understand that the users have been given rope, but it may be time to
take some of that rope back or make the rope so odious that nobody will
want to touch the rope(?) I am trying to figure out where this would be
a recommended assertion coding style. Does somebody have a realistic
example of this type of assertion that they could share? One that would
convince me to vote in favor of this Mantis item (if I had a vote)

If this is going to be an accepted style, I like Stu's idea that the
placement of the assertion in the procedural block merely inherits some
important conditions, signals or edges and in reality spins itself off
as a separate concurrent assertion, leaving the always_comb sensitivity
unchanged.

Regards - Cliff

On 9/26/2011 8:59 AM, Seligman, Erik wrote:
>
> Let me clarify why I was pushing for the concurrent assertion
> variables and clocks to contribute to the sensitivity of always_comb
> blocks.
>
> My biggest fear, as someone 'in the trenches' helping designers to use
> assertions in code (yes, Cliff/Stu, I consider myself as real as you
> guys in some sense J), is the *false positive*: the case where a
> designer thinks he has added a check for some error condition, but it
> is not being checked. Such situations tend to result in expensive
> bugs found much later.
>
> Let's look at this case:
>
> always_comb begin
>
> a = b;
>
> a1: assert property (@(posedge clk) (c==d));
>
> end
>
> If we don't have concurrent assertion variables (clk, c, and d)
> trigger their always block, and the design has an error in which
> (c==d) becomes false, it may never be reported, even though the author
> thinks he is checking for it.
>
> What are the downsides to having clk, c, and d contribute to the
> sensitivity list above? If I have been following this thread
> correctly, the main ones are:
>
> - Methodology: arguably a1 would be better placed elsewhere. But for
> reasons debated in the last PAR, general concurrent asserts are legal
> in always blocks. The language gives the users enough rope, and they
> will hang themselves with it.
>
> - Simulation correctness: As explained earlier in the thread, extra
> triggers of an always_comb block should not change the values, so I
> don't think this is a real danger. (Unless assertion action blocks
> mess with simulation variables, in which case all bets are off anyway.)
>
> - Performance: There may be a performance penalty, but performance
> hotspots can be debugged. I would much rather have a performance risk
> than a false-positive risk.
>
> *From:* Korchemny, Dmitry
> *Sent:* Sunday, September 25, 2011 12:23 PM
> *To:* Clifford E. Cummings; Stuart Sutherland
> *Cc:* 'Samik Sengupta'; Seligman, Erik; sv-ac@eda-stds.org;
> mills@lcdm-eng.com
> *Subject:* RE: [sv-ac] RE: Call to vote: Due September 26 (resend with
> the correct Mantis number)
>
> Hi Cliff,
>
> I agree with your point. Note, however, that it is possible to limit
> performance degradation because of inclusion of a clock into the
> sensitivity list as I suggested in my previous mail.
>
> As for the assertion writing methodologies is concerned, they may be
> different. For example, we do embed concurrent assertions into RTL.
> Also, I don't see a difference for Makefiles between embedding
> concurrent and deferred assertions.
>
> Thanks,
>
> Dmitry
>
> *From:* owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] *On Behalf Of
> *Clifford E. Cummings
> *Sent:* Saturday, September 24, 2011 03:36
> *To:* Stuart Sutherland
> *Cc:* 'Samik Sengupta'; Seligman, Erik; sv-ac@eda-stds.org;
> mills@lcdm-eng.com
> *Subject:* Re: [sv-ac] RE: Call to vote: Due September 26 (resend with
> the correct Mantis number)
>
> Hi, All -
>
> Per Stu's comment, I am not completely up on the discussion, but I do
> have concerns.
>
> In general, adding extra unrelated (in an RTL sense) signals to a
> sensitivity list would not affect the output value. Re-triggering
> combinational logic additional times should still resolve to the
> correct combinational outputs. Similarly, re-triggering latch-based
> logic would either pass the combinational value through to the output
> during transparent mode, and not impact the output during latching
> mode. We have always encouraged engineers to avoid extra sensitivity
> list signals mostly for simulation performance reasons because extra
> triggers translates into re-evaluation of the expressions within the
> logic blocks. Unsuspecting engineers could cause significant
> performance degradation by adding multiple assertion-tested signals to
> the sensitivity list.
>
> I don't know what is legal or not, but my greater concern is if an
> assertion action block is allowed to make assignments to the
> always_comb and always_latch outputs. That would certainly be
> dangerous and could cause outputs to be wrong and mismatch the
> synthesized logic. Under those circumstances, non-input signals
> changing could cause the assertion to assign an invalid output value
> that would not be fixed until the next RTL input changes.
>
> As an interesting side-note, Harry Foster and I have been strongly
> recommending the placement of concurrent assertions into bind files as
> opposed to putting them in the RTL code itself (which is a deviation
> from Harry's recommendations in his Assertion Based Design book). The
> reason is that RTL synthesis is often controlled by Makefiles, and
> every time a new assertion is added to the RTL code, the file
> time-stamp changes and could cause engineers to re-synthesize designs
> that in reality have not changed. Keeping the separate bind file
> allows engineers to add all the assertions they want without fear of
> triggering a synthesis Makefile run.
>
> Regards - Exiled SV Committee Member - Cliff
>
> On 9/23/2011 2:26 PM, Stuart Sutherland wrote:
>
> In my opinion, even adding the condition(s) of an immediate assertion
> to the always_comb (or always_latch) sensistivity list is a BAD IDEA!
> It will force engineers to go back to the old days of having to deal
> with simulation and synthesis seeing very different things in the same
> block of code, and will lead to mismatches in RTL simulation and
> synthesized hardware. It is nasty, dangerous, and can risk expensive
> re-spins of a chip. Don't mess with the rules of inferred sensivity!!!!
>
> I would much rather see a rule in the standard that any type of
> assertion in always_comb and always_latch does not affect the inferred
> sensitivity list in any way. A cautionary note would be appropriate
> that if the immediate assertion reads an expression that are not read
> elsewhere in the procedure, the immediate assertion will not be
> evaluated when that expression changes value.
>
> Again, I am copying Cliff and Don, in case fellow real designers think
> I am off base.
>
> Stu
>
>
>
> --
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean.
>

-- 
Cliff Cummings - Sunburst Design, Inc. 14355 SW Allen Blvd., Suite #100, 
Beaverton, OR 97005 Phone: 503-641-8446 / FAX: 503-641-8486 
cliffc@sunburst-design.com / www.sunburst-design.com World Class 
Verilog, SystemVerilog & OVM/UVM Training
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.