--- Quote Start ---
Normally quartus should not put unduely long delays between registers unless there is too many layers of comb. logic.
I am not sure I understand why quartus puts such delay from A to B in your case. Moreover if you have freedom to put extra pipe registers then it means you don't worry about the rule of one clock of timing(default multicycle) and so your solution of extra pipe registers is equivalent to adding multicycle and then save some registers.
In short, you can just add multicycle, or set max delay or add pipe that quartus spreads along path or force manual fitting.
--- Quote End ---
I think you're right. I should be able to add multicycles to shift the setup and hold window enough to pass timing. I haven't used multicycles before but I'm aware of them. IIRC, they are used to push the data required time back by a configurable amount of cycles. Thanks for the idea.
--- Quote Start ---
How to you specify timing requirements in your design? Do you constrain the desired clock rate? Do you set maximum path delays between the registers in question?
--- Quote End ---
I use create_clock for clocks coming from input pins and derive_pll_clocks to let Quartus define pll output clocks. That's usually sufficient. I do not constrain path delays between registers.
--- Quote Start ---
Philippe -
That's unfortunate you had to lock things down. That makes for an inflexible design if things change in the future.
I'm curious if your problem even makes sense. What device and speed grade are you targeting and what is the frequency of "clk"? Also, what is the fanout from source to destination? And what version of Quartus are you running?
Bob
--- Quote End ---
Device: 5SGXMA7N2F40C3
Quartus: 13.1.4 Build 182
Fanout is 36.
The clock frequency is a bit out of spec at 781.25 MHz (1.28ns) which is why Quartus was having trouble meeting setup requirements. This clock is driving a minimal amount of logic. It is just being used to serialize 4-bit words that are being clocked at 195.3125 MHz. I know that the LVCMOS IOs in Stratix V are rated at 166 MHz but the resulting serial signal toggles no faster than 10 MHz. However, we need the serial clock to be fast in order to have finer control of the edge locations.
update First, a clarification on the general design. I am fanning out 4-bit words to 36 IOs across the FPGA at 195.3125 MHz. Next to each IO there is some logic to serialize the 4-bit words at 781.25 MHz.
When I made my first post, my design had no location constraints and Quartus did not place the serialization logic very close to the IOs that were being driven. This failed timing because the IC delay between the serialization logic and the IO was large (large relative to a 1.28 ns setup relationship). I tried adding register stages between the serialization logic and the IO cell to reduce the IC delay between each stage but Quartus clustered the register stages together so there was always one stage with IC delay greater than 1.28 ns. This prompted my question about how to get Quartus to evenly spread out a chain of registers.
Since then, I added location constraints to place the fanned-out 4-bit words right next to each IO (this section meets timing easily because it is clocked at 195.3125 MHz). This helped Quartus place the serialization logic right next to the IOs so IC delay is no longer a problem. Thanks for all your responses!
Honored Contributor
