How to really confuse the heck outta ModelSim

A

Andy Peters

Guest
Here's a good one.

reg c, r;
reg [3:0] d;
wire [3:0] q;

generate
genvar n;
for (n = 0; n < 4; n = n + n) begin : FooGen
foo bar
(.c (c),
.r (r),
.d (d[n]),
.q (q[n]));
end / FooGen
endgenerate

The ol' vlib command went off into la-la land, and froze the
application. (Had to kill it w/TaskMan).

Fixing the n = n + n typo made it all better. Note to self: use
larger font. Think while typing...

-a
 
Yup, sometimes I'll leave Task Manager open while running modelsim. My
clumsy fingers hit some wrong keys, and then I have to stamp out all
those vish and vlm things. Oh well, it's still a great simulator.

Check your operating system's temp directory occasionally. I found
gigabytes of modelsim droppings in mine.
 
On 6 Feb 2004 12:35:22 -0800, Bassman59a@yahoo.com (Andy Peters)
wrote:

Here's a good one.

reg c, r;
reg [3:0] d;
wire [3:0] q;

generate
genvar n;
for (n = 0; n < 4; n = n + n) begin : FooGen
foo bar
(.c (c),
.r (r),
.d (d[n]),
.q (q[n]));
end / FooGen
endgenerate

The ol' vlib command went off into la-la land, and froze the
application. (Had to kill it w/TaskMan).

Fixing the n = n + n typo made it all better. Note to self: use
larger font. Think while typing...
Click to expand...
vlib? or vsim?

Allan.
 
Allan Herriman <allan.herriman.hates.spam@ctam.com.au.invalid> wrote in message news:<8q09209j0d6v9b6cjiiqdridkhfurhu11k@4ax.com>...
On 6 Feb 2004 12:35:22 -0800, Bassman59a@yahoo.com (Andy Peters)
wrote:

Fixing the n = n + n typo made it all better. Note to self: use
larger font. Think while typing...

vlib? or vsim?
Click to expand...
vsim, of course. Note to self: use larger font. Think BEFORE typing ...

--a
 
Bassman59a@yahoo.com (Andy Peters) wrote in message news:<9a2c3a75.0402061235.486dc2b4@posting.google.com>...
The ol' vlib command went off into la-la land, and froze the
application. (Had to kill it w/TaskMan).
Click to expand...

For comparison, NC-Verilog stops quickly with an error:

for (n = 0; n < 4; n = n + n) begin: FooGen
|
ncelab: *E,CUFGSX (./x.v,8|3): Infinite loop in for-generate statement.
 
sharp@cadence.com (Steven Sharp) wrote in message news:<3a8e124e.0402101440.7d876334@posting.google.com>...
Bassman59a@yahoo.com (Andy Peters) wrote in message news:<9a2c3a75.0402061235.486dc2b4@posting.google.com>...

The ol' vlib command went off into la-la land, and froze the
application. (Had to kill it w/TaskMan).


For comparison, NC-Verilog stops quickly with an error:

for (n = 0; n < 4; n = n + n) begin: FooGen
|
ncelab: *E,CUFGSX (./x.v,8|3): Infinite loop in for-generate statement.
Click to expand...
Time to submit a bug report, methinks ...

-a
 
Steven Sharp <sharp@cadence.com> wrote:
: Bassman59a@yahoo.com (Andy Peters) wrote in message news:<9a2c3a75.0402061235.486dc2b4@posting.google.com>...
: >
: > The ol' vlib command went off into la-la land, and froze the
: > application. (Had to kill it w/TaskMan).


: For comparison, NC-Verilog stops quickly with an error:

: for (n = 0; n < 4; n = n + n) begin: FooGen
^^^^^
Are you sure you didn't mean n = n + 1 ?

With n = 0, n = n + n never will reach 4!

Bye
--
Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
 
On 11 Feb 2004 12:06:17 -0800, Bassman59a@yahoo.com (Andy Peters)
wrote:

sharp@cadence.com (Steven Sharp) wrote in message news:<3a8e124e.0402101440.7d876334@posting.google.com>...
Bassman59a@yahoo.com (Andy Peters) wrote in message news:<9a2c3a75.0402061235.486dc2b4@posting.google.com>...

The ol' vlib command went off into la-la land, and froze the
application. (Had to kill it w/TaskMan).


For comparison, NC-Verilog stops quickly with an error:

for (n = 0; n < 4; n = n + n) begin: FooGen
|
ncelab: *E,CUFGSX (./x.v,8|3): Infinite loop in for-generate statement.

Time to submit a bug report, methinks ...
Click to expand...
It's time to repeat that "Think BEFORE typing" mantra.

I'm surprised that NC-Verilog caught that infinite loop, since the
halting problem isn't solvable (in general) and trivial tests, such as
checking that n is assigned within the loop, wouldn't have picked up
this particular bug.

Do you suppose that it just has an iteration counter with a threshold,
or did it prove that there was an infinite loop in this case?


That reminds me of this piece of VHDL that would stop Modelsim in its
tracks:

clk <= not clk;

Someone (not me) forgot to add a time delay to the assignment, and
vsim would just sit there all day, toggling the clock without
advancing the simulation time.

Regards,
Allan.
 
Allan Herriman <allan.herriman.hates.spam@ctam.com.au.invalid> wrote in message news:<9dll20tthnivgo9u0135ur0498uoebh467@4ax.com>...
On 11 Feb 2004 12:06:17 -0800, Bassman59a@yahoo.com (Andy Peters)
wrote:

sharp@cadence.com (Steven Sharp) wrote in message news:<3a8e124e.0402101440.7d876334@posting.google.com>...

I'm surprised that NC-Verilog caught that infinite loop, since the
halting problem isn't solvable (in general) and trivial tests, such as
checking that n is assigned within the loop, wouldn't have picked up
this particular bug.

Do you suppose that it just has an iteration counter with a threshold,
or did it prove that there was an infinite loop in this case?
Click to expand...
In this case it proved that there was an infinite loop and quit
immediately. It can do that for many cases, including the cases
most likely to come up by mistake. It has an iteration counter
with a threshold to catch the rest, and produces a slightly different
error in that situation.

It would actually be possible to determine whether any generate loop
is an infinite loop algorithmically. The undecideability of the
halting problem for a general computation doesn't apply. That is
based on a model where a computation has a potentially infinite number
of states, like a Turing machine. This is a reasonable idealized model
for general computation, where the number of possible states of a
program is immense (or even infinite, if you posit an infinite amount
of offline storage).

In the computation of the iterations of a generate loop, the only
state variable that can change during computation is the genvar.
In a typical implementation, this is a 32-bit integer. This places
an upper limit of 2**32 iterations that could occur without the
computation being in an infinite loop. If it doesn't terminate in
that many iterations, it must be infinite. The algorithm isn't even
too impractical on today's machines.
 
Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de> wrote in message news:<c0e8ld$p15$1@news.tu-darmstadt.de>...
Steven Sharp <sharp@cadence.com> wrote:
: Bassman59a@yahoo.com (Andy Peters) wrote in message news:<9a2c3a75.0402061235.486dc2b4@posting.google.com>...
:
: > The ol' vlib command went off into la-la land, and froze the
: > application. (Had to kill it w/TaskMan).


: For comparison, NC-Verilog stops quickly with an error:

: for (n = 0; n < 4; n = n + n) begin: FooGen
^^^^^
Are you sure you didn't mean n = n + 1 ?

With n = 0, n = n + n never will reach 4!
Click to expand...
Uwe,

Go back to the start of the thread!

--a
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top