Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

Integers in VHDL, what happens to natural range 0 to 1000 int counter if never Rst...

Status
Not open for further replies.

jgrigo

Newbie level 2
Joined
Jan 6, 2012
Messages
2
Helped
0
Reputation
0
Reaction score
0
Trophy points
1,281
Activity points
1,316
For an integer defined with range 0 to 1000, and if the integer is an incrementing counter.

What happens if the signal that resets an integer counter never goes active and the integer counter does not have a clamp? How does the synthesizer handle an integer counter that is attempting to go beyond the defined limits. Does the synthesized design clamp it at max range defined? ...does it clamp at max value associated with the allocated bits (1023 for 10 bits since defined range 0-1000)? ....does it roll over? ...is it synthesizer based (Xilinx ISE)? BTW, I know this is not a good design practice....

Code is like this in a clocked process.

Code:
If(FrameSync = '1')then
   Integer0_1000 <=  0;
else
   Integer0_1000 <=  Integer0_1000 + 1;
end if;

I know simulation just stops (crashes) and I always use std_logic_vectors since they roll-over and are predicatable. I never had time in my career to make builds and characterize what happens in this condition using an integer counter.

Any insight is appreciated!
 

integer range 0 to 1000 is usually synthesized as unsigned(9 downto 0) without additional logic for the counter. Respectively it rolls over from 1023 to 0.

To avoid simulation mismatch, you should either add an explicite overflow handling or extend the range to 1023.
 

This is one example where the integer type can be a help and a hindrance. The fact it causes an error in simulation is self linting, pointing you straight at the problem. The hindrance comes from a test that misses this situation and then the hardware behaves different to the simulation.
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top