[sv-bc] 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.

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>, sv-ec@eda.org, 
sv-bc@eda.org
Date: Thursday, February 28, 2008 7:51:02 PM
> An intra-assignment delay in a nonblocking assignment does not block.
>  
> Shalom
>
>     ------------------------------------------------------------------------
>     *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:16 PM
>     *To:* sv-ec@server.eda.org; sv-bc@server.eda.org
>     *Subject:* [sv-ec] always_comb LRM e.g. wrong?
>
>     Hi,
>     In SV 1800-2005 LRM page 146 there is an e.g.:
>     *always_comb
>     d <= #1ns b & c;
>     *
>     Also it is mentioned there:
>     *Statements in an always_comb shall not include those that block,
>     have blocking timing or event controls, or fork...join statements.
>
>     *With that context, the e.g. is wrong as a blocking timing control
>     is present. SV 1800-2008 draft4 version removes that restriction.
>     Is it purposefully done?
>
>     -- 
>     Regards
>     Surya
>         
>
>
>     -- 
>     This message has been scanned for viruses and
>     dangerous content by *MailScanner* <http://www.mailscanner.info/>,
>     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.