Honored Contributor
Honored Contributor1. No idea. Are other clocks getting uncertainty added? Look at the comments to see this assignment called out, and then expand it to see the uncertainty it adds(there will be a lot of them). I've never seen this before though.
2. The <target> does not have to be in there, as I do that all the time. I create virtual clocks solely for I/O constraints, basically creating the virtual clock and then use that clock in the set_input/output_delay -clock option. Most of the time that clock will look identical to the clock coming into the FPGA. So why do it? - It makes more sense when you understand set_input/output_delay constraints. They are not directly constraining the I/O paths in the FPGA. Instead they describe an external register, what it's clocked by, and how long it takes to send data to the FPGA. Armed with that information, TimeQuest can then figure out what to make the I/O paths look like. - Allows the user the ability to change that external clock. For example, I could change it's duty cycle, or give it more uncertainty, or give it a set_clock_latency, or change it's -waveform, without having to change the clock coming into the FPGA. THis provides flexibility. - Easier timing reports. Rather than having to name all the I/O, my timing .tcl file might have something like: report_timing -setup -from_clock ext_clk_virt -npaths 50 -detail full_path -panel_name "s: Inputs ext_clk_virt" report_timing -hold -from_clock ext_clk_virt -npaths 50 -detail full_path -panel_name "h: Inputs ext_clk_virt" This will report input setup and hold timing on all inputs clocked by this virtual clock. If I add a new input port that uses this clock, it will automatically be reported. - And most importantly, the derive_clock_uncertainty will do the right thing. If you use an internal clock as the same clock for your set_input/output_delay constraints, the derive_clock_uncertainty can only add one setup and hold uncertainty value when that clock is the source and destination, and as such, it will use the uncertainty values when this is inside the device. If you create a virtual clock, it now knows there is a different clock and will calculate a different uncertainty. This is probably the most important one(although admittedly the difference in uncertainty will be small) 3. For input/output constraints I use -add_delay for double-data rate interfaces. Basically it means you are desribing a second external register that the I/O port connects to. So for DDR it might be something like: set_output_delay -clock ddr_ext_clk -max 0.5 [get_ports ddr_out*] set_output_delay -clock ddr_ext_clk -min 0.5 [get_ports ddr_out*] set_output_delay -clock ddr_ext_clk -max 0.5 [get_ports ddr_out*] -clock_fall -add_delay set_output_delay -clock ddr_ext_clk -min 0.5 [get_ports ddr_out*] -clock_fall -add_delay I believe I've posted a document about source-synchronous DDR constraints, which would help explain this. (But yes, the very first one does not use -add_delay. I think the write SDC command, which I generally don't recommend, appends -add_delay to all of them because it just doesn't know, and doesn't really hurt if one didn't exist. And you'll also note I didn't need it for the -min option if there was a -max, since those two are constraining two different sides and would not overwrite each other.)
