New(?) fast binary counter for FPGAs without carry logic (e.g. Actel) -- Request For Comment

Yes, but not much. As I wrote, it's (n-k) mod 2^k.

Yes and no. Currently, the Actel architecture suits our needs for aerospace, radiation tolerant design quite well. Of course we will port our design to other families, e.g. (much slower) Atmel and (more recent) Spartan-6.

I only tried to mention the idea -- because it may be useful somewhere again, in general.

Marek

Reply to
robotron
Loading thread data ...

our recent design.

Yes, the Spartan 6 look-ahead carry logic is quite fast, and in addition to the fast gates it has its own fast dedicated routing. Still 425 MHz is likely to be much faster than a typically achievable system speed for all but the most carefully tuned designs. And it turns out that having two flip-flops plus a LUT matches the slice architecture of the newer Xilinx parts, so the resource usage at the slice level is not bad for the pcounter. In fact if I get rid of the async reset in my code, the pcounter and the standard carry-chain counter use the same resources (8 slices for 32 bits).

Getting back to the inversion issue, it seems to me that if you want to work back to a binary number and also use the enable input, you would need to base the inversion on the p bits as well as q bits, or else base it on the history of the en input as well as the q bits. Essentially, knowing the current p bit values allows the software to finish the carry propagation.

-- Gabor

Reply to
Gabor

Am Dienstag, 11. September 2012 20:47:01 UTC+2 schrieb robotron:

If I understand your description correctly it is a carry save accumulator:

formatting link

Quote: "To put it another way, we are taking a carry digit from the positio= n on our right, and passing a carry digit to the left, just as in conventio= nal addition; but the carry digit we pass to the left is the result of the = previous calculation and not the current one. In each clock cycle, carries = only have to move one step along, and not n steps as in conventional additi= on."

Kolja Sulimma

formatting link

Reply to
Kolja Sulimma

Similar sorts of carry pipelining were common in the early Xilinx XC2000/3000 parts; I recall there being some fast counter techniques in application notes and Xcell journals of that era.

Pipelined carry chains at one or two bits per carry were also commonly used for accumulators and counters in the GHz clock rate GaAs standard cell GaAs designs that I worked on in the early 90's.

The pictures from the following TriQuint patent show a few variants of the input/output deskew trees that can be implemented for delay equalization of a loadable accumulator having carry pipelining:

formatting link

( disclaimer : I worked with some of the authors back when I was doing a foundry design through TriQuint )

- Brian

Reply to
Brian Davis

Dear colleagues,

thank you for the pointers to prior art. I have included link to this newsgroup thread to the project page.

Best regards, Marek

Reply to
robotron

Here are some more links regarding counter & accumulator carry techniques.

-------------------- Links to early Xilinx counter app notes:

Ultra-Fast Synchronous Counters in XC3000 & XC4000 FPGAs

formatting link

Loadable Binary Counters in a XC3000 FPGA

formatting link

pages 15-18 of Xcell Journal #7

formatting link

-------------------- Haven't found a pdf for XAPP 001 yet: " " High-Speed Synchronous Prescaler Counter " (XAPP 001) " " This simple design provides a very basic non-loadable, " up counter with a count-enable control. However, this " simplicity permits it to be both the densest and the " second fastest design. " " A prescaler (CEP/CET) technique is used to gain speed, " permitting the ripple-carry portion of the counter " eight clock periods in which to settle. Without special " adaptation, however, this technique precludes loading " the counter. As a non-loadable counter, three bits can " be implemented in three CLBs (1 CLB/bit), with the least " significant six bits requiring only four CLBs; this " explains the compactness. Only one TILO delay is incurred " in the ripple-carry path for each three bits. " This technique of making the low N bits run fast, with the upper bits running slower by 2^N, should map well into a compact yet fast implementation of a non-loadable binary counter for your Actel part.

I.e., use something like the pcounter scheme for the low few bits, then make the upper bits with a ripple carry, enabled by the carry out of the low bits.

You probably will need to add special timing constraints to get the tools to understand the multicycle carry, and that the ripple chain is a false path after FF reset.

The advantage of this is that you would now only need to deskew N LSB's of the counter for straight binary output.

-------------------- ORCA-3 FPGAs had an optional register in the dedicated carry chain:

" Fast-carry logic and routing to adjacent PFUs for " nibble-wide, byte-wide, or longer arithmetic functions, " with the option to register the PFU carry-out.

-------------------- More carry-pipelined accumulator references:

( I've mentioned accumulators because they are a more general carry design problem than are counters, and because I know where to look for literature describing high speed pipelined versions.)

"Direct Digital Synthesizers: Theory, Design and Applications", Vankka lib.tkk.fi/Diss/2000/isbn9512253186/isbn9512253186.pdf See pages 48-49 for accumulator pipelining techniques.

"Single Chip 500 MHz Function Generator" P.H. Saul, W. Barber, D.G. Taylor, T. Ward IEE Proceedings, Vol. 138, No. 2, pp 239-243, April 1991

Reprinted in "Direct Digital Frequency Synthesizers", Kroupa (ed), IEEE Press,

1999

Fig. 2 shows the one-bit-per-carry accumulator structure Fig. 5 shows the accumulator output deskew tree

-Brian

Reply to
Brian Davis

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.