Re: [sv-bc] mantis 1940

From: Don Mills <mills_at_.....>
Date: Fri Sep 28 2007 - 08:10:00 PDT
Shalom,

But 6.6 does not say anything about vectors.  If you take all references to vectors of  wire or tri out of 6.8, is that to mean that they don't exist in the language anymore?  No, it just won't be in the LRM anymore.  With the changes you are making to 6.8, where in the LRM is the description/rules telling me how to declare a tri-stable data bus?

tri  [15:0]  data_bus;



Bresticker, Shalom wrote:
Don,

In my opinion, 6.6 (Net declarations) should say more clearly that a net
declaration starts with a net kind followed by a data type, where the
data type can be implicit. 

6.6 currently says, 

"A net declaration begins with a net type that determines how the values
of the nets in the declaration are resolved. The declaration can include
optional information such as delay values and drive or charge strength.
...
If a set of nets share the same characteristics, they can be declared in
the same declaration statement.

Any 4-state data type can be used to declare a net. For example:

trireg (large) logic #(0,0,0) cap1;
typedef logic [31:0] addressT;
wire addressT w1;
wire struct packed { logic ecc; logic [7:0] data; } memsig;

If a data type is not specified in the net declaration, then the data
type of the net is logic.

Certain restrictions apply to the data type of a net. A valid data type
for a net shall be one of the following:

a) A 4-state integral type, including a packed array or packed
structure.
b) An unpacked array or unpacked structure, where each element has a
valid data type for a net."

So the information is actually there.

Also 6.2 defines 'data object' and 'data type'. Maybe we should add
there that a data object has a data type as well as a data value.

Thanks,
Shalom

  
-----Original Message-----
From: owner-sv-bc@server.eda.org 
[mailto:owner-sv-bc@server.eda.org] On Behalf Of Don Mills
Sent: Thursday, September 27, 2007 10:38 PM
To: sv-bc@server.eda.org
Subject: [sv-bc] mantis 1940


Shalom,

Let me see if I can explain the issue/question I have with 
this proposed change.  You state:

"But 'net types' refers to wire, trireg, etc. These are 'net 
kinds' or 'resolution types', not 'data types'. In contrast 
to 1364, they have no size. Size is not relevant to them. 
Only data types have size. So 'net types' should not be 
mentioned here."

With this sentence in mind I can understand scrubbing "net" 
and "net type" for the text in 6.8 and 6.8.1 as noted in the 
changed text.  But now when I read the new text from the 
proposal it make the following appear to be illegal.

wire [15:0] data_bus;

Of course this is legal but then where is the section in the 
LRM that defines a bundle of wire's as a vector.  Section 6.6 
is on Net declarations, 6.7 is on Variable declarations, and 
6.8 is on Vector declarations.  If we remove the textural 
references to "net" and "net type" in section 6.8, then the 
only implication that we can have a declaration as noted 
above is in the example in section 6.8.  I think that we need 
to have some verbiage somewhere that defines vectors of wire 
(and other net types) similar to what you are putting in the 
new text in section 6.8.  Maybe another paragraph in section 
6.8 or maybe another subsection in 6.8.  I think an 
additional paragraph would make sense.

Now the next question is, did I express myself clear enough 
here to communicate my concern?
    
---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

  

-- 
==========================================================
Don Mills
mills@lcdm-eng.com
www.lcdm-eng.com
==========================================================

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean. Received on Fri Sep 28 08:11:49 2007

This archive was generated by hypermail 2.1.8 : Fri Sep 28 2007 - 08:12:12 PDT