Fast counting in Spartan 3

Preben, have you done the timing analysis on a straightforward implementation? I have run longer counters at higher frequency in Spartan 3...There is a built-in carry structure! Is your counter loadable? if not, your counter might be implemented as a ripple ( or a partially-ripple) counter, then you can count several hundred MHz ( use the Q as clock source for the next slice, or next group of 4 flip-flops.) If you do this, you have to wait out the ripple delay before you use or decode the counter output. Thre are many ways to achieve 100 MHz, or 2x, or 4x that performance, it all depends on your real requirements. Peter Alfke, Xilinx Applications.

!00 MHz does not sound that fast for a Spartan III. Did you try a HDL synthesys and P&R with time constraint?

Perhaps an 8 bit prescaler with a pipelined clock enable to an 11 bit counter.

Have fun

-Newman

"Preben" schrieb im Newsbeitrag news:420fab6f$0$12714$ snipped-for-privacy@dread14.news.tele.dk...

Just a straight forward approach. Been there, done this recently. It was a

Regards Falk

Spartan 3, 100MHz and ... fast? I think you are kidding. Did you try to implement the counter? I guess it will run much faster

Bye

Like everyone say, 100MHz is trivial. If you had to go much faster there are many clever ways (depending on how you can compromise). Here are two O(1) counters:

1. Linear feedback shift register. Of course, when you really need the count the conversion back is expensive.

1. Carry-save addition. Maintain the count y as x1-x2, where x1 and x2 are two n-bit integers. To increase y, assign (in parallel)

x1 >Hi everyone,

I got a 401 on that.

Transcriping URL's by hand and mispelling, grief:

Sorry.

Tommy

Just remove the extra "d" in stanford. I am curious how it got there though. I can't imagine anyone actually typing that url.

You should be able to get better than 160 MHz from a 19 bit counter using the carry chain in spartan3. I am assuming you tried to implement it, and are getting poor results. Look at the implementation (ie, what the synthesis actually produced). The counter should be one layer of logic, and any controls, especially controls leading into the carry chain, should come from a flip flop without going through any combinatorial logic other than the LUT for the carry chain. A common pitfall is with the expression of either a reset or load signal. If you have a synchronous reset you can't also have an asynch reset without forcing to two layers (unless you are clever about the implementation, which the tools generally are not). Likewise, a load signal coded as an if then else will infer a mux between the carry chain and flip-flops. Even if the implementation is going to two levels, you may still be able to get 100MHz with a little bit of floorplanning. The automatic placement is notoriously bad at placing a second level of logic. Would probably help if you'd post your code.

What's the preferred style for counters then? It sounds like this is suboptimal:

reg [N:0] counter; always @(posedge clk) if (reset || count == MAX) // Assuming a non-power of 2 counter

Hi everyone...

Yeah, it seems though, that there is no difficulty counting that fast!

So I don't need to worry at all ;-) That's a nice thing!

Thanks /Preben

Just to provide some quick numbers... here is a quick test. I'll shortly need to do many stages "wide" forward difference units, so I took a quick look at the speed. Of course, the chip was "empty", in a real design it's more difficult... This was a "push-button" design, no particular optimization was done.

// Optimize for speed, -4, normal effort, xc3s400-4ft256, ISE 6.3i3

// Up-counter: q