--- Quote Start ---
Can you post the different results? Do a report_timing with -file "TQ_results.txt" for each one and attach, pointing out the difference? (I wouldn't be surprised if the uncertainty is different, but that's it and should be a small difference)
For source-synchronous, Tco isn't really the correct spec. What you really want to enter is the data pin's skew in relation to the clock. For example, let's say the Data has a Tco of 4ns while the clock has a Tco of 3.5ns. We don't want to enter a set_input_delay of 4ns, but of 0.5ns(Plus any board skew). Conversely if the data has a min Tco of 3ns and the clock is still 3.5ns, then the set_input_delay -min is -0.5. I was kind of thinking that's what you meant when entering Tco and -Min Tco for your values, but wanted to be explicit.
--- Quote End ---
If you mean my results then here they are:
sys_clk: fmax 238, io worst slack -1.495, worst core slack +.278
vir_clk: fmax 411, io worst slack -1.475, worst core slack +.278
fmax (I think) is different but strangely io setup slacks are almost same, core slack is same but this funny fmax just doesn't make sense. Moreover 411 is > my request ! I thought fmax covers io path. Am I missing something?
Regarding tCO: you are right that the main idea is to enter data offset relative to clock at input pins but your terminology is not familiar, I have never heard of clock tCO??? tCO is defined for data at external chip boundary(not fpga pins) relative to its clock
When using tCO only we assume clock and data board delays are equal otherwise they are added to tCO equations.
edit: I think what TQ is doing it first it add 20 ps as uncertainty between vir_clk and sys_clk (this accounts for different io setup slack). Moreover it does not include -ve slack when calculating fmax on vir_clk case. in case of sys_clk it takes -1.495 into account and so fmax goes down to 238
Honored Contributor
