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
>> 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
> 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?
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
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
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
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.
> 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:<87hd5c9...@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.
> 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>
> 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.
> Kai Harrekilde-Petersen <k...@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 :-)
Thank you ^_^
But how to use $sformat to make up new file name - say inp0.dat,
inp1.dat ?
Best regards,
Davy
$sformat (file_name_str, "inp%0d.dat", i);
$readmemh(file_name_str...)
Ajeetha, CVC