ZBT/NoBL clock and PLL setup

--- Quote Start ---

Am I making this too hard?

--- Quote End ---

Not really, being careful doesn't hurt.

--- Quote Start ---

I'm using a TQFP package, and my trace lengths vary from 200mils to 2200mils, with the clock line straddling the middle at about 1000mil. If I loop the clock from the clock pin on the RAM back to a dedicated clock input, that would make the entire trace 2000mil, but the RAM would still see the clock at 1000 mil.

I'm not sure how to set this up. I would like the RAM to run at at least 160MHz (I'm using a 200MHz rated part, but the design needs to run at a minimum of 80MHz, with the dual-port interface running at 2X the system clock)

I haven't rolled the board yet but without seriously reworking it, it's going to be hard to get the trace lengths aligned. I may not even be able to do much better. As for the PLL, I know I need to bring in the mirror clock as a reference input, but beyond that, I'm not sure how to configure it to do what I need.

--- Quote End ---

1000 mil, longer or shorter, is about 155 ps skew, At 160 MHz you have 6,600 ps, so that shouldn't affect the timing budget much. At 2200 mil the total delay is about 390 ps or 5% of the clock period. Quartus II and TimeQuest will handle that nicely.

--- Quote Start ---

I have the SRAM Clock routed out of PLL2_CLKOUTp. Right now, it's source terminated with a 50 ohm resistor, with a fairly straight shot to the clock input on the RAM.

--- Quote End ---

You can't use series termination if your signal goes to multiple destinations (unless you actually use special routing). So you need to parallel terminate at the FPGA. But there is no need to route the clock back to the FPGA as you can perfectly constrain everything using the output clock (and internally the PLL output feeding it).

I appreciate the reply. As it turns out, the Cyclone PLL's can't do external feedback anyway, so bringing the clock back in is pointless.

I just want to make sure I don't run into problems with excessive contention due to the clock at the RAM being significantly delayed from the clock in the FPGA. It's probably overkill, but I'd rather this board be reliable by design.

If it does turn into a problem, I could probably up the clock rate to 180, drop the core to 60, and insert NOP's between every command. A more intelligent design would check for contention before issuing the instruction, but then the latency becomes somewhat variable.

I'm rolling these boards on my own nickel, so a respin would come directly out of my pocket. ;)