[sv-cc] RE: Typespec diagram : Section 32.17

Tapati has opened a whole new can of worms here that
affects 32.14 as well.

If we treat my_arr as an "array var", we can't extract
the individual bits via the "var bit" relationship.
If we treat it as a "bit var", we can't extract the
elements of type "a" -- nor the type of those elements.

Until today I hadn't looked closely at the syntax and
other statements in the LRM that make the declaration
of "my_arr" possible.  I had assumed (without thinking
much about it) that a packed array had an element type
of either "bit" or "logic".  But the LRM clearly allows
a packed array in which the element type is a packed
structure.

Oh, well, we still have 7 hours to figure out a solution.
;-)

Regards,
Jim V.

--------------------------------------------------------- 
James H. Vellenga                            978-262-6381 
Engineering Director                   (FAX) 978-262-6636 
Cadence Design Systems, Inc.         vellenga@cadence.com 
270 Billerica Rd 
Chelmsford, MA 01824-4179 
"We all work with partial information." 
---------------------------------------------------------- 
  
 

] -----Original Message-----
] From: Tapati Basu [mailto:Tapati.Basu@synopsys.com] 
] Sent: Monday, May 09, 2005 5:06 PM
] To: sv-cc@eda.org; Jim Vellenga
] Subject: Typespec diagram : Section 32.17
] 
] What should be the Typespec of this variable ? 
] 
] bit [2:0][3:0][4:0] a ??
] 
] If I return the type as bit Typespec, then I can get the 
] ranges using ranges 
] iterate. That is fine, But then how do we represent this scenario ? 
] 
] typedef struct packed{
]    bit i;
]    bit j;
] }a;
] 
] a [2:0][3:0][4:0] my_arr 
] 
] What should be the typespec of this ? 
] 
] Can anybody please answer me ? 
] 
] - Tapati 
]   
]   
] 
] 
] >X-Authentication-Warning: server.eda.org: majordom set sender to 
] owner-sv-cc@eda.org using -f
] >X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
] >Content-class: urn:content-classes:message
] >MIME-Version: 1.0
] >Subject: [sv-cc] A couple of comments on 345
] >Date: Mon, 9 May 2005 15:35:04 -0400
] >Thread-Topic: A couple of comments on 345
] >Thread-Index: AcVUzjLfiUO7413xQX6VkTZHEHjhwQ==
] >From: "Jim Vellenga" <vellenga@cadence.com>
] >To: "Steven Dovich" <dovich@cadence.com>, "SV-CC" <sv-cc@eda.org>
] >X-Received: By mailgate2.Cadence.COM as MAA18705 at Mon May  
] 9 12:32:33 2005
] >X-Virus-Scanned: ClamAV 0.83/873/Mon May  9 09:36:51 2005 on 
] server.eda.org
] >X-Virus-Scanned: ClamAV 0.83/873/Mon May  9 09:36:51 2005 on 
] server.eda.org
] >X-Virus-Status: Clean
] >Content-Transfer-Encoding: 8bit
] >X-MIME-Autoconverted: from quoted-printable to 8bit by 
] server.eda.org id 
] j49JZ74Y021043
] >X-pstn-levels: (S:99.90000/99.90000 R:95.9108 P:95.9108 
] M:97.0232 C:98.7678 )
] >
] >In 26.3.8, there seems to be a stray word "comp".
] >
] >In the same section, the note talks about "by direct
] >lookup".  As far as I can tell, this is a phrase that
] >is new to 1364.  Does it mean via vpi_handle_by_name?
] >If so, perhaps it would be simpler to say "through
] >object relationships or via vpi_handle_by_name."
] >
] >Also, in the same note, would Stu prefer the use of
] >"can" rather than "may"?
] >
] >Regards,
] >Jim V.
] >
] >--------------------------------------------------------- 
] >James H. Vellenga                            978-262-6381 
] >Engineering Director                   (FAX) 978-262-6636 
] >Cadence Design Systems, Inc.         vellenga@cadence.com 
] >270 Billerica Rd 
] >Chelmsford, MA 01824-4179 
] >"We all work with partial information." 
] >---------------------------------------------------------- 
] >  
] 
] Tapati Basu
] 
] 
] 
]