Number | 287
|
Category | enhancement
|
Synopsis | `compatibility - backward compatibility compiler directives
|
State | etfpassed
|
Class | enhancement
|
Arrival-Date | Feb 21 2003
|
Originator | Stuart Sutherland <stuart@sutherland-hdl.com>
|
Release | 2001b
|
Environment |
|
Description |
Add a set of backward compatibility compiler directives: `compatibility 1364-1995 `compatibility 1364-2001 `compatibility default `endcompatibility The 1364 standard includes some required compiler directives, and some optional, but recommended directives. I would see a compatibility modes as being an optional directive. |
Fix |
"Proposal to take 1800, 26.4 and make it 19.11 (omitting P1800-2005 version specifier), and update the cross-ref list at beginning of clause 19 to include `pragma, `begin_kewords and `end_keywords. Also remove any other references to SystemVerilog. Moved: Chas Second: Stu Approved Unanimously." |
Audit-Trail |
From: Shalom Bresticker <Shalom.Bresticker@motorola.com> To: Stuart Sutherland <stuart@sutherland-hdl.com> Cc: etf-bugs@boyd.com Subject: Re: enhancement/287: `compatibility - backward compatibility compiler directives Date: Tue, 25 Feb 2003 11:33:14 +0200 Stuart, You will have to specify the exact meaning and benefit of these directives. > Add a set of backward compatibility compiler directives: > > `compatibility 1364-1995 > `compatibility 1364-2001 > `compatibility default > `endcompatibility From: Stefen Boyd <stefen@boyd.com> To: Shalom Bresticker <Shalom.Bresticker@motorola.com> Cc: etf-bugs@boyd.com Subject: Re: enhancement/287: `compatibility - backward compatibility compiler directives Date: Tue, 25 Feb 2003 03:43:57 -0800 Shalom, I think they would have the same rules for appearing in source as the `timescale (not in a module, just outside). I'm not sure what else needs to be defined... Actually, I would want to define some standard attributes for this purpose in 1364 (1364.1 was the first to introduce standard attributes, but this would be a good place for them). I wouldn't think we'd want to let them be used everywhere, but having attributes to specify the version for modules, configs and for config_rule_statement would be pretty helpful. Tools already have to have compatibility modes... this just gives a standard way to get at them. Note that we would have to define the location of attributes in the bnf for configs. Stefen At 01:40 AM 2/25/2003 -0800, Shalom Bresticker wrote: >Precedence: bulk > >The following reply was made to PR enhancement/287; it has been noted by >GNATS. > >From: Shalom Bresticker <Shalom.Bresticker@motorola.com> >To: Stuart Sutherland <stuart@sutherland-hdl.com> >Cc: etf-bugs@boyd.com >Subject: Re: enhancement/287: `compatibility - backward compatibility >compiler > directives >Date: Tue, 25 Feb 2003 11:33:14 +0200 > > Stuart, > > You will have to specify the exact meaning and benefit of these directives. > > > > Add a set of backward compatibility compiler directives: > > > > `compatibility 1364-1995 > > `compatibility 1364-2001 > > `compatibility default > > `endcompatibility > -------------------- Stefen Boyd Boyd Technology, Inc. stefen@BoydTechInc.com (408)739-BOYD www.BoydTechInc.com (408)739-1402 (fax) From: Shalom Bresticker <Shalom.Bresticker@motorola.com> To: Stefen Boyd <stefen@boyd.com> Cc: etf-bugs@boyd.com Subject: Re: enhancement/287: `compatibility - backward compatibilitycompiler directives Date: Tue, 25 Feb 2003 13:50:21 +0200 I said that the MEANING needs to be defined, not the rules where they can appear. And the benefit is not clear to me. The code needs to pass a compiler anyway. What is the usage model? And what is "default" ? Why do you need both "default" and "end" ? Does `resetall affect it? What is the relationship between 1364-2001 and 1364-2004 (2005?)? etc. Shalom Stefen Boyd wrote: > I think they would have the same rules for appearing in > source as the `timescale (not in a module, just outside). > I'm not sure what else needs to be defined... > > Actually, I would want to define some standard attributes > for this purpose in 1364 (1364.1 was the first to introduce > standard attributes, but this would be a good place for them). > I wouldn't think we'd want to let them be used everywhere, > but having attributes to specify the version for modules, > configs and for config_rule_statement would be pretty helpful. > Tools already have to have compatibility modes... this just > gives a standard way to get at them. Note that we would have > to define the location of attributes in the bnf for configs. > > Stefen > > At 01:40 AM 2/25/2003 -0800, Shalom Bresticker wrote: > > > > > You will have to specify the exact meaning and benefit of these directives. > > > > > > > Add a set of backward compatibility compiler directives: > > > > > > `compatibility 1364-1995 > > > `compatibility 1364-2001 > > > `compatibility default > > > `endcompatibility From: Stefen Boyd <stefen@boyd.com> To: Shalom Bresticker <Shalom.Bresticker@motorola.com> Cc: etf-bugs@boyd.com Subject: Re: enhancement/287: `compatibility - backward compatibilitycompiler directives Date: Tue, 25 Feb 2003 08:13:21 -0800 Shalom, It's become increasingly clear that we broke existing designs with 1364-2001... adding any new keyword, no matter how careful, we are is going to break designs. From what I hear from vendors, they have switches that put them into a mode to accept the 95 standard or the 2001 standard. Once we add more in 2004/5, and future standards after that, we'll undoubtedly add new keywords. Users will want to use old designs as part of a new chip WITHOUT MODIFICATION. Vendors already have a solution, but it makes sense to standardize access to that for users so it works the same way across all of them. This will be REQUIRED if we want to deal with any amount of the new features added in SystemVerilog because there are so many new keywords that will break stuff... Allow the user the control to say "this is my old design" and "here's the new stuff, I want to take advantage of those cool new features." Stefen At 04:00 AM 2/25/2003 -0800, Shalom Bresticker wrote: > I said that the MEANING needs to be defined, not the rules where they > can appear. > > And the benefit is not clear to me. The code needs to pass a compiler > anyway. > What is the usage model? > > And what is "default" ? > > Why do you need both "default" and "end" ? > > Does `resetall affect it? > > What is the relationship between 1364-2001 and 1364-2004 (2005?)? -------------------- Stefen Boyd Boyd Technology, Inc. stefen@BoydTechInc.com (408)739-BOYD www.BoydTechInc.com (408)739-1402 (fax) From: Stephen Williams <steve@icarus.com> To: Stuart Sutherland <stuart@sutherland-hdl.com> Cc: etf-bugs@boyd.com Subject: Re: enhancement/287: `compatibility - backward compatibility compiler directives Date: Tue, 25 Feb 2003 09:28:39 -0800 `compatibility 1364-1995 `compatibility 1364-2001 `compatibility default `endcompatibility The problem with the somewhat similar `timescale directive is that it's file scope is not bound. This compiler directive changes the language being used, so its scope needs to be carefully controlled. In particular, it would be highly bad if a `compatibility directive in a library module leaks out into subsequent files. For example, I write a main program in 2001 Verilog, but import some modules from a vendor library that includes `compatibility directives. At the point after the library module is brought in, 2001 constructs stop working. Or just as bad, the inverse case where the vendor library uses 2001 constructs and the user code uses the `compatibility 1995 directive to get his/her legacy (er, stable) design to compile. At the very least, I suggest that a `compatibility section require a matching `endcompatibility. I also suggest they nest, and come in the same source file. Might I also suggest that the operand be a constant string? It would be counterproductive to add a new keyword to selectively disable the use of new keywords:-) -- Steve Williams "The woods are lovely, dark and deep. steve at icarus.com But I have promises to keep, steve at picturel.com and lines to code before I sleep, http://www.picturel.com And lines to code before I sleep." From: Stefen Boyd <stefen@boyd.com> To: Stephen Williams <steve@icarus.com> Cc: etf-bugs@boyd.com Subject: Re: enhancement/287: `compatibility - backward compatibility compiler directives Date: Tue, 25 Feb 2003 09:35:39 -0800 Steve, That's why I liked the idea but wanted to see it work as an attribute used on modules or in a config... That would give it scope that wouldn't have the same file order issues of a compiler directive Stefen At 09:30 AM 2/25/2003 -0800, Stephen Williams wrote: >Precedence: bulk > >The following reply was made to PR enhancement/287; it has been noted by >GNATS. > >From: Stephen Williams <steve@icarus.com> >To: Stuart Sutherland <stuart@sutherland-hdl.com> >Cc: etf-bugs@boyd.com >Subject: Re: enhancement/287: `compatibility - backward compatibility >compiler directives >Date: Tue, 25 Feb 2003 09:28:39 -0800 > > `compatibility 1364-1995 > `compatibility 1364-2001 > `compatibility default > `endcompatibility > > The problem with the somewhat similar `timescale directive is that > it's file scope is not bound. This compiler directive changes the > language being used, so its scope needs to be carefully controlled. > > In particular, it would be highly bad if a `compatibility directive > in a library module leaks out into subsequent files. For example, > I write a main program in 2001 Verilog, but import some modules > from a vendor library that includes `compatibility directives. At > the point after the library module is brought in, 2001 constructs > stop working. > > Or just as bad, the inverse case where the vendor library uses > 2001 constructs and the user code uses the `compatibility 1995 > directive to get his/her legacy (er, stable) design to compile. > > At the very least, I suggest that a `compatibility section require > a matching `endcompatibility. I also suggest they nest, and come > in the same source file. > > Might I also suggest that the operand be a constant string? It > would be counterproductive to add a new keyword to selectively > disable the use of new keywords:-) > > > -- > Steve Williams "The woods are lovely, dark and deep. > steve at icarus.com But I have promises to keep, > steve at picturel.com and lines to code before I sleep, > http://www.picturel.com And lines to code before I sleep." > > -------------------- Stefen Boyd Boyd Technology, Inc. stefen@BoydTechInc.com (408)739-BOYD www.BoydTechInc.com (408)739-1402 (fax) From: "Brad Pierce" <Brad.Pierce@synopsys.com> To: <etf-bugs@boyd.com> Cc: Subject: Re: enhancement/287: `compatibility - backward compatibility compiler directives Date: Tue, 25 Feb 2003 09:44:56 -0800 Adding new operands to compiler directives does not introduce new keywords. For example, `default_nettype none does not require that 'none' be a keyword, as discussed in http://www.boyd.com/1364_btf/report/full_pr/137.html >Might I also suggest that the operand be a constant string? It >would be counterproductive to add a new keyword to selectively >disable the use of new keywords:-) -- Brad From: Gordon Vreugdenhil <gvreugde@Synopsys.COM> To: Stefen Boyd <stefen@boyd.com> Cc: etf-bugs@boyd.com Subject: Re: enhancement/287: `compatibility - backward compatibilitycompiler directives Date: Tue, 25 Feb 2003 10:00:29 -0800 Just as a side note, not all compatibility issues can be resolved by `compatibility. As the first example that came to mind, V2K limits the number of MCDs to 30 versus 31 since the high-order bit now indicates whether the value is an MCD or FD. That is a global issue that can't be locally resolved since and MCD/FD is a value that can end up anywhere. Gord. -- ---------------------------------------------------------------------- Gord Vreugdenhil gvreugde@synopsys.com Staff Engineer, VCS (Verification Tech. Group) (503) 547-6054 Synopsys Inc., Beaverton OR From: Shalom.Bresticker@motorola.com To: Stefen Boyd <stefen@boyd.com> Cc: etf-bugs@boyd.com Subject: Re: enhancement/287: `compatibility - backward compatibilitycompiler directives Date: Tue, 25 Feb 2003 21:44:02 +0200 (IST) I have not yet heard of any cases where 1364-2001 broke existing designs. I do believe, however, that implementations of 1364-2001, particularly synthesis tools, changed how they related to 1364-1995 code as well. There is also a difference between a mode switch for a tool and a directive within the code itself. In any case, the questions I posed as to the detailed description of such directives need to be discussed because they are not trivial. Shalom On Tue, 25 Feb 2003, Stefen Boyd wrote: > It's become increasingly clear that we broke existing > designs with 1364-2001... adding any new keyword, no matter > how careful, we are is going to break designs. From what > I hear from vendors, they have switches that put them > into a mode to accept the 95 standard or the 2001 standard. > Once we add more in 2004/5, and future standards after > that, we'll undoubtedly add new keywords. Users will > want to use old designs as part of a new chip WITHOUT > MODIFICATION. Vendors already have a solution, but it > makes sense to standardize access to that for users so > it works the same way across all of them. > This will be REQUIRED if we want to deal with any amount > of the new features added in SystemVerilog because there > are so many new keywords that will break stuff... Allow > the user the control to say "this is my old design" and > "here's the new stuff, I want to take advantage of those > cool new features." > > Stefen > > At 04:00 AM 2/25/2003 -0800, Shalom Bresticker wrote: > > I said that the MEANING needs to be defined, not the rules where they > > can appear. > > > > And the benefit is not clear to me. The code needs to pass a compiler > > anyway. > > What is the usage model? > > > > And what is "default" ? > > > > Why do you need both "default" and "end" ? > > > > Does `resetall affect it? > > > > What is the relationship between 1364-2001 and 1364-2004 (2005?)? > > -------------------- > Stefen Boyd Boyd Technology, Inc. > stefen@BoydTechInc.com (408)739-BOYD > www.BoydTechInc.com (408)739-1402 (fax) > From: Gordon Vreugdenhil <gvreugde@Synopsys.COM> To: Shalom.Bresticker@motorola.com Cc: etf-bugs@boyd.com Subject: Re: enhancement/287: `compatibility - backward compatibilitycompilerdirectives Date: Tue, 25 Feb 2003 12:14:39 -0800 Shalom, we have several in-house designs from customers that broke when we enabled V2K keywords. That is one of the reasons that VCS still requires a "+v2k" flag at compile time for most V2K features. We have had internal discussions about how to manage different kinds of design source, so it is good that some of this is turning into a wider discussion. Gord. Shalom.Bresticker@motorola.com wrote: > > Precedence: bulk > > The following reply was made to PR enhancement/287; it has been noted by GNATS. > > From: Shalom.Bresticker@motorola.com > To: Stefen Boyd <stefen@boyd.com> > Cc: etf-bugs@boyd.com > Subject: Re: enhancement/287: `compatibility - backward compatibilitycompiler > directives > Date: Tue, 25 Feb 2003 21:44:02 +0200 (IST) > > I have not yet heard of any cases where 1364-2001 broke existing designs. > -- ---------------------------------------------------------------------- Gord Vreugdenhil gvreugde@synopsys.com Staff Engineer, VCS (Verification Tech. Group) (503) 547-6054 Synopsys Inc., Beaverton OR From: Shalom.Bresticker@freescale.com To: btf-bugs@boyd.com Cc: Subject: Re: enhancement/287: `compatibility - backward compatibilitycompilerdirectives Date: Thu, 10 Jun 2004 18:17:35 +0300 (IDT) Stuart has already proposed that such a directive be optional. Another issue is whether the definition of such a directive would require from the tool vendor to implement more than a simple enable or disable of keywords. If that were all that were required of the vendor, it would be relatively simple to implement. However, if "1364-2001 compatibility" would require him to disable any and all features added in later versions of the standard, that would be much harder for a vendor to implement, to the point of having to write another half-simulator, just to be compatible with an older version of the standard. That would seem to be unfairly expensive for someone writing a new tool (as opposed to someone extending an existing one). It is true that there are a few things which actually change from one version of the standard to the next, as opposed to added extensions, such as the use of bit 31 of an MCD, but those cases have been quite few and relatively unimportant. Shalom From: Steven Sharp <sharp@cadence.com> To: etf-bugs@boyd.com, Shalom.Bresticker@freescale.com Cc: Subject: Re: enhancement/287: `compatibility - backward compatibilitycompilerdirectives Date: Fri, 18 Jun 2004 14:10:18 -0400 (EDT) > However, if "1364-2001 compatibility" would require > him to disable any and all features added in later versions of the > standard, that would be much harder for a vendor to implement, In fact, if the earlier versions of the standard are not readily available, this is a bigger issue than just implementation effort. I believe that if this directive is added to the standard, that the behavior required to be compliant needs to be fully specified in the standard also. I don't believe that referring to an earlier obsoleted version of the standard is a valid specification. Trying to specify everything that has changed from all previous versions of the standard is impractical. Restricting it to something smaller, such as just keywords, or just the things that are not backward-compatible, would make both specification and implementation much simpler. > It is true that there are a few things which actually change from one > version of the standard to the next, as opposed to added extensions, > such as the use of bit 31 of an MCD, but those cases have been quite few > and relatively unimportant. The change in x/z-extension behavior for unsized literals is the only other one I can think of. Steven Sharp sharp@cadence.com From: "Stuart Sutherland" <stuart@sutherland-hdl.com> To: "'Steven Sharp'" <sharp@cadence.com>, <etf-bugs@boyd.com> Cc: Subject: RE: enhancement/287: `compatibility - backward compatibilitycompilerdirectives Date: Fri, 18 Jun 2004 12:51:24 -0700 When I proposed enhancement 287, my primary concern was--and still is--keyword compatibility. What I would like to have is a standard way to specify that a tool *parse* older versions of the standard. I agree that it is not desirable to have tools be fully backward compatible for every feature and bug of previous standards. I suggest that the specification of the compatibility mode specifically state that the command only affects the reserved word list, and that the specification include the reserved words for 1364-1995 and for 1364-2001. That way no one has to go digging for obsolete LRMs to find the old reserved word lists. I have no strong preference as to how keyword backward compatibility is handled. The use of `compatibility, or even compiler directives in general, was meant as a suggestion to start the ball rolling. Perhaps it would be more clear if the directives were: `reserved_keywords 1955 `reserved_keywords 2001 `reserved_keywords 2005 (assuming a 1364-2005 standard) `reserved_keywords default (where default is the current 1364 standard) `resetall should be modified to state that it changes the `reserved_keywords directive to default. Regarding 1995 vs. 2001 compatibility, I recall there being three changes in 2001 that were not backward compatible: new keywords, the extension of unsized literal X or Z values past 32 bits, and the reduction of $fopen from 31 MCDs to 30 MCDs. Stu ~~~~~~~~~~~~~~~~~~~~~~~~~ Stuart Sutherland stuart@sutherland-hdl.com 503-692-0898 > -----Original Message----- > From: owner-etf@boyd.com [mailto:owner-etf@boyd.com] On > Behalf Of Steven Sharp > Sent: Friday, June 18, 2004 11:10 AM > To: etf-bugs@boyd.com > Subject: Re: enhancement/287: `compatibility - backward > compatibilitycompilerdirectives > > The following reply was made to PR enhancement/287; it has > been noted by GNATS. > > From: Steven Sharp <sharp@cadence.com> > To: etf-bugs@boyd.com, Shalom.Bresticker@freescale.com > Cc: > Subject: Re: enhancement/287: `compatibility - backward > compatibilitycompilerdirectives > Date: Fri, 18 Jun 2004 14:10:18 -0400 (EDT) > > > However, if "1364-2001 compatibility" would require > > him to disable any and all features added in later versions of the > > standard, that would be much harder for a vendor to implement, > > In fact, if the earlier versions of the standard are not readily > available, this is a bigger issue than just implementation effort. > > I believe that if this directive is added to the standard, that the > behavior required to be compliant needs to be fully specified in the > standard also. I don't believe that referring to an earlier > obsoleted > version of the standard is a valid specification. > > Trying to specify everything that has changed from all > previous versions > of the standard is impractical. Restricting it to something smaller, > such as just keywords, or just the things that are not > backward-compatible, > would make both specification and implementation much simpler. > > > > It is true that there are a few things which actually > change from one > > version of the standard to the next, as opposed to added > extensions, > > such as the use of bit 31 of an MCD, but those cases have > been quite few > > and relatively unimportant. > > The change in x/z-extension behavior for unsized literals is > the only other > one I can think of. > > Steven Sharp > sharp@cadence.com > > > > From: "Brophy, Dennis" <dennisb@model.com> To: Steven Sharp <sharp@cadence.com>, etf-bugs@boyd.com Cc: Subject: RE: enhancement/287: `compatibility - backward compatibilitycompi lerdirectives Date: Fri, 25 Jun 2004 07:16:22 -0700 With respect to access to the older versions of the specification, one can get older versions of 1364 from IEEE Xplore. (Thankfully the Verilog 95 copy on Xplore is a PDF file generated directly from the source. There are other superseded standards that are mere PDF files from scanned pages that offer no search capabilities.) Now that patent LOAs are part of the mix, and they expire upon a specification being superseded. If you want to use an old version of the specification and the LOAs covered essential patents, one would presumably need to negotiate directly with the IPR holder. We all observe that this industry has ignored the status of superseded standards since the user community has come to expect all versions of the standard are supported to some degree or another. How many people use VHDL 87 or 93? How many solutions still reference OVI SDF 2.1 and not IEEE 1497? Verilog 95 & 2001 share this as well. It may be admiral to codify consumer and supplier practice, but if we go down the route of 'compatibility, we may have other issues that would need basic IEEE SA attention and support in the issues that Steven points out. -Dennis -----Original Message----- From: owner-etf@boyd.com [mailto:owner-etf@boyd.com] On Behalf Of Steven Sharp Sent: Friday, June 18, 2004 11:10 AM To: etf-bugs@boyd.com Subject: Re: enhancement/287: `compatibility - backward compatibilitycompilerdirectives The following reply was made to PR enhancement/287; it has been noted by GNATS. From: Steven Sharp <sharp@cadence.com> To: etf-bugs@boyd.com, Shalom.Bresticker@freescale.com Cc: Subject: Re: enhancement/287: `compatibility - backward compatibilitycompilerdirectives Date: Fri, 18 Jun 2004 14:10:18 -0400 (EDT) > However, if "1364-2001 compatibility" would require > him to disable any and all features added in later versions of the > standard, that would be much harder for a vendor to implement, In fact, if the earlier versions of the standard are not readily available, this is a bigger issue than just implementation effort. I believe that if this directive is added to the standard, that the behavior required to be compliant needs to be fully specified in the standard also. I don't believe that referring to an earlier obsoleted version of the standard is a valid specification. Trying to specify everything that has changed from all previous versions of the standard is impractical. Restricting it to something smaller, such as just keywords, or just the things that are not backward-compatible, would make both specification and implementation much simpler. > It is true that there are a few things which actually change from one > version of the standard to the next, as opposed to added extensions, > such as the use of bit 31 of an MCD, but those cases have been quite few > and relatively unimportant. The change in x/z-extension behavior for unsized literals is the only other one I can think of. Steven Sharp sharp@cadence.com From: Shalom.Bresticker@freescale.com To: "Brophy, Dennis" <dennisb@model.com> Cc: etf-bugs@boyd.com Subject: RE: enhancement/287: `compatibility - backward compatibilitycompi lerdirectives Date: Sun, 27 Jun 2004 13:12:26 +0300 (IDT) Dennis, Actually this searchable version of 1364-1995 is actually fairly recent. The original one was indeed unsearchable. Now, the PDF version on IEEE Xplore is 6.3MB big. It also does not have any bookmarks. I created another, identical, PDF version of 1364-1995 which is only 2.3MB big and even has bookmarks. I had offered it to IEEE Publications, but nothing came of it. Do you maybe have some influence in the right places? Thanks, Shalom On Fri, 25 Jun 2004, Brophy, Dennis wrote: > Thankfully the Verilog 95 copy on Xplore is a PDF file generated directly from the source. -- Shalom Bresticker Shalom.Bresticker @freescale.com Design & Reuse Methodology Tel: +972 9 9522268 Freescale Semiconductor Israel, Ltd. Fax: +972 9 9522890 POB 2208, Herzlia 46120, ISRAEL Cell: +972 50 5441478 [ ]Freescale Internal Use Only [ ]Freescale Confidential Proprietary Fix replaced by tom_fitzpatrick@mentor.com on Mon Apr 11 14:16:11 2005 "Proposal to take 1800, 26.4 and make it 19.11 (omitting P1800-2005 version specifier), and update the cross-ref list at beginning of clause 19 to include `pragma, `begin_kewords and `end_keywords. Also remove any other references to SystemVerilog. Moved: Chas Second: Stu Approved Unanimously." |
Unformatted |
|
Hosted by Boyd Technology