RE: [sv-bc] packed union net ?

From: Radosław Nawrot <Radoslaw.Nawrot@aldec.com.pl>
Date: Mon Oct 13 2014 - 06:08:43 PDT
but resolution function is optional 
  _____  

From: Bresticker, Shalom [mailto:shalom.bresticker@intel.com] 
Sent: Monday, October 13, 2014 3:03 PM
To: Radosław Nawrot; 'SV-BC'
Subject: RE: [sv-bc] packed union net ?



In user-defined net types, the resolution method is user-defined. There is
no built-in resolution function. Maybe I am not understanding you.

 

From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of Rados?aw
Nawrot
Sent: Monday, October 13, 2014 16:01
To: Bresticker, Shalom; 'SV-BC'
Subject: RE: [sv-bc] packed union net ?

 

Ok.
I'm just wondering : why isn't it allowed with the same resolution method as
in user-defined net types ?


Regards,
Radek

  _____  

From: Bresticker, Shalom [mailto:shalom.bresticker@intel.com] 
Sent: Monday, October 13, 2014 2:48 PM
To: Radosław Nawrot; 'SV-BC'
Subject: RE: [sv-bc] packed union net ?

Thanks.

 

It was deliberate for wires not to be allowed 2-state built-in data types,
because such drivers can have multiple or no drivers, resulting in X or Z
states, which 2-state data types cannot express.

 

Regards,

Shalom

 

From: Radosław Nawrot [mailto:Radoslaw.Nawrot@aldec.com.pl] 
Sent: Monday, October 13, 2014 15:42
To: Bresticker, Shalom; 'SV-BC'
Subject: RE: [sv-bc] packed union net ?

 

BNF allow it :

net_declaration12 ::= // from A.2.1.3

net_type [ drive_strength | charge_strength ] [ vectored | scalared ]

data_type_or_implicit [ delay3 ] list_of_net_decl_assignments ;

 

data_type_or_implicit ::=

data_type

| implicit_data_type

 

data_type ::=

integer_vector_type [ signing ] { packed_dimension }

| integer_atom_type [ signing ]

| non_integer_type

| struct_union [ packed [ signing ] ] { struct_union_member {
struct_union_member } }

{ packed_dimension }13

| enum [ enum_base_type ] { enum_name_declaration { , enum_name_declaration
} }

{ packed_dimension }

| string

| chandle

| virtual [ interface ] interface_identifier [ parameter_value_assignment ]
[ . modport_identifier ]

| [ class_scope | package_scope ] type_identifier { packed_dimension }

| class_type

| event

| ps_covergroup_identifier

| type_reference14

 

Additionally  (As a workaround ) user can define own nettype:

 

6.6.7 (User-defined nettypes):

Certain restrictions apply to the data type of a net with a user-defined
nettype. A valid data type shall be

one of the following:

a) A 4-state integral type, including a packed array, packed structure or
union.

b) A 2-state integral type, including a packed array, packed structure or
union with 2-state data type

members.

 

BTW : Is it inconsequence that LRM allows 2-state user-defined nets but
disallows (according to 6.7.1 citatum ) 2-state build-in net ?

 

Radek

 

  _____  

From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of
Bresticker, Shalom
Sent: Sunday, October 12, 2014 3:07 PM
To: 'SV-BC'
Subject: [sv-bc] packed union net ?

Can a net be a packed union ?

 

6.7.1 says,

 

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) A fixed-size unpacked array or unpacked structure, where each element has
a valid data type for a net.

 

However, 6.11.1 defines packed unions as integral types:

 

"The term integral is used throughout this standard to refer to the data
types that can represent a single basic

integer data type, packed array, packed structure, packed union, enum
variable, or time variable."

 

Thanks,

Shalom

 

Shalom Bresticker 
Communications & Storage Infrastructure Group Design Automation

Intel Jerusalem, Israel 
+972  2 589 6582 (office) 
+972 54 721 1033 (cell) 
http://www.linkedin.com/in/shalombresticker 

The devil is in the details.

 

---------------------------------------------------------------------
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.


-- 
This message has been scanned for viruses and 
dangerous content by  <http://www.mailscanner.info/> MailScanner, and is 
believed to be clean. 

---------------------------------------------------------------------
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.


-- 
This message has been scanned for viruses and 
dangerous content by  <http://www.mailscanner.info/> MailScanner, and is 
believed to be clean. 

---------------------------------------------------------------------
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.


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Mon Oct 13 06:09:20 2014

This archive was generated by hypermail 2.1.8 : Mon Oct 13 2014 - 06:09:25 PDT