[sv-cc] Packed types (205): discovery and request

DISCOVERY: There appears to be a significant LRM implication with regard
to embedded packed types.
Combining the LRM's sparse remarks about packed types' implementation
dependence (E.6.3-E.6.4) with
the one, specific usage example for embedded packed types (E.9.4),
implies a significant characteristic for
embedded packed types that may far outstrip what the group intended to
guarantee.

BACKGROUND:
1. Embedded packed types are currently source compatible.
2. The standard utility functions and macros -- both binary and
source-compatible -- should work for every vendor.
3. The LRM states that the representation of packed types is
"implementation-dependent" (E.6.3-4).
4. The utilities for bit/logic/part get-from/put-into the simulator
format, not the canonical format (F.1).

THE LRM CODE EXAMPLE (E.9.4):

  typedef struct {
        int a;
        sv_BIT_PACKED_ARRAY(6*8, b) [64]; /* implementation specific
representation */
        int c;
  } triple;

  /* Note that 'b' is defined as for 'bit [6*8-1:0] b [63:0]' */
  <snip>
  void foo(const triple *i)
  {
  int j;
  /* canonical representation */
  svBitVec32 arr[SV_CANONICAL_SIZE(6*8)]; /* 6*8 packed bits */
  <snip>
  printf("%d %d\n", i->a, i->c);
  for (j=0; j<64; j++) {
     svGetBitVec32(arr, (svBitPackedArrRef)&(i->b[j]), 6*8);
  ...
  }

WHAT THE CODE IMPLIES
For the example to work, the simulator's representation (organization)
must be the same for 2-state stand-alone
packed arrays and a struct field that consists of an unpacked array of
2-state packed arrays. This is true because
there is no provision for the standard utility, svGetBitVec32, to
distinguish different simulator formats for various kinds of
packed types (e.g., for embedded vs. non-embedded ones).

WHY IT MAKES A DIFFERENCE
Simulators might not represent stand-alone packed arrays identically to
the 3 embedded forms (unpacked array of
packed array, field of packed array, field of unpacked array of packed
array). The example may be misleading and
only intend to show a specific 2-state implementation where this
relation holds. However, it forces us to think about
what we intend to provide the user.

ALTERNATIVES -- EMBEDDED PACKED ARRAYS
How we think the user handles embedded packed types is strongly tied to
what utilities (if any) we intend to provide.
The basic choices are:

1. User deals with raw vendor packed representation -- no tools;
    the vendor reveals the simulator representation that it
delivers-to-C via documentation (or the user infers it by experiment).

2. User deals with canonical form:
2.a Vendors deliver the same format to C for all embedded and
non-embedded packed types;
       (all the std. utilitites in F.1 work for both kinds).
2.b Vendors supply utilities to convert between embedded and
stand-alone simulator formats or across some other
       aspect where simulator formats differ (e.g.,
GetStandaloneFromPacked,...), then the std. get/put bit/logic/part
utilities
       work on the stand-alone form (and the example is missing this
conversion step).
2.c Vendors supply a separate set of utilities to work on embedded
packed type format(s) that differ from the stand-alone one.

The example suggests we intend 2.a, although it may only intend to do so
for 2-state or for a single implementation.

REQUEST:
Before we pursue discussing how to implement embedded packed types, it
seems wise to consider a fundamental question --
what are we intending to provide to the user by providing embedded
packed types?
Received on Mon Oct 11 13:42:49 2004