RE: [sv-bc] Mantis 3231 proposal

I'm going to rescind my vote for 3231. The use of 'fork' was deliberate
to exclude all kinds of fork statements in a function . 13.4.4 makes an
explicit exception for fork/join_none with restrictions. 13.4.4 also
provides the exceptions for # in a function under the appropriate
conditions.

Dave Rich
Verification Technologist
Mentor Graphics Corporation
New Office Number: 510-354-7439

  <http://www.twitter.com/dave_59> <http://go.mentor.com/drich>

From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of
Alsop, Thomas R
Sent: Monday, October 25, 2010 2:15 PM
To: Jonathan Bromley
Cc: sv-bc@eda.org
Subject: 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 <http://www.mailscanner.info/> , and is
believed to be clean. 
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.