RE: [sv-ec]E-mail Vote: Closed October 10th 2007

From: Steven Sharp <sharp_at_.....>
Date: Sun Oct 14 2007 - 09:15:10 PDT
>The problem with the simpler restriction is that a fork/join block is
>now legal in any function as long as it contains no blocking statements.
>This was probably an oversight when the BNF was changed from 1364-2001
>to 1364-2005, but it's there now.

Okay, that is indeed a problem.  Perhaps this should be changed back.
I don't see any reason for allowing fork/join in functions.  Without
any blocking statements it is useless, and can be replaced with a
begin/end.

The existing proposal still has the problem that it only allows for
forks that are direct children of inital/always, not deeper descendents.
I suppose it could be reworded in a recursive way, something like
"or fork block from a thread from which it would be allowed".


>> -----Original Message-----
>> From: owner-sv-ec@server.eda.org [mailto:owner-sv-ec@server.eda.org]
>On
>> Behalf Of Steven Sharp
>> Sent: Friday, October 12, 2007 8:05 PM
>> To: sv-ec@server.eda.org; Mehdi.Mohtashemi@synopsys.com
>> Subject: RE: [sv-ec]E-mail Vote: Closed October 10th 2007
>> 
>> Another minor issue with 1336:
>> 
>> The wording says "initial procedure, always procedure, or fork block
>> from one of those procedures".
>> 
>> There is no need to try to restrict where the fork block came from.
>> The other places that this is presumably trying to disallow already
>> cannot fork, so the restriction is not needed.  If you cannot execute
>> a fork block from them, then you don't have to disallow a fork block
>> that came from them.  All fork blocks come from places where it was
>okay.
>> All the restriction accomplishes is to disallow it for fork blocks
>that
>> came from fork blocks that came from initial/always procedures (i.e.
>> "originated in" an initial/always procedure), which should be legal.
>> 
>> The simpler "initial procedure, always procedure, or fork block"
>should
>> provide the desired restriction, without the unnecessary one.
>> 
>> Steven Sharp
>> sharp@cadence.com
>> 
>> 
>> --
>> This message has been scanned for viruses and
>> dangerous content by MailScanner, and is
>> believed to be clean.
>

Steven Sharp
sharp@cadence.com


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Sun Oct 14 09:15:27 2007

This archive was generated by hypermail 2.1.8 : Sun Oct 14 2007 - 09:15:51 PDT