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

 

[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.