ISSUE 287

Number 287
Category enhancement
Synopsis `compatibility - backward compatibility compiler directives
State etfpassed
Class enhancement
Arrival-DateFeb 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