Timing constraint problem while using altera ipcore

Question

Hello everyone,

I met two problems while using altera ipcores: fir core and fft core(in Straitix III system). The sample clk in my project is 187MHz, and I’ve checked the user guide that both fir and fft cores can meet timing constraint.

In my design the fir core is designed as a coefficient reloading structure, which coefficients could be reloaded from input port before the ipcore working. The fft core is designed as a variable streaming structure, which is also a variable structure from 256 point to 8192 point. Besides, in the real working process, the fir coefficients will be preloaded before the ipcore starts to work, and the fft point is also set to a fix value(256 or 512, …, or 8192) before system work each time. These two processes are independent, so there must be no timing conflict between coef_reload process and data_transmit process in fir core, or point_set process and data_transmit process in fft core. ALL those situations mentioned above have been considered by us before the system works.

But after finishing the design, when I use TimeQuest and check fmax I found that the real sample clk is only 117MHz. When I use report timing function in TimeQuest, I found that nearly all worse time paths reported are in those two cores. I have no idea on how to write timing constraint for these two cores. In order to meet performance, anybody who knows how to set timing constraint in sdc file? Thanks a lot.

altera_forum · Answer

Once you have constrained your designs clocks, Timequest should use their frequencies in its analysis. Just create the input clocks in your .sdc file with the correct frequency/period.

If the fitter isn't able to meet the timing requirements, you may need to increase the pipeline level. I don't know if it is configurable in the fir and fft cores.

altera_forum · Answer

Thank you for your quick reply, Daixiwen.

For both of your advice, I’ve already considered them before compiling the project. In my .sdc file, I created my input clock, set it with the correct, required frequency. But after the fitter process, it still can’t meet the timing requirements.

For your second advice, I’ve think it over too. In the fir core, one of options is pipeline level, the default option is 1, but I have already set it to the maximum value 3, so how should I do next? While in the fft core, I guess there no such option for pipeline setting since I did not find any options in the Parameterize column. Your advice remind me, maybe I could add several pipelines manually in the output port, to meet requirement? But by doing so only increase the output data timing, there is no help for the data processing inside the fft core. I will try it, but it might not be useful either……

altera_forum · Answer

One more thing to explain in the fir core, in the coefficient fixed architecture, the register to register delay is fixed, so it will meet the fmax that mentioned in the datasheet. But for coefficient reloading architecture, the input coefficient data will first arrive coefficient register and then the core works, so the fmax is decreased due to the extra data processing in coefficient reloading part. But in fact, the coefficient reloading process is preprocessed before the fft data process. I want to add constraint in sdc file to hide the coefficient processing, for the constraint from interface to inside register is easy to add, but for register-to-register inside core I do not know how to write constraint, that upsets me.

altera_forum · Answer

Unfortunately I don't know the FIR's internals, I design my own filters without using the megacore. Can the coefficients loading be done in a different clock domain?

Did you have a loot at the timing advisor (Tool menu)? It con give you some ideas about settings to change to increase the fmax.

Do you have some options to register the core's inputs and outputs? If yes, enable them.

altera_forum · Answer

--- Quote Start ---

Unfortunately I don't know the FIR's internals, I design my own filters without using the megacore. Can the coefficients loading be done in a different clock domain?

Did you have a loot at the timing advisor (Tool menu)? It con give you some ideas about settings to change to increase the fmax.

Do you have some options to register the core's inputs and outputs? If yes, enable them.

--- Quote End ---

It is has two ways to design the fir core with coefficient reloading process, one is synchronous clock domain, and the other is in different clock domain. Since the asynchronous architecture is a little bit difficult when I consider about the data transfer between this core and my other circuit, in addition, one clock domain is more stable in the system, so I give up that idea and design all of them in one clock domain. So for the fir core, the coefficient reloading is done in one clock domain. The structure could be remodified, but I still wish to do it based on my current structure. If it still can’t meet timing requirement, I would consider to change it later.

And for those options in tool menu, I’ve already set them, for instance, optimize speed in Analysis, check auto fit in fitter effort, etc. Could you give more advice based your own design experience?

Btw, when you design fir by yourself, how to write timing constraint to meet requirement in your project?

Forum Discussion

Timing constraint problem while using altera ipcore

9 Replies

Recent Discussions

Agilex5 Engineering Silicon

Does direct connection of two AXI4 Masters to DDR Slave support auto-arbitration on Agilex 5?

Arria 10: Remote Update Watchdog unpredicted behavior

MAX 10. No 3.0 V Schmitt Trigger I/O standard

CYCLONE 10LP Decouple capacitors