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

From: Rich, Dave <Dave_Rich_at_.....>
Date: Fri Oct 12 2007 - 22:58:38 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.

Dave



> -----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.


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Fri Oct 12 22:59:01 2007

This archive was generated by hypermail 2.1.8 : Fri Oct 12 2007 - 22:59:11 PDT