How about having it depend on the context of the function definition? Functions defined inside modules, interfaces, and packages (i.e., design contexts) have the more restrictive requirements, while those in programs and package anonymous program blocks (i.e., testbench contexts) are less restrictive - allow fork/join_none, nonblocking assign, inta-assignment delays, even triggering, anything else that doesn't block. --Mike Burns Bresticker, Shalom wrote: > I don't know about 'context', but as for 'pure', it might be better to > have 'pure' be a default, as you would have to write 'impure' if you > wanted to write risky or non-synthesizable code. > > Shalom > > >>-----Original Message----- >>From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org] > > On > >>Behalf Of Brad Pierce >>Sent: Thursday, April 27, 2006 7:32 AM >>To: sv-ec@server.eda.org; sv-bc@server.eda.org >>Subject: [sv-bc] Re: [sv-ec] No event triggers in functions? >> >>Another possibility would be to enhance function and task declarations >>with the 'context' and 'pure' keywords of 26.4.2 and 26.4.3. >> >> >>>Relaxing the restrictions on side-effects is less of a problem. I >>>don't know how valuable their protection is to designers. If they >>>are seen as too valuable to give up, I suppose one compromise would >>>be to remove the restrictions only on class method functions. >> >>-- Brad > >Received on Mon May 1 08:11:10 2006
This archive was generated by hypermail 2.1.8 : Mon May 01 2006 - 08:11:33 PDT