| Register | FAQ | Calendar | Search | Today's Posts | Mark Forums Read |
|
#21
| |||
| |||
| On Aug 18, 11:27 pm, "Marty Ryba" <martin.ryba.nos...@verizon.net> wrote: > "Andy" <jonesa...@comcast.net> wrote in message > > news:d4ece4bd-1bcd-45b1-bf08-782fd22b5df7@x41g2000hsb.googlegroups.com... > > > > >> rickman wrote: > >> > One suggestion. When implementing counters, it is slightly more > >> > efficient to implement them as loadable down counters. > >> > This is because in most technologies there is a carry chain built in > >> > that can detect when counter is 0. If you are counting up to (M-1) > >> > the synthesizer has to use LUTs to detect the final state if M is not > >> > a power of 2. > >> > Rick > > Many synthesis tools will not infer the carry bit from the decrement > > for a comparison = 0. They will implement an AND function to test each > > bit. > > > However, if you use integers for counters, it is easy to detect > > rollovers with the carry bit. > > signal counter : integer range 0 to 2**n-1; > > if counter - 1 < 0 then -- check the carry bit > > counter <= start_val; > > do_something; > > else > > counter <= counter - 1; -- reuse same decrementer > > end if; > > Note that integer operations are always signed, 32 bit. so the result > > of the decrement in the conditional expression can in fact be less > > than zero. Not to worry, synthesis will figure out which of the 32 > > signed bits really gets used, and throw away the rest. > > Andy > > I tried an experiment today with a unit with a 22-bit unsigned counter > (count down). I had initially implemented it as std_logic_vector; and it > turned out initially that I had to stop at one instead of zero. I changed > the logic to a 22-bit unsigned, and changed the load value by one so that > the "stop" point came at cnt_out = 0. Then, I tried it with an integer range > 0 to 2*22-1 and the cnt_out -1 test mentioned by Andy. > > Using Synplify Pro 8.8 into ISE 9.1, the *unsigned* came out noticeably > smaller (both worked). The *integer* was largest (even bigger than the > initial SLV code). Looking at the RTL view, it seemed like a big and was > still implied in the unsigned case, but I imagine that could be misleading. > > I'm going to try a few more and see if the trend continues (at least see if > unsigned works better than SLV, though that difference may have just come > from changing the test from cnt_out = "0000000000000000000001" to cnt_out = > 0). > > Just one data point... I would expect all three to be the same if coded properly. You pointed out that the slv version counted differently. To make an integer optimal, you need to restrict the range of the integer. Otherwise it is assumed to be a 32 bit value and all 32 bits are initially implemented. The unused bits are typically removed by the place and map tools, but that comes later. So declare a subtype for your counter with a range of 0 to N-1. Then it should use the same logic as the other two. Rick |
|
#22
| |||
| |||
| On Aug 18, 11:27 pm, "Marty Ryba" <martin.ryba.nos...@verizon.net> wrote: > > I tried an experiment today with a unit with a 22-bit unsigned counter > (count down). I had initially implemented it as std_logic_vector; and it > turned out initially that I had to stop at one instead of zero. I changed > the logic to a 22-bit unsigned, and changed the load value by one so that > the "stop" point came at cnt_out = 0. Then, I tried it with an integer range > 0 to 2*22-1 and the cnt_out -1 test mentioned by Andy. > > Using Synplify Pro 8.8 into ISE 9.1, the *unsigned* came out noticeably > smaller (both worked). The *integer* was largest (even bigger than the > initial SLV code). I forgot to mention... Try changing the terminal test to just if (counter = 0) then If the counter is implemented as a down counter, I would expect the tools to be able to figure out that this test can be done in the carry chain. I can't imagine that a synthesis vendor would not have optimized this form of a counter. It is just so common. Especially if you declare the signal as a range of natural. Rick |
![]() |
| Thread Tools | |
| Display Modes | |
In an effort to better serve ads to our visitors, cookies are used on objectmix.com. For more information, check out our Privacy Policy.