--- Quote Start ---
0ns external delay doesn't mean no IO requirement, just that the external device isn't chewing up any of the requirement. I am guessing the setup relationship is 6.4ns, so you have 6.4ns to get out. Run:
report_timing -setup -to_clock ddsclk1_ext -npaths 20 -detail full_path -panel_name "s:ddsclk1_ext" -file "./TQ/ddsclk1_ext_setup.txt"
(You can do this by right-clicking on the summary row you listed above and going to report_timing, and modifying accordingly). My first guess is you're not using a PLL to shift the clock tree back, and without that it's easy to have a Tco greater than 6.4ns. It may be somewhat difficult to meet timing even with it, but I think should work.
My second concern is if your constraints are even correct. From the description, the dds sends out a clock to the FPGA, the FPGA sends data back, which must reach the dds in time to meet setup, and you want to do this in one clock cycle. If it's 6.4ns period, the external setup is 2ns, you need to get through the FPGA plus both board delays in 4.4ns. But that doesn't even account for how long it takes the dds chip to send out its clock. If that's 2ns, then your down to only 2.4ns for the FPGA and board delays.
The other option is that the FPGA sends the data back to the DDS along with a clock. I have no idea if that's even possible, but if it is, then you need to create source-synchronous timing constraints, i.e. you put a generated_clock on the output port sending a clock out, and your set_output_delay would use that clock for its -clock option.
Anyway, just throwing those out as a concern.
--- Quote End ---
Hi Rysc,
Thanks for your opinion, I runned the report and got this. (attached the waveform pic)
http://www.alteraforum.com/forum/attachment.php?attachmentid=10163&stc=1 As you can see, the clock delay is 6.3 something ns, which I think is very large. Is this normal? Wha do you think?
On your first concern, I am not using a PLL in my design, I am just using the clocks from the DDSes to drive my design.
On your second concern, yes that is the way I'm implementing this design. The DDS sends out a clock signal that I'm using to drive my design. The DDS also uses this clock signals to sample the data that I am sending it. And the data to clock timing for the DDS are 2ns (setup) and 0ns (hold). So do you think this way of implementation is not so practical?
On your third concern, I don't think I can do it that way, because the DDSes samples the data using its own clock.
What do you think?
Thanks for your comments!
Honored Contributor
