virtual clock source latency

[Altera_Forum]

Hi 

 Seems I'm not the only one on a SDC quest, but I couldn't find my problem so far.  I'm trying to specify IO-timings for some simple GPIOs driven by registers/software. So the easiest approach would be to give numbers for tSU and tH directly, but in can live with any approach (and so far tried more than one).  The GPIO registers are clocked with 48MHz. This clock is generated by a PLL and then passed through several clock gates (ASIC design... *sigh*). For this reason, timequest always adds some 15ns source latency on that clock (what is correct...).  Whatever I do now on the ports, those 15ns phase shift break timing. Either they are missing as source latency for the virtual clock or they are simply not added to the min/max delay.  I guess I could just modify my numbers or use set_clock_latency, but this is not very convenient if the 15ns change (what they normally do for different seeds). Is there any proper way, to relate the virtual clock source latency to another clocks latency?  Thanks, emanuel

[Altera_Forum]

It sounds like the 15ns is correct, it's just that you have lots of margin. (If the clock delay doesn't matter, then you have source-synchronous outputs and should constrain it that way).  

If you do, just add multicycles between the internal clock and the virtual clock, i.e.: set_multicycle_path -setup -from [get_clocks internal_clk] -to [get_clocks virtual_clk] 2 set_multicycle_path -hold -from [get_clocks internal_clk] -to [get_clocks virtual_clk] 1  A single multicycle adds ~20ns, which should take care of it.  Or is the problem on your inputs to this domain, whereby you have a hold failure? You might be doing a "same-edge transfer". This is basically where the same clock edge that launches data externally from the virtual clock goes through so much clock skew that it "beats the data" to the register, and that's the transfer you want. To do that, just add:  set_multicycle_path -setup -from [get_clocks virtual_clk] -to [get_clocks internal_clk] 0

[Altera_Forum]

Well, I have the problem on both ends, output setup and input hold. But obviously caused by the same issue. 

 I can definitely fix that with a multicycle. But is that the best way?  I could as well do something source synchronous (what is not completely wrong), but there is no clock pin resp. no output clock at all.  Then I'm not sure if I understand you correctly: You write if the clock delay doesn't matter, then it is source-synchronous. Isn't that the other way round?  In my case, the clock insertation delay does not matter. Just the timing analysis forces me to respect that from the pin point of view, because this delay is always included in the arrival path.

[Altera_Forum]

For source-synchronous, it's not that the clock delay doesn't matter, it's that it tends to "cancel out" with the data delay(this is when the FPGA is sending source synchronously). I was wondering if that was what you meant when you said it doesn't matter. Otherwise I'm not sure how it doesn't matter. If the clock delay is 5ns on one compile and 150ns on the next compile, I assume that's going to affect timing. Obviously that's never going to happen, but shouldn't the clock path be part of the analysis?  

Usually multicycles are the correct solution. For example, if you have a 20ns clock period and are sending data out, but the clock delay is 15ns, the data delay is 4ns and the setup requirement of the external device is 5ns, then you miss timing by 4ns. If 20ns really were the requirement, then I think the clock delay is very important. If you've got multiple cycles to get there and so the 15ns delay doesn't matter too much, then multicycles would apply. (If I'm missing something in what you're doing, please elaborate...)

[Altera_Forum]

You might have hit my problem here... Let me elaborate and see ;) 

 I'm trying to constrain an output path that is basically running without a clock in the STA sense (software might create one by bit banging). So all I can try is to limit the time from this software driven register to the output pin.  Picking up your example, the 15ns clock delay possibly applies to all registers driving output pins. In that case, I would not mind if the sum of clock delay, data delay and external setup is bigger than one period, as long as the sum of data delay and external setup is not.   But probably my assumption of having the same clock delay to all output registers is rather daring.  Also, the idea to constrain something rather asynchronous below one clock period seems somewhat strange in that light. So I can easily use a multicycle and assume that no one ever tries to send data faster.  Maybe my thoughts here are not very clear... Maybe I'm just not smart enough for STA and SDC...

[Altera_Forum]

Just looking at the output side first, what's latching the data being sent, i.e. what is the FPGA driving and how is that external device clocked? If you only look at the time from the software driven register to the output, and let's say that's 5ns, when is that going to be latched by the external device? What delay would make that fail, i.e. would 6ns from the register to the output fail, or 10ns?  

One other way to think of the clock tree and the data delay is that they're really part of the same thing(which TimeQuest calls Data Arrival Path). For example, let's say we could move the delays around. For example, let's say the clock path was shortened by 10ns, but the data path out was increased by 10ns. Now, the data will change on the output at the exact same time, but if you're just measuring from the register out, then you will get a very different analysis, but by measuring the clock tree you will get the same result and this juggling of numbers won't affect the slack(as it shouldn't). (Note that the general problem is over-thinking these things.)