Forum Discussion
Altera_Forum
Honored Contributor
15 years agoJust taking a quick look, one thing that jumps out is the create_generated_clock assignment doesn't seem to be applied to anything. You say what the -source is, i.e. where the clock comes from, but it needs to be applied to the output port. Something like:
create_generated_clock -name inv_src_clk_out -invert -source [get_ports src_clk] [get_ports clk_out] Basically I just added the [get_ports clk_out]. Without that, it's a virtual generated clock, i.e. it exists outside of the FPGA. (I almost wish it would have errored out, but there are cases where people use virtual generated clocks). Anyway, once you add that, you're telling TQ where the generated clock exists, i.e. at the output port. It will use the delays all the way back to the source clock. When you do report_timing -setup -detail full_path -npaths 100 -to [get_ports data_out] -panel_name "s: * -> data_out" you will see the data required path starts at the clock coming in and traces all the way to the clock coming out. 1) For a source synchronous output, there is no virtual clock. Virtual clocks are when there is a board level clock that drives the FPGA and the external device. (I admittedly need to add a long write-up on source-synchronous interfaces). 3) You need to change the values from 0.0. Basically you need to account for board skew and requirements of the receiving device. Right now you have a 4ns setup and -4ns hold. That means the data could be skewed by +/-4ns and still meet timing. You're basically giving the entire data window to the FPGA to play with, but really some of it will be lost at the board level, some at the external device. Put down the external device specs and I might be able to help.