Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > VHDL > Counter defined as "integer range 0 to X"

Reply
Thread Tools

Counter defined as "integer range 0 to X"

 
 
aleksazr@gmail.com
Guest
Posts: n/a
 
      06-19-2012
(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?
 
Reply With Quote
 
 
 
 
aleksazr@gmail.com
Guest
Posts: n/a
 
      06-19-2012
On Tuesday, June 19, 2012 12:09:58 PM UTC+2, (unknown) wrote:
> (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.
 
Reply With Quote
 
 
 
 
Martin Thompson
Guest
Posts: n/a
 
      06-19-2012
http://www.velocityreviews.com/forums/(E-Mail Removed) writes:

> (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

--
(E-Mail Removed)
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.co.uk/capabilities...ronic-hardware
 
Reply With Quote
 
Gabor
Guest
Posts: n/a
 
      06-19-2012
Martin Thompson wrote:
> (E-Mail Removed) writes:
>
>> (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
>


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
 
Reply With Quote
 
Rob Gaddi
Guest
Posts: n/a
 
      06-19-2012
On Tue, 19 Jun 2012 15:02:30 -0400
Gabor <(E-Mail Removed)> wrote:

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

--
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order. See above to fix.
 
Reply With Quote
 
joris joris is offline
Senior Member
Join Date: Jan 2009
Posts: 152
 
      06-19-2012
Quote:
Originally Posted by Rob Gaddi View Post
On Tue, 19 Jun 2012 15:02:30 -0400
Gabor <(E-Mail Removed)> wrote:
[color=blue]counter <= (counter + 1) mod 6;
But in this case you'd want
Code:
counter <= (counter + 1) mod 7;
 
Reply With Quote
 
Gabor
Guest
Posts: n/a
 
      06-20-2012
Rob Gaddi wrote:
> On Tue, 19 Jun 2012 15:02:30 -0400
> Gabor <(E-Mail Removed)> wrote:
>
>> 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.


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
 
Reply With Quote
 
peter.hermansson@sts.saab.se
Guest
Posts: n/a
 
      06-21-2012
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
 
Reply With Quote
 
Jan Decaluwe
Guest
Posts: n/a
 
      06-22-2012
On 06/19/2012 09:49 PM, Rob Gaddi wrote:
> On Tue, 19 Jun 2012 15:02:30 -0400
> Gabor<(E-Mail Removed)> wrote:
>
>>
>> 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.


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

--
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Python as a HDL: http://www.myhdl.org
VHDL development, the modern way: http://www.sigasi.com
World-class digital design: http://www.easics.com
 
Reply With Quote
 
Andy
Guest
Posts: n/a
 
      06-24-2012
On Jun 20, 9:37*am, Gabor <(E-Mail Removed)> wrote:
> Rob Gaddi wrote:
> > On Tue, 19 Jun 2012 15:02:30 -0400
> > Gabor <(E-Mail Removed)> wrote:

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

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


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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
User-defined exception: "global name 'TestRunError' is not defined" jmike@alum.mit.edu Python 1 07-10-2008 12:37 PM
Page File counter and Private Bytes Counter George2 C++ 1 01-31-2008 09:27 AM
Using parenthesis with defined (#if defined(...)) Angel Tsankov C++ 1 04-05-2006 10:00 PM
#if (defined(__STDC__) && !defined(NO_PROTOTYPE)) || defined(__cplusplus) Oodini C Programming 1 09-27-2005 07:58 PM
Session("counter") vs. ViewState("counter")...a newbie question The Eeediot ASP .Net 3 12-22-2004 09:31 PM



Advertisments