Re: [sv-bc] Verilog Std Ambiguity

Hi Shalom.

I'm on the ba reflector now, so there isn't any need to
address Emails to me individually.

The rule for single-bit delays specifies only 1->0 and 0->1 as
fall and rise, respectively.   The final state criterion
is used only functionally, to determine posedge or
negedge, or generic change, in an event control expression.

Changes to and from z and x have to take into account delay
pessimism or a third value in the delay assignment.

Thus, assign #( 1, 2 ) Wire = Reg;, should result in a delay of
1 only when Wire goes from 0 to 1.  If Wire goes from x or z to 1,
the pessimistic delay of 2 should be used, not the final-state delay
of 1.

I think the Std should apply this, somehow, to vector delays, too.
I don't see why the default of delay pessimism should be abandoned
for vector delays.


Bresticker, Shalom wrote:
> I found the historical references to this issue that I remembered seeing.
> Surprisingly, web pages for both are still available.
> 
> DISCLAIMER: These may well not reflect current tool behavior.
> 
> 1. There was an old company called Verifarm that had a simulator called Vcomp. They posted a table on language compatibility issues, apparently around 2000-2001. It can still be found at http://vcomp.sourceforge.net/doc-vcomp-6.shtml. The relevant part is this:
> 
> "ANSI doesn't specify which delay (rising/falling/etc) to use for a net that changes strength, but not value, nor does it specify which delay to use for a multibit net that changes from say 10 to 01" (presumably the reference is to IEEE Std 1364-1995)
> 
> Cadence Verilog (presumably Verilog-XL): "wires in scalared nets are treated as independent wires vectored nets seem to get delays that are the minimum of the applicable bits, it doesn't seem to scalar assign delays"
> 
> VCS: "vector and scalar nets seem to be treated the same and a net going to a 0 value is a 0-delay time and all going non-0 is a 1-delay time"
> 
> 
> 2. There is a Synopsys VCS Solvnet note from 9/9/2002 (https://solvnet.synopsys.com/retrieve/print/002489.html):
> 
> Question:
> 
> What differences can I expect between VerilogXL and VCS when I use different delay values for rising and falling edges of vectors greater than 32 bits?
> 
> Answer:
> 
> The Verilog language allows a different delay value to be used for a rising edge or a falling edge of a signal. Take the following simple example:
> 
> wire b;
> reg a;
> 
> assign #(1,0) b = ~a;
> 
> For the single bit signal b, a rising transition will occur 1 time unit after the input signal "a" changes, and a falling transition will occur 0 time units after the input signal changes. As expected, VCS and VerilogXL behave the same for the single bit signals.
> 
> However, there is no clear definition of the expected behavior if a separate rising and falling edge is specified for a multi-bit vector, due to the fact that some bits could be transitioning from 1 -> 0 and some bits from 0 -> 1.  This is not a recommended codingstyle due to the possibility of unexpected and inconsistent results.  
> 
> In cases in which vectors have different rising and falling edges and the vector size is greater than 32 bits, VCS and VerilogXL behave differently and simulation mismatches will occur.  VerilogXL will only look at the LSB of the entire vector, and base its transition delay on that bit alone.  If the LSB is a 1, VerilogXL will use the rising edge delay value.  If it is a 0, VerilogXL will use the falling edge delay value.
>   
> In contrast, VCS will break up the vector into 32-bit words, and then look at the LSB of each 32-bit word.  If any LSB of the 32-bit words is a 1, the rising edge delay value will be used. The falling edge delay value will be used only if ALL LSBs of the 32-bit words are 0.
> 
> Note that in both VerilogXL and VCS, the final value of the LSB is  used to determine rising or falling edge delay values -- not the transition of the LSB.  In other words, if the LSB was a 1 before and after the vector changed values, the rising edge delay value is used even though the LSB did not transition from 0 -> 1."
> 
> 
> Regards,
> Shalom
> ---------------------------------------------------------------------
> Intel Israel (74) Limited
> 
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
> 
> 

-- 
      John Michael Williams
      Senior Adjunct Faculty
Silicon Valley Technical Institute

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.