Posted on:

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. 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 registertoregister inside core I do not know how to write constraint, that upsets me.
Posted on:

Possibly your coefficient data is not registerer/piepelined enough (check in depth the critical paths reported by the timing analyzer from origin register to target register). However, if you can guarantee the coefficients reloading part is separated from the subsequent processing (i.e. you can make sure there is enough time for the coefficient signals to settle before used in calculation), you could define multicycle paths or false paths. But be aware that you really have to knwo what you do in this case as the timing analyzer will not care about anymore when decalred false path! Multicycle paths or false paths could look like this in your SDC file: set_false_path from [get_registers{F*:\FF*F*fmFsm_cur.*}] to [get_registers {STMSRVTOP:STMsFM_DIR_q}] set_multicycle_path 2 setup from {*P:0:PRC*VLGCLUT:LUTreg_cur[*]} to {*P:0:PRC*VLGCLUT:LUTDIVU:DIVreg_cur[*]} end