Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
11 years ago

Syncronous counter generating rippled outputs

This thing is driving me crazy. I have been trying to make a synchronous 16 bit divide-by-N counter with schematic entry. I got the logical part working. Two different designs. Both seem to be compiling into the same code.

Here is the problem.... When I run the timing simulator, I am seeing Asynchronous output. I've seen cleaner output on plain ripple counters. On the first Dff, the output is 9ns after the clock. Because its synchronous, the clock is fed directly to all 16 Dff's. OK, that wouldn't be so bad if the outputs were even, but they are not. The delay between the clock and the output randomly ranges between 5 and 9ns.

On these compiles, the difference wasn't enough of a setup and hold (I'm guessing) that the terminal count logic could pick up on it and output spurious counts, but that could change with the next compile. The other thing is that the count seems to be true in spite of the jagged output.

My circuit: Its just a string of 16 D flip flops all fed by the same master clock. The D input on the flip flops are fed by the appropriate look-behind circuitry. Since there is nothing between the output of the FF and the pin, the outputs should all change at exactly the same time, but they don't. The terminal count output is generated when all of the FF's are 0. Then that is fed back to the load input. The load input loads the divisor and and the down counting continues back to 0 where the process recycles.

Could clock fan out be an issue here?

5 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    11 years ago

    I assume you are saying you got 16 D registers (one on each output) and you want skew of output bits to be zero or consistent.

    You don't need to. This is the whole point behind synchronous design. Any skew between clock edges are to be ignored by next stage

    It is enough to do functional sim and see it clean plus timing analysis rather than timing sim
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    11 years ago

    Thanks for the reply. I have attempted to attach an image of the timing simulation. The outputs are supposed to change on the rising clock pulse.

    I'm thinking you're right because the desired output (TCN) seems valid. It starts to fail around 170 MHz. But with delays like that, it should be failing closer to 100 MHz. At 170MHz, some of the delays are longer than the clock period. The image shows the simulation at 100MHz. Notice how the Q0 output delay is almost the full clock period (10ns). Then it still has to go through the look behind logic to feed the D inputs of the other ff's. More delay.

    That kind of thing doesn't make sense to me. Is there any possibility that the simulator is flawed? Or my use of it?

    Anyhow, I guess the thing to do is not worry about it like you said. My physical system clock is only 48MHZ so this circuit should work.

    Is there a way in quartus to make certain nodes faster? Or some way to mark a node as timing critical so that it isn't routed to the next gate by way of the other side of the chip?

    https://www.alteraforum.com/forum/attachment.php?attachmentid=10710
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    11 years ago

    The main concept of default synchronous design is that an update on Q output is ok as long as new value is available at destination register (after passing through any luts) within 1 clock period and without violating timing window of destination register. This is how fmax is limited. TQ will tell if your fmax is achievable or not.

    So read TQ report and don't worry about your visual analysis.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    11 years ago

    Thanks again. I'm a newbie so I am assuming that TQ means TimeQuest. I've been ignoring that because its RED and it didn't seem important until now and stuff has worked anyway. Anyhow, I went into it and found in one panel "Clocks" is set to 1GHz. Then under "Slow 1200MV 85C Model" -> "FMAX Summary" it says 243.37MHz and then under the same thing in "0C" it says 250MHz.

    Does that mean anything or am I totally going down the wrong path here? Know any good tutorials for TimeQuest?

    Getting back to the original question, I am now wondering if the timing patterns are at the output pins of the chip rather than the circuit. I didn't specifically assign any pins, but I'm wondering if the software might have gone ahead and done that anyway. If that is true, it might explain the bizarre outputs.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    11 years ago

    Without sdc file for timing constraints the tool defaults to that funny speed.

    You must add sdc file to determine your clock name and speed. And you also need to determine io constraints.

    Additionally for io use fast output registers.