RE: [sv-bc] Mantis 3231 proposal

Actually, 13.4.4 says that "fork-join constructs shall be allowed inside a function." It gives no exceptions to this. There are restrictions on what processes can call such a function, but that is not a restriction on the function declaration itself.

________________________________
From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of Rich, Dave
Sent: Monday, October 25, 2010 6:00 PM
To: Alsop, Thomas R; Jonathan Bromley
Cc: sv-bc@eda.org
Subject: 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
[cid:341364901@27102010-1B22]<http://www.twitter.com/dave_59> [cid:341364901@27102010-1B29] <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<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.