Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Valued Contributor III
1,615 Views

Verilog down counter checking for carry

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 <0 or >= 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 <= counter + $signed({1'd0, 1'd1}); if ((counter < $signed({1'd0, 1'd0}))) begin counter <= (counter - $signed({1'd0, 1'd1})); end else begin counter <= 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) 

0 Kudos
7 Replies
Highlighted
Valued Contributor III
5 Views

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

0 Kudos
Highlighted
Valued Contributor III
5 Views

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.
0 Kudos
Highlighted
Valued Contributor III
5 Views

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.
0 Kudos
Highlighted
Valued Contributor III
5 Views

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?
0 Kudos
Highlighted
Valued Contributor III
5 Views

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.
0 Kudos
Highlighted
Valued Contributor III
5 Views

Ok, thanks, I would just like to point out that in "how you imagine economical logic" the 'you' is not me nor is this my idea but something I've read from various places. Maybe there is a benefit, maybe not, but I would like to know the answer to my original question.

0 Kudos
Highlighted
Valued Contributor III
5 Views

The answer to your original question is that checking the MSB state doesn't work without a redundant counter bit.

0 Kudos