Verilog Suports Binary Ouput Surely...... what.... NO!?

[lingwitt]

Does the verilog-2001 standard support writing unformatted, pure,
binary data the way C's fwrite allows?

It would seem like this is a staple of digital design.

Thank you Kindly.

 

lingwitt wrote:

Does the verilog-2001 standard support writing unformatted, pure,
binary data the way C's fwrite allows?

With the Verilog-2001 I/O extensions, you can use $fwrite with a %u
(unformatted) form at descriptor. However, that does write in units
of
32 bits, so anything that is not a multiple of that will get padded.
You
can write individual bytes with the %c format descriptor, though some
implementations have the bug of being unable to write out a 0 byte
that way.

There is also a %z format descriptor, which will write out binary data
in 4-value form. Obviously, this data is only useful for tools that
have
an understanding of 4-value data, such as a waveform tool or another
simulation.

It would seem like this is a staple of digital design.

Not so much. It is useful in some situations, but I am not sure why
you think it would be a staple.

 

[lingwitt]

On Apr 5, 1:32 pm, s...@cadence.com wrote:

lingwitt wrote:
Does the verilog-2001 standard support writing unformatted, pure,
binary data the way C's fwrite allows?

With the Verilog-2001 I/O extensions, you can use $fwrite with a %u
(unformatted) form at descriptor. However, that does write in units
of 32 bits, so anything that is not a multiple of that will get padded.
You can write individual bytes with the %c format descriptor, though some
implementations have the bug of being unable to write out a 0 byte
that way.

There is also a %z format descriptor, which will write out binary data
in 4-value form. Obviously, this data is only useful for tools that
have an understanding of 4-value data, such as a waveform tool or another
simulation.

It would seem like this is a staple of digital design.

Not so much. It is useful in some situations, but I am not sure why
you think it would be a staple.

Thank you for the reply.

I can envision large scale tests in which much data must be validated
or otherwise produced. It simply does not make any sense to use an
ASCII
format for efficiency reasons.

Then again, verilog simulators seem to be woefully slow, so perhaps
this
is the reason that such large scale verilog simulations don't exist.

In any case, I do not understand why verilog would make producing
binary
data from what is supposed to be binary data a task that is difficult.


Rant:

However, other simple tasks (such as reverse bit slicing) are also
difficult.
It just feels like no one really cared about making development
simple.

Verilog reaks of corporate blockheadedness in which people bend
themselves around
their tools in order to get anything working, rather than having tools
do the hard work.

 

[Petter Gustad]

"lingwitt" <lingwitt@gmail.com> writes:

I can envision large scale tests in which much data must be
validated or otherwise produced. It simply does not make any sense
to use an ASCII format for efficiency reasons.

There are compressed binary data formats in use. One of them is the
TRN format used by signalscan. There is an API available from Cadence
so you can post-process these files even the common task is to read
them into your waveform viewer.


Petter
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

 

[Stephen Williams]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Petter Gustad wrote:

"lingwitt" <lingwitt@gmail.com> writes:

I can envision large scale tests in which much data must be
validated or otherwise produced. It simply does not make any sense
to use an ASCII format for efficiency reasons.

There are compressed binary data formats in use. One of them is the
TRN format used by signalscan. There is an API available from Cadence
so you can post-process these files even the common task is to read
them into your waveform viewer.

He (the original poster) is not complaining about waveform output,
he's ranting about general purpose I/O. He apparently wants to do
the sort of stuff that people use C and VPI to do.

- --
Steve Williams "The woods are lovely, dark and deep.
steve at icarus.com But I have promises to keep,
http://www.icarus.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFGFlnLrPt1Sc2b3ikRAo4pAKDHTdG7x2O/EIf/i8RSz9QV5e0KiQCfXx15
O4SidwbFQ9iIK3FVF/Ailus=
=fD4T
-----END PGP SIGNATURE-----

 

[Petter Gustad]

Stephen Williams <spamtrap@icarus.com> writes:

There are compressed binary data formats in use. One of them is the
TRN format used by signalscan. There is an API available from Cadence
so you can post-process these files even the common task is to read
them into your waveform viewer.

He (the original poster) is not complaining about waveform output,
he's ranting about general purpose I/O. He apparently wants to do
the sort of stuff that people use C and VPI to do.

I'm not thinkning about waveform output other than that it's the most
common usage for $recordvars and friends. But rather that you can dump
a set of nets to a (compressed if you like) binary TRN file and then
postprocess it using the provided API later.

Petter
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

 

[lingwitt]

On Apr 6, 10:31 am, Stephen Williams <spamt...@icarus.com> wrote:

Petter Gustad wrote:
"lingwitt" <lingw...@gmail.com> writes:

I can envision large scale tests in which much data must be
validated or otherwise produced. It simply does not make any sense
to use an ASCII format for efficiency reasons.

There are compressed binary data formats in use. One of them is the
TRN format used by signalscan. There is an API available from Cadence
so you can post-process these files even the common task is to read
them into your waveform viewer.

He (the original poster) is not complaining about waveform output,
he's ranting about general purpose I/O. He apparently wants to do
the sort of stuff that people use C and VPI to do.

Thanks for both of the replies.

Indeed, I was expecting to find some
construct supported directly by standard
Verilog. Yet, to my chagrin, one must resort
to the VPI (which looks just as badly thought out).

Neverthless, I looked into TRN, and after numerous
clicking-arounds and google searches, I decided that
if it can't be found easily, it ain't worth it!

Thanks anyhow.

 

[Petter Gustad]

"lingwitt" <lingwitt@gmail.com> writes:

Neverthless, I looked into TRN, and after numerous
clicking-arounds and google searches, I decided that
if it can't be found easily, it ain't worth it!

TRN is the format used by signalscan from Cadence (former Design
Accelration Inc). Synopsys uses a similar format called VPD (but I
don't know if Synopsys provide an API).

As for writing plain binary files you can look into some older
messages from this group:

http://groups.google.com/group/comp.lang.verilog/browse_frm/thread/509805ccf704ea61/e6943e93addb5ac1?lnk=st&q=&rnum=2#e6943e93addb5ac1

Petter

--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?