I think that we already have some other systf routines now (ie. $signed) that I don't think can be written by users since they have polymorphic return types. So I think that some of the systf routines are "more equal" than others and it would be unsurprising to me if implementations made restrictions in that space. Implementation restrictions in terms of interactions between "legacy" Verilog assumptions are likely inevitable to some degree. I think that part of Steven's comments relate to whether we should be considering whether a "non-overridable" systf should even *be* a systf. I agree with that sentiment but think that overturning the precendent is likely not worth the level of change. I do think that we should be very careful in trying to avoid use of systf forms for things that really cannot be written as user code. Gord Bresticker, Shalom wrote: > Hi, > >> I assume that users can define system functions with no >> arguments, and that the syntax for a call to such a system >> function would not need to have parentheses. > > The LRM implies that it is allowed. > >> If a user >> defined such a system function named $inferred_clock, then >> the syntax $inferred_clock used in an expression would refer >> to that system function, not to the special meaning in this >> proposal. That seems like a problem. > > I don't think so. The number of user-defined system tasks and functions > is orders of magnitude less than the number of user-defined identifers. > > Shalom > --------------------------------------------------------------------- > Intel Israel (74) Limited > > This e-mail and any attachments may contain confidential material for > the sole use of the intended recipient(s). Any review or distribution > by others is strictly prohibited. If you are not the intended > recipient, please contact the sender and delete all copies. > > -- -------------------------------------------------------------------- Gordon Vreugdenhil 503-685-0808 Model Technology (Mentor Graphics) gordonv@model.com -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Fri Mar 14 01:06:47 2008
This archive was generated by hypermail 2.1.8 : Fri Mar 14 2008 - 01:07:39 PDT