Verilog 2001 File I/O: read large file?

[Davy]

Hi all,

I want to read one data @(posedge clock) and compare with my module
output.
The data file may contain one million data and very large.

What's the most efficient way to do it?

My boss told me to use $readmemh, but it seems waste RAM.
Does Verilog 2001 support buffered read like in C? Where can I find the
definition?

BTW, I use Modelsim 6.

Any suggestions will be appreciated!
Best regards,
Davy

 

[Ajeetha]

I would like to understand what kind of design this is to offer
efficient comment/suggestion. On the face of it, the verification
architecture/approach seems to be not well thought out. For e.g. if
this is an image processing system, an offline UNIX diff is a far
better choice.

My boss told me to use $readmemh, but it seems waste RAM.

$readmemh can take start and end addr as well. So you could read say
1024 locations at one go, hence using only a 1K memory.

Does that help?

Regards
Ajeetha, CVC
www.noveldv.com

 

[Petter Gustad]

"Davy" <zhushenli@gmail.com> writes:

I want to read one data @(posedge clock) and compare with my module
output.
The data file may contain one million data and very large.

What's the most efficient way to do it?

$readmemh might be efficient if you have enough memory. If not, you
might want to do something like:

integer patfile;
event eof;

initial begin
patfile = $fopen("pattern.in", "r");
end

always @(posedge clk) begin
$fscanf(patfile,"%1b%4x",yourbitdata,yoursomeother16data);
if ($feof(patfile)) begin
->eof;
end
end

always @(eof) begin
$fclose(patfile);
end

Does Verilog 2001 support buffered read like in C? Where can I find the
definition?

IEEE 1364-2001

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?

 

ModelSim is a relatively slow simulator anyway. VCS and NC are faster.
If the design is too much for ModelSim, you might want to consider
those simulators.

 

Verilog-2001 supports $fscanf calls, similar to C fscanf. The degree
to which it is buffered depends on the implementation in the simulator.
The language does not provide for user control of buffering beyond the
$fflush call to flush the buffers. It is likely that the underlying
implementation is using C stdio, and getting the buffering that comes
with that.

 

[Art Stamness]

If the comparison is simple and can be directly mapped bit for bit to a
two dimensional memory, then I would recommend using the $readmem(h/b)
type of comparison. ( and if the memory isn't too big ).

If the simulation needs to be finished exactly when the first
miscompare is detected, because waiting for an offline comparison would
take too much time, then You can follow some of the other suggestions
posted in this thread about $fopen, $fscanf. I find these to be
painfully slow, and not fun to write or debug, but they absolutely can
work.

The simplest answer, if the test isn't really long, and you can afford
to let the test to run to completion before figuring out the correct
answer is to do an offline comparison :

- Write a BFM that will trace the output that you intend to compare to
some file.
- Write a Perl script to do the comparison off-line. (PERL is very
useful for extracting usefull information from large text files,
Verilog is not).

Sometimes the answer to a programming problem in Verilog is to write an
offline checker in perl. Having more tools at your disposal than just
the HDL language itself, will make for faster and more effective
comparison.

And if you are interested in Verilog Verification jobs in the future,
you will find almost all ( that I have ever seen ) , list Verilog and
Perl as the two key tools to doing large scale verification.

-Art

 

[Davy]

Hi,

The problem is the input reference file is too large to load in just
one time.

When I use NC-Verilog and readmemh(), the PC will crash. I think it's
malloc() is not right.

So how to use readmemh() to read file in several parts?

Best regards,
Davy

 

[Ajeetha]

Hi,
Quick idea:

1. Split your large file to several smaller/manageable ones - should be
straight forward. Say every file is 1K
2. Declare 1K mem in Verilog
3. Use $sformat to make up new file name - say inp0.dat, inp1.dat etc.
4. Use $readmemh(fname, mem)

The 1K above is arbitrary, you can choose optimum based on trial and
error.

Does that help
Ajeetha, CVC
www.noveldv.com

 

There is no way to get $readmemh to start reading a file in the middle.
You would have to do as Ajeetha suggested and break it up into
multiple files.

If your machine is crashing due to executing the $readmemh, then you
should submit a bug report, because that would be a bug in the
simulator. If it is exiting because your Verilog memory was so large
that you exceeded the virtual memory available on your system, then
that is not a bug in the simulator.

As far as speed is concerned, $readmem is probably faster than using
$fscanf. It has probably been tuned more over time, and was more
amenable to tuning because it is more specialized.

 

[Kai Harrekilde-Petersen]

Petter Gustad <newsmailcomp6@gustad.com> writes:

4) Get a better simulator and more memory for your computer. I've
never used modelsim, but several other verilog simulators. VCS has
a pretty low memory footprint. Running on AMD64 under 64-bit Linux
is a good option.

The 64-bit version of Modelsim will run nicely on Opteron/AMD64 and
64-bit Linux. I've done gatelevel sims using 8GB of physical memory
routinely on such a setup.

(Hi Petter. Are you still at Dolphin?)


Kai
--
Kai Harrekilde-Petersen <khp(at)harrekilde(dot)dk>

 

[Petter Gustad]

"Davy" <zhushenli@gmail.com> writes:

The problem is the input reference file is too large to load in just
one time.

When I use NC-Verilog and readmemh(), the PC will crash. I think it's
malloc() is not right.

Is the method described in news:<87hd5c9b2y.fsf@gustad.com> too slow,
i.e. is $scanf to slow? You have several options:

1) Print out the simulated values to a file and compare the file after
your simulation has completed. This could be worthwhile if the
$fscanf implementation is too slow. However if the PLI overhead is
too large you should expect that $display or $write to be slow as
well.

2) Read a larger chunk of expect values using $fscanf

3) Precalculate CRC or some other checksum for chunks of your data,
you can then calculate the CRC for some larger frames of your
simulator generated data and compare it every 1024 (or whatever is
efficient) to the precomputed CRC. You will not know exactly where
it failed, but you will know that it failed (useful for regression
tests) and what chunk it failed in.

4) Get a better simulator and more memory for your computer. I've
never used modelsim, but several other verilog simulators. VCS has
a pretty low memory footprint. Running on AMD64 under 64-bit Linux
is a good option.


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?

 

[Kai Harrekilde-Petersen]

Petter Gustad <newsmailcomp6@gustad.com> writes:

Kai Harrekilde-Petersen <khp@harrekilde.dk> writes:

The 64-bit version of Modelsim will run nicely on Opteron/AMD64 and
64-bit Linux. I've done gatelevel sims using 8GB of physical memory
routinely on such a setup.

Hi Kai! I've been running VCS on Opterons/Athlon-64s. I've find that
VCS is consuming very little memory (of course SDF back-anotation
consumes a bit). Have you compared the memory footprint of Modelsim
and VCS?

No, we did all simulations on Modelsim. I think we used to do some VCS
simulations for signoff, before the 64-bit version of Modelsim came
out, but that's several years back now. Since modelsim was part of our
flow, staying with it was the easy option - and modelsim was fast
enough, anyway. The SDF file was (uncompressed) just over 4GB, but
the simulation without SDF backannotation took less than 3-400MB of
RAM (It's been a year and a job change since then - I don't recall the
details). To give you an order of scale, this was a 7Mgates + 9Mbit
design.

Yes, I'm still at Dolphin.

Say hello to the guys from me


Kai
--
Kai Harrekilde-Petersen <khp(at)harrekilde(dot)dk>

 

[Petter Gustad]

Kai Harrekilde-Petersen <khp@harrekilde.dk> writes:

The 64-bit version of Modelsim will run nicely on Opteron/AMD64 and
64-bit Linux. I've done gatelevel sims using 8GB of physical memory
routinely on such a setup.

Hi Kai! I've been running VCS on Opterons/Athlon-64s. I've find that
VCS is consuming very little memory (of course SDF back-anotation
consumes a bit). Have you compared the memory footprint of Modelsim
and VCS? Anyway, the O.P. seemed to have problems comparing simulation
results with a large expect file. This is most likely not related to
Modelsim, but supported/available memory on the target simulation
platform.

Yes, I'm still at Dolphin.

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?

 

[Davy]

Hi Ajeetha,

Thank you ^_^

But how to use $sformat to make up new file name - say inp0.dat,
inp1.dat ?

Best regards,

Davy

 

[Ajeetha]

From my memory:

$sformat (file_name_str, "inp%0d.dat", i);
$readmemh(file_name_str...)

Ajeetha, CVC

 

Note that $swrite can do this too. $sformat is only needed if the
format itself is a variable.