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

From: Duncan, Ralph <ralph_duncan@mentorg.com>
Date: Tue Oct 26 2004 - 10:33:44 PDT

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

Thanks for your time spent considering this matter,
Ralph

Ralph Duncan
Mentor Graphics
San Jose, CA
Received on Tue Oct 26 10:33:51 2004

This archive was generated by hypermail 2.1.8 : Tue Oct 26 2004 - 10:34:04 PDT