modelsim doesn't like my increment w/wraparound

[Ben Voigt]

I'm getting this error:
Fatal: (vsim-3421) Value 125000 for inc_tick is out of range 0 to
124999.

From this code:
SUBTYPE tick_t IS NATURAL RANGE 0 TO 124999;
SIGNAL tick, inc_tick : tick_t;
SIGNAL tick_overflow : BOOLEAN;
tick_overflow <= (tick = tick_t'HIGH);
inc_tick <= tick_t'LOW WHEN tick_overflow ELSE tick + 1;

The expression tick+1 overflowed, but it can at most glitch (the other
path of the selected assignment is active) and the setup time for the
flip-flop shouldn't be an issue.

This synthesizes just fine, but fails under simulation. I can get it
to simulate using a process and sequential if statement, but that's
about five times more code than I have now (I need the overflow flag
for other logic).

Any ideas how to do this elegantly?

 

[Mike Treseler]

I'm getting this error:
Fatal: (vsim-3421) Value 125000 for inc_tick is out of range 0 to
124999.

Any ideas how to do this elegantly?

Include the overflow value in the subtype range.
This value is needed for simulation.

SUBTYPE tick_t IS NATURAL RANGE 0 TO 125000;

or maybe

SUBTYPE tick_t IS NATURAL RANGE 0 TO -1 + 2**17

Synthesis utilization will not be affected.

-- Mike Treselre

 

[Ben Voigt]

Include the overflow value in the subtype range.
This value is needed for simulation.

 SUBTYPE tick_t IS NATURAL RANGE 0 TO 125000;

Yes, but... that changes the period of my counter and still breaks. I
can compare against tick_t'HIGH-1 instead, but that's a magic number
which I don't like.

I eventually got rid of the inc_tick signal completely, since the
process doing tick <= inc_tick can use a IF directly with no glitching
(it's clocked, the value of tick_overflow has time to settle and the
problematic addition is never simulated).

 

[Mike Treseler]

Yes, but... that changes the period of my counter and still breaks. I
can compare against tick_t'HIGH-1 instead, but that's a magic number
which I don't like.

Sometimes the range has to exceed the rollover value.

I eventually got rid of the inc_tick signal completely, since the
process doing tick <= inc_tick can use a IF directly with no glitching
(it's clocked, the value of tick_overflow has time to settle and the
problematic addition is never simulated).

That's even better.

 

[backhus]

I'm getting this error:
Fatal: (vsim-3421) Value 125000 for inc_tick is out of range 0 to
124999.

From this code:
   SUBTYPE tick_t IS NATURAL RANGE 0 TO 124999;
   SIGNAL tick, inc_tick : tick_t;
   SIGNAL tick_overflow : BOOLEAN;
   tick_overflow <= (tick = tick_t'HIGH);
   inc_tick <= tick_t'LOW WHEN tick_overflow ELSE tick + 1;

The expression tick+1 overflowed, but it can at most glitch (the other
path of the selected assignment is active) and the setup time for the
flip-flop shouldn't be an issue.

This synthesizes just fine, but fails under simulation.  I can get it
to simulate using a process and sequential if statement, but that's
about five times more code than I have now (I need the overflow flag
for other logic).

Any ideas how to do this elegantly?

Hi,
if this is just a n error that happens on the delta-cycle level, it
has no real meaning, but is still annoying.
Likle others said it would be a good idea to expand the range of your
type by one.
Maybe like this:

SUBTYPE tick_t IS NATURAL RANGE 0 TO 125000;
SIGNAL tick, inc_tick : tick_t;
SIGNAL tick_overflow : BOOLEAN;
tick_overflow <= (tick = tick_t'HIGH-1); -- regard the -1 here.
your flag will come at the right time
inc_tick <= tick_t'LOW WHEN tick_overflow ELSE tick + 1;

Give it a try and if it works take a look at the delta-cycles of
signal inc_tick.
You probably will still find the value of 125000 there, but only for a
few delta cycles, then it should be overridden by 0.

Have a nice simulation
Eilert

 

[Pieter Hulshoff]

I'm getting this error:
Fatal: (vsim-3421) Value 125000 for inc_tick is out of range 0 to
124999.

From this code:
SUBTYPE tick_t IS NATURAL RANGE 0 TO 124999;
SIGNAL tick, inc_tick : tick_t;
SIGNAL tick_overflow : BOOLEAN;
tick_overflow <= (tick = tick_t'HIGH);
inc_tick <= tick_t'LOW WHEN tick_overflow ELSE tick + 1;

The expression tick+1 overflowed, but it can at most glitch (the other
path of the selected assignment is active) and the setup time for the
flip-flop shouldn't be an issue.

This synthesizes just fine, but fails under simulation. I can get it
to simulate using a process and sequential if statement, but that's
about five times more code than I have now (I need the overflow flag
for other logic).

Any ideas how to do this elegantly?

How about:
tick_overflow <= (tick = tick_t'HIGH);
inc_tick <= tick_t'LOW WHEN (tick = tick_t'HIGH) ELSE tick + 1;
?

Kind regards,

Pieter Hulshoff

PS: I hope this is inside a clocked process, otherwise you should get some
interesting synthesis results.

 

[Andy]

Jonathan's response illustrates another subtle issue: scope control.

From the OP example we cannot tell whether tick_overflow, inc_tick, or
tick itself is needed elsewhere, since they are all signals. Since we
don't see the actual update to tick (hopefully synchronous!), we can
assume that inc_tick is needed there, but where else?

By using variables, Jonathan has declared that next_tick (FKA
inc_tick) is only needed within that process, in which only the
signals tick and tick_overflow are used/exported. If it turns out that
tick itself is not really needed anywhere (just tick_overflow), then
tick could be a variable too, and we would then be able to work with
up or down counters, whichever might be more efficient in the target
architecture. Sometimes detecting a rollover on a down counter
requires less logic. By isolating tick from external access, it can be
changed/optimized without fear of breaking something else.

By deliberately controlling scope, you are telling future maintainers
(perhaps even yourself in a few weeks/months/years) important
information about the ripple effect of potential changes.

Block statements can be used for "local signals" to control scope as
well, if you prefer the delayed-update semantics of signal
assignments.

Andy

 

[sleeman]

That's true, and it's something I all too often ignore.
One of my reasons for ignoring blocks is a vague
folk-memory that tool support for blocks is not as
good as it might be.  Have you (or anyone) ever encountered
problems with VHDL block statements in real tools?

It would be ironic if it there were such problems, since blocks are
(during elaboration, per the LRM) the penultimate simplification of
the structural aspect the entire design. There's nothing "closer to
the metal" in terms of language semantics until the entire design is
turned into the simulator's "grist for the mill" : nets and processes.

- Kenn

 

[Andy]

Beautifully said, and I couldn't agree more.  Is that

statement in the public domain so I can repeat it
frequently and openly?  Especially when talking to
Verilog folk, for many of whom "scope control" means
the timebase knob ;-)

Repeat at will...

I've not used block statements very much, and not any that I recall in
synthesis; I tend to use variables/processes instead. To be fair, my
processes tend to be on the large side (too bad blocks can't be used
inside processes).

Andy