>From: Gordon Vreugdenhil <gordonv@model.com> >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. It is interesting that you chose the example of $signed. In 20.4 of IEEE Std 1364-2005, it says that a user-provided application with the same name as a built-in system task/function overrides the built-in system task/function. Two paragraphs later it explicitly states that $signed and $unsigned can be overridden. It goes on to point out that there is no way to match their behavior of having a return width based on the width of the argument. But that clearly does not change the fact that they can be overridden. There are other cases where user-provided implementations cannot match behavior that is allowed for built-in system tasks/functions. For example, the built-in math and conversion functions can be used in constant expressions, while user-defined system functions cannot. The same is true of some SV system functions, such as $bits. But I am not aware of anything in either LRM that says that you cannot still override them. It would just be an error if the overridden version were used in a constant expression. Implementations may be making special restrictions in some of these situations, but I believe that this is not compliant with the LRM. >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. Unless they are defined to be something distinct from a systf (like the timing checks), or the LRM explicitly specifies that certain systfs cannot be overridden, I would maintain that they can be overridden. 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 Tue Mar 18 15:17:26 2008
This archive was generated by hypermail 2.1.8 : Tue Mar 18 2008 - 15:17:50 PDT