RE: [sv-bc] packed union net ?

From: Bresticker, Shalom <shalom.bresticker@intel.com>
Date: Mon Oct 13 2014 - 06:11:01 PDT
If no resolution function is defined, then multiple drivers are not allowed. It is true that in the case of no driver, you would still get a Z turning to 0.

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

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> [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> [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 MailScanner<http://www.mailscanner.info/>, 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<http://www.mailscanner.info/>, 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.
---------------------------------------------------------------------
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:11:59 2014

This archive was generated by hypermail 2.1.8 : Mon Oct 13 2014 - 06:12:04 PDT