>From: "Eduard Cerny" <Eduard.Cerny@synopsys.com> >[Ed:] >1800-2005 already introduced many new keywords which are also >potentially common words: cross, design, protected, priority, etc. Yet, >people got used to it and managed to work around the problem. People were very unhappy about it (at least our customers were). They expected to be able to compile their legacy Verilog designs under SV without any problems, since it was touted as "backward compatible". Yes, they managed to work around it, but that does not mean that we should make them do it again when it is easily avoided. This same issue was raised with 1800-2005 because of some of the keywords that you mention. There was considerable debate over it. Ultimately, the fact that there was legacy SV code based on the Accellera SV standard overrode the issue with legacy Verilog code. But we are now talking about new language extensions, so that argument does not apply. For new keywords, we can choose ones that are less likely to conflict with legacy code. This is a situation where we can learn from past experience. >>[Stu:] >>Is it appropriate to us a system >function >> for this functionality? I don't have an answer...I just to make sure >the >> usage of $-type names is appropriate. >[Ed:] >These are treated as system functions and are interpreted at compilation >/ elaboration time. There is already precedent, e.g., $bits. AT one >point there was a discussion whether new keywords should be introduced >instead (or find existing ones that would fit the purpose). However, it >was judged that system functions are a better choice. You do need to recognize that the use of system functions allows the possibility for users to override them via PLI, with whatever definition they want. That is one of the properties of system functions. If you don't want this to be possible, then you should not use a system function. 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 14:22:02 2008
This archive was generated by hypermail 2.1.8 : Tue Mar 18 2008 - 14:24:35 PDT