Sunday, 4 December 2011

Asynchronous behaviour of synchronous counter

I've written before about performing timing analysis with Altera's FPGA design software, Quartus II. I find Analysing timing for a complex FPGA project far from easy. Distinguishing which timing violations are important and which ones are the result of poorly constrained paths can be tricky. Sometimes a path in your design may report negative slack, but you don't care, because you only latch the signal on every other clock, or perhaps because that path's timing just isn't important to your design.

That being said, once you've identified that a timing violation that does concern the performance of your design it can be tricky to understand what the Timing Analyzer is saying. Typically all you have to go on is a source and destination 'node' in your design and the corresponding clock domains to which the violation concerns. Earlier this week I came across a timing violation which at first glance didn't make any sense.

The analyser flagged a negative slack time from the q[] output of a counter (marked as 'source') to the register 'reg' marked as 'dest' in the diagram below:

This didn't make any sense. There is no combinational logic joining the source to the destination. At least it looks that way on first inspection.

If you consider the behaviour of the synchronous counter, the cout output is dependent upon the direction of the counter. When counting upwards, cout goes high when the counter value is '1111..11' however when counting down, cout goes high when the count reaches '0000...00'. This implies that cout is  directly, and combinationally dependent upon updown.

The reason for the timing violation now makes sense, the combinational path joining source to dest now includes 'path_a' and 'path_b' in series, it is as if the path continues from the updown input through to cout output of the counter.

This path includes quite a lot of combinational logic, hence the failure to meet timing requirements. It is these sorts of subtleties that make resolving timing issues far from trivial.

Source: "lpm_counter Megafunction User Guide", Altera, 2007, retrieved 4th December 2011, URL:

No comments: