RE: [sv-bc] Re: [sv-ec] No event triggers in functions?

Historically, I think at least one of the reasons nonblocking
assignments were forbidden was to protect the users.

First of all, Verilog lint tools are a relatively recent development.
For a long time, there were no tools to detect dangerous or erroneous
code styles.

A problem with a nonblocking assignment is that if you do an NBA to the
function return value, it won't be returned to the expression which
called the function. This is because the assignment is non-blocking and
the function executes in zero time, so the function returns immediately
with the value of the function variable before the nonblocking
assignment finishes execution. The value is updated only afterwards.

This can happen in a testbench context as well as in a design context.
It can be very difficult to debug. I actually encountered such a case
once.

Now lint tools could warn of this. But that would still not help for
nonsynthesizable or verification code, where lint tools are not run.

Shalom

> -----Original Message-----
> From: Michael Burns [mailto:michael.burns@freescale.com]
> Sent: Tuesday, May 02, 2006 7:31 PM
> To: Bresticker, Shalom
> Cc: Arturo Salz; sv-ec@eda.org; sv-bc@eda.org
> Subject: Re: [sv-bc] Re: [sv-ec] No event triggers in functions?
> 
> 
> Hi folks,
> 
> The fork/join_none is a different class of issue - it's clearly more
> problematic, and less important to me. The others (nonblocking assign,
> intra-assignment delay, event triggers - dont' forget nonblocking
event
> triggers) are pretty straightforward. If we're concerned about
> synthesizability, that's a whole new discussion. Event triggers are
> already not synthesizable (at least according to 1364.1).
> 
> I personally agree with Arturo - I don't see the need for the
> restrictions I mentioned; I just thought they might make it more
> palatable to those who are concerned about side effects of functions
on
> scheduling for design.
> 
> -Mike