When we do timing constrain in input or output, usually we need create a virtual clock. My question is, how can I know the phase relation between virtual clock and clock inside the system, in order to define virtual clock? Another question is similar, if in my design, one FPGA input is drive by another FPGA output. But the input and output are drive by two different clock source with same parameters (same model oscillations). How can I know these two clock sources phase relation in order to define these two virtual clocks in timing constrain? Thanks very much.

What do you mean by phase? If there is a clock going into the FPGA, and you constrain that clock going into it, then the delays inside the FPGA(clock insertion delays, clock latency, etc.) will be covered by timing analysis. You don't need to know this except for closing timing. For example, if your virtual clock driving an input has a 10ns period with a rise at 0, and the clock going into the FPGA is described the say, let's say there's a 3ns clock delay to the input register in the FPGA. that will be covered in the timing analysis as clock delay, will affect the clock skew, and though your setup relationship is 10ns, it will make it 3ns easier to meet setup timing and 3ns harder on hold timing. The main time phase inside the FPGA should be known is with a PLL. For example, if that clock drives a PLL which does a 2ns phase-shift(but still keeps a 2ns clock), then your setup relationship becomes 2ns and your hold relationship becomes -8ns. There are still delays inside the FPGA that are accounted for in timing analysis, but they don't affect the setup or hold relationship. I believe this answers your second question too. Don't just look at your .sdc. Put something in that you think is right, launch TimeQuest, and run: report_timing -setup -npaths 50 -detail full_path -from_clock virt_clk -panel_name "Virtual Clock||Setup" report_timing -hold -npaths 50 -detail full_path -from_clock virt_clk -panel_name "Virtual Clock||Hold" (If you're looking at outputs, change the -from_clock to a -to_clock" Then go in and look at the results, specifically the Waveform(which is a coarse view) and the Data Path tab(which is really where everything is at). Study how the delays are used and affect your slack. If you want, make a change to your .sdc, save it, Reset Design in TimeQuest and then re-do the reports. See how they change. I find it very useful to study the timing analysis when trying to understand how .sdc constraints affect them.

Thanks, Rysc. I think my statement is unclear which confused you. So you mentioned this: "For example, if your virtual clock driving an input has a 10ns period with a rise at 0". Actually, my question is here, for the clocks which drive the input and output respectively, how can I know when they rise? E.g., assume both of them has a 10ns period, but how can I know when they rise between 0 and 10&#65311; Do we always assume they rise at 0 if we don't do any specific design in oscillations? Thanks very much.

The virtual clock is "perfect" so it rises at 0, 10, etc. The clock going into the FPGA is also perfect at that point, but inside the FPGA will have different delays to everything it drives, which TQ accounts for. I guess yes, they rise at 0 without any PLL shifts(or something in your .sdc to say you've shifted it externally). THe .sdc describes the ideal clocks, and then the place-and-route does stuff to those clocks which are part of the timing analysis, but you don't have to know what those delays are up front or do anything to account for them. (Which would be very chicken-and-egg-y, since you would need to know the place-and-route to enter the .sdc constraints, but don't want to do place-and-route until the .sdc is correct...) If I'm not answering your question, please put more detail on what you want it to account for, or maybe a more detailed example?

--- Quote Start --- The virtual clock is "perfect" so it rises at 0, 10, etc. The clock going into the FPGA is also perfect at that point, but inside the FPGA will have different delays to everything it drives, which TQ accounts for. I guess yes, they rise at 0 without any PLL shifts(or something in your .sdc to say you've shifted it externally). THe .sdc describes the ideal clocks, and then the place-and-route does stuff to those clocks which are part of the timing analysis, but you don't have to know what those delays are up front or do anything to account for them. (Which would be very chicken-and-egg-y, since you would need to know the place-and-route to enter the .sdc constraints, but don't want to do place-and-route until the .sdc is correct...) If I'm not answering your question, please put more detail on what you want it to account for, or maybe a more detailed example? --- Quote End --- Thanks, Rsyc. I think you answered my question. But let me double check to confirm it. So when I create a clock outside the FPGA, it maybe: 1. system clock to drive inner logic, input or outputs 2. virtual clock to drive external components In both cases, the clock will rise at 0. Does my understanding right? Thanks.

Yes. Whenever you do: create_clock -period Xns TQ assumes the rising edge is at 0ns and the falling edge is at X/2ns. If you don't want that, use the -waveform option to do something different, like: create_clock -period 10.0 -waveform {1.0 6.} This is a clock with a rising edge at 1 and falling at 6, i.e. shifted 1ns in time.

The virtual clock about input or output in timing constrain

11 Replies

Altera_Forum
Honored Contributor
12 years ago
What do you mean by phase? If there is a clock going into the FPGA, and you constrain that clock going into it, then the delays inside the FPGA(clock insertion delays, clock latency, etc.) will be covered by timing analysis. You don't need to know this except for closing timing. For example, if your virtual clock driving an input has a 10ns period with a rise at 0, and the clock going into the FPGA is described the say, let's say there's a 3ns clock delay to the input register in the FPGA. that will be covered in the timing analysis as clock delay, will affect the clock skew, and though your setup relationship is 10ns, it will make it 3ns easier to meet setup timing and 3ns harder on hold timing.
The main time phase inside the FPGA should be known is with a PLL. For example, if that clock drives a PLL which does a 2ns phase-shift(but still keeps a 2ns clock), then your setup relationship becomes 2ns and your hold relationship becomes -8ns. There are still delays inside the FPGA that are accounted for in timing analysis, but they don't affect the setup or hold relationship.
I believe this answers your second question too.
Don't just look at your .sdc. Put something in that you think is right, launch TimeQuest, and run:
report_timing -setup -npaths 50 -detail full_path -from_clock virt_clk -panel_name "Virtual Clock||Setup"
report_timing -hold -npaths 50 -detail full_path -from_clock virt_clk -panel_name "Virtual Clock||Hold"
(If you're looking at outputs, change the -from_clock to a -to_clock" Then go in and look at the results, specifically the Waveform(which is a coarse view) and the Data Path tab(which is really where everything is at). Study how the delays are used and affect your slack. If you want, make a change to your .sdc, save it, Reset Design in TimeQuest and then re-do the reports. See how they change. I find it very useful to study the timing analysis when trying to understand how .sdc constraints affect them.
Altera_Forum
Honored Contributor
12 years ago
Thanks, Rysc.

I think my statement is unclear which confused you. So you mentioned this: "For example, if your virtual clock driving an input has a 10ns period with a rise at 0". Actually, my question is here, for the clocks which drive the input and output respectively, how can I know when they rise? E.g., assume both of them has a 10ns period, but how can I know when they rise between 0 and 10？ Do we always assume they rise at 0 if we don't do any specific design in oscillations?

Thanks very much.
Altera_Forum
Honored Contributor
12 years ago
The virtual clock is "perfect" so it rises at 0, 10, etc. The clock going into the FPGA is also perfect at that point, but inside the FPGA will have different delays to everything it drives, which TQ accounts for. I guess yes, they rise at 0 without any PLL shifts(or something in your .sdc to say you've shifted it externally). THe .sdc describes the ideal clocks, and then the place-and-route does stuff to those clocks which are part of the timing analysis, but you don't have to know what those delays are up front or do anything to account for them. (Which would be very chicken-and-egg-y, since you would need to know the place-and-route to enter the .sdc constraints, but don't want to do place-and-route until the .sdc is correct...)
If I'm not answering your question, please put more detail on what you want it to account for, or maybe a more detailed example?
Altera_Forum
Honored Contributor
12 years ago
--- Quote Start ---
The virtual clock is "perfect" so it rises at 0, 10, etc. The clock going into the FPGA is also perfect at that point, but inside the FPGA will have different delays to everything it drives, which TQ accounts for. I guess yes, they rise at 0 without any PLL shifts(or something in your .sdc to say you've shifted it externally). THe .sdc describes the ideal clocks, and then the place-and-route does stuff to those clocks which are part of the timing analysis, but you don't have to know what those delays are up front or do anything to account for them. (Which would be very chicken-and-egg-y, since you would need to know the place-and-route to enter the .sdc constraints, but don't want to do place-and-route until the .sdc is correct...)
If I'm not answering your question, please put more detail on what you want it to account for, or maybe a more detailed example?
--- Quote End ---

Thanks, Rsyc. I think you answered my question. But let me double check to confirm it. So when I create a clock outside the FPGA, it maybe:
1. system clock to drive inner logic, input or outputs
2. virtual clock to drive external components

In both cases, the clock will rise at 0. Does my understanding right?

Thanks.
Altera_Forum
Honored Contributor
12 years ago
Yes. Whenever you do:
create_clock -period Xns
TQ assumes the rising edge is at 0ns and the falling edge is at X/2ns. If you don't want that, use the -waveform option to do something different, like:
create_clock -period 10.0 -waveform {1.0 6.}
This is a clock with a rising edge at 1 and falling at 6, i.e. shifted 1ns in time.
Altera_Forum
Honored Contributor
12 years ago
--- Quote Start ---
If you don't want that, use the -waveform option to do something different, like:
create_clock -period 10.0 -waveform {1.0 6.} This is a clock with a rising edge at 1 and falling at 6, i.e. shifted 1ns in time.
--- Quote End ---

Will there be a case that I will create two clocks as:

create_clock clk1 -period 10.0 -waveform {1.0 6.0}
create_clock clk2 -period 10.0 -waveform {0 5.0}

??

Thanks.
Altera_Forum
Honored Contributor
12 years ago
Possibly. Let's say clk1 drives some external device and clk2 drives the FPGA, and external device drives the FPGA. Let's also say the board oscillator takes 1ns longer to drive the external device. Also say the external device has a Tco of 4.7 and min Tco of 2.4, and drives onto ports din[*] of the FPGA. You might do something like:

create_clock -period 10.0 -waveform {1.0 6.0} -name ext_clk
create_clock -period 10.0 -name fpga_sys_clk [get_ports fpga_sys_clk]
set_output_delay -clock ext_clk -max 4.7 [get_ports {din[*]}]
set_output_delay -clock ext_clk -min 2.4 [get_ports {din[*]}]
Altera_Forum
Honored Contributor
12 years ago
--- Quote Start ---
Let's also say the board oscillator takes 1ns longer to drive the external device.
--- Quote End ---

That is what I asked. My question is:
1. how can I know in which case, the board oscillator will takes a duration (e.g. 1ns) to drive the external device?
2. Can this duration be controlled by PCB designer?
3. Where can I check it if I have a PCB?

Thanks very much.
Altera_Forum
Honored Contributor
12 years ago
Any idea, Rysc? Thanks very much.
Altera_Forum
Honored Contributor
12 years ago
Are you making your own board? The PCB engineer should be able to give you that data. If you're buying the board from a 3rd party, you can ask them or possibly get the trace lengths. I've generally seen people do quick calculations off length(and PCB material) alone. I don't remember the number, but I think you could google it and find something. (PCB propogation delays per inch) I found the following:
http://www.eeweb.com/electronics-quiz/pcb-transmission-line-delay
which states:
The rule of thumb used to solve this problem is that the propagation delay of a stripline trace is ~ 180 ps per inch. The propagating delay of a microstrip trace is ~150 ps.

Forum Discussion

The virtual clock about input or output in timing constrain

11 Replies

Recent Discussions

Cyclone-V SCFIFO - adding ECC to M10K/MLAB/Auto memory

Will serialization factor of 6 in LVDS serdes IP be supported in the future on Agilex5?

System PLL of Agliex5 PCIE example design cannot be locked after configuration

JTAG Chain Broken on Agilex 7-I Dev Kit

Request for Cyclone V Pinout File Information