I'm wondering how to optimize comparison a wide counter value with few defined values. Maybe it will be easier if I show it on example - let say there is a receiver that gets data in well defined format - 1004, 8-bit symbols are grouped in one frame. In every CLK cycle one 8-bit symbol appears on receiver input. The last four symbols in frame are sequence number, that helps the receiver to find boundaries of frames. So, useful data that should be forwarded to next module are 1000 symbols. But, these symbols are also grouped in 4 smaller subframes, 250 symbols each one. Subframes are aligned to bigger frame's boundary - 1st symbol of bigger frame is also first symbol of 1st subframe. I would like to filter out sequence symbols in big frame, forward encapsulated data to next module and set additional output signal that shows subframes' beginnings.

My fist idea was to build state machine that looks where are big frames boundaries. If it catches sync sequence few times, it goes to sync state. Then use 10-bit counter that counts every symbols. On counter values 0, 250, 500, 750 would be subframes' 1st symbols (that I can signalise to next module by additional output signal - call it StartOut), and on counter values 1000-1003 the next module should be disabled, to skip sync sequence. Unfortunately this solution is not so good - output signals Enable and StartOut are functions of 10 bits. There are some logic (including 10-bit comparators) that slows down output signals' maximum speed. It becomes more limited if big frame size increases, and 16-bit counter is needed.

Searching StackExchange I found this question: vhdl synthesis optimization: counters in statemachines. There is shown an idea how to reduce output signal dependency, and make it a function of only one 1-bit signal. But it works rather with counting to one value. Here is a problem of one counter and few values that should be compared with it.

Do you have any idea how to improve speed in comparison counter with few constant values?

  • \$\begingroup\$ A 10 bit comparator should be very fast... it's the 10-bit increment that I'd worry about. \$\endgroup\$ – Ben Voigt Oct 2 '12 at 19:18
  • \$\begingroup\$ @Ben Voigt, how do you would implement removing sync sequence, without the counter? Do you have any hint? \$\endgroup\$ – Grzegorz Majewski Oct 4 '12 at 13:47

In general, the usual answer to this sort of problem is to pipeline. You might consider adding pipeline registers immediately after the 10-bit comparators, before the logic that combines them into the enable signal for the next stage. To keep the resulting enable signal aligned with the correct data in the data path, you'll probably also need a pipeline register for the data, too.

But yes, you can also use the technique described in the other question. For your specific 10-bit counter example, instead of counting from 0 to 1003 and using a comparator to identify state 999 to turn off the enable signal, you could make it an 11-bit counter that counts from -1000 to 3. The MSB of this counter is your enable signal, and when the count gets to 3[1], you reload the counter with -1000 ... and also load an auxiliary 9-bit count-down counter with the value 249. Each time this auxiliary counter reaches -1 (MSB set) is the start of another subframe (in addition to the one that starts at the beginning of the main frame).

[1]Note that detecting "3" is a function of just 3 bits — the MSB and the two LSBs — not a function of 11 bits.

| improve this answer | |
  • \$\begingroup\$ Thanks Dave. Pipelining - of course, it speeds up enebale signal. I've just wondered if there is something like trick with using carry signal in StackExchange thread mentioned above. Something that could avoid 10-bit comparators. \$\endgroup\$ – Grzegorz Majewski Oct 2 '12 at 10:00
  • \$\begingroup\$ Dave, the second part of your answer is that trick I looked for. Thanks again. It is hard for me to switch from C programming to VHDL, and I have sometimes problems with finding so smart solutions. \$\endgroup\$ – Grzegorz Majewski Oct 2 '12 at 12:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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