RE: [sv-bc] Ballot for proposed changes for 1800-2008 Draft 3

From: Bresticker, Shalom <shalom.bresticker_at_.....>
Date: Thu Apr 26 2007 - 01:35:40 PDT
I think it remained in 1364-2001/2005 only because of PLI
back-compatibility. 

We could have handled other references to memories, e.g., $readmem,
without much trouble.

It needs to be SV-CC's decision.

 

Shalom

 

________________________________

From: Warmke, Doug [mailto:doug_warmke@mentor.com] 
Sent: Thursday, April 26, 2007 11:04 AM
To: Bresticker, Shalom; Brad Pierce; sv-bc@server.eda.org
Subject: RE: [sv-bc] Ballot for proposed changes for 1800-2008 Draft 3

 

Hello all,

 

Personally I would like to take advantage of the merge to remove the

concept of "memory" from the LRM.  It is a perfect subset of unpacked

fixed-size arrays.   Such redundancy can only lead to confusion and

reduce the LRM's integrity.

 

There are implications in PLI, as well as other places in the LRM.

Currently the SV-CC is working through some difficult issues

with arrays. I think the idea of removing "memory" as a special kind

of array wouldn't be too much additional work, and may even help

them simplify their problem space.

 

I think we could make this happen.

 

Regards,

Doug

 

 

 

________________________________

From: owner-sv-bc@server.eda.org on behalf of Bresticker, Shalom
Sent: Wed 4/25/2007 11:54 PM
To: Brad Pierce; sv-bc@server.eda.org
Subject: RE: [sv-bc] Ballot for proposed changes for 1800-2008 Draft 3

1364-2005 has the following:

4.9.3 Memories

A one-dimensional array with elements of type reg is also called a
memory. These memories can be used to model read-only memories (ROMs),
random access memories (RAMs), and reg files. Each reg in the array
is known as an element or word and is addressed by a single array index.

An n-bit reg can be assigned a value in a single assignment, but a
complete memory cannot. To assign a value to a memory word, an index
shall be specified. The index can be an expression. This option provides
a mechanism to reference different memory words, depending on the value
of other variables and nets in the circuit. For example, a program
counter reg could be used to index into a RAM.

4.9.3.1 Array examples

4.9.3.1.1 Array declarations

reg [7:0] mema[0:255]; // declares a memory mema of 256 8-bit
                       // registers. The indices are 0 to 255

Shalom


> -----Original Message-----
> From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org]
> On Behalf Of Brad Pierce
> Sent: Thursday, April 26, 2007 9:50 AM
> To: sv-bc@server.eda.org
> Subject: Re: [sv-bc] Ballot for proposed changes for 1800-2008 Draft 3
>
> 7.2.4 in the draft under review begins
>
>    "A one-dimensional array with elements of types reg, logic or bit
> is
> also called a memory."
>
> In SystemVerilog this would include
>
>     logic M[1024];
>
> but not
>
>     reg [15:0] M[1024];
>
> -- Brad
>
> -----Original Message-----
> From: Bresticker, Shalom [mailto:shalom.bresticker@intel.com]
> Sent: Wednesday, April 25, 2007 11:38 PM
> To: Brad Pierce; sv-bc@eda.org
> Subject: RE: [sv-bc] Ballot for proposed changes for 1800-2008 Draft 3
>
> Stu meant there is one unpacked dimension.
> He did not say there are no packed dimensions.
>
> So this:
>
> >       reg [15:0] M[1024];
>
> is and always has been a memory.
>
> I don't know about this:
>
> > Is the following a memory?
> >
> >       reg [3:0] [3:0] M[1024];
>
> Verilog never had anything like this, so memories never related to it.
>
> Shalom
>
> > -----Original Message-----
> > From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org]
> > On Behalf Of Brad Pierce
> > Sent: Thursday, April 26, 2007 9:26 AM
> > To: sv-bc@server.eda.org
> > Subject: RE: [sv-bc] Ballot for proposed changes for 1800-2008 Draft
> 3
> >
> > Stu writes --
> >
> > >> BP1-7-1   yes ___ no _X_ abstain ___
> > >I disagree with the suggested change.  This subclause is
> specifically
>
> > >defining a "memory" as a one-dimensional unpacked array.  There is
> no
>
> > >"fastest varying unpacked dimension".  An array with multiple
> > unpacked
> > >dimensions is not a memory, and referring to one as such would
> break
> > the VPI
> > >definitions of memories and arrays.
> >
> > Yet the sentence in question is --
> >
> >   "Each packed dimension in the array is known as a memory element
> or
> > word"
> >
> > If there's only one dimension, then why is it talking about 'each
> > packed dimension'?  And how could a dimension, let alone each packed
> > dimension, be an element?  And why isn't the following a memory?
> >
> >       reg [15:0] M[1024];
> >
> > It is an array with one unpacked dimension, but it is a two-
> > dimensional array.
> >
> > Is the following a memory?
> >
> >       reg [3:0] [3:0] M[1024];
> >
> > -- Brad
> >
> > -----Original Message-----
> > From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of
> > Stuart Sutherland
> > Sent: Tuesday, April 24, 2007 11:47 PM
> > To: sv-bc@eda.org
> > Subject: RE: [sv-bc] Ballot for proposed changes for 1800-2008 Draft
> 3
> >
> > Matt,
> >
> > Here's my votes.
> >
> > I am traveling the morning of the conference call to discuss the
> > voting.
> > I should be able to call in for the first 30 minutes of the call.
> >
> > Stu
> > ~~~~~~~~~~~~~~~~~~~~~~~~~
> > Stuart Sutherland
> > Sutherland HDL, Inc.
> > stuart@sutherland-hdl.com
> > 503-692-0898
> >
> >
> > > SB1-1-1   yes _X_ no ___ abstain ___
> > > SB1-1-2   yes _X_ no ___ abstain ___
> > > SB1-1-3   yes _X_ no ___ abstain ___
> > > SB1-1-4   yes _X_ no ___ abstain ___
> > > SB1-1-5   yes _X_ no ___ abstain ___
> > > SB1-2-1   yes ___ no _X_ abstain ___
> > There are many references in the LRM to "1364" and "1800" without a
> > specific year.  Either these references need to be changed to
> > "1364-2005" or "1800-2005", or the definition of "IEEE 1364" and
> "IEEE
>
> > 1800" should be left in.  Most references to "1364" and "1800" can
> > have a year added, but some may need to stay generic; specifically
> > 1.7, 5.5.2, 21.12 (multiple places), C.2.1, C.2.2, I.12, I.12.1
> > (multiple places).  I will change my vote to yes if the committee
> > decides that all references to "1364" and "1800" have a specific
> > version added.
> >
> > > SB1-3-1   yes ___ no _X_ abstain ___
> > I have no problems with the current wording, and no new wording is
> > recommended.  I will change my vote to yes of specific wording
> changes
>
> > are recommended.
> >
> > > SB1-3-2   yes _X_ no ___ abstain ___
> > > SB1-3-3   yes _X_ no ___ abstain ___
> > A question is raised as to whether "config" should be listed as a
> > design unit, but no recommendation given.  I will change my vote to
> > yes if the committee agrees to remove "config", or for a description
> > of config to be added to clause 3 (saying editor is to create the
> > wording is OK).
> >
> > > SB1-5-1   yes _X_ no ___ abstain ___
> > > SB1-5-2   yes _X_ no ___ abstain ___
> > > SB1-5-3   yes ___ no _X_ abstain ___
> > I think the discussion of time values makes more sense where it is
> > than in clause 4.
> >
> > > SB1-5-4   yes _X_ no ___ abstain ___
> > > SB1-5-5   yes _X_ no ___ abstain ___
> > > SB1-5-6   yes _X_ no ___ abstain ___
> > > SB1-6-1   yes _X_ no ___ abstain ___
> > > SB1-6-2   yes _X_ no ___ abstain ___
> > > SB1-6-3   yes _X_ no ___ abstain ___
> > The suggestion is: "6.14 and 7.6 both describe strings. Merge them
> > ***or*** have only a two-sentence paragraph in 6.14".  I do not
> > approve of removing 6.14.  I do approve of I approve of having a
> > two-sentence paragraph in 6.14 with a forward reference to 7.6.
> >
> > > SB1-7-1   yes _X_ no ___ abstain ___
> > > SB1-7-2   yes _X_ no ___ abstain ___
> > > SB1-10-1  yes ___ no _X_ abstain ___
> > This needs to be a separate mantis item that goes through the full
> > discussion, voting, and approval process.
> >
> > > SB1-10-2  yes _X_ no ___ abstain ___
> > > SB1-11-1  yes ___ no _X_ abstain ___
> > I think a more correct fix is to change the term "procedural
> > assignment operators" in 10.3 and 10.3.1 to "assignment operators",
> so
>
> > as to match the description of these operators in 11.2.7 and A.6.3.
> >
> > > SB1-11-2  yes ___ no _X_ abstain ___
> > The description of the wording problem is not detailed enough for
> the
> > editor
> > (me) to implement.
> >
> > > SB1-11-3  yes ___ no _X_ abstain ___
> > This is an open mantis item (#1004), and needs to be addressed using
> > the standard discussion, voting and approval method.
> >
> > > SB1-11-4  yes _X_ no ___ abstain ___
> > > SB1-12-1  yes _X_ no ___ abstain ___
> > > SB1-16-1  yes _X_ no ___ abstain ___
> > > SB1-19-1  yes _X_ no ___ abstain ___
> > > SB1-19-2  yes ___ no _X_ abstain ___
> > This is an alleged errata in 1364-2005, and should be addressed as a
> > separate Mantis item.
> >
> > > SB1-20-1  yes _X_ no ___ abstain ___
> > > SB1-20-2  yes _X_ no ___ abstain ___
> > > SB1-21-1  yes ___ no _X_ abstain ___
> > This is an enhancement request that needs to be a separate Mantis
> > item.
> >
> > > SB1-21-2  yes ___ no _X_ abstain ___
> > This is a change to a definition in 1364-2005.  It should be a
> > separate Mantis item for discussion, voting and approval.
> >
> > > SB1-21-3  yes _X_ no ___ abstain ___
> > > SB1-22-1  yes _X_ no ___ abstain ___
> > > SB1-22-2  yes _X_ no ___ abstain ___
> > > SB1-22-3  yes _X_ no ___ abstain ___
> > > SB1-22-4  yes ___ no _X_ abstain ___
> > I agree with the principle of the change, but this is a definition
> > that does not exist in either 1364-2005 or 1800-2005.  It needs to
> be
> > a separate Mantis item with discussion, voting and approval.
> >
> > > SB1-25-1  yes _X_ no ___ abstain ___
> > > SB1-25-2  yes _X_ no ___ abstain ___
> > > SB1-25-3  yes _X_ no ___ abstain ___
> > > SB1-27-1  yes _X_ no ___ abstain ___
> > > SB1-33-1  yes ___ no ___ abstain _X_
> > I think the current order of clauses 30-33 is fine, but will change
> > order if the committee approves.
> >
> > > SB-O-1    yes ___ no _X_ abstain ___
> > This needs committee discussion on what the correction should be.
> > Make
> > it a
> > separate Mantis item.
> >
> > > SB-O-2    yes ___ no _X_ abstain ___
> > This needs committee discussion on what the correction should be.
> > Make
> > it a
> > separate Mantis item.
> >
> > > SB-O-3    yes ___ no _X_ abstain ___
> > This needs committee discussion on what the correction should be.
> > Make
> > it a
> > separate Mantis item.
> >
> > > SB-O-4    yes ___ no _X_ abstain ___
> > I think the current split on string literal topics is correct.  5.9
> > discusses string literal syntax in the same clause with other
> > literals.
> > 11.6.1 discusses operations on string literals in the same clause on
> > operations on other types of data.
> >
> > > SB-O-5    yes ___ no _X_ abstain ___
> > Moving the discussion on string literals and string types closer
> > together because they are related would only move other closely
> > related topics further apart.  This is one of those cases where
> there
> > is no perfect solution to how to group topics.  I prefer to keep
> > string literals with other literals and string arrays with other
> > arrays.
> >
> > > SB-O-6    yes ___ no _X_ abstain ___
> > This needs committee discussion on what the correction should be.
> > Make
> > it a
> > separate Mantis item.
> >
> > > SB-O-7    yes ___ no _X_ abstain ___
> > This needs committee discussion on what the correction should be.
> > Make
> > it a
> > separate Mantis item.
> >
> > > SB-O-8    yes _X_ no _X_ abstain ___
> > This is a duplicate of SB1-10-2, of which I am also in favor.
> >
> > > SB-O-9    yes ___ no _X_ abstain ___
> > This needs committee discussion on what the correction should be.
> > Make
> > it a
> > separate Mantis item.
> >
> > > SB-O-10   yes ___ no _X_ abstain ___
> > I think this should be left as-is.
> >
> > > SB-O-11   yes ___ no _X_ abstain ___
> > Discussion on this should be turned over to the SV-CC committee.
> >
> > > SB2-6-9-1 yes _X_ no ___ abstain ___
> >
> >
> > > BP1-5-1   yes ___ no _X_ abstain ___
> > The note in 5.8 should remain deleted.  It is redundant with the
> same
> > note in 5.7.  The Greek letter has already been corrected for draft
> 3.
> >
> > > BP1-5-2   yes _X_ no ___ abstain ___
> > > BP1-5-3   yes ___ no _X_ abstain ___
> > This would be changing a definition in 1800-2005.  It is also part
> of
> > a larger issue that has been raised on consistent usage of "data
> type"
> > and
> > "data object" throughout the LRM, and should be dealt with in a
> Mantis
>
> > item on that topic.
> >
> > > BP1-5-4   yes ___ no _X_ abstain ___
> > This is part of a larger issue that has been raised on consistent
> > usage of "data type" and "data object" throughout the LRM, and
> should
> > be dealt with in a Mantis item on that topic.
> >
> > > BP1-5-5   yes ___ no _X_ abstain ___
> > This is part of a larger issue that has been raised on consistent
> > usage of "data type" and "data object" throughout the LRM, and
> should
> > be dealt with in a Mantis item on that topic.
> >
> > > BP1-5-6   yes _X_ no ___ abstain ___
> > > BP1-5-7   yes ___ no _X_ abstain ___
> > This is part of a larger issue that has been raised on consistent
> > usage of "data type" and "data object" throughout the LRM, and
> should
> > be dealt with in a Mantis item on that topic.
> >
> > > BP1-5-8   yes ___ no _X_ abstain ___
> > This is part of a larger issue that has been raised on consistent
> > usage of "data type" and "data object" throughout the LRM, and
> should
> > be dealt with in a Mantis item on that topic.
> >
> > > BP1-6-1   yes _X_ no ___ abstain ___
> > > BP1-6-2   yes ___ no ___ abstain _X_
> > I will go along with what the committee decides.
> >
> > > BP1-6-3   yes _X_ no ___ abstain ___
> > > BP1-6-4   yes _X_ no ___ abstain ___
> > > BP1-6-5   yes ___ no _X_ abstain ___
> > This is already covered in Mantis 507, and is scheduled to be
> > corrected in draft 3.
> >
> > > BP1-6-6   yes ___ no ___ abstain _X_
> > I will go with what the committee decides regarding removal of the
> > editor question, but personally I do not think this is an
> appropriate
> > usage of an informative note.  I think this note should either be
> > deleted or be made part of the preceding paragraph.
> >
> > > BP1-7-1   yes ___ no _X_ abstain ___
> > I disagree with the suggested change.  This subclause is
> specifically
> > defining a "memory" as a one-dimensional unpacked array.  There is
> no
> > "fastest varying unpacked dimension".  An array with multiple
> unpacked
>
> > dimensions is not a memory, and referring to one as such would break
> > the VPI definitions of memories and arrays.
> >
> > > BP1-7-2   yes _X_ no ___ abstain ___
> > > BP1-7-3   yes _X_ no ___ abstain ___
> > > BP1-7-4   yes ___ no _X_ abstain ___
> > I disagree with removing the paragraph.  An introduction paragraph
> and
>
> > general definition of a structure is needed.  If the text is not
> > correct, then a proposal on correct wording should be made,
> discussed,
>
> > and voted on.
> >
> > > BP1-8-1   yes _X_ no ___ abstain ___
> > > BP1-9-1   yes _X_ no ___ abstain ___
> > > BP1-9-2   yes _X_ no ___ abstain ___
> > > BP1-9-3   yes _X_ no ___ abstain ___
> > > BP1-9-4   yes _X_ no ___ abstain ___
> > > BP1-10-1  yes _X_ no ___ abstain ___
> > > BP1-10-2  yes _X_ no ___ abstain ___
> > > BP1-10-3  yes _X_ no ___ abstain ___
> > > BP1-11-1  yes _X_ no ___ abstain ___
> > > BP1-12-1  yes ___ no ___ abstain _X_
> > I will go along with the committee decision.  I think it is helpful,
> > but not essential, to mention that a default branch is not the only
> > way to catch x/z values in the case expression.
> >
> > > BP1-12-2  yes _X_ no ___ abstain ___
> > > BP1-12-3  yes _X_ no ___ abstain ___
> > > BP1-12-4  yes _X_ no ___ abstain ___
> > > BP1-12-5  yes _X_ no ___ abstain ___
> > > BP1-13-1  yes _X_ no ___ abstain ___
> > > BP1-13-2  yes _X_ no ___ abstain ___
> > > BP1-13-3  yes _X_ no ___ abstain ___
> > > BP1-13-4  yes _X_ no ___ abstain ___
> > > BP1-13-5  yes _X_ no ___ abstain ___
> > > BP1-13-6  yes _X_ no ___ abstain ___
> > > BP1-13-7  yes _X_ no ___ abstain ___
> > > BP1-22-1  yes _X_ no ___ abstain ___
> > > BP1-22-2  yes _X_ no ___ abstain ___
> > > BP1-22-3  yes _X_ no ___ abstain ___
> > > BP1-22-4  yes _X_ no ___ abstain ___
> > > BP1-22-5  yes _X_ no ___ abstain ___
> > > BP1-A-1   yes _X_ no ___ abstain ___
> > > MH-1      yes ___ no _X_ abstain ___
> > This is a duplicate of BP1-7-4.  A Mantis item should be created
> with
> > a proposal for the exact changes needed.
> >
> > > MH-2      yes ___ no _X_ abstain ___
> > A Mantis item should be created with a proposal for the exact
> changes
> > needed (one Mantis item could cover both MH-1 and MH-2).
> >
> > > MH-3      yes _X_ no ___ abstain ___
> > I approve based on the assumption that the requested change is to
> > delete the words "Verilog syntax for" instead of the currently
> deleted
>
> > "Verilog syntax".
> >
> > > HC-D-1    yes _X_ no ___ abstain ___
> > > HC-D-2    yes _X_ no ___ abstain ___
> > > HC-E-1    yes _X_ no ___ abstain ___
> > > HC-O-1    yes _X_ no ___ abstain ___
> > > HC-O-2    yes _X_ no ___ abstain ___
> > > HC-O-3    yes _X_ no ___ abstain ___
> > > HC-O-4    yes _X_ no ___ abstain ___
> > > HC-O-5    yes _X_ no ___ abstain ___
> > > HC-O-6    yes _X_ no ___ abstain ___
> > > HC-O-7    yes _X_ no ___ abstain ___
> >
> > Most of Heath's issues were about formatting.  The note at the
> > beginning of these annexes already states that formatting still
> needs
> > to be done.
> > No
> > review or voting on this type of issue was needed.
> >
> >
> >
> >
> >
> > --
> > This message has been scanned for viruses and dangerous content by
> > MailScanner, and is believed to be clean.
> >
> >
> > --
> > This message has been scanned for viruses and dangerous content by
> > MailScanner, and is believed to be clean.
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.




-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Thu Apr 26 01:36:48 2007

This archive was generated by hypermail 2.1.8 : Thu Apr 26 2007 - 01:36:57 PDT