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