Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
8 years ago

Timequest relating an external clock input to a virtual clock

Hello, I am having an understanding issue, and I am hoping for help. I have checked out Joe Martin's TimingClosureFieldguide, and Altera's TimeQuest Timing Analyzer Cookbook, and Ryan Scoville's TimeQuest User Guide.

Here is my situation: I have an Arria 5 communicating with a bunch of different peripherals (DDR3, ADC, Ethernet, JESD204 etc) all using clocks sourced from PLL's. So there are several clock domains.

Now I want to add an FTDI FT600 USB peripheral, it supplies the clock, and the data. All read and write activity is clocked by the FT600 sourced clock. The clock is only present for a short time before the transaction to a short time after the transaction, so I cannot use a PLL to generate a clock from it.

The clock is 100 MHz, and the board delay is about 1.2ns. I know the setup and hold times for data driving from the FPGA to the FT600, and the output delay and hold times of the FT600 driving data to the FPGA.

The most general solution is to use a Virtual clock and then use an expression to calculate the input and output delay max and min values. This is explained in Example 12 of the Altera cookbook. However the bit I don't get is contained in these words out of the cookbook:

# create the input clock

create_clock -name clkA -period 10 [get_ports clkA]# create the associated virtual input clock

create_clock -name clkA_virt -period 10

They say it is associated, but clkA is never referred to ever again. Same in the Ryan Scoville's examples. Nowhere is the real clock ever linked to the virtual clock. Now I am guessing here that Quartus might assume all 10ns clocks are related to each other. It is true that clkA is driving some logic which is then related to the inputs and outputs. However the phase relationship between the virtual clock and the real clock could be anything.

I also have other 10ns clocks which have arbitrary phase to clkA (I use Fifos to transfer between the clock domains). So I have used clock_groups to separate the domains.

However I have no clue how TimeQuest associates the virtual clock with the real clock, and sets a phase relationship between them. Can anyone explain this?

Thanks,

Bart Schroder

4 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    8 years ago

    The simple answer is that any physical clock(like clockA in your case) is same phase as virtual clock by defaultand both start a zero phase. If you want to change its phase then apply -waveform to clockA

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    8 years ago

    Thanks for the quick answer. However, the real question was how does Quartus associate a particular virtual clock with a particular real clock when there are lots of real clocks? I assume this is done these ways:

    1. The virtual clock is referring to inputs and outputs connected to logic clocked by the real clock and

    2. The virtual clock and the real clock are in the same clock group and

    3. All the other clocks are in other clock groups with -asynchronous between the groups.

    and then you could use -waveform to change the phase between the real and virtual clocks if required.

    Is this correct?

    Thanks!
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    8 years ago

    --- Quote Start ---

    Thanks for the quick answer. However, the real question was how does Quartus associate a particular virtual clock with a particular real clock when there are lots of real clocks? I assume this is done these ways:

    1. The virtual clock is referring to inputs and outputs connected to logic clocked by the real clock

    --- Quote End ---

    No 1 is correct. It is not related to any physical clock. Just abstract for reference. TQ then knows the values you enter relevant to this reference, and knows what clock is used in logic, and knows if real clock is of any different phase relative to virtual reference.

    As such I see its use as optional since we can use physical clocks directly as references for example for their io statements.

    TQ encourages use of virtual clock. One case that you must use it if you want to apply your own clock uncertainty.

    your suggestions No2 & 3 don't make sense to me.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    8 years ago

    A better way to explain it would be like this. Take an input. A virtual clock is used to describe the clock driving the "upstream" device, essentially the source register. When you create your set_input_delay constraint, you have to point to this virtual clock. This ties the virtual clock as the source clock to whatever clock is driving the input register, the destination register, in the FPGA, whether it's a base clock (create_clock) or generated clock (create_generated_clock, derive_pll_clocks). Outputs are tied to virtual clocks with set_output_delay in a similar manner.