How much violation is ok?

I would recommend trying to meet timing if you can.

What frequency is your design operating at?

What are the failing paths; internal or external?

Have you looked at the logic to see why the path is failing? Have you looked at modifying the logic, eg., can pipeline registers be used to improve the timing.

Cheers,

Dave

To give more details of my project:

There are 100 and 200 MHz domains in my design and violations are obviously in 200 MHz domain. I have tried DSE - but these violations are hard to close. The violations are inside DDR2 controller of Altera (it is encrypted, so no way I can try to fix them). To make matters worse, the device utilization is a whopping 90%.

Also, does it make sense to run DSE on a machine with 4GB RAM and i5 core processor on Windows 7 - I see it hang after 3 to 4 iterations.

--- Quote Start ---

There are 100 and 200 MHz domains in my design and violations are obviously in 200 MHz domain. I have tried DSE - but these violations are hard to close. The violations are inside DDR2 controller of Altera (it is encrypted, so no way I can try to fix them). To make matters worse, the device utilization is a whopping 90%.

--- Quote End ---

Have you tried reducing the logic usage - just to see if the errors clear? At least that would then confirm that the high utilization was leading to the DDR controller failing timing.

Does TimeQuest indicate any DDR constraints are being ignored or not matched? There are paths in the Altera IP that are supposed to be cut, but in some cases, I've seen the constraints ignored (in the PCIe IP if I recall correctly).

--- Quote Start ---

Also, does it make sense to run DSE on a machine with 4GB RAM and i5 core processor on Windows 7 - I see it hang after 3 to 4 iterations.

--- Quote End ---

I've never had DSE produce anything useful.

I'd look into confirming that it is possible to get the DDR controller to meet timing with a reduced logic design, and then send the file(s) to Altera in a Service Request, eg., either two separate designs or a design with a generic that changes the resource utilization.

In parallel with that you could see if using a design partition helps, eg., restrict the placement of the DDR controller ... though I have not used this aspect of Quartus, so can't comment on the likelihood of success. I do know of Xilinx users that have had to resort to floor planning to squeeze that last ounce of performance out of their parts.

The other thing you can do is to try a couple of different speed grades - not because you should use a faster device, but to get a sense of how badly constrained the DDR controller is.

Cheers,

Dave

The design was meeting timing when the utilization was around 80% - so I assume the violations now are due to the added logic (90%)

And I am already working with the best speed grade. And none of the DDR constraints are ignored. FYI, I am working with Quartus-II 6.1 and classic timing analyser - cannot help these facts as its a legacy design!

And when I reduced some logic (which was acceptable), the timing meets occasionally (now utilization is 84%). And when it fails, the violations are no more in DDR - each time a new part of the design in the 200 MHz domain fails to meet.

My feeling is, the device utilization is at its saturation point for timing closure.

So, am back to my question - how much violation can be safely waived?

Thanks,

Satish

--- Quote Start ---

150ps is small enough that you might be able to do a 'seed sweep', to get a good build seed value which meets timing

--- Quote End ---

the seeds themselves only form part of the seed equation. It is mainly affected by the source code. So a seed that meets on one build is not guaranteed to be a "good seed" for the next DSE run.

This is a great article on how the fitter works and how DSE fits into the equation:

http://www.alterawiki.com/wiki/the_quartus_ii_fitter_and_seed_sweeps

--- Quote Start ---

The design was meeting timing when the utilization was around 80% - so I assume the violations now are due to the added logic (90%)

And I am already working with the best speed grade. And none of the DDR constraints are ignored. FYI, I am working with Quartus-II 6.1 and classic timing analyser - cannot help these facts as its a legacy design!

And when I reduced some logic (which was acceptable), the timing meets occasionally (now utilization is 84%). And when it fails, the violations are no more in DDR - each time a new part of the design in the 200 MHz domain fails to meet.

My feeling is, the device utilization is at its saturation point for timing closure.

So, am back to my question - how much violation can be safely waived?

Thanks,

Satish

--- Quote End ---

Ideally you need to pass timing. If it gets hard here is my approach:

Check failing path for any signals that have higher probability of failing . The idea is to see if you can improve on them.

revisit the code for any long paths.

check that some paths can be deconstrained

If after all it fails marginally then DSE can help as it may vary slack by some +/-10% or so.

If you have to live with negative slack then what matters is the signals involved and DVT (device,voltage,temp) variables and I don't see the relation to be linear but I better see some builds and test them in hardware directly.

--- Quote Start ---

The design was meeting timing when the utilization was around 80% - so I assume the violations now are due to the added logic (90%)

--- Quote End ---

Yes and no. If your design contains unnecessarily long paths, then you may be making the tool work hard to meet timing. If you can pipeline logic, then its generally a good idea to try that.

--- Quote Start ---

And I am already working with the best speed grade. And none of the DDR constraints are ignored. FYI, I am working with Quartus-II 6.1 and classic timing analyser - cannot help these facts as its a legacy design!

--- Quote End ---

What feature of 6.1 is needed? You should be able to upgrade to the newest version of the tool that supports the device you are working with. If its a FLEX or ACEX you can use 9.0SP2.

--- Quote Start ---

And when I reduced some logic (which was acceptable), the timing meets occasionally (now utilization is 84%). And when it fails, the violations are no more in DDR - each time a new part of the design in the 200 MHz domain fails to meet.

My feeling is, the device utilization is at its saturation point for timing closure.

--- Quote End ---

The tool is not very granular. It has to look at the design as a whole, if you have some poorly coded logic in one area of the design, then the tool does not account for that in its attempts to meet timing. Take a look at your code as a whole, not just the failing paths.

--- Quote Start ---

So, am back to my question - how much violation can be safely waived?

--- Quote End ---

Can you control the clock source to the design, eg., via an external synthesizer or by using a PLL inside the device? If so, run a test that shows the hardware is all working, and then keep increasing the operating frequency. Once the design stops working, you'll have an idea of what your timing margin is. This is only a single sample test though, and by (bad) luck you might have the fastest version of the device you'll ever buy, so the results should be interpreted conservatively ;)

This test is easier to do with an external synthesizer since you can just program a new frequency. If using a PLL, you need to use a reconfigurable PLL, so that you are not changing timing (by resynthesizing the design with a new PLL setting).

Cheers,

Dave