Subject: Re: [sv-bc] Semantics of cont assign to variable suggestion
From: Dave Rich (David.Rich@synopsys.com)
Date: Fri Jan 24 2003 - 10:04:10 PST
Jay,
NBAs should not be used to model combinational logic. Clock gating logic
should not have any NBAs in their path. Having NBAs in a chain of
combinational logic will not be very efficient.
Also, you are mixing VHDL syntax here
reg r;
r <= a & b & c; in VHDL
is
assign r = a & b & c; in Verilog
This is one of those things that you can't map directly to Verilog-2001
syntax.
If you really want to put this in terms of Verilog semantics you could
say that this is the same as if "r" was a wire, except that 'r' can only
hold the value its type will allow.
Jay Lawrence wrote:
>(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
>===================================
>
>
>
>
-- -- Dave Rich Principal Engineer, CAE, VTG Tel: 650-584-4026 Cell: 510-589-2625 DaveR@Synopsys.com
This archive was generated by hypermail 2b28 : Fri Jan 24 2003 - 10:05:04 PST