RE: [sv-bc] Mantis 3231 proposal

Jonathan,

This one most definitely can be interpreted different ways, see the 13.4.4 section highlighted:

13.4.4 Background processes spawned by function calls
Functions shall execute with no delay. Thus, a process calling a function shall return immediately.
Statements that do not block shall be allowed inside a function; specifically, nonblocking assignments, event
triggers, clocking drives, and fork-join_none constructs shall be allowed inside a function.

And from 13.4:

A function shall not contain any time-controlled statements. That is, any statements containing #,
##, @, fork, wait, wait_order, or expect.

The NB assignment most certainly seems like a spawned process when it has timing control in it.

-Tom

-----Original Message-----
From: Jonathan Bromley [mailto:jonathanbromley@ymail.com]
Sent: Monday, October 25, 2010 1:12 PM
To: Alsop, Thomas R
Cc: sv-bc@eda.org
Subject: Re: [sv-bc] Mantis 3231 proposal

On 25/10/2010 18:33, Alsop, Thomas R wrote:
> I uploaded a proposal for this issue as well. Hoping we have a minute
> to review today.
>
> http://www.eda-stds.org/mantis/view.php?id=3231
>
Tom,

I didn't attend BC today so may be repeating stuff
that was discussed there, but it's interesting that I
was shot in the foot only today by a simulator that
takes too literally the wording in 1800-2009/13.4:

     A function shall not contain any time-controlled
     statements. That is, any statements containing #

The tool in question rejected this code, because
the function contains a # time-delay....

    function void assign_later(bit b);
      some_signal <= #5 b;
   endfunction

This is surely absurd, and also conflicts with 13.4.4,
but the wording of 13.4 is overly restrictive and probably
should be changed. I would like to be able to report this
as the preposterous bug it is, without getting LRM hair
splitting from the tool vendor! The point, surely, is that a
function must not contain any statement that could block
the flow of execution. "Time-controlled statement" has
no meaning defined in the LRM and is quite unhelpful.
Intra-assignment delays of any kind in a nonblocking
assignment are surely OK in a function.

Thanks

Jonathan Bromley

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