Portability of files written with %z

[Jonathan Bromley]

I've spent a while staring at the Verilog-2001 LRM (section
17.1.1.2, Format Specifications) trying to decide what should
happen when you write stuff with %z (4-state binary I/O).

I am happy to accept that the resulting file will differ
on various platforms because of byte ordering, endianness,
struct alignment issues and all the usual suspects.
However, my reading of the LRM leads me to believe that
such files should be interoperable between simulators
on a single platform, because the I/O machinery is
specified at quite a low level.

Contrariwise, I have two well-known simulators giving different
results on the same platform (32-bit Intel Linux). Basically
they are both writing out 32-bit words in little-endian order,
but they are swapping the aval and bval words.

For example:

reg [31:0 v;
...
v = 32'0xz1; // aval = 0x00_00_0F_01
// bval = 0x00_00_0F_F0
$fwrite(f, "%z", v);

gives the following byte-streams (using "od -t x1"):

simulator A:
01 0F 00 00 F0 0F 00 00
simulator B:
F0 0F 00 00 01 0F 00 00

I am entirely convinced that this is a Bad Thing (tm).
However, I would value the community's opinions on
whether it's a violation of the LRM.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL, Verilog, SystemC, Perl, Tcl/Tk, Verification, Project Services

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, BH24 1AW, UK
Tel: +44 (0)1425 471223 mail:jonathan.bromley@doulos.com
Fax: +44 (0)1425 471573 Web: http://www.doulos.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[Jonathan Bromley]

On 2 Feb 2005 11:22:15 -0800, sharp@cadence.com wrote:

The key phrase in the LRM is "as if ... the data were in a
s_vpi_vecval structure (See 27.14, Figure 179)." If you
look at that structure definition, you will see that the fields
are defined in the order aval then bval. Simulator B is
not compliant with the standard.

Thanks, that was my interpretation too. However... I guessed
that Simulator B was trying to keep interoperability with
versions of itself running on 64-bit platforms, where (perhaps)
a struct of two ints might possibly be written out by write(2)
as a single 64-bit word, which could (depending on your point
of view) entail swapping the aval and bval.

Simulator B also has a less controversial and probably more
alarming bug, in its implementation of %u - it writes out
the aval word, unmodified, instead of doing the Right Thing
by flattening x and z bits to zero. (How hard is it to
calculate (s.aval & ~s.bval) ?)

Neither simulator is one of yours
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL, Verilog, SystemC, Perl, Tcl/Tk, Verification, Project Services

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, BH24 1AW, UK
Tel: +44 (0)1425 471223 mail:jonathan.bromley@doulos.com
Fax: +44 (0)1425 471573 Web: http://www.doulos.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

Jonathan Bromley wrote:

I guessed
that Simulator B was trying to keep interoperability with
versions of itself running on 64-bit platforms, where (perhaps)
a struct of two ints might possibly be written out by write(2)
as a single 64-bit word, which could (depending on your point
of view) entail swapping the aval and bval.

Actually, I believe that the original implementors of
Simulator B decided to use an internal representation
with the aval and bval reversed. This was apparently
to get some small (real or imagined) performance gain
for certain operations. With more modern machines,
any such gains are almost certainly gone, but their
internal representation remains reversed.

This leaves them with the continuing problem that
their internal representation is backwards from what
the standard specifies for VPI and the %z format.
This presumably slows down their VPI, due to the need
to swap the data. Apparently they decided to have %z
write out their internal representation, instead of
complying with the standard. Of course, this makes
their output wrong for any other tool that reads it.
It will only work when read back in by Simulator B
(which may be the most common case anyway).

It is possible that this decision was not a conscious
one. The implementor of %z may not have read the LRM
carefully, or may not have realized that their
internal representation was backwards from the one in
the standard.

Simulator B also has a less controversial and probably more
alarming bug, in its implementation of %u - it writes out
the aval word, unmodified, instead of doing the Right Thing
by flattening x and z bits to zero. (How hard is it to
calculate (s.aval & ~s.bval) ?)

Not hard. This could be a conscious decision to
deviate from the standard to try to get a speed gain
(which is likely to be insignificant compared to the
cost of performing I/O). Or it could be that the %u
implementation was done by someone who was not careful
or experienced enough to do it right.

Neither simulator is one of yours

Well, I knew Simulator B wasn't ours.

 

Tristan Gingold wrote:

Sure, but there are no rules in the C language which defines how the
structure is mapped in memory...

This is incorrect. From 5.6.4 of "C, a Reference Manual",
by Harbison and Steele:

"C compilers are constrained to assign components
increasing memory addresses in a strict order, with the
first component starting at the beginning address of the
structure itself."

Padding is allowed, but the declared order must be
preserved.

Even if this were not the case, and the C compiler were
allowed to use a different order, this would not allow
%z to use an arbitrary order. It would still have to
match the order of the particular C compiler supported
for PLI. This allows a separate C program compiled with
that same C compiler to read the data back in to a
s_vpi_vecval structure with predictable behavior. If
two simulators support the same C compiler on the same
platform, it should also make the %z format portable
between them.