RAM Event Counters with Pre-Counter Sweeping for High Event Rates
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Conventional event counter implementations on ASICs and FPGAs are inefficient in terms of resource utilization, as they require a large number of registers and logic blocks, and previous attempts to use RAM-based solutions have been lossy and do not account for event frequency.
Innovation Solution
Implementing a system where each event source feeds a small dedicated 'pre-counter' with the actual count kept in 64-bit wide RAM, using a state machine to sweep through pre-counters and accumulate values in RAM, ensuring that pre-counters do not overflow and reducing the need for large event counters.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Measurement precision
If conventional implementation uses 64 registers and an adder for each 64-bit counter, then counting precision is maintained, but silicon space consumption increases significantly
Solution Approach 1:
The counter is segmented into two parts: a small pre-counter (8-16 bits) that handles high-frequency event counting locally, and a larger RAM-based counter (64 bits) that accumulates the pre-counter values. This segmentation allows each component to be optimized for its specific function, reducing overall resource requirements while maintaining full 64-bit counting precision.
Solution Approach 2:
The pre-counter acts as an intermediary between the event source and the main RAM-based counter. It temporarily holds and accumulates event counts locally before transferring them to the main counter, enabling the system to handle high-frequency events without requiring a large counter at every stage.
2Adaptability or versatility
If hundreds of 64-bit counters are implemented on FPGA, then event counting capability is provided, but LUT consumption becomes very significant
Solution Approach 1:
Each counter is segmented into a small pre-counter and a shared RAM-based storage. The pre-counters are simplified in size (8-16 bits vs. 64 bits), dramatically reducing the LUT requirements for each counter instance. Multiple counters can share the same RAM resource, further reducing overall LUT consumption while maintaining the ability to count hundreds of events simultaneously.
Solution Approach 2:
The RAM-based counter serves as a universal resource that can be shared among multiple pre-counters. Instead of each counter having its own full 64-bit storage, multiple simplified pre-counters can accumulate their counts in the shared RAM, reducing the total number of LUTs required while maintaining support for hundreds of event sources.
3Device complexity
If RAM is used to substitute registers for counter implementation, then resource utilization improves, but counting accuracy may be lost due to overflow issues
Solution Approach 1:
The pre-counter performs preliminary accumulation of event counts in a small, fast register before transferring to the larger RAM-based counter. This preliminary action ensures that even at maximal event rates, the pre-counter's limited width is sufficient to hold intermediate values, preventing overflow and maintaining accuracy through the two-stage accumulation process.
Solution Approach 2:
The system transitions from a single-dimensional counter width problem to a two-dimensional solution: a small pre-counter width combined with a larger RAM-based counter width. This dimensional change allows the system to achieve both resource efficiency (small pre-counter) and accuracy (large effective width through RAM accumulation).
4Reliability
If pre-counters are made wide enough to prevent overflow at maximal event rate, then counting reliability is maintained, but resource consumption increases
Solution Approach 1:
The counting function is segmented between a small pre-counter and a larger RAM-based counter. The pre-counter only needs to be wide enough to handle intermediate accumulation (8-16 bits), while the full precision (64 bits) is achieved through the combined system. This segmentation maintains reliability without requiring all counters to be wide from the start.
Solution Approach 2:
The system maintains continuous counting operation through the two-stage process: the pre-counter continuously accumulates events at high rate, and the sweeper continuously transfers accumulated values to the RAM-based counter. This continuous action ensures no overflow occurs while keeping the pre-counter width minimal, as the transfer happens frequently enough to prevent accumulation beyond pre-counter capacity.
Data Source
Figure 1
Figure 2
Figure 3
AI summary
There is broadly contemplated herein an arrangement whereby each event source feeds a small dedicated "pre-counter" while an actual count is kept in a 64-bit wide RAM. Such an implementation preferably may involve a state machine that simply sweeps through the pre-counters, in a predetermined fixed order. Preferably, the state machine will access each pre-counter, add the value from the pre-counter to a corresponding RAM location, and then clear the pre-counter. Accordingly, the pre-counters merely have to be wide enough such that even at a maximal event rate, the pre-counter will not be able to wrap (i.e., reach capacity or overflow) before the "sweeper" state machine accesses the pre-counter.