Icarus verilog simulation time

[Simon]

Does anyone have a good idea for how fast Icarus ought to be ? I'm
trying to decide whether I'm asking too much of it, or whether I've got
a bug that's causing it problems...

[simon@atlantis ~]$ date && vvp -v a.out && date
Thu Jul 22 23:12:31 BST 2004
Compiling VVP ...
Compile cleanup...
... Linking
... Removing symbol tables
... 2119 functors
766 table
336 bufif
136 resolv
194 variable
... 1058 opcodes (49152 bytes)
... 236 nets
... 6 memories
... 14 scopes
... 0.06999 seconds, 15244.0/2108.0/14024.0 KBytes size/rss/shared
Running ...
(and we wait...)

I initially let this run for an hour or so, I'm about to leave it
running overnight. The machine is a Linux box running Fedora Core 2 on
AMD64, and is usually fairly snappy. I'm running the latest snapshot of
icarus.



I tested Icarus on another (far simpler test module and it all
seemed to work fine:

[simon@atlantis test]$ vvp -v a.out
Compiling VVP ...
Compile cleanup...
... Linking
... Removing symbol tables
... 65 functors
0 table
0 bufif
0 resolv
64 variable
... 22 opcodes (24576 bytes)
... 2 nets
... 0 memories
... 1 scopes
... 0.000999 seconds, 14668.0/1528.0/14024.0 KBytes size/rss/shared
Running ...
0 a = 2, b = 4
5 a = 6, b = 4
10 a = 6, b = 5
15 a = 11, b = 5
20 a = 11, b = 10
25 a = 21, b = 10
30 a = 21, b = 20
35 a = 41, b = 20
... -2.1684E-19 seconds, 14668.0/1596.0/14024.0 KBytes size/rss/shared
Event counts: (event pool = 341)
20 thread schedule events
0 propagation events
0 assign events
0 other events


If I am asking too much of the simulator, is there a rough guide
somewhere as to what are the most-limiting factors, and how far you can
push them - I've tried googling, but for once the online
god-of-knowledge has failed :-(

Simon

 

[Chris Briggs]

ptkwt@aracnet.com (Phil Tomson) wrote in message

Yes, but even though it was a coding error on your part it should be
possible for the simulator to detect this kind of condition and issue
warnings. Some simulators do this: after a certain number of events in
the current delta-cycle (say 10000000 ) without simulation time being
advanced they issue a warning so that you would have seen it after a
minute or two. It would probably not be too difficult to add this to
Icarus, but then again I haven't looked at the Icarus source for a while
so maybe it wouldn't be so easy. If it causes a performance hit (it
should be negligable, but it is an extra condition to check during each
delta-cycle, so there is some overhead), perhaps a command-line switch
could be added to enable/disable this behavior.

I agree this sounds like a good feature, and conceptually it seems
simple enough, but who knows how complicated these things are? I'm
curious as to what simulators you've seen this in. Lately I've been
using NC-Verilog, but I've also used VCS and Finsim, and to my
knowledge none of them have this feature. (In fact, I know Finsim
didn't when I used it because at one point I had a 0-time loop that
bogged down the server for the whole class.)

One thing I like to add to my testbenches is a "heartbeat" message. At
it's most basic it's just:
initial forever #100000 $display("heartbeat");
I also have mine print the simulation time plus the system date and
time. You pick a delay whereby you see one of these messages every 30
seconds to a minute (or whatever interval you like) and so the absence
of one for longer indicates a problem.

-cb

 

[Chris Briggs]

Simon <news@gornall.net> wrote in message news:<f0YLc.838$eV.16@newsfe1-gui.ntli.net>...

(and we wait...)

Well, if it never finishes you probably have some other problem. Maybe
you're never getting the condition which triggers your $stop or
$finish. Or it's possible you have a zero-time loop (probably caused
by a race condition) in your code and simulation time isn't advancing.

I would start by capturing waves and figuring out if it's getting
stuck somewhere. Note that if it is a zero-time loop, waves might not
be able to show it because the info you need to see might be buffered
at that point and never written to the waves file.

-cb

 

[Simon]

Chris Briggs wrote:

Well, if it never finishes you probably have some other problem. Maybe
you're never getting the condition which triggers your $stop or
$finish. Or it's possible you have a zero-time loop (probably caused
by a race condition) in your code and simulation time isn't advancing.

I would start by capturing waves and figuring out if it's getting
stuck somewhere. Note that if it is a zero-time loop, waves might not
be able to show it because the info you need to see might be buffered
at that point and never written to the waves file.

Cheers - I'd left it running overnight, and with 11 hours work, when I
hit CTRL-C it told me it was on tick 0!

Anyway, it turned out to be a stupid mistake in the embedded RAM
initialisation statements. What I wasn't sure about (never used Icarus
before) was just how long it took to initialise the simulation - I was
pretty sure it shouldn't be 11 hours though

Now all I've got to do is figure out why...

wire [`MSB:0] pcNew = pc + branchOffset;

.... isn't adding two perfectly valid numbers together whenever the
branchOffset is negative. Maybe I'll make my branches absolute [grin]
Bound to be another stupid mistake and it's late...

Simon.

 

[Phil Tomson]

In article <f8e87dac.0407230628.28f4b7a1@posting.google.com>,
Chris Briggs <chris@engim.com> wrote:

Simon <news@gornall.net> wrote in message
news:<f0YLc.838$eV.16@newsfe1-gui.ntli.net>...
(and we wait...)

Well, if it never finishes you probably have some other problem. Maybe
you're never getting the condition which triggers your $stop or
$finish. Or it's possible you have a zero-time loop (probably caused
by a race condition) in your code and simulation time isn't advancing.

If this were the case wouldn't he get some sort of warning about a race
condition (some simulators check to see if simulation time isn't advancing
and warn you after a certain number of delta-time events)? I'm not sure
if Icarus does this, but it seems like it would be fairly easy to add and
perhaps enable/disable with a command-line option.

Phil

 

[Phil Tomson]

In article <fegMc.902$ub4.896@newsfe5-gui.ntli.net>,
Simon <news@gornall.net> wrote:

Chris Briggs wrote:

Well, if it never finishes you probably have some other problem. Maybe
you're never getting the condition which triggers your $stop or
$finish. Or it's possible you have a zero-time loop (probably caused
by a race condition) in your code and simulation time isn't advancing.

I would start by capturing waves and figuring out if it's getting
stuck somewhere. Note that if it is a zero-time loop, waves might not
be able to show it because the info you need to see might be buffered
at that point and never written to the waves file.

Cheers - I'd left it running overnight, and with 11 hours work, when I
hit CTRL-C it told me it was on tick 0!

I guess that answers my previous question.

Anyway, it turned out to be a stupid mistake in the embedded RAM
initialisation statements.

Yes, but even though it was a coding error on your part it should be
possible for the simulator to detect this kind of condition and issue
warnings. Some simulators do this: after a certain number of events in
the current delta-cycle (say 10000000 ) without simulation time being
advanced they issue a warning so that you would have seen it after a
minute or two. It would probably not be too difficult to add this to
Icarus, but then again I haven't looked at the Icarus source for a while
so maybe it wouldn't be so easy. If it causes a performance hit (it
should be negligable, but it is an extra condition to check during each
delta-cycle, so there is some overhead), perhaps a command-line switch
could be added to enable/disable this behavior.


Phil

 

[Shalom Bresticker]

If pc is an unsigned variable (e.g, if it is declared as 'reg'),
then branchOffset will be interpreted as unsigned in the addition operation even
if it is of a signed type.

Shalom


Simon wrote:

Now all I've got to do is figure out why...

wire [`MSB:0] pcNew = pc + branchOffset;

... isn't adding two perfectly valid numbers together whenever the
branchOffset is negative. Maybe I'll make my branches absolute [grin]
Bound to be another stupid mistake and it's late...

--
Shalom Bresticker Shalom.Bresticker @freescale.com
Design & Reuse Methodology Tel: +972 9 9522268
Freescale Semiconductor Israel, Ltd. Fax: +972 9 9522890
POB 2208, Herzlia 46120, ISRAEL Cell: +972 50 5441478

 

[ka]

On Fri, 23 Jul 2004 22:24:11 GMT, Simon <news@gornall.net> wrote:

Now all I've got to do is figure out why...

wire [`MSB:0] pcNew = pc + branchOffset;

... isn't adding two perfectly valid numbers together whenever the
branchOffset is negative. Maybe I'll make my branches absolute [grin]

two's complement numbers can be added together and negative numbers
are handled correctly in verilog (even pre 2001) IF they are sized
correctly. Are you size-extending branchOffset to the size of pc
correctly ? If your offset is smaller than your pc size (which is a
common way of encoding the offsets in the instruction set) you need to
sign-extend it to the size of the pc for adding a negative number to
work.

 

[Simon]

kal wrote:

On Fri, 23 Jul 2004 22:24:11 GMT, Simon <news@gornall.net> wrote:

Now all I've got to do is figure out why...

wire [`MSB:0] pcNew = pc + branchOffset;

... isn't adding two perfectly valid numbers together whenever the
branchOffset is negative. Maybe I'll make my branches absolute [grin]


two's complement numbers can be added together and negative numbers
are handled correctly in verilog (even pre 2001) IF they are sized
correctly. Are you size-extending branchOffset to the size of pc
correctly ? If your offset is smaller than your pc size (which is a
common way of encoding the offsets in the instruction set) you need to
sign-extend it to the size of the pc for adding a negative number to
work.

That was exactly it - I found it last night. I wasn't *too* worried,
because it was part of the:

add rdst, rA, rA, immediate
sub rdst, rA, rB, immediate

.... constructs, and because these are inverse functions you could get
the desired behaviour in both directions. However having it signed means
you can add 2 large registers and subtract a small offset, which may be
useful, so I've fixed it that 'immediate' is signed

Thanks for the help though

Simon

 

[Phil Tomson]

In article <f8e87dac.0407311908.7b2c69d3@posting.google.com>,
Chris Briggs <chris@engim.com> wrote:

ptkwt@aracnet.com (Phil Tomson) wrote in message
Yes, but even though it was a coding error on your part it should be
possible for the simulator to detect this kind of condition and issue
warnings. Some simulators do this: after a certain number of events in
the current delta-cycle (say 10000000 ) without simulation time being
advanced they issue a warning so that you would have seen it after a
minute or two. It would probably not be too difficult to add this to
Icarus, but then again I haven't looked at the Icarus source for a while
so maybe it wouldn't be so easy. If it causes a performance hit (it
should be negligable, but it is an extra condition to check during each
delta-cycle, so there is some overhead), perhaps a command-line switch
could be added to enable/disable this behavior.

I agree this sounds like a good feature, and conceptually it seems
simple enough, but who knows how complicated these things are? I'm
curious as to what simulators you've seen this in.

I'm pretty sure I've seen this in the ModelSim simulators, but I don't
currently have access to ModelSim to try it out.

Lately I've been
using NC-Verilog,

I know for sure that ncsim doesn't have this feature - I ran into this
recently with a VHDL design and I recall thinking it was a bit bogus to
not have this.

I made up my own HDL/Simulator called RHDL (Ruby Hardware Description
Language) a couple of years ago and I made sure that it included this
feature because I appreciated it in other simulators.

but I've also used VCS and Finsim, and to my
knowledge none of them have this feature. (In fact, I know Finsim
didn't when I used it because at one point I had a 0-time loop that
bogged down the server for the whole class.)

Perhaps ModelSim is the only major simulator that currently has this
feature. Fortunately, Icarus is open source so we could implement this
feature and after testing to make sure it works submit a patch to the
maintainer. I'm thinking this is about 4 lines of code to implement (more
if you add a commandline switch, of course); it shouldn't be a major deal,
but like I said, I haven't looked at the Icarus source for a while.

Phil