From: Clifford E. Cummings (cliffc@sunburst-design.com)
Date: Fri Aug 03 2001 - 12:32:04 PDT
Hi, All -
I have been busy and unable to keep up with all of the new errata that have
been posted lately, but Don Mills contacted me and said I should probably
get involved with this one, now.
I can see that some additional wording is in order, especially in section
3.5 and possibly in section 6.1.2.
The problem with updating a Verilog standard is that information about
functionality is placed in multiple locations within the document. As a BTF
we tried to make clear enhancements. We obviously failed in this case.
Specific proposals for changes to specific paragraphs to satisfy everyone's
understanding of the enhancement would be greatly appreciated.
Paul and Mac have already pointed out to me that genvars should be labeled
as "natural" (0 plus all positive integers) as opposed to the "positive"
label that we used in the standard.
With respect to errata/5:
I proposed this enhancement/errata during the standards process to remove
the annoying requirement that 1-bit wires on the LHS of a continuous
assignment, that do not go to a port, must be explicitly declared.
Everywhere in the Verilog language, an undeclared identifier defaults to a
1-bit wire, except the above case (Verilog-1995).
In Verilog-1995:
- If the LHS variable of a continuous assignment drives a port, the size
can be inferred from the port definition and the data type is assumed to be
wire, unless otherwise declared.
- If the LHS variable of a continuous assignment does NOT drive a port, the
size and data type must be declared, even if it is just a 1-bit wire (most
annoying!).
Because of the latter requirement, engineers disperse 1-bit wire
declarations, with declaration assignments, throughout their RTL code to
avoid having to make numerous 1-bit wire declarations elsewhere in the
module.
The enhancement was added to remove the non-orthogonal requirement to
declare all 1-bit internal nets. Nothing more.
The enhancement was never intended to infer nets with sizes greater than
1-bit. I am not opposed to such an enhancement in the future, but I am also
not opposed to requiring declarations of all internal busses. Because
internal bus declarations are required, engineers also disperse wire-bus
declarations with assignments throughout their RTL code. Oh well!
The `default nettype = none enhancement is the exact opposite of this
enhancement, that is, this enhancement requires that all 1-bit wires be
declared. Having done a large VHDL ASIC (which requires all signal and
variable declarations) where the top-level design included three pages of
1-bit signal declarations and where I spent as much time debugging
declarations as I did debugging actual design problems, I find the `default
nettype = none enhancement to be repulsive and a step backwards; however, I
know there are factions that like to require engineers to declare all
signals as a form of self-documentation. I obviously am not one of those
engineers. I also know that the `default nettype = none enhancement is
touted as a way to easily find typos. I personally think it
counterproductive to add three pages of net declarations to find one or two
misspelled identifiers (which takes longer?). I personally think this is
the job of a good waveform viewer. (Now descending from soap-box).
Stu - I vote that you update you HDLCON-2001 presentation materials since
some people have started using it as a reference for implementing
Verilog-2001 enhancements. You might even want to add a further disclaimer
on the last slide that this is not the IEEE standard, might contain errors,
that you intend to continuously update the slides, and that the most recent
copy can be downloaded from your website at www.sutherland-hdl.com/... . I
think you have just created a living document and have semi-obligated
yourself to maintaining it. Fun, eh? ;-)
BTW slide 14 that Paul references below is a slide that I recently flagged
to Don Mills as a slide with an error. There were about a half-dozen slides
where I suggested corrections and I know Stu intends to give a corrected
and updated presentation in an upcoming conference. Stu, do you want to
give details since people like Paul are using your slides as reference
examples?
Regards - Cliff
At 08:30 AM 8/1/01 -0700:
>The following reply was made to PR errata/5; it has been noted by GNATS.
>
>From: Stuart Sutherland <stuart@sutherland-hdl.com>
>To: btf-bugs@boyd.com, btf@boyd.com
>Cc: btf@boyd.com
>Subject: Re: errata/5: Bad description of implicit nets created from
> continuous assignments
>Date: Wed, 01 Aug 2001 08:27:21 -0700
>
> My "Verilog-2000" presentation become the de facto standard? I HOPE NOT!
>
> Just to set the record straight, my "Verilog-2000" presentation was created
> for HDLCon 2000. I had to submit the paper and examples in January 2000,
> several weeks before the ballot draft for the 1364 LRM was complete. A
> couple of specifications changed between when I wrote the paper and the
> actual ballot draft, such as attributes. As a result of the balloting,
> some more things changed, such as the rules for constant functions. And,
> alas, the ballot review process took so long that the standard became
> "Verilog-2001" instead of "Verilog-2000".
>
> In regards to implicit nets on the LHS of continuous assignments, my text
> and example were based on what I understood would be added to the ballot
> draft, but which apparently never made it in. I recall discussing that
> particular slide and example with Cliff to make sure I understood the
> intent of the behavioral task force resolution of the enhancement. And I
> still think I got the intent correct. In my opinion, The fact that a
> vector net on the LHS of continuous assignment is _not_ inferred was an
> editing error in the preparation of ballot draft. Unfortunately, the error
> was not caught during the ballot, and is now part of the standard.
>
> I raised a red flag on this issue with Cliff several months ago, when I was
> going through "draft 6", the post-ballot LRM, to create the Verilog-2001
> version of my quick reference guide. Cliff said he was sure it was in the
> LRM somewhere, but didn't have time at that moment to look for it. I
> finally decided to pull the enhancement from my reference guide, because I
> could not find anywhere in the LRM that said a vector would be inferred on
> the LHS of a continuous assignment.
>
> So let me ask all of the BTF a question. Should I update the slide
> presentation? I've left it alone, because changing it would mean it is no
> longer the presentation I gave at HDLCon 2000. But, in addition to this
> example on implicit nets for continuous assignments, there are some minor
> errata in some of the examples. If companies really are considering my
> slides as "a de facto LRM" instead of the IEEE 1364-2001 LRM, then perhaps
> I should update the examples?
>
> Stu
>
> At 07:21 AM 8/1/2001, Paul Graham wrote:
> >Precedence: bulk
> >
> >
> >The following reply was made to PR errata/5; it has been noted by GNATS.
> >
> >From: Paul Graham <pgraham@cadence.com>
> >To: Shalom.Bresticker@motorola.com
> >Cc: btf-bugs@boyd.com
> >Subject: Re: errata/5: Bad description of implicit nets created from
> >continuous assignments
> >Date: Wed, 1 Aug 2001 07:18:57 -0700 (PDT)
> >
> > > > Since the LRM has been through several drafts and has been approved
> > by the
> > > > IEEE with the existing wording, and since this new type of implicit
> > > > declaration has some unresolved issues, I think that Verilog-2001
should
> > > > omit this new feature.
> > >
> > > Which new feature ?
> > > Since it's already in 6.1.2, it can't be omitted.
> >
> > The new feature that I meant is a declaration implied by an otherwise
> > undefined assignment target. And it's not mentioned in 6.1.2. 6.1.2
only
> > refers to implicit declarations, without defining them. And section 3.5,
> > which defines then, doesn't mention the implicit declaration of an
> > assignment target. The only written reference I have seen to this new
> > feature is in Stuart Sutherland's nice overview of the Verilog-2000
features
> > (slide 14) in which he gives this example:
> >
> > Verilog-2000 assign n = a * b; // defaults to wire, width of (a
* b)
> >
> > which disagrees with your understanding that the implicit declaration
> > should be a scalar.
> >
> > I wonder how many vendors have started implementation based on
Sutherland's
> > slides? They may well become the de-facto LRM. Why not -- they're much
> > easier to read!
> >
> > Paul
//*****************************************************************//
// Cliff Cummings Phone: 503-641-8446 //
// Sunburst Design, Inc. FAX: 503-641-8486 //
// 14314 SW Allen Blvd. E-mail: cliffc@sunburst-design.com //
// PMB 501 Web: www.sunburst-design.com //
// Beaverton, OR 97005 //
// //
// Expert Verilog, Synthesis and Verification Training //
//*****************************************************************//
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:54:43 PDT
and
sponsored by Boyd Technology, Inc.