How do I identify carry/overflow condition in Verilog?

[Altera_Forum]

Hi 

I need to identify an overflow condition for a counter in Verilog code. Say that count register is 16bits wide; I make the assignment  count <= count + 1  and I need to know when the overflow condition happens. I now defined count as 17bits wide and I simply check when 17th bit toggles, and the design works. Anyway, I think there should be a better and more efficient way to do it.  I have only minor experience with Verilog, so I don't know how to get the overflow status signal from the adder for a generic operation count<=count+n   Cris

[Altera_Forum]

--- Quote Start ---  I now defined count as 17bits wide and I simply check when 17th bit toggles, and the design works. Anyway, I think there should be a better and more efficient way to do it.  --- Quote End ---   Yes, you are writing behavioral code, so you should do the same for the overflow. You are also "allowed" to add the reset on overwflow action for clarity, although it's performed automatically without coding it. if (count == 16'hffff) begin count <= 0; // do something on overflow end The point is to let the design compiler decide how the overflow action can be implemented with least effort. If you want to know how, inspect the gate level code.

[Altera_Forum]

Hi FvM, 

What you say was already clear to me. Testing the condition count==16'hffff is good for a simple counter with 1 increments. But I need to identify overflow for the general case with a n increment, where the counter doesn't hit the ffff value. I wondered if a Verilog instruction was available, without need to inspect at gate level.  Cris

[Altera_Forum]

Your method of adding 17th bit is the most efficient for modulo 2 counter. 

 If you mean how to continue counting at overflow for any counter then your example will work for modulo 2 counter. for non modulo 2 you can use variable to predetect overflow and take action:   e.g to count 0:99   clked process variable : count_v ... begin if count_v > 99 then  count_v := countv -99; else  count_v := count_v + incr; end if; count <= count_v; ..

[Altera_Forum]

I don't understand, what you mean with the general overflow condition in contrast to the above example. In behavioral code (count <= count +1), the overflow condition would be always expressed in a similar way, e.g.  

if (count >=12345)

[Altera_Forum]

I explain better. 

Increment can be 1 or any other value and it changes during circuit operation. The count is modulo 2. I don't care the actual count value but I must generate a pulse every time the count overflows.  Example 1 old count: 0x4000 increment: 0x0600 new count: 0x4600 no pulse generated  Example 2 old count: 0xFF00 increment: 0x0600 new count: 0x0500 pulse generated  I think this is what kaz correctly understood. So, according to him my bit17 trick is already the best way to do the job. As I said before I'm not a HDL expert and I always used schematics or gate level design, so I was accustomed with using the overflow/carry signal from the adder. I supposed I could access it from Verilog, too. Probably this is not possible in a pre-synthesis phase.  Thank you both for your answers Cris

[Altera_Forum]

The problem is, that you originally referred to a counter but are actually using an adder. The condition you are asking for is the carry bit of the adder. In this case, I agree, that the 17 th dummy bit is an appropriate way to implement the overflow check. Checking for the MSB toggling to zero would be another option. Most likely they end up in the same gate level code.

[Altera_Forum]

I agree with the OP. It can be said that it is, in a way, some sort of limitation of the HDL. The OP is right that for using the carry out outside the counter/adder itself, you implement a dummy extra bit as a full counter. Hardware wise, an extra bit would represent an extra LE that it would be wasted. 

 In an ideal world, the compiler might be able to identify that this extra bit is dummy, that only the carry out is needed, and optimize accordingly. In practice, compilers aren't, yet, that smart.  Thing are complicated in an FPGA, because the carry out signal is usually available at the carry chain only. This means that it is not so easy to optimize and avoid the extra dummy bit. If you insist, it might be possible to perform manual optimization and save one LE. That would probable require using low level WYSIWYG primitives.

[Altera_Forum]

After trying a few examples, I must admit, that I apparently overestimated the Quartus compiler capabilities in this regard. It recognizes the redundancy of behavioral code in some cases but doesn't in others. But it handles the carry chain effectively for a binary counter or adder. So the suggested dummy bit method seems to be almost optimal.