Manual Logic Duplication

Yeah, that used to be in the Timing Closure Floorplan, but after that was integrated into the Chip Editor, I don't see it anymore.

How much are you failing timing by? How large is the fanout of the node you want to replicate? How far is the hop to the destination nodes that are failing timing? Does it feed separate blocks or just a lot of stuff(will explain later, but determines if you should use max_fanout or manual logic duplication)? I tend to do this when I'm close to meeting timing, as it usually doesn't have huge savings, but is often enough to close timing.

Note that replicating logic doesn't help much from a buffering standpoint, as FPGA's are buffered all over the place. How they do help is they allow a node with high fanout to be placed closer to the logic it's driving. For example, if a control register feeds logic on the top of the chip and the bottom, replicating it allows one to be placed on the top and one on the bottom. Make sure the node you are replicating is a register, so the name is constant compile to compile. If you're trying to replicate a combinatorial node, it won't work because the name will change in future compiles and your assignment will no longer apply. There are a couple ways to achieve this. But you want to Locate the node to the Assignment Editor. I usually just look at the timing report(Classic or TimeQuest) and just highlight and copy it. Then open the Assignment Editor and paste it:

1) If I paste it into the To column and apply the assignment Maximum Fanout and then for Value, give it a number. For example, if the node has a fanout of 128, I might set it to 16, so I get 8 copies of this register, each with a fanout of 16(don't set it to 1, as that's overkill). Note that this is a "dumb" assignment, i.e. it doesn't intelligently decide what to replicate for each fanout. So it works perfectly if the 128 destinations are all similar, but if 64 of them are part of the PCI core on the top of the device, and the other 64 are part of the SPI bus on the bottom, you will end up with replicates that have a fanout of 16, but some of those 16 will be PCI and some will be SPI, and you'll still have the same problem.

2) If you put the node name in the From column of the Assignment Editor, then you can put *PCI* in the To column, and use the Assignment Manual Logic Duplication. Then the value is the new name of the duplicated register, like reg2PCI or something. This will duplicate the register once, and that duplicate will feed all nodes that fanout to *PCI*. So it allows more control. To be honest, I seldom do this, and instead use 1) or 3)

3) Replicate the node in your logic. This gives you good control, as the combinatorial logic it feeds can also be replicated, if that's what you want. The only thing is that by default, Quartus merges duplicate registers. You can turn this off globally, but I don't recommend it. Instead, put the name of both registers into the To column of the Assignment Editor and add the assignment Remove Duplicate Registers and set it to Off(love the double negatives). This way those registers won't be merged.

Good luck.

Hi Rysc,

Thank you for the detailed reply. I fail to meet timing requirement in the margin. Report from Timing analyzer says the design meets fast model but fails to meet slow model. In slow model the setup time is violated at around 0.430 ns and the recovery of CLK fails around 0.830 ns.

Could you suggest a way for this problem???

regards,

skr

I would fix the Recovery first, as that's usually the most straightforward. Do you understand what Recovery is? Do you understand why it's failing? Your recovery net should usually be on a global and will meet timing(unless it's a very fast domain). Otherwise you'll need to add registers to meet timing(if it's using local routing).

Once that is fixed, I would look at setup. What's your setup requirement? (.430 isn't too much if you have a 20ns requirement, but if it's 4ns, it's tougher to improve upon). What are your compile times? Are you doing the other options like synthesizing for Speed, turning on Physical Synthesis? How many paths fail?

Hi Rysc,

Thank you for the reply. I have made corrections to fix the recovery(making recovery nets globals; when I changed some settings i included some of those nets to local which gave me the problem with recovery slack).

Quartus is very new to me and I donot know most of the features or terms used in here. Frankly I dont know what recovery is. Thank you for very nice explanation.

My design was targeted for 100Mhz and now it runs more than the speed intended for.

Thank you so much for your clarifications... I will come back to you if I encounter any more problems :-)

regards,

skr

Recovery is analogous to setup, where it's a source register feeds a destination register, the only difference is that it feeds the asynchronous port(clear or preset) of the destination register. For a simple example, a 10ns clock domain might have a register called areset that fans out to the aclr port of all registers in that domain. When that source register goes from 1->0, releasing the destination registers from their reset state, we want that signal to hit all the destination registers within 10ns. What that means is that the clock edge at time 0ns, they will all be held in reset, and at the next edge they will all be released from reset and see the clock.

If any registers fail, i.e. have a delay to them that is longer than 10ns, than those registers will still be in reset for that clock edge. If they are part of a state-machine or some control logic that "goes" on the first clock, this can cause serious issues, because your device comes out of reset over various clocks. It's also troublesome in that it causes "random" failures. Meaning, if timing analysis says the path to some registers is 12ns, which is a failure, some devices might be much faster than that and still work, some might be longer. It can be a nightmare to debug.

The reason it's called Recovery is that it describes how the destination registers(i.e. all the registers in this domain) recover from the reset state.

Glad to hear your making progress.