[sv-bc] incorrect statement about struct and class type compatibility in section 12.25

From: Francoise Martinolle <fm_at_.....>
Date: Tue Feb 22 2005 - 09:03:20 PST
 
Section 12.25 states:
  

2) SystemVerilog structs are type compatible so long as their bit sizes are
the same, thus copying structs of

different composition but equal sizes is allowed. In contrast, SystemVerilog
objects are strictly stronglytyped.

Copying an object of one type onto an object of another is not allowed.

 

This is a bit obsolete and incorrect.

 

This sentence should detail which kind of structs we are talking about here.
I think we should be comparing

unpacked structs and classes and packed structs and classes. Even though I
think that a class most closely

resembles an unpacked struct (there is no packing requirement for a class
data). 

The rules for assignment compatibility for unpacked structs are different
from the rules for 

assignment compatibility of packed structs. Unpacked structs are strongly
typed. Packed structs are not.

The sentence in the LRM appears to be referring to type equivalence of
packed structs (same number of total

bits, both packed structs being 2 state or 4 state, both packed structs
being signed or unsigned), however the copying

example given suggests that it should talk about assignment compatibility.

I suggest to change the first 2 sentences:

"SystemVerilog structs are type compatible so long as their bit sizes are
the same, thus copying structs of

different composition but equal sizes is allowed. " 

To:

SystemVerilog packed structs are always type assignment compatible.
SystemVerilog unpacked structs are strongly

typed and assignment compatibility between two different struct types
requires struct type equivalence as defined in 

section 6.9.2

The second problem I found is that the statement about systemVerilog class
objects is incorrect.

You can assign a derived class object to a superclass object (advantage of
inheritance)

but not the other way around. I agree that systemVerilog objects are
strongly typed but the last sentence

should be rewritten as perhaps:

"Copying an object of one class type onto an object of a different class
type inheritance hierarchy

is not allowed."

 

Anyway I think that this paragraph should be rewritten.

 

Francoise

     

 
Received on Tue Feb 22 09:03:25 2005

This archive was generated by hypermail 2.1.8 : Tue Feb 22 2005 - 09:03:48 PST