| Number | 5
|
| Category | errata
|
| Synopsis | Bad description of implicit nets created from continuous assignments
|
| State | lrmdraft
|
| Class | errata-simple
|
| Arrival-Date | Jul 30 2001
|
| Originator | Paul Graham, Cadence
|
| Release | 2001a, 2001b, 3.5
|
| Environment |
http://boydtechinc.com/btf/archive/btf_1997/1297.html http://boydtechinc.com/btf/archive/btf_1997/1291.html |
| Description |
Section 6.1.2 says, "The continuous assignment statement shall place a continuous assignment on a net data type. The net may be explicitly declared, or may inherit an implicit declaration in accordance with the implicit declarations rules defined in 3.5." Unfortunately, section 3.5 does not mention that case. Furthermore, it is not clear what is the width of the implicit net. According to the notes in my mail archives, it seems that a scalar is created unless the name is connected to a vector port. Yet a third case is if I have assign a[0:3] = b ; and a is not explicitly declared nor connected to a port. That is, the range explicitly appears in the continuous assignment. All this needs to be cleared up and 6.1.2 and 3.5 brought into alignment with each other. See BE55 and BE61 in the BTF database. (I don't know why they became two different entries. They seem very similar.) |
| Fix |
This was submitted to IEEE in Oct, 2001 Passed 10/7/02: Add to 3.5 the following additional item: If an identifier appears on the left-hand side of a continuous assignment statement, and that identifier has not been declared previously, an implicit scalar net declaration of the default net type is assumed. |
| Audit-Trail |
From: Shalom Bresticker <Shalom.Bresticker@motorola.com> To: btf-bugs@boyd.com, pgraham@cadence.com Cc: Subject: Re: errata/5: Bad description of implicit nets created from continuous assignments Date: Wed, 01 Aug 2001 11:17:20 +0300 --------------41C428665E5D873F78089DC2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Paul, See my comments inside. > The wording of section 6.1.2 was updated to refer to section 3.5, which is > good, sort of. It is good that the definition of an implicit signal was > concentrated in one section in the LRM, instead of being repeated > redundantly in several sections. But 3.5, the key section, was never > updated to include the new intention of allowing an assignment lhs to imply > an implicit signal declaration. > > Section 6.1.2 is also inaccurate, in that it suggests that an assignment > target may *only* be an explicitly or implicitly declared net. It can of > course be a part-select or bit-select or concatenation. True. Table 6-1, which comes earlier, is clear, but 6.1.2 is not completely precise. My understanding is that an implicit declaration occurs only when the LHS is a simple net identifier, i.e., not part-select or bit-select or concatenation. > Or what about: > > parameter p1 = 4, p2 = 4; > input [p1-1:0] x, y; > > assign z = x * y; > > What is the width of z? Is it 1? Is it (p1 + p2)? My understanding is that z is implicitly declared as a scalar. A lint tool should then identify a mismatch between LHS and RHS widths. > 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. > Let it go into Verilog-2006, after it has been > thought through more carefully. We can't (almost) make a change which will affect backward compatability, only fix bugs and make new extensions. By the way, we don't have to wait till 2006. I have already proposed that we start preparing a new revision sooner with corrections and maybe some small enhancements which we might be able to agree on by then. Shalom > > Section 6.1.2 says, > > "The continuous assignment statement shall place a continuous assignment on a net data type. The net may be explicitly declared, > or > > may inherit an implicit declaration in accordance with the implicit declarations rules defined in 3.5." > > > > Unfortunately, section 3.5 does not mention that case. > > > > I'll file a bug report. > > > > What should the width be in that case ? > > According to my mail archives, it seems that a scalar is created unless the name is connected to a vector port. -- ************************************************************************** Shalom Bresticker Shalom.Bresticker@motorola.com Motorola Semiconductor Israel, Ltd. Tel #: +972 9 9522268 P.O.B. 2208, Herzlia 46120, ISRAEL Fax #: +972 9 9522890 ************************************************************************** --------------41C428665E5D873F78089DC2 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit <!doctype html public "-//w3c//dtd html 4.0 transitional//en"> Paul, See my comments inside.
Section 6.1.2 is also inaccurate, in that it suggests that an assignment
My understanding is that an implicit declaration occurs only when the
parameter p1 = 4, p2 = 4;
assign z = x * y;
What is the width of z? Is it 1? Is it (p1 + p2)?
By the way, we don't have to wait till 2006.
Shalom
-- ************************************************************************** Shalom Bresticker Shalom.Bresticker@motorola.com Motorola Semiconductor Israel, Ltd. Tel #: +972 9 9522268 P.O.B. 2208, Herzlia 46120, ISRAEL Fax #: +972 9 9522890 ************************************************************************** --------------41C428665E5D873F78089DC2-- 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 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Stuart Sutherland Sutherland HDL Inc. stuart@sutherland-hdl.com 22805 SW 92nd Place phone: 503-692-0898 Tualatin, OR 97062 www.sutherland-hdl.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From: Shalom Bresticker <Shalom.Bresticker@motorola.com> To: Stuart Sutherland <stuart@sutherland-hdl.com> Cc: btf-bugs@boyd.com Subject: Re: errata/5: Bad description of implicit nets created from continuous assignments Date: Thu, 02 Aug 2001 15:52:08 +0300 --------------944F9094BE3175100B97645B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Stuart Sutherland wrote: > 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 don't remember any such resolution. All my email archives refer to implicit declaration of a vector only in the case of a net which is connected to a port. I also see problems with it, otherwise. Let's take the example: > Verilog-2000 assign n = a * b; // defaults to wire, width of (a * b) What is the range of n ? Is it [0:N] or [N:0] or [17:N+17] ? Is n accessible only as a vector, with no bit-selects or part-selects ? 1364 has no such concept. What happens if there are two parallel continuous assignments to n, each with a different width ? What happens if I write assign n[0:3] = a * b ; ? Etc. So I think the correct and best thing is that it will imply a scalar. Besides, you still have the form: wire [0:N] n = a * b ; > 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? I think you definitely should, because people are relying on it, especially because of your standing in 1364. I think you should also add a warning note on your web-site. Regards, Shalom > > > Stu > > At 07:21 AM 8/1/2001, Paul Graham wrote: > > > > > 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 > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Stuart Sutherland Sutherland HDL Inc. > stuart@sutherland-hdl.com 22805 SW 92nd Place > phone: 503-692-0898 Tualatin, OR 97062 > www.sutherland-hdl.com > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- ************************************************************************** Shalom Bresticker Shalom.Bresticker@motorola.com Motorola Semiconductor Israel, Ltd. Tel #: +972 9 9522268 P.O.B. 2208, Herzlia 46120, ISRAEL Fax #: +972 9 9522890 ************************************************************************** --------------944F9094BE3175100B97645B Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit <!doctype html public "-//w3c//dtd html 4.0 transitional//en"> Stuart Sutherland wrote: <blockquote TYPE=CITE>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 don't remember any such resolution. All my email archives refer to implicit declaration of a vector only in the case of a net which is connected to a port. I also see problems with it, otherwise. Let's take the example:
> Verilog-2000 assign
What is the range of n ? Is it [0:N] or [N:0] or [17:N+17] ?
What happens if there are two parallel continuous assignments to n,
What happens if I write
Etc.
So I think the correct and best thing is that it will imply a scalar.
Besides, you still have the form:
So let me ask all of the BTF a question. Should I update the slide
I think you should also add a warning note on your web-site.
Regards,
Stu
At 07:21 AM 8/1/2001, Paul Graham wrote:
> > > Since the LRM has been through several drafts and has been
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-- ************************************************************************** Shalom Bresticker Shalom.Bresticker@motorola.com Motorola Semiconductor Israel, Ltd. Tel #: +972 9 9522268 P.O.B. 2208, Herzlia 46120, ISRAEL Fax #: +972 9 9522890 ************************************************************************** --------------944F9094BE3175100B97645B-- From: "Clifford E. Cummings" <cliffc@sunburst-design.com> To: btf-bugs@boyd.com Cc: btf@boyd.com Subject: Re: errata/5: Bad description of implicit nets created from continuous assignments Date: Fri, 03 Aug 2001 12:32:04 -0700 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 // //*****************************************************************// From: Shalom Bresticker <Shalom.Bresticker@motorola.com> To: "Clifford E. Cummings" <cliffc@sunburst-design.com> Cc: btf-bugs@boyd.com Subject: Re: errata/5: Bad description of implicit nets created from continuous assignments Date: Sun, 05 Aug 2001 10:10:37 +0300 --------------DCCBDBEC7A0493DA5D60B025 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cliff, This is off the subject for errata/5, but for the record: genvars are NOT labeled as "positive". The exact wording (in draft 6) is : "A genvar is an integer that is local to and shall only be used within a generate loop that uses it as an index variable. If any bit of the genvar ever is set to an X or Z or if the genvar is set to a negative value, this shall be an error." Shalom "Clifford E. Cummings" wrote: > 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. -- ************************************************************************** Shalom Bresticker Shalom.Bresticker@motorola.com Motorola Semiconductor Israel, Ltd. Tel #: +972 9 9522268 P.O.B. 2208, Herzlia 46120, ISRAEL Fax #: +972 9 9522890 ************************************************************************** --------------DCCBDBEC7A0493DA5D60B025 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit <!doctype html public "-//w3c//dtd html 4.0 transitional//en"> Cliff, This is off the subject for errata/5, but for the record:
genvars are NOT labeled as "positive".
The exact wording (in draft 6) is :
"A genvar is an integer that is local to and shall only be used within
Shalom
"Clifford E. Cummings" wrote:
-- ************************************************************************** Shalom Bresticker Shalom.Bresticker@motorola.com Motorola Semiconductor Israel, Ltd. Tel #: +972 9 9522268 P.O.B. 2208, Herzlia 46120, ISRAEL Fax #: +972 9 9522890 ************************************************************************** --------------DCCBDBEC7A0493DA5D60B025-- From: Shalom Bresticker <Shalom.Bresticker@motorola.com> To: Cc: btf-bugs@boyd.com Subject: Re: errata/5: Bad description of implicit nets created from continuous assignments Date: Mon, 06 Aug 2001 17:11:51 +0300 --------------5503AF6BF4AC9A5C62223058 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Here's an interesting curiosity in Verilog-XL. I just encountered such a case, and it turns out you can't reference it with a hierarchial name reference. Example: module qq ( a ) ; output [3:0] a ; assign a = 2 ; endmodule module pp ; initial force qq.a = 0 ; endmodule will give you a message that a is undeclared in qq. From pp, it recognizes a only as an external port of qq, not as an internal signal. Shalom "Clifford E. Cummings" wrote: > 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. -- ************************************************************************** Shalom Bresticker Shalom.Bresticker@motorola.com Motorola Semiconductor Israel, Ltd. Tel #: +972 9 9522268 P.O.B. 2208, Herzlia 46120, ISRAEL Fax #: +972 9 9522890 ************************************************************************** --------------5503AF6BF4AC9A5C62223058 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit <!doctype html public "-//w3c//dtd html 4.0 transitional//en"> Here's an interesting curiosity in Verilog-XL. I just encountered such a case, and it turns out you can't reference
Example:
module qq ( a ) ;
module pp ;
will give you a message that a is undeclared in qq.
From pp, it recognizes a only as an external port of qq, not as an internal
Shalom
"Clifford E. Cummings" wrote:
-- ************************************************************************** Shalom Bresticker Shalom.Bresticker@motorola.com Motorola Semiconductor Israel, Ltd. Tel #: +972 9 9522268 P.O.B. 2208, Herzlia 46120, ISRAEL Fax #: +972 9 9522890 ************************************************************************** --------------5503AF6BF4AC9A5C62223058-- From: Steven Sharp <sharp@cadence.com> To: btf@boyd.com, btf-bugs@boyd.com Cc: btf@boyd.com Subject: Re: errata/5: Bad description of implicit nets created from continuous assignments Date: Mon, 6 Aug 2001 14:09:25 -0400 (EDT) >From: Shalom Bresticker <Shalom.Bresticker@motorola.com> >To: Cc: btf-bugs@boyd.com >Subject: Re: errata/5: Bad description of implicit nets created from continuous assignments > Here's an interesting curiosity in Verilog-XL. > > I just encountered such a case, and it turns out you can't reference it with a hierarchial name reference. > > Example: > > module qq ( a ) ; > output [3:0] a ; > assign a = 2 ; > endmodule > > module pp ; > initial force qq.a = 0 ; > endmodule > > will give you a message that a is undeclared in qq. > > From pp, it recognizes a only as an external port of qq, not as an internal signal. > I just tried this testcase in Verilog-XL 3.20.s002 and it worked fine. Perhaps this problem has been fixed since the version you are using. Steven Sharp sharp@cadence.com From: Shalom.Bresticker@motorola.com To: etf-bugs@boyd.com Cc: Subject: Re: errata/5: Bad description of implicit nets created from continuous assignments Date: Wed, 25 Sep 2002 12:15:18 +0300 (IDT) I had wondered whether the fix to errata/5 was formally approved by the VSG. I found the following mail which indicates that such a vote did indeed take place. I do not have the following mails, but I assume there were such and that the fix was officially approved. So we can leave 5 as vsg-passed. However, that does not apply to 8 and 18. Shalom ---------- Forwarded message ---------- Date: Fri, 05 Oct 2001 11:20:28 -0700 From: Clifford E. Cummings <cliffc@sunburst-design.com> To: btf@boyd.com, 1364core@ovi.org Subject: Verilog Standards Group - VOTE - (votes due Tuesday, October 9, 2001) Precedence: bulk Dear Verilog Standards Group Members - Please review the following proposal and vote YES or NO by Tuesday, October 9th. Eligible voters and their respective votes are listed at the end of this e-mail message. The following paragraph has been proposed to be added to section 3.5 of the IEEE1364-2001 to clarify an issue that has already caused severe confusion about an enhancement that was added to the IEEE1364-2001 Standard, even before the Standard has been officially published. We are now trying to clarify the issue before the Standard goes to print. Stu Sutherland has submitted a "friendly amendment" to the section 3.5 proposal. I believe Stu's wording is more accurate and takes into account the `default_nettype compiler directive, so I have modified the wording for this proposal as follows: ----- MODIFIED PROPOSAL: Add the following indented paragraph to the end of section 3.5. Indenting to match the indenting of the two last paragraphs already in section 3.5: "If an identifier appears on the left-hand side of a continuous assignment statement, and that identifier has not been declared previously, an implicit scalar net declaration of the default net type is assumed." ----- Please note: a "NO" vote does not remove this enhancement from the IEEE1364-2001 Standard, it merely keeps the above paragraph of clarification from being added to the Standard. The enhancement will still be part of the Standard, but will remain poorly documented and confusing. If you have already previously voted on the former wording of this proposal, and if your vote does not change due to the changed wording to this proposal, you do not have to submit a new vote (your vote will be counted the same as before). If you have not already voted, please vote YES or NO on the above proposed addition to the end of section 3.5 and e-mail your vote to me no later than Tuesday, October 9th, 2001. Approval will be by simple majority of all IEEE VSG members that elect to cast a vote. Regards - Cliff Cummings Behavioral Task Force Chairperson VOTES - IEEE VSG (per names listed in the front of the IEEE1364-2001 Standard) Adam Krolnik - YES Alec G. Stanculescu - ?? Anders Nordstrom - ?? Andrew T. Lynch - ?? Charles Dawson - ?? Chris Spear - YES Clifford E. Cummings - YES David Roberts - ?? Deborah J. Dalio - ?? Girish S. Rao - ?? Hiroaki Nishi - ?? James A. Markevitch - ?? Karen Pieper - YES Kasumi Hamaguchi - ?? Kurt Baty - ?? Leigh Brady - ?? Lukasz Senator - ?? Lynn A. Horobin - ?? Makoto Makino - ?? Maqsoodul (Maq) Mannan - ?? Marek Ryniejski - ?? Michael McNamara - ?? Naveen Gupta - ?? Paul Colwill - ?? Prabhakaran Krishnamurthy - ?? Shalom Bresticker - ?? Stefen Boyd - YES Steve Meyer - ?? Steve Wadsworth - ?? Steven Sharp - ?? Stu Sutherland - YES Stuart Sutherland - ?? Takashima Mitsuya - ?? Tatsuro Nakamura - ?? Ted Elkind - ?? Tom Dewey - ?? Tom Fitzpatrick - ?? Tsutomu Someya - ?? Yasuaki Hatta - ?? Yatin Trivedi - ?? Yokozeki Atsushi - ?? VOTES - BY OTHER INTERESTED PARTIES (Do not count towards the official vote) Don Mills - YES Paul Graham - NO (I believe Paul's objection is not related to the wording of the proposal, but that implicit scalar wire declarations from continuous assignments are even allowed. This enhancement was already approved by the IEEE1364 Verilog Standards Group. We are now just trying to clean up some confusion in the IEEE1364-2001 Standard) //*****************************************************************// // 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 // //*****************************************************************// From: Shalom Bresticker <Shalom.Bresticker@motorola.com> To: 1364@accellera.org, etf-bugs@boyd.com Cc: Subject: Re: errata/5: Bad description of implicit nets created from continuous assignments Date: Mon, 23 Dec 2002 11:46:54 +0200 I have changed the wording of the end of this addition slightly, to make it consistent with the wording of the first two bullets in this clause, FROM: If an identifier appears on the left-hand side of a continuous assignment statement ... , an implicit scalar net declaration of the default net type is assumed. TO: If an identifier appears on the left-hand side of a continuous assignment statement ... , then an implicit scalar net of default net type shall be assumed. Shalom |
| Unformatted |
|
Hosted by Boyd Technology