RE: [sv-cc] Item 205, proposal ready, summary

Ralph, et al.

Clearly, a lot of thoughtful work has gone into this proposal.
Whether or not we agree to it, I do have a number of other comments,
which may in some cases turn out to be questions.

The new section E.6.8 contains the partial sentence "If a vendor's
implementation uses a different representational scheme, the data can
be marshaled...." If I understood this correctly on my second reading,
the proposal is talking only about allowing a different
representational scheme for packed arrays, but still requiring that the
internal representation of elements of unpacked arrays have a fixed and
predetermined size and alignment. If this is so, then the partial
sentence might better say "If a vendor's implementation uses a
different representational scheme for packed arrays, the data can be
marshaled...." Did I interpret this sentence correctly?

In the revised E.1 (paragraph 5), do you want "require that the
SystemVerilog implemenation format and canonical format be the same
size for packed types" to be rather "require that the SystemVerilog
implementation format and canonical format have the same size and
alignment"?

In that same paragraph, "predicatable" => "predictable".

In E.9.4. Example 3 ... (after C code), the NOTEs should be changed to
have numbers. At least as of 1993, IEEE required this for multiple
notes in a section. If we accept this change, then the comment in the
SystemVerilog code in the preceding section can change to "...indicated
by Note 2 following the code".

Also in the "(after C code)" section, I didn't know what
"6*8svLogicActual32" is supposed to mean.

Finally, in F.1, you refer to "These macros". In the first place, I
think you mean "These typedefs" rather than "These macros". But
secondly, in the context "These" could refer either to the preceding
typedefs or to the following typedefs. Careful formatting (if we pass
it successfully to the editor) would help, but it would be better to
say "The typedefs svBitActual32 and svLogicActual32...."

Regards,
Jim Vellenga

---------------------------------------------------------
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: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] On
] Behalf Of Duncan, Ralph
] Sent: Tuesday, October 26, 2004 1:34 PM
] To: sv-cc@eda.org
] Subject: [sv-cc] Item 205, proposal ready, summary
]
] Item 205, which proposes an approach for making mixed C and
] System Verilog packed types binary compatible,
] is slated for discussion and a vote during this Wednesday's
] meeting. Since the proposal's text changes are
] lengthy, here is a short rationale and technical summary of
] the proposal.
]
] RATIONALE
] We propose gaining binary compatibility for embedded packed
] types by requiring vendors to deliver embedded
] packed types with specified size and alignment properties.
] The approach's salient properties are:
] . We gain usability -- a single, binary compatibility
] level -- by accepting a vendor constraint.
] . The approach does not dictate vendors' internal
] organization of packed types.
] . A performance overhead for using packed types this way
] is likely -- we think the tradeoff is worthwhile.
] . 4-byte allocation chunks are likely to minimize
] marshalling for the most common cases.
] . The proposed user macros reveal packed types' array
] dimensions and data type in an intuitive way.
]
] SUMMARY
] . Standardize the size of packed type 'actual' implementation
] formats, making canonical and actual format sizes
] identical for 2 and 4-state arrays, respectively. Thus,
] their size in 4-byte chunks becomes
] 2-state: ((widthInBits + 31) / 32)
] 4-state: ((widthInBits + 31) / 32) * 2
]
] . Define 2 types, svBitActual32 and svLogicActual32 that
] supply the C compiler with a base type for packed types'
] actual formats. These types are used to convey size and
] alignment information, not to specify internal organization.
]
] typedef unsigned int svBitActual32;
] typedef struct {unsigned int part1; unsigned int
] part2;} svLogicActual32;
]
] . Add macro SV_PACKED_DATA_NELEMS(N) to report the number of
] array elements (array "chunks") needed to
] represent a 2-state or 4-state packed datatype in either
] actual or canonical format: i.e., (width + 31) / 32.
]
] COMMENTS
] . Suggested improvements to these definitions that would
] apply both to this matter and to other DPI definitions or sections
]
] are welcome but would best be considered separately.
]
] . The URL for the full discussion, examples and text-change
] proposal is:
]
] http://www.eda.org/svdb/bug_view_page.php?bug_id=0000205
] <http://www.eda.org/svdb/bug_view_page.php?bug_id=0000205>
]
] Thanks for your time spent considering this matter,
] Ralph
]
] Ralph Duncan
] Mentor Graphics
] San Jose, CA
]
]
]
]
]
Received on Tue Oct 26 12:14:25 2004