Welcome to Altera’s constraining source synchronous interfaces online training. My name is Karl. This presentation is about constraining and analyzing source synchronous interfaces with the TimeQuest timing analyzer.

These are the main objectives for this presentation. At the end of the presentation, you will be able to describe the basic functionality of a source synchronous interface and describe its main benefit over common clock system interfaces. You will also be able to write SDC constraints to constrain single data rate source synchronous input and outputs. And finally You will be able to use the TimeQuest timing analyzer to report and analyze timing on source synchronous outputs and inputs.

This is an advanced training so there is some basic information you should know, and some skills you should have, to get the most out of this presentation. You should understand static timing analysis concepts like slack and input and output delays. You should know how to create SDC constraints for clocks and IOs. This includes base and generated clocks and input and output delays. You should also have experience using the TimeQuest timing analyzer and should know how to use it to analyze timing on designs.
If you need to review any of the prerequisite material, you should look at the existing TimeQuest timing analyzer trainings or some documentation on timing analysis such as the TimeQuest timing analysis chapter of the Quartus II Handbook or the Timequest user guide located on the alter wiki site.

This is the agenda for the presentation. I’ll start by explaining how source synchronous interfaces work, where they are used, and what their benefits are. Next, we’ll look at the specific techniques and calculations required to constrain source synchronous inputs and outputs. Finally, we’ll see how to analyze source synchronous interface timing with the TimeQuest timing analyzer. Let start with source synchronous interfaces overview.

A source synchronous interface transports clock signal with a bus of data signals over matched paths so that process voltage and temperature variance affects both clock and data in similar manners. The key characteristic of source synchronous interfaces is that the strobe or clock signal is sent from the driver, not a separate clock source common to the two devices. The benefit is much faster bus frequency. The transfer can be between devices on one board, or across a backplane. Data can sent with either center aligned or edge aligned with respect to the clock. Depending on the situation a phase shift in either the transmit or receive devices maybe required. Data can also be sent in single data rate or double data rate modes. With double data rate, data is sent on both the rising and falling edges of the clocks. In today’s presentation we’ll focus on the single data rate interfaces, there’s a separate online presentation focused on the double data rate interfaces. Examples of modern interconnects using source synchronous interfaces include memory interface such as DDR or QDR, hyper transport, pci express, or any custom interfaces you may design.

As we said earlier source synchronous interfaces can be sent with data either center aligned or edge aligned with respect to the clock. The alignment refers to the alignment of the clock and data at the interface between the devices.

Here are the example wave forms.

The top diagram shows a center aligned clock. The transmitter launches data on the positive edge. A separate PLL output is likely used to shift the clock going to the receive device to achieve the center alignment. The receive device then uses the clock as it is sent to latch the data which should be in the middle of the data valid window.

The bottom diagram shows an edge aligned clock, here the transmitter still launches data on the positive edge but the transmitter sends the clock either is or adjusted so it’s edge aligned with respect to the data, in this case the receive must adjust the clock by 180 degrees to properly clock in the data with the associated clock.

In addition to data that can be sent either center aligned or edge aligned to the clock. Data transfer can also happen on a same edge or opposite edge bases.

With same edge transfers data being launched on rising edge of the clock gets latched also on the rising edge of the clock and if data is sent on the falling edge of the clock, the receiving devices is expected to also latch in the data on the falling edge of the clock.

With opposite edge transfers data being launched on the rising edge of the clock gets latched by the falling edge of the clock and data sent on the falling edge of the clock gets latched by the launch edge of the clock, though the last case is extremely rare.

Same edge and opposite edge transfers can happen with edge aligned or center aligned interfaces as shown in the diagram. Notice that the clock is adjusted for the various edge to edge transfers so that the actual setup and hold relationship do not change with respect to either same edge or opposite edge transfers.

Now that we have an understanding of the source synchronous interfaces, let’s take a look at how to constrain single data rate source synchronous interfaces, we’ll focus on the input interfaces first.

To constraing source synchronous single data rate input interfaces to the FPGA. Follow the methodology listed here.

We first need to create a virtual clock that we’ll reference the input delays to later. This is used to determine the launch edge of the transfer.
Then we’ll create a clock at the input clock IO of the FPGA, this is used to determine the latch edge of the interface.
Lastly we specify the input delay relative to the virtual clock we declared in the first step. The input delay calculations depend on specs for the upstream device available, we will see how we can derive and set the input delays.

The first step of constraining an input interface is to declare a virtual clock. The virtual clock is used to calculate the launch edge of the source device. Virtual clock differ from regular clocks in that they do not have physical locations associated with them, so when using the create clock command to create a virtual clock there’s no target. The only required parameters are the period of the clock and name of the clock.

SS Input Data will arrive to the FPGA in reference in to this virtual clock. So when we declare input delays the associated launch clock will be the virtual clock.


It is actually not necessary to use a virtual clock to constrain the input delays. You can create
input delay constraints relative to the input clock instead of the virtual clock, but
using a virtual clocks makes the constraining of the interface easier and more accurate.
Using virtual clocks makes derivation of clock uncertain more accurate since off chip to on chip clock domain transfers can now be calculated. Also since the virtual clock is in its own clock domain, it’ll be easier to constrain certain interfaces as well see in the upcoming slide and also it makes it easier to analyze the input paths in timequest since reports can be generated based on the launch virtual clock.

Next we’ll need to define an input clock for the source synchronous interface. The methodology will depend on the type of input clock mechanism we choose Direct Clocking or PLL clocking.

With direct clocking, clock is used as is to capture the data, because of this only center aligned low speed inputs can be implemented with direct clocking as fine tuning of clock to data relationship is not allowed here.

With PLL clocking you’ll be able to implement either center aligned or edge aligned interface.
Higher speed interfaces require PLL resources to control the clock data relationship. The PLL provides compensation over the process, voltage and temp. When using the PLL Configure it in the SS comp. mode. In source-synchronous compensation mode, the clock and data relationship at the FPGA device inputs will be preserved to the best of PLLs ability at the Input Register through precise adjustment of clock to data relationship.

Here’s an example of how we can declare input clocks for center aligned data.

First because of the center alignment, we have the option of using direct clocking only if this is a low speed interface since clock and data in delays will not be exactly the same and the center alignment cannot be precisely preserved at the input register..

First we create a virtual clock, then because the transmitting device has shifted the clock, we specify a clock constraint for the clk_in port with a phase shift of 180 degrees of the clock period. Since in our case the period is 8, the waveform parameter in the second create clock command which specifies the rising edge at 4ns and falling at 8ns denotes the 180 phase shift in relation to the virtual clock and data.

<click>
If you’ve chose to use a PLL in source synchronous mode to better align the clock with data, then in addition to the two create clock commands for the virtual clock and input clock, you’ll also need an additional create generated clock command to generate the clock at the output of the PLL. There will be no phase, multiply, or divide factor for this generated clock command.

With the PLL you could’ve also just used the derive pll clocks command.

In this case data is transmitted edge aligned with the clock. The receiver has to implement a PLL to phase the clock 180 degrees to capture the data within its data valid window.

Here, We again create a virtual clock that describes the launch clock. We create a clock constraint for the clock input pin that drives the PLL and then create a generated clock constraint for the PLL output which is our latch clock.

Notice the clock in clock we created has the same phase as the virtual clock but the 180 degree phase shift is now specified for the generated clock command for the PLL output tap. Of course when parameterizing the pll using megafunctions, you have to make sure the 180 degree is added there. Again derive pll clocks could’ve been used here as well.

With the clocks defined the last step in constraining source synchronous is to assign appropriate external delays to the inputs based on upstream device and board parameters

These constraints are derived based on the type of information available to the FPGA designer we’ll look at each of these individually.

The input external device may provide tco max and min numbers and those maybe listed as either relative to its output clock or its input clock.
Or you may have a spec that provides desired setup and hold times of the FPGA.
And finally common to source synchronous transfers, specifications may provide the maximum skew between clock and data at the FPGA input.

When one of these three sets of information, we can derive the proper value to add to our SDC constraint.

Here is what to do if the data sheet for the external device providing the SS inputs defines tco max and min in relation to the output clock.

Because when we define delays using the set input delay command the delay is in reference to the clock, then the Tco value relative to the output clock is the delay. Here the calculation is made easy

Max delay is simply the maximum tco plus max data trace delay minus the min clock trace delay, to get the aboslute biggest most pessimistic value.

Min delay is minimum tco value plus min data trace delay + minus the maximum clock trace delay, again to get the smallest most pessimistic number.

Remember input delay max is used for setup calculations where the biggest delay contribution to the delay path makes it most likely to fail and input delay min is used for setup calculations where smaller value is most likely to fail.

In my example, I’ve stored the value of tco max and min, data trace max and min and clk trace max and min in tcl variables.
Then I use the tcl set command to create new variables in max delay and in min delay. The expr command in the first two lines is used to do arithmetic calculations in Tcl.
When in max delay and inmin delay calculated I can use the set input delay command referencing the virtual clock with the calculated values and the target being the data_in IO as shown in the 3rd and 4th comamnds in the example SDC code.

If instead your external device providing the source sync inputs lists tco max and min from the input clock. You will essentially have to calculate the data tco max and min in reference to the output clock.

In this case device spec lists tco data max and min and tco clk max and min, you will have to do a subtraction of the tco clk from the tco data to calculate the data tco in relation to the output clock.

As with the previous example we’ll need the most pessimistic numbers to calculate the input delays so for max delay we use tco data max subtract by tco clk min adding to it data trace max and subracting clk trace min.
For input delay min, we use the opposite, tco data min subtracting tco clk max adding data trace min and subtracting clk trace max.

The syntax of the input delay command is exactly the same as the previous example.

If the spec provides a specific set and hold time for the FPGA input that will ensure the interface will pass timing, use the equations here to derive the maximum and minum input delays, we will explain the equations in the next couple of slides.

The max delay is the time between the latch edge and the launch edge minus the setup requirement
The min delay is the hold time subtract by the difference between hold luanch and latch edges.

Once we derive the delays we would use the set input delay max and min commands to input the value into the SDC file as we’ve done in the previous examples.

This slide explains the Center Aligned case and how to derive min and max delays from hold and setup requirements.

The input delay is defined as the time it takes from the launch edge to get to the FPGA IO.
Setup requirement is defined as the latest a signal must get to the FPGA IO before the latch edge. Looking at the top diagram the maximum amount of external delay is the distance between the two blue lines which is setup latch minus setup launch which in the center aligned case is period over 2 subtract by the setup requirement.

The input delay min is defined as the fastest a signal can get from the launch edge to the FPGA IO while the hold time requirement is the minimum amount of time the data must remain stable after the latch clock or the minimum delay from the latch clock for the next data.. So the two terms, hold time and min delay has the same meaning but different reference points. With the hold time know we need to convert it in relationship to the launch edge. Since the difference between the edges is period over 2 the input min delay is hold minus period / 2.

With edge aligned inter faces the relationship between setup and hold and and max and min delay is the same as the center aligned case except now the launch and latch relationships have changed. For setup, launch and latch are using the same clock edge as the destination device is used to shift the clock, so the delay needs to be shifted by another period over 2 from the center aligned case so the input max delay is just negative setup since the data is actually required to get to the FPGA IO before the clock, again remember the clock gets shifted by 180 degrees later to make it possible to capture that particular data.

In the edge aligned hold case the equation becomes hold subtracted by a period since launch edge is actually a full cycle a head of the latch edge. Again this equation is the same as the center aligned case but shifted by an additional period / 2.

Let’s look at an example. In this case I have a center aligned interface with setup and hold requirements specified. Here, the clock has an 8 ns period and the setup requirement is 2.3 ns while hold requirement is 1.2ns

Using the equations provided I calculate my max delay which is period /2 minus Tsu which is 1.7 and my min delay is hold time minus period /2 which is -2.8.

With the variables in max delay and in min delay calculated you would just use the familiar set input delay command to communicate to timequest my maximum and minimum delays in relation to the launch virtual clock edge.

The final possibility when constraining source synchronous input interfaces is if a desired skew at the input of the FPGA is provided.

The skew value says the data will arrives within the window formed by the skew value around the clock edge.
In this case the maximum delay is simply the skew value as that’s the latest a data can get to the FPGA after the clock edge.
While the minimum delay in this case would simply be negative skew as that’s the fast the data can arrive and since it’s before the clock edge the value is negative.

With skew specification regardless of data alignment, we would use those values in reference to the virtual clock and set the maximum and minimum skew values for the data inputs.

Here’s an summary of all the equations used to calculate maximum and minimum delay for single data rate source synchronous input interfaces.

This table can be used as a cheat sheet as you constrain your interfaces. Here all of the methods of calculating delay values are listed.

Now that we’ve explained the input interface constraints, lets now talk about output interface constraints.

For SSO interfaces on the FPGAs, the FPGA is sending out both the data and clock to a downstream device.

In order to properly constrain the interface, follow the methodology here.
First you will create a generated clock at the output clock IO of the FPGA.
Then you will specify output max and min delays for the data out signal in reference to the generated output clock.

Finally, certain exceptions are needed to makes sure the valid timing calculations are done and also to cut paths that don’t need to be analyzed.

A generate clock is needed for source synchronous output interfaces because there’s a definite relationship between the output clock signal and the clock used to generate the dataout and this relationship must be taking into account in the clock path of the IO interface.

The way to tell the timing analyzer to analyze this as part of the clock path is to create a generated clock for the output clock, the source of the generated clock would be the output of the PLL.

Then when creating output delay constraints for dataout, you would use the generated output clock as reference, in order for timequest to determine where the latch edge is.

There are several ways you can create a output clock on the FPGA.

First, you may choose to use a common data and output clock, this save FPGA device resources but it would only work for edge-aligned low-speed interface where precise clock data alignment is not important. And in this case, the receiving device is required to shift the clock.

A output clock can also be generated by a PLL, because the PLL output phase is adjustable this clock can be used in either edge aligned or center aligned interfaces at the same time it can also be used to adjust the clock phase for precise output clock data alignment.

The third option is to use a DDIO register, DDIO or double data rate IO register are located in most mid to high end FPGAS, they are mean for use in double data rate interfaces but can also be used to align clock and data for source synchronous single data rate interfaces. Here because the same type of dedicate circuitry is used to generate both data and clock you can easily get precise alignment. You can also use DDIO register in conjunction with a PLL.

This slide represent the FPGA sending out common data and output clock.

Here the clock that drives the data register is also routed out to clk out IO. Because you’re limited to using this in low speed applications, this type of interface is probably not too common.
But this interface is simple and does not require PLL resources.

To constrain this interface all you need to do is create the clock that drives the data out register as with the first line of code here.

And then use a generated clock command to create a clock at the output IO of the FPGA with the source of the generated clock being the clock that drives the data register.

Here we use a PLL to generate the output clock. This is much more common in source synchronous output interfaces because it gives you phase and off set control so you can precisely achieve any data alignment you need.

In this case the first thing you do is create the clock for the clock in IO this is not shown in this slide.

Then we use a generated clock to create a clock for the first tap of the PLL which is used for the data register. This is shown in the first line of code. Note the source is the input of the PLL.

The second generated clock command here creates the clock for the clock output. Here if you’re using edge aligned interface the phase offset would be 0 while if you choose to use an edge aligned interface the phase alignment would be 180.

Note also that the first two generated clock commands here could have been replaced with the derive pll clocks command.

Lastly, we use a third generated clock command to bring the clock to the output IO, here the generated clock source is the second output tap of the PLL and the destination is the clock out port.

The third method of generating output clocks is with the DDIO registers. DDIO registers again are meant for double data rate applications but we can use it to generate clock and data for SDR as well. Because these blocks should provide equal skew for the data and clock outputs, we can get very good alignment easily.

In this example I’m using the PLL to generate the clocks for both the data out register and the clock out DDIO registers. This give me separate control. So my first two generated commands creates the two clocks at the pll output taps. Notice for the second statement I can use a phase shift to generate center aligned clock.

The final create generate clock command declares the clock at the clock out port using the pll output tap as a source.

Note in this case I could have also been able to preserve one of the PLL outputs as you can invert the clock out easily by swapping the VCC and GND connections instead of using the 180 phase shift.

Much like the input interfaces, once the clocks are declare we are ready to specify the output delay in reference to the clock.

For output interfaces, the data delay may be derived in one of two ways depending on the information available for the receiving device.

First method can be used if the external downstream device provides its setup and hold requirements and board parameters are known this is also known as the system centric view.

The second method is used if a maximum allowed data skew which specify the relationship between the clock and the data is given for the FPGA interface.

With system-centric delays, you’re given setup and hold numbers for the receiving device and possibly numbers for clock and data trace delays, here we would calculate delays using the same exact equations as the common clock synchronous IOs.

In this case, the setup requirement of the external delay contributes to the delay because setup is defined as the minimum time data must be stable before the clock gets to the external device so the setup time is the amount of external delay.
So for maximum delay, we use the Setup requirement added to the data trace max subtracting the clock trace min.

For hold time, the hold time subtracts from the external delay because hold time is defined as the amount of time data must remain stable after the clock, so the delay must come from the FPGA which means the external delay is a negative value.

So the minimum delay would be negative Th plus data trace min minus clock trace max.

Again this is the same equation as common IO interfaces.

Once we derive the value, we input the delay in to the set output delay max and min statements. Notice that it’s very important to set the output delays in reference to the clock out at the output clock IO.

If you’re given the desired skew at the FPGA output, you use these equations to convert to external delay to be used in the SDC constraint.

For max delay, the setup relation ship is simply the latch edge minus the launch edge if the total data is less than that then the timing is met. The skew requirement means the amount of delay inside the FPGA must not exceed the skew value. So the maximum delay external to the FPGA must be setup latch minus setup launch minus skew. Depending on center aligned or edge aligned data, we would use different values for latch minus launch.

For min delay, the skew represent the minimum amount of time data must remain stable past the hold time. So the minimum output delay without violating skew at hold is simply skew added by the hold relationship with hold relationship being negative hold launch hold latch

We’ll see diagrams of these equasions on the next few slides.

Here are the skew equations derived for the output delay in a center aligned case.

On the top, for setup skew is the amount of delayed allowed in the FPGA so the external delay is calculated as latch minus launch minus skew which is period /2 minus skew.

For the bottom diagram, here’s our hold diagram, skew is the amount of time after the hold relationship data must remain stable. So in the diagram the minimum exter delay is the distance from the skew edge to the latch edge. Which is skew subtracted by period over 2.

Here are the same diagram but for the edge aligned case, the equations are the same as center aligned case the difference is the launch to latch relationship is shifted by another period /2.

So in this case the maximum external delay from the FPGA IO pin to the latch edge becomes just negative skew

And the minimum output delay becomes skew minus period..

For both of these it’s expected that the latch clock edge will get shifted which is why the equation looks like the way it does.

Here’s an example applying the equations from the previous slide.

Using the equations from the previous slides for a center aligned outputs using the skew approach: Given our period is 8 and skew is .7 ns.

The Max delay is 3.3 ns, the max amount of data shift allowed outside of the FPGA to still meet skew setup timing.

The Min delay is -3.3 ns The min amount of time data could be shifted external to the FPGA before the next launch to meet the .7 ns input skew (hold) requirement.

Once we use the tcl variable to calculate the values, we use the set output delay max and min to enter the constraint in SDC and referencing it to the clk_out clock we created at the clock output IO.

Here is a summary of all the output delay values for source synchronous single data rate interfaces. As with the input summary table, feel free to use this as a reference for your future sdc needs.

With the data values specified for output paths, we’re not quite done.
Timequest assume all output IOs are used as data and will try to analyze it, if a min and max delay is not specified it will be flagged as an unconstrained path.

When we brought the clk signal out to IO for source synchronous purpose, it also be falsely analyze as data.

Since it’s a clock with no destination register, we’ll need to cut off the data analysis.

Remember the easiest way to do this is to use the set false path command. Here I simply need set false path to with the name of the clk out IO.
When we use set false path here, only the clk out as data is cut off, clk out as part of the clock path for the data out will not be effected.

When the launch clock and the latch clock has the same period and phase, the default setup relationship goes to the next clock edge.
However with edge aligned interfaces that’s not the setup relationship we want, instead we need the setup relationship to be the same clock cycle as the latch clock will eventually be shifted approximate 180 degrees.

So we need to set a multicycle path in those circumstances. As a review multicycle paths are used to modified setup or hold relationship to a specified edge. For setup the default setup relationship is 1. Therefore with edge-aligned outputs a multi-cycle setup of zero is required to move the timing analysis to the same edge. Multicycle hold is not needed because as a review hold relationships moves with the setup relationshipo.

In the constraints shown notice an offset variable was created. The tx offset variable is used to adjust the PLL so your output clock is exactly edge aligned to the data at the interface compensating for any clock and data path differences.

As long as the offset less than or = zero then the multi-cycle exception is required. If the off set is greater than 0 then multicycle is not needed because the default setup, which is the smallest relationship greater than 0 is the actual setup relationship we want.

As before the offset variable must match the actual offset of the PLL set in the megafunctions.

The final type of exception needed is if you choose to use the DDIO register to synchronize the data out and clkout signals.

The DDIO registers have two output register one launches on the rising clock edge one launches on the falling clock edge. Time quest understands the polarity of these registers and will try to analyze both rising and falling edge launches.

However because we have tied the data bus to both inputs, data launched by the falling edge of the register is exactly the same as the data launched by the rising edge of the clock so the falling edge of the clock will never trigger a data change and therefore we do not need to analyze the data launched by the falling edge of the clock.

To resolve this we use the set false path command but use the option fall from the tx data clk the clock that launches the data.

In the last portion of the presentation, we will look at how to analyze source synchrnous interface timing.

There are many reports you can run to verify your constraints are entered properly.

Diagnostic reports will tell you if things make sense. Are constraints ignored? What signals go across clock domains? This is particularly useful because we separated input clocks with the virtual clocks and the output generated clocks from the clocks driving the output data, we can easily see the IO cross crossing this way.

For a quick look at what paths go across the SS interfaces, look at the setup and hold summary reports for the input and output paths. If you want a detailed look at either the inputs or the outputs run the report timing commands.

Finally for the absolute best timing, you can run an analysis of all the outputs to analyze the margins of setup an holds at all corners and then adjust the phase of the output clock to optimize the margins to get equal setup and hold margins to give a wide data valid window.

Here’s an detailed report timing analysis of setup timing for a source synchronous center aligned single data rate input. Notice here the launch clock is show as the virtual clock representing the clock at the upstream device.

Notice that the input data delay enter is .7ns this shows in both the data arrival path report as well as the waveform.

Also important is to verify the setup relationship, you can see the setup relationship in the path summary but visually it’s easiest to see in the waveforms. Here you see that the launch edge is precisely half a clock cycle ahead of the latch meaning this is a correct center aligned input.

For this path after the quickest data required time and the slowest data arrival path are analyzed we have a setup slack of 1.394 ns meaning this particular SS interface passes timing.

In the diagram here, we analyze an output edge aligned single data rate interface.

Here you see that the latch clock is tx clock placed at the output IO. The delay I’ve derive and specified in the SDC file, .8ns in this case, shows up in the data required path. This is because outputs are always analyzed at the FPGA IO so any external delay just gets subtracted from the data required path. This is true for common clock synchronous Ios as well.

When analyzing edge aligned output interfaces make sure the launch and latch relationship match what you expect. In our case we see in the waveform launch and latch is the same clock cycle which coincides with our edge aligned behavior.

This interface passes timing by .014 ns.

For output interface driven by a PLL, will be wise to balance setup and hold margins to get precise alignement.
If you want to do this, you should analyze output timing for setup and hold at all operating conditions and then take an average of the setup and hold margin then finally based on the difference of the margins, adjust the PLL so the average setup and hold margins are the same. This will mean data valid window is centered.
To make this easy you should write a timing analysis script to accomplish this in one step.

Here are some additional references.

If you would like to learn more about source synchronous interfaces and other timing analysis techniques from an in-person instructor please sign up for the advanced timing analysis instructor-led training.
If you would like to learn more about tcl syntax, see our free introduction to tcl online training class.

In this course we focused on single data rate source synchronous interfaces, if you’d like to learn more about double data rate source synchronous interfaces, please see our follow on training.

There is a great document on constraining source synchronous interfaces on the altera wiki site and finally altera provides app note 433 which documents how to constrain and analyze source synchronous interfaces.

If you would like to receive additional training on other topic involving FPGA design. Please see altera.com/training for a complete list of our offerings. Altera offers instructor led trainings, virtual class room trainings with a live instructor over the internet, and over 150 free online training.

One more thing: when you registered for this on-line training, you should have received a link to a short survey where you can provide feedback on the course. We’d greatly appreciate it if you’d fill out that survey now. We’re constantly updating and improving our training materials, and your feedback helps us create the materials that you want!

Thanks for attending Altera’s source synchronous interfaces online training. My name is Karl and best of luck on all of your designs.