RE: [sv-bc] Re: [sv-ec] always_comb LRM e.g. wrong?

True, but still irrelevant.
What matters is what the LRM says.
It's also true that examples are not normative and also that the LRM
does contain mistakes, but an example of an intra-assignment delay in an
NBA is not one of them.
That's why it is called a *nonblocking* assignment.

Shalom 

> -----Original Message-----
> From: owner-sv-bc@server.eda.org 
> [mailto:owner-sv-bc@server.eda.org] On Behalf Of Surya Pratik Saha
> Sent: Thursday, February 28, 2008 5:09 PM
> To: Bresticker, Shalom
> Cc: sv-ec@server.eda.org; sv-bc@server.eda.org
> Subject: [sv-bc] Re: [sv-ec] always_comb LRM e.g. wrong?
> 
> Hi Shalom,
> NC does not flag error for the following case:
>     always_latch
>         wait (d) begin end
> 
> I think 'wait' is a blocking statement. Isn't it?
> 
> Regards
> Surya
> 
> 
> 
> -------- Original Message  --------
> Subject: Re:[sv-ec] always_comb LRM e.g. wrong?
> From: Bresticker, Shalom <shalom.bresticker@intel.com>
> To: Surya Pratik Saha <spsaha@cal.interrasystems.com>
> Cc: sv-ec@eda.org, sv-bc@eda.org
> Date: Thursday, February 28, 2008 8:25:13 PM
> > Well, if you insist:
> >
> > 1. NCV does flag it.
> > 2. It was not clear until Mantis 1468 that the same 
> restrictions apply 
> > to always_latch.
> >
> > Shalom
> >
> >   
> >> -----Original Message-----
> >> From: owner-sv-ec@server.eda.org
> >> [mailto:owner-sv-ec@server.eda.org] On Behalf Of Surya Pratik Saha
> >> Sent: Thursday, February 28, 2008 4:28 PM
> >> To: Bresticker, Shalom
> >> Cc: sv-ec@server.eda.org; sv-bc@server.eda.org
> >> Subject: Re: [sv-ec] always_comb LRM e.g. wrong?
> >>
> >> Hi Shalom,
> >> The following code snippet:
> >>     always_latch
> >>         fork
> >>         d <= #1ns b & c;
> >>         join
> >>
> >> Should be erroneous. Right? But that also passed by most of the 
> >> simulator.
> >>     
> > 
> ---------------------------------------------------------------------
> > 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.
> >
> >
> >
> >
> >
> >
> >   
> 
> 
> 
> 
> 
> --
> This message has been scanned for viruses and dangerous 
> content by MailScanner, and is believed to be clean.
> 
> 
---------------------------------------------------------------------
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.


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