Verilog down counter checking for carry

Question

Hi,  this is so basic I'm embarrassed to ask but half an hour googling did not find the answer so here goes.  Conventional wisdom says down counters are most efficient way to implement for example delays and what not.   Be that as it may, this involves checking when the counter underflows and then re-loading the counter.  My question is that how to do that in Verilog?  I can of course check the MSB of the counter but that implies that I need to 'know' what is the counter size in bits when I check it. What I mean is that not only do I have to write down the size of the counter where I define it but also in where I do the checking and that is ugly to me.  I principle if the value is signed I can check for the counter being &lt;0 or &gt;= 0 but the question is  if the synthesiser is smart enough to implement this check on the MSB?  A further question is if there is a way to avoid the -1 value of the counter from appearing in the 'output'.  What I mean is that if I code it like this:  reg signed [3:0] counter = 4'sd16;   
always @(posedge sys_clk) begin
    counter &lt;= counter + $signed({1'd0, 1'd1});
    if ((counter &lt; $signed({1'd0, 1'd0}))) begin
        counter &lt;= (counter - $signed({1'd0, 1'd1}));
    end else begin
        counter &lt;= 3'd7;
  the counter will have the value of -1 for one clock cycle so re-loading the counter with the value 7 will produce not 7 not 8 but 9 states, which is ugly to me. Is there a way to avoid that state without increasing resource usage?  wbr Kusti     (Never mind the $signed, that code is machine generated)

altera_forum · Answer

This seems way over complicated for what you want to do.  Just do an up counter and when a certain bit goes high, you reset the counter.  I don't understand how you would not "know" the counter size in bits and why doing a bit check is "ugly".

altera_forum · Answer

Hi,

thanks for looking into this.

Going down and checking the MSB uses the least resources because checking the end of count

only requires checking one bit, the sign. This is regardless of what the re-load value is.

Going up you need to check with multiple and/xor logic for the end of count value OR

you have to reload with a value that is the size of the counter minus the count you want,

which is even uglier.

So going down is definitely better from resource use point of view (at least in the hardware

level) and IF the checking the MSB can be done as <0 or >=0 then that is also better

that checking the MSB explicitly because if I need to write the MSB bit number there I can make a mistake

if/when the counter size changes. If I check the MSB explicitly I need to change the counter size

in two places in the source code which is not as clean and maintainable as having it only in one place.

My background is software so I tend to look at this perhaps from the good source code style point of view more than a hardware guy would.

altera_forum · Answer

You explanation of up vs. down checking doesn't make sense. With an up counter, like I said, you just have to check one bit. If you're counting to 16, for example, when the counter equals "10000", the MSB is high and you overflow. You don't need to do any of the stuff you're talking about.

Worrying about hardware use with logic this simple is not something you should be concerned about either unless you are using a really old, small FPGA or your design is so massive (filling 80 to over 90% of the device) that you are looking for any little thing you can to reduce resource usage (which there are many other places to look at to reduce resource usage than this).

As far as the size of the counter changing, just use a parameter for the counter width. That way you only have to make a change in one spot at the top of the design file.

altera_forum · Answer

We are getting off the topic here, but don't take my word for it, look here starting

from 'Synthesis Considerations' which explains why down counters are better:

http://www.bitweenie.com/listings/verilog-counter/

But that is not what I was asking.

I realise this is a small issue, but I'm in the beginning of both this design and my career (if any) as a Verilog coder and I like to get and learn the fundamentals right. Why learn bad habits if you can lear good? There must be a reason why todays code is so bloated, the compressed download of full Quartus Pro is 40 GB!! Maybe if people would pay more attention to what resources they are using world could be a better place. But again we digress.

Parameter does solve the issue of having the counter size in one place, at least partially.

However, consider following:

say I need to count to 11 so my counter is 4 bits but I have to write this as

reg[0:3] and check the bits as rg[3] & rg[1] & rg[0] so my source code nowhere shows the number 11

which was important from the design point of view, neither does it show 4 which is the implementation

size but it shows 3.

Not very good coding practice, at least looking at this from where I come from.

And now I have four places in my code where I can make a mistake where as counting down

I only have two and by calculating the number of bits my counter requires a log(11)/log(2)+1 I can

automate the register size selection and have my code show explicitly the design point of view which

is that the counter counts 11. Of course I would write all that a bit more prettily with parameters and

stuff but I think previous illustrates the point.

But again those are beside the point, my question was simply is the synthesiser smart enough

to recognise that it can implement <0 and >=0 as a single bit check?

altera_forum · Answer

The imagined "single bit check" requires that you have an additional fifth register implemented in your counter.

What you probably didn't yet consider is that the usual fully synchronous counter implementation involves combinational logic to generate the input for each register, it also would for the carry generation. I see this is contrary to how you imagine economical logic, but it's the main stream of FPGA design, for several reasons.

I must confess that I rarely think about describing a delay timer as up or down counter. Sometimes the decision is suggested by additional conditions, sometimes it doesn't matter.

Forum Discussion

Verilog down counter checking for carry

7 Replies

Recent Discussions

Questa Starter license missing FEATURE/INCREMENT lines”

Issue with configuring EPCQ64A & Cyclone10LP using NiosV as processor.

Error with PDN Tool 2.0 for Cyclone V

Trouble Getting started with Stratix 10 SOC

JTAG Chain Broken on Agilex 7-I Dev Kit