Timequest / virtual clock

[Altera_Forum]

Altera recommends in the Quartus Handbook to use virtual clock if you model 

external delays in conjunction with clock uncertainty. I am analyzing a small design were the external chips and the fpga is driven from the same clock source and I didn't specify  clock uncertainty in the sdc file. Therefore I would assume that there should be no difference in the timing result if I use a virtual clock or not but I am getting completely  different fmax values (80MHz or 37Mhz). Could someone please explain me the reason  for this and what the right use of virtual clock is?  The sdc file looks like this:  create_clock -name clk -period 30.000 [get_ports {PCI_CLK}]  set_input_delay -clock clk -max 11 [get_ports {D1 ...}] set_input_delay -clock clk -min 2 [get_ports {D1 ...}]  set_output_delay -clock clk -max 10 [get_ports {B1 ...}] set_output_delay -clock clk -min 0 [get_ports {B1 ...}]  or respectively:  create_clock -name clk -period 30.000 [get_ports {PCI_CLK}] create_clock -name clk_virt -period 30.000  set_input_delay -clock clk_virt -max 11 [get_ports {D1 ...}] set_input_delay -clock clk_virt -min 2 [get_ports {D1 ...}]  set_output_delay -clock clk_virt -max 10 [get_ports {B1 ...}] set_output_delay -clock clk_virt -min 0 [get_ports {B1 ...}]

[Altera_Forum]

I'm not expert about virtual clock, but your is a false problem. 

I mean you've restricted your clock at 33Mhz (30ns) and with both constraint sets you respect that value, so you should not care of..  Synthesis and fitting try to respect all sdc assignment you've done and when they successfully achieve all of them they end timing closure.

[Altera_Forum]

I know that both results would allow to drive the circuitry with the actual clock of 33MHz but 

obviously one sdc file is delivering a wrong result and it should be good to know which one is the right way. Please note that I get the different fmax values also if I just repeat the timequest analysis without recompilation (no new synthesis and no new fitting).

[Altera_Forum]

I'm not an expert, too, so please don't take this as the Bible. 

Anyway I think the problem is due to the fact that virtual clock has a 30ns setup relationship with internal clock, since TQ assumes it is generated outside fpga, synchrounously to internal clock. So the virtual clock has no delay at all when latching/launching I/O data, while I/O data itself has the delay. On the other hand, the internal clock accounts for the delay required to reach the I/O, which makes no sense for data clocked externally. Infact, TQ guide recommends not using an internal clock with set_input/output_delay, unless you use a generated clock which actually feeds an output pin.  PS: you should see what I explained above if you analyze the full path with TQ in both cases.  Regards

[Altera_Forum]

Moserw, 

 The first tip you may want to follow when comparing two SDC files is to do the two different Timing Analyses with the same fit (same place and route result). This ensures your timing is constant and therefore you can do an apples to apples comparison. If you believe the SDC files are equivalent, then you should get the same exact slack (note you may need to look at multiple paths to confirm all paths are the same).  In your simplistic example, there is really no advantage of using a virtual clock unless you also use clock_latency to model the delay from the clock to the clock pin. Virtual clocks are also useful when you want a way to easily add multicycle or false path exceptions on the I/O paths (because it is easy to make an exception from the virtual clock to the clock).  Anyway, do the two analyses and see if you can confirm your slack is the same.  David

[Altera_Forum]

David, 

 That is what I tried to say in my last posting. I get this two different timing results if I only change the SDC file and do the analysis without recompilation (same synthesis, place and route). This is really strange ...