0
\$\begingroup\$

I want to implement some kind of event counter in my FPGA design (Vendor-A or Vendor-X). I have several dozens of signals: half are 1-bit and other half of them is 5-bit. Signals are located in different parts of my design.

I want to count summation of every signals at the same time. Signal will come at high frequency, sum of every signal should be written in 48- or 64-bit register or memory. There is no much free space in my FPGA and I want not to use full 64-bit wide adder, but find some more compact (in number of LUTs required).

How should I design my adder to be more compact? Should I split it into small fast-counting counter (of 8, 12 or 16 bits) and slow and compact serial adder for remaining bits, which will use carry from small counter? Small counter will send carry not too often, so I will have hundreds of ticks to work on wider parts in multicycle adder. Can I use one serial adders with several different small counters?

\$\endgroup\$
4
  • \$\begingroup\$ Most FPGA fabrics from these vendors have an "arithmetic mode" for LUTs that makes the implementation of full adders very cheap, so I'm not sure you can optimize much here. \$\endgroup\$
    – Simon Richter
    Commented Mar 3, 2016 at 0:54
  • \$\begingroup\$ There is just fast carry chain in LUTs (how much LUT-4 of Cyclone4 are needed for 64-bit adder at 50 or 75 MHz?). I think that serial (byte-serial, bit-serial) multicycle implementation may use less LUTs than needed for high-frequency 1-cycle full width 64-bit adders. \$\endgroup\$
    – osgx
    Commented Mar 3, 2016 at 1:39
  • \$\begingroup\$ You are aware of carry-save adders? Similarly, the register with 48 data bits might include redundant information for predetermining carry-through for large chunks (more significant bits will only experience an increment; only one chunk will perform an increment, the others are zeroed or never reached) or saving a carry (requiring a slower "normalization" of the register value). (You may already have considered such; I am not a hardware designer, just a computer architecture enthusiast.) \$\endgroup\$
    – user15426
    Commented Mar 3, 2016 at 3:15
  • \$\begingroup\$ The main difficulty I see is that you still have to get the current counter value to the adder. If the value is stored in registers, then these take up LUTs anyway, but you get additional overhead for addressing. \$\endgroup\$
    – Simon Richter
    Commented Mar 3, 2016 at 18:36

1 Answer 1

Reset to default
1
\$\begingroup\$

You have not said it but it seems obvious that you are accumulating this event counter so that it can be read out of the FPGA for some purpose. That means that you have some provision to bring out register content, presumably under some software control.

I would simply extend that to allow readout of more smaller counters as opposed to trying to squeeze it all into this huge counter. Place these smaller counters in the design where the individual events need counting and then let software read each out. Software can do a brilliant job of adding the subtotals together. And who knows, there may be an advantage of knowing what the various subtotals were.

\$\endgroup\$
1
  • \$\begingroup\$ Yes, I need software readout, but this readout is planned to be rare (around 1 per minute) and may be not regular. So, my idea was to have full sums since powerup in hardware and do readout of them when they are needed or by daemon. Some of events will signal +1 (or +15 or +30 in wide signal) to counter at very high rate, for example at 1/4 or 1/3 of all ticks at 50 MHz, so in 1 minute I will have 1 Gevents and I need at least 32 bits. I already have 20 signal points and I want to compare them and not lost any of them in case when daemon was not waked by OS in time, so 40 - 48 bits are better. \$\endgroup\$
    – osgx
    Commented Mar 3, 2016 at 3:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.