Counter defined as "integer range 0 to X"

[aleksazr]

(I'm not talking about simulation, but real hardware only)

signal counter : integer range 0 to 6;
counter <= counter +1;

The counter must be 3 bits wide (0-7)...
will it ever contain a value of 7,
or will the tools create additional logic to prevent that?

 

[aleksazr]

(I'm not talking about simulation, but real hardware only)

signal counter : integer range 0 to 6;
counter <= counter +1;

The counter must be 3 bits wide (0-7)...
will it ever contain a value of 7,
or will the tools create additional logic to prevent that?

I did a post'-route simulation - the counter does reach 7.

 

[Martin Thompson]

(I'm not talking about simulation, but real hardware only)

signal counter : integer range 0 to 6;
counter <= counter +1;

The counter must be 3 bits wide (0-7)...
will it ever contain a value of 7,
or will the tools create additional logic to prevent that?

What logic would you like the tools to create for you? Anything they do
will be different to the simulation result(and also different to what
other users want

All you've said to the compileris "I don't intend this signal to ever
be > 6" - so anything greater than 6 is an error of some sort.

The simulator will trap this state and tell you it's happened.

Synthesizers don't have that option, so they take the easy way out and
create a 3-bit counter as you've discovered. That was all we could
afford to do in the olden-days when chips were small and slow (realtively)

Now that we have such enormous, fast, chips, I think it would be useful
for the synth to (optionally) be able to add logic to catch this. And
other asserts I put in my code.

They could all be aggregated at the top level into some (user-defined)
debug code which could turn LEDs on, send messages over Ethernet,
serial, whatever.

Martin

 

[Gabor]

What logic would you like the tools to create for you? Anything they do
will be different to the simulation result(and also different to what
other users want

All you've said to the compileris "I don't intend this signal to ever
be > 6" - so anything greater than 6 is an error of some sort.

The simulator will trap this state and tell you it's happened.

Synthesizers don't have that option, so they take the easy way out and
create a 3-bit counter as you've discovered. That was all we could
afford to do in the olden-days when chips were small and slow (realtively)

Now that we have such enormous, fast, chips, I think it would be useful
for the synth to (optionally) be able to add logic to catch this. And
other asserts I put in my code.

They could all be aggregated at the top level into some (user-defined)
debug code which could turn LEDs on, send messages over Ethernet,
serial, whatever.

Martin

Well I for one think it would be much more useful for the synthesizer to
wrap to zero after state 6 so the count matches the range of the signal.
Obviously that's not the expected behavior for VHDL, though.

-- Gabor

 

[Rob Gaddi]

Well I for one think it would be much more useful for the synthesizer to
wrap to zero after state 6 so the count matches the range of the signal.
Obviously that's not the expected behavior for VHDL, though.

-- Gabor

Of course it isn't; integers don't do that either in math or in VHDL.

If you want it to behave according to modular arithmetic, you
explicitly call out modular arithmetic.

counter <= (counter + 1) mod 6;

This way there's no type-based ambiguity, that some integers go from 6
to 0, and others go from 6 to 7.

 

[joris]

On Tue, 19 Jun 2012 15:02:30 -0400
Gabor <[email protected]> wrote:
counter <= (counter + 1) mod 6;

But in this case you'd want

counter <= (counter + 1) mod 7;

 

[Gabor]

Of course it isn't; integers don't do that either in math or in VHDL.

In hardware, where the size of the counter is based on the range,
the count will wrap. Thus for example an integer range 0 to 2^n-1
will have exactly the behavior I described. My thought was that
handling non-power-of-2 ranges in a way that mimicked this
behavior would be useful - more useful than adding some sort
of error reporting mechanism in hardware.

If you want it to behave according to modular arithmetic, you
explicitly call out modular arithmetic.

counter <= (counter + 1) mod 6;

This way there's no type-based ambiguity, that some integers go from 6
to 0, and others go from 6 to 7.

As long as the language (or library) spells out the behavior of

counter <= counter + 1;

for any given type, then there is no ambiguity.

-- Gabor

 

[peter.hermansson]

Den tisdagen den 19:e juni 2012 kl. 12:09:58 UTC+2 skrev (okänd):

(I'm not talking about simulation, but real hardware only)

signal counter : integer range 0 to 6;
counter <= counter +1;

The counter must be 3 bits wide (0-7)...
will it ever contain a value of 7,
or will the tools create additional logic to prevent that?

If you increment an integer outside its range, you will get a simulation error. The mod operator is only supported by synthesis for a power of 2. An easy solution is to test for wrap around with an if - else statement.

/Peter

 

[Jan Decaluwe]

Of course it isn't; integers don't do that either in math or in VHDL.

Integers don't do this, but modulo arithmetic is very well
defined in math. And it has many practical applications
of course.

A language like Ada found this important enough to introduce
modular types, which in VHDL would have looked as follows:

signal counter: mod range 0 to 6;

Note that this is an abstract type in which wrap-around
is defined as a mathematical operation; not just for
powers of 2 and not as a side effect of a representation,
as with signed/unsigned.

What I found interesting is that the Ada design docs
explicitly mention the case of powers of 2 as a possible
compiler optimization. The link with hardware design seems
obvious, and I find it a pity that VHDL seems to have
forgotten to keep track of its Ada foundation.

As I believe modular types are ideal for hardware design,
they have been introduced in the development version of MyHDL:

http://myhdl.org/doku.php/meps:mep-106

 

[Andy]

In hardware, where the size of the counter is based on the range,
the count will wrap.  Thus for example an integer range 0 to 2^n-1
will have exactly the behavior I described.  My thought was that
handling non-power-of-2 ranges in a way that mimicked this
behavior would be useful - more useful than adding some sort
of error reporting mechanism in hardware.






As long as the language (or library) spells out the behavior of

counter <= counter + 1;

for any given type, then there is no ambiguity.

-- Gabor

A synthesis tool's job is to create hardware that behaves (at least on
a clock cycle basis) like the RTL simulates. Since the code does not
simulate (does not continue) if counter exceeds 6, then the synthesis
tool has no direction on what to do. Therefore anything is
permissible. It could saturate, it could count modulo 6, or it could
count modulo 8. Generally the latter is the most efficient in
hardware, so generally that is what they do. BUT THEY DON'T HAVE TO!!!

Note that the error does not occur until a value larger than 6 is
attempted to be stored in counter. You can add 1 to counter anytime
you want, and not get an error, so long as you don't store the results
back in counter if they are outside the range of counter. Thus, you
can detect a carry out by checking the results of the increment or
decrement before you store it:

if count - 1 < 0 then -- don't try this with unsigned!!!
count <= 6;
else
count <= count - 1; -- shared decrementor with comparison above
end if;


Andy