Forum: FPGA, VHDL & Verilog Timing constraint problem while using altera ipcore

Author: grant zhao (zlygrant)
Posted on:

Rate this post
0 useful
not useful
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 

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 

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

Author: pek (Guest)
Posted on:

Rate this post
0 useful
not useful
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 

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:STM|sFM_DIR_q}]

set_multicycle_path 2 -setup -from {*P:0:PRC|*VLGCLUT:LUT|reg_cur[*]} 
-to {*P:0:PRC|*VLGCLUT:LUT|DIVU:DIV|reg_cur[*]} -end


Entering an e-mail address is optional. If you want to receive reply notifications by e-mail, please log in.

Rules — please read before posting

  • Post long source code as attachment, not in the text
  • Posting advertisements is forbidden.

Formatting options

  • [c]C code[/c]
  • [avrasm]AVR assembler code[/avrasm]
  • [vhdl]VHDL code[/vhdl]
  • [code]code in other languages, ASCII drawings[/code]
  • [math]formula (LaTeX syntax)[/math]

Bild automatisch verkleinern, falls nötig
Note: the original post is older than 6 months. Please don't ask any new questions in this thread, but start a new one.