Re: SystemVerilog draft 6 - structs,unions & packing.

Subject: Re: SystemVerilog draft 6 - structs,unions & packing.
From: Peter Flake (flake@co-design.com)
Date: Fri Apr 26 2002 - 11:23:49 PDT

Kevin,

Since there are existing Verilog simulators, I think it is unrealistic to demand changes to their data structures.

Currently the PLI specification sets constraints e.g. tf_nodeinfo.

I think your suggestion of an alignment control may be useful, but I propose that it should be a tool-specific feature which could be supplied by the attribute mechanism.  For example

(* alignbits=32, little_endian *)
typedef struct packed {
        bit [15:0] count ;
        bit enable;
} Ctrl;  // match compiled alignment

Peter.

At 02:56 PM 4/22/02 -0700, Kevin Cameron wrote:
[Not sure who your question is addressed to.]

One aim of SystemVerilog (certainly Superlog) is to remove the use of VPI/PLI
when integrating C and Verilog. Also, if you are trying to align hardware descriptions
with embedded code (as with the ARM-7 system I'm currently working on) the C
code is being executed on the simulated machine (not through PLI/VPI).

I agree with your statement that the simulator does not have to match the packing of
any particular C compiler, but I consider it a requirement that I can match the packing
of most C compilers when necessary. E.g. if I have a bunch of control bits in a memory
-addressable register I might have the following C-code:

    typedef struct {
    int  count:16,
         enable:1;
  } Ctrl;

  const Ctrl *ctrl_reg = (Ctrl *)0x20000;

  ...
  ctrl_reg->count  = 10;
  ctrl_reg->enable = 1;

The layout of "Ctrl" in C will be exact, if I want to reuse that description in SystemVerilog
I need know which of my 32 bits on the data bus are which in SystemVerilog e.g.:

    union {
    logic [31:0] raw;
    Ctrl         ct;  // as in C
    ...
  } data; // Bus values
   ...
       case (addr)// Address decode
        32'h20000: if (data.ct.enable) begin
                     x = data.ct.count;
                     ....

Currently it appears this may work if my target embedded processor uses the
same alignment and packing as that doing the simulation.
 

Ideally, I would add some syntax so that the SystemVerilog version of the struct
can be derived from the C (like classes in C++) and the alignment added, e.g.:

  struct SV_Ctrl : align (32,little) public Ctrl {}; // match compiled alignment

Since that kind of addition is too much work for 3.0, we need to define what
the default packing and alignment is so that the struct can be written to match
the simulation host instead.

Kev.
 

David Smith wrote:
It seems to me that the issue of C interface is not part of the language. It is not defined anywhere in the LRM. It is defined, within limits, within the VPI/PLI interface. If this is the interface to access data then when the VPI/PLI interface is defined it needs to be handled. One comment is that the packing order used within the simulator does NOT have to match the packing order used in the C code. Since this is different on different systems it will always be inefficient for one of them. The code that supports the C API can choose to guarantee that the packing is always correct for the platform it is on. All this means is that the packing of the bits used within the language must be consistently used within the language. So, where is the C interface designed that will see this data? RegardsDavidDavid W. Smith
Architect

Avant! Corporation
9205 SW Gemini Drive
Beaverton, OR 97008

Voice: 503.520.2715
FAX: 503.643.3361
Email: david_smith@avanticorp.com
http://www.avanticorp.com
-----Original Message-----
From: Kevin Cameron [mailto:Kevin.Cameron@nsc.com]
Sent: Monday, April 22, 2002 12:05 PM
To: vlog-pp@eda.org
Cc: flake@co-design.com
Subject: Re: SystemVerilog draft 6 - structs,unions & packing.
 





Knowing packing order for data in structures is essential for co-simulating hardware
and software. It should be possible to define register layout (bit fields) in a C struct
used by embedded software and have it map consistently to hardware described in
SystemVerilog.

Currently I'm simulating a little-endian ARM 7 system on big-endian Sparc machines.
If SystemVerilog defaulted to big-endian packing of its structures because it was being
run on Sparc, any mapping I set up between SV structs and C structs will not run the
same if I then run the simulation on a Linux/X86 simulator.

SystemVerilog should by default be a simulation platform independent description.

Previous posts:

Vlog-pp - Verilog++: Unions - overlaying bits & logic
Vlog-pp - Verilog++: Re: Unions - overlaying bits & logic

A secondary issue is whether the X/Z information in logic types is orthogonal to the
1/0 values, if it is you should be able to create a union of C and SV types such that
you can extract the C-type 1/0 value, e.g.:

    union {
     int           C;
     logic [31:0]  SV;
  } csvi;

    ....
    csvi.SV = 32'hDEADBEAF;
    csvi.SV = 32'hXXXXXXXX; // X status of bits is othogonal
    ....
    printf ("0x%08X\n",cvsi.C); // C prints 0xDEADBEEF

Currently that doesn't appear to be excluded in the LRM, but makes a huge difference
in how you would approach implementation.

Previous post:

 Vlog-pp - Verilog++: Integer types in BNF
 

There is also no description of how packing "left to right" in System Verilog relates to C packing.

Note: C distinguishes packed and unpacked with the ':' field syntax, e.g.:

  typedef struct { // packed
        int exp:8,
            mag:16;
  } exp_mag;

is not the same as:

 typedef struct { // unpacked
       char  exp;
       short mag;
 } exp_mag;

- "mag" and "exp" will pack differently depending on endianess and whether shorts can be
byte aligned.

Kev.
 

This archive was generated by hypermail 2b28 : Fri Apr 26 2002 - 11:38:58 PDT