Subject: [sv-bc] Semantics of cont assign to variable suggestion
From: Jay Lawrence (lawrence@cadence.com)
Date: Fri Jan 24 2003 - 09:38:15 PST
(My apologies to those of you who are getting this twice, I earlier sent
it to sv-ec).
In Wednesday's meeting we made great progress on this discussion.
In the meeting, I was trying to find a syntactic expansion of the
behavior so that the semantics would be clear from existing Verilog
rules, and implementation would not need to be a "special case" the
developer and user would need to understand.
The mapping I was trying to do was
reg r;
r <= a & b & c;
Would become
always @(*)
r = a & b & c;
Peter pointed out that this is not correct in the case where there is
feedback
r <= (a & b & c) | r;
In this case the above always block would not retrigger due to the
sequential nature of the equivalent always block. So we added a semantic
caveat that said if the lhs did change and was on the rhs it would
trigger again. This special case made me nervous but made sense.
In thinking about it more on my way home, I came up with the different
mapping:
always @(*)
r <= (a & b & c) | r;
Note I've used the non-blocking assignment operator instead of the
blocking assignment.
With this modification, the special scheduling caveat is not needed. The
process will make the non-blocking assignment and arrive back at the
sensitivity. When the non-blocking assignment happens it will trigger
the process if there is feedback. No special caveat for sensitivity is
required! Voila! And we've used the "safer" non-blocking assignment
minimizing races.
We still need to have the special "release" semantics that this process
is triggered when there is a release.
Comments?
Jay
===================================
Jay Lawrence
Architect - Functional Verification
Cadence Design Systems, Inc.
(978) 262-6294
lawrence@cadence.com
===================================
This archive was generated by hypermail 2b28 : Fri Jan 24 2003 - 09:38:42 PST