From: Shalom Bresticker (Shalom.Bresticker@motorola.com)
Date: Thu Aug 02 2001 - 06:00:01 PDT
The following reply was made to PR errata/5; it has been noted by GNATS.
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">
<html>
Stuart Sutherland wrote:
<blockquote TYPE=CITE>In regards to implicit nets on the LHS of continuous
assignments, my text
<br>and example were based on what I understood would be added to the ballot
<br>draft, but which apparently never made it in. I recall discussing
that
<br>particular slide and example with Cliff to make sure I understood the
<br>intent of the behavioral task force resolution of the enhancement.
And I
<br>still think I got the intent correct. In my opinion, The fact
that a
<br>vector net on the LHS of continuous assignment is _not_ inferred was
an
<br>editing error in the preparation of ballot draft. Unfortunately,
the error
<br>was not caught during the ballot, and is now part of the standard.</blockquote>
I don't remember any such resolution.
<br>All my email archives refer to implicit declaration of a vector
<br>only in the case of a net which is connected to a port.
<p>I also see problems with it, otherwise. Let's take the example:
<p>> Verilog-2000 assign
n = a * b; // defaults to wire, width of (a * b)
<p>What is the range of n ? Is it [0:N] or [N:0] or [17:N+17] ?
<br>Is n accessible only as a vector, with no bit-selects or part-selects
?
<br>1364 has no such concept.
<p>What happens if there are two parallel continuous assignments to n,
<br>each with a different width ?
<p>What happens if I write
<br> assign n[0:3] = a * b ; ?
<p>Etc.
<p>So I think the correct and best thing is that it will imply a scalar.
<p>Besides, you still have the form:
<br> wire [0:N] n = a * b ;
<br>
<blockquote TYPE=CITE>I raised a red flag on this issue with Cliff several
months ago, when I was
<br>going through "draft 6", the post-ballot LRM, to create the Verilog-2001
<br>version of my quick reference guide. Cliff said he was sure it
was in the
<br>LRM somewhere, but didn't have time at that moment to look for it.
I
<br>finally decided to pull the enhancement from my reference guide, because
I
<br>could not find anywhere in the LRM that said a vector would be inferred
on
<br>the LHS of a continuous assignment.
<p>So let me ask all of the BTF a question. Should I update the slide
<br>presentation? I've left it alone, because changing it would mean
it is no
<br>longer the presentation I gave at HDLCon 2000. But, in addition
to this
<br>example on implicit nets for continuous assignments, there are some
minor
<br>errata in some of the examples. If companies really are considering
my
<br>slides as "a de facto LRM" instead of the IEEE 1364-2001 LRM, then
perhaps
<br>I should update the examples?</blockquote>
I think you definitely should, because people are relying on it,
<br>especially because of your standing in 1364.
<p>I think you should also add a warning note on your web-site.
<p>Regards,
<br>Shalom
<br>
<blockquote TYPE=CITE>
<p>Stu
<p>At 07:21 AM 8/1/2001, Paul Graham wrote:
<p>> > > Since the LRM has been through several drafts and has been
approved
<br>> by the
<br>> > > IEEE with the existing wording, and since this new type
of implicit
<br>> > > declaration has some unresolved issues, I think that Verilog-2001
should
<br>> > > omit this new feature.
<br>> >
<br>> > Which new feature ?
<br>> > Since it's already in 6.1.2, it can't be omitted.
<br>>
<br>> The new feature that I meant is a declaration implied by an
otherwise
<br>> undefined assignment target. And it's not mentioned in
6.1.2. 6.1.2 only
<br>> refers to implicit declarations, without defining them.
And section 3.5,
<br>> which defines then, doesn't mention the implicit declaration
of an
<br>> assignment target. The only written reference I have
seen to this new
<br>> feature is in Stuart Sutherland's nice overview of the Verilog-2000
features
<br>> (slide 14) in which he gives this example:
<br>>
<br>> Verilog-2000 assign
n = a * b; // defaults to wire, width of (a * b)
<br>>
<br>> which disagrees with your understanding that the implicit declaration
<br>> should be a scalar.
<br>>
<br>> I wonder how many vendors have started implementation based
on Sutherland's
<br>> slides? They may well become the de-facto LRM.
Why not -- they're much
<br>> easier to read!
<br>>
<br>> Paul
<p>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
<br>Stuart Sutherland
Sutherland HDL Inc.
<br>stuart@sutherland-hdl.com
22805 SW 92nd Place
<br>phone: 503-692-0898
Tualatin, OR 97062
<br>www.sutherland-hdl.com
<br>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~</blockquote>
<pre>--
**************************************************************************
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
**************************************************************************</pre>
</html>
--------------944F9094BE3175100B97645B--
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:54:43 PDT
and
sponsored by Boyd Technology, Inc.