>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