Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
15 years ago

How do I identify carry/overflow condition in Verilog?

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

8 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    --- 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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    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.