Timing Problems in Altera FPGAs

Hi Guys,

I am implemented an real time image correction in an Arria Altera FPGA. However I have this problem with the timing violations. I have used about 95% of the logic available in the FPGA. Before the implementation of this correction mechanism I had about 89% logic utilization. My logic was used because I included custom instruction to do floating point hardware based calculations. This has consumed some resources and also I have used a Nios(s type) of processor so that I could do floating point calculations.

I have problem with timing violations. When I free up some logic the timing violations are not there. Can you give me some suggestions as how should I proceed or solve the problem??
How can I solve the timing violations in Altera FPGAs?? Freeing up logic is the only alternative I have got??

As the FPGA fills up, fitter options to compensate timing problems, e.g. by selecting different routes, dwindle. You probably lose some 100 ps of timing margin. It should be nevertheless possible to fill your FPGA up to 99%.

You'll analyze where the timing violations occur and try to restructure the failing paths, e.g. by adding pipeline levels. If the violations are related to domain crossing, you may reconsider the synchronization method.

ye you will need to reduce logic.

in the nios you can use a "fat" nios to debug code, and a "slim" nios to functional version.
remove other debugging code like jtag , generators , checkers.
reduce brams size as much as possible.
remove unused registers/features.

There are several ways to help remove timing errors. They should be done in this order.
1. Modify your code and break up the logic on the failing paths? are there several sequential LUTs in the failing path? can it be broken up with extra pipeline registers? Also - are the failing paths into or out of DSPs or RAMs? these have a fixed location, so where the logic is placed can hurt the timing. Add extra pipeline registers at the entry and exit of a ram, even if there is no logic between pipe stages. This gives the fitter the option to move a single register around between your logic and the ram/dsp and can make the fitter's job much easier.

2. Are there any false paths or multi-cycle paths that you have failed to specify? making the fitter work harder in one area where it didnt need to can hurt the timing in another area.

3. Run a seed sweep - are there any path that fail consistantly? then you probably need to re-asses the source code (like step 1).

4. Add max delays to fitter only on the paths that fail all the time, to make the fitter work harder on the specified path. BE WARNED: this really should be a last resort when 1/2/3 are exhausted. This can quickly turn into a game of whack-a-mole. (you fix one path, only to have the next path in the chain fail timing)

Hi Guys,

Thanks for your replies.

@trickydicky - Yes I do have about 16 RAMS whose data are loaded into by the NIOS processor after doing the floating point calculations. Are you saying that I build registers at the input and output of the RAM?? My RAM is a dual port RAM and receives two clocks one is the data clock and the other is the NIOS related clock to write the data into it.

You'll need to add the extra register wherever the path failure is. If the failure is nothing to do with the ram, then the extra pipelining probably wont help you. If you need extra registers, there is an avalonMM bridge block that adds extra pipe stages to the bus.

What are the system clocks in this design?

I think the path failure is due to the RAM because the project functions properly without my code in it even though there exists timing violations . System clock is 25MHz and the data clock is 3 times i.e 75Mhz.

If you're having timing problems at 25Mhz and 75Mhz, then I suspect the real problem is design flaws. 25/75Mhz is very slow for an arria, and you shouldnt struggle too hard to make a full design meet timing at this speed.

Are you assessing the timing failures? instead of making assumptions - find out where the paths are and act accordingly.

TrickyDicky said:

If you're having timing problems at 25Mhz and 75Mhz, then I suspect the real problem is design flaws. 25/75Mhz is very slow for an arria, and you shouldnt struggle too hard to make a full design meet timing at this speed.

Are you assessing the timing failures? instead of making assumptions - find out where the paths are and act accordingly.

Click to expand...

Tricky design flaws is rather harsh...I would term it an improperly pipelined design.

In a synchronous design with good pipelining practices an Aria should be easily capable of 300 MHz designs (i.e. 4x your 75 MHz). As your design can't make timing on one of the clock domains of 25/75 MHz, that means you didn't account for levels of logic while designing the circuits.

I suspect we would likely see 20-30 levels of LUTs from source register to destination register. If you look at the timing report of the violations what kind of paths do you see? If you don't know how to read the timing report then post the full report for the first two violations.

I am not able to understand properly. However there are plenty of clocks in the design and some are clocks generated by PLL's. The clocks that I needed was the clock which Nios uses and that was system clock 25Mhz and the other is the pixel data clock which is used to sample the pixel data from the camera sensor and the valid signals which is 75Mhz (a PLL generated one).

I give these two clocks to the dual ports of the ram. Do you want me to post the timing analyser report summary(setup and hold summary)??

What are you not able to understand? DId you write some custom HDL code to connect to your NIOS system? did you put a good level of pipelining in? can you not add more pipeline stages to the floating point cores?

Without your design, posting the timing report wont really be much use to us. The timing report will give you the paths that are failing, you should be able to work out where the paths are in your design

do you set false paths between clock domain? that might help...

Yes I have written a connector HDL program and added in the qsys project where the slave signals are connected to NIOS processor and the export signals from this connector are port mapped to my block.
@aruip - I will try setting false paths and check.

do you set false paths between clock domain? that might help...

Click to expand...

You should have declared unrelated clock domains by a "set_clock_groups" constraint in your sdc file.