UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Observer andrewsi
Observer
14,583 Views
Registered: ‎02-05-2012

Need help controlling skew between an internally generated clock output and associated data outputs on Spartan6

Jump to solution

Hey folks, I'm working with a design on a Spartan 6 that I need a little help with.

The module in question is taking a 27Mhz input clock from an oscillator and using a dynamically programmed DCM to generate a derived output clock (pixel clock) of up to 148.5Mhz (i.e. HDMI pixel clock.)  This pixel clock is routed to an output pin through an ODDR2, which is Xilinx's recommendation for how to best route a BUFG clock to an output pin. The rate of the clock can be changed on the fly using other inputs to the design, but in the S6, when you have a dynamically programmed clock generator the tools are very careful to spew lots of warnings that the resulting clock will have no fixed phase relationship to anything on the input side, so in effect everything downstream relying on that clock is async from the rest of the design from a timing analysis perspective.

 

There is also additional logic in the FPGA that generates a 36-bit-wide parallel data bus and associated video sync signals, using this generated pixel clock, which are output on other pins to an HDMI transmitter chip nearby.

 

The question here is how to appropriately set up constraints in the UCF file so that there is a predictable setup/hold time of the data and sync signals with respect to the rising edge of the generated pixel clock.  Ordinarily, i would think that you would use OFFSET OUT with BEFORE/AFTER/VALID modifiers, but the OFFSET documentation says this only works when the clock comes in from an input pad and can't be used for onboard generated clocks.  I have done a little experimentation with picking some internal nodes of the generated clock for a FROM constraint, and the output pins as the TO, but frankly, I'm not sure I'm doing it right. 

 

The unconstrained design definitely winds up corrupting the output data from some of the pins, as significant skew can be seen on an O-scope between some (but not all) of the data lines and the clock, so I know constraints are needed, I'm just a little too non-expert to understand exactly how to accomplish that in the UCF file.  And before anyone asks, yes, the traces from the FPGA to the transmitter chip are carefully length-matched.

 

Thanks to anyone who might be able to provide some help-

Andy

0 Kudos
1 Solution

Accepted Solutions
Instructor
Instructor
22,394 Views
Registered: ‎08-14-2007

Re: Need help controlling skew between an internally generated clock output and associated data outputs on Spartan6

Jump to solution

What's feeding the DCM?  The phase doesn't really matter.  If you can trace back to an input pin, the tools will report the clock to output delay iven if the phase reported makes no sense.  You can also set the timing report to show unconstrained paths.  Then you sould have an entry for unconstrained out after ...

 

In any case, constraints are not the proper way to control output skew.  You must push all output registers into the IOB to get low skew.  Once you've done that, then the only thing you can control is the relative clock phase going to the data outputs vs the forwarded clock output.  For single-data-rate interfaces, this can be as simple as inverting the clock at the ODDR that forwards it off-chip to center the rising edge in the data window.  For DDR interfaces you'd generally use a DCM or PLL to create a 90 degree phase shifted clock to the ODDR for the clock, and use the normal non-phase-shifted clock for the ODDR's of the data pins.

-- Gabor
0 Kudos
10 Replies
Historian
Historian
14,579 Views
Registered: ‎02-25-2008

Re: Need help controlling skew between an internally generated clock output and associated data outputs on Spartan6

Jump to solution

There is also additional logic in the FPGA that generates a 36-bit-wide parallel data bus and associated video sync signals, using this generated pixel clock, which are output on other pins to an HDMI transmitter chip nearby.


Set an OFFSET OUT constraint. It'll report the clock-to-out for all of the signals, the 36-bit bus and the ODDR-forwarded clock. You can infer the skew by eyeballing the clock-to-out times. My experience is that the skew is quite tight.

----------------------------Yes, I do this for a living.
0 Kudos
Observer andrewsi
Observer
14,573 Views
Registered: ‎02-05-2012

Re: Need help controlling skew between an internally generated clock output and associated data outputs on Spartan6

Jump to solution
Bassman, what about the following statement in the OFFSET constraints white paper?

"The OFFSET constraint does not optimize paths clocked by an internally generated clock. You can use FROM:TO or multi-cycle constraints for these paths, taking into account the clock delay."

This is an internally generated clock...
0 Kudos
Observer andrewsi
Observer
14,570 Views
Registered: ‎02-05-2012

Re: Need help controlling skew between an internally generated clock output and associated data outputs on Spartan6

Jump to solution

And furthermore, just to try out your suggestion, I'm having a hard time getting the constraint to not be ignored.

 

The design is something like this:

Dynamically programmed DCM CLKFX -> pixel_clk -> data generation------------------> TXDATA, TX sync signals

                                                                                   -> ODDR2----------------------------> TXCLK

                                              CLKFX180-> pixel_clk_n -> ODDR2 (inverted input)

 

In the UCF, I define:

NET "hdmi_it/pixel_clk" TNM_NET = PixelClkGen;
NET "hdmi_it/pixel_clk_n" TNM_NET = PixelClkGen2;

NET <all the relevant signals> TNM_NET = VidOutBus;

(The output of the ODDR2 comes to a pad called TXCLK).

 

TIMESPEC TS15 = PERIOD PixelClkGen 165000Khz HIGH 50%;
TIMESPEC TS16 = PERIOD PixelClkGen2 165000Khz HIGH 50%;

TIMEGRP VidOutBus OFFSET = OUT 2.5ns BEFORE TXCLK RISING;

 

Maybe I'm doing this all wrong, but defined this way, MAP tells me that "The clock TXCLK associated with TIMEGRP "VidOutBus" OFFSET = OUT 2.5 ns BEFORE COMP "TXCLK" "RISING" does not clock any registered output components."  Which may be true, since TXCLK comes from the ODDR2 and not from pixel_clk directly.  But If I change the offset constraint to try to use PixelClkGen instead of TXCLK, then Translate tells me NET PixelClkGen not found or not connected to a pad, and the same if I specify hdmi_it/pixel_clk directly.  So I'm sure I'm making total noob mistakes here, but I'm at a bit of a loss as to the right way to do this.

 

0 Kudos
Instructor
Instructor
22,395 Views
Registered: ‎08-14-2007

Re: Need help controlling skew between an internally generated clock output and associated data outputs on Spartan6

Jump to solution

What's feeding the DCM?  The phase doesn't really matter.  If you can trace back to an input pin, the tools will report the clock to output delay iven if the phase reported makes no sense.  You can also set the timing report to show unconstrained paths.  Then you sould have an entry for unconstrained out after ...

 

In any case, constraints are not the proper way to control output skew.  You must push all output registers into the IOB to get low skew.  Once you've done that, then the only thing you can control is the relative clock phase going to the data outputs vs the forwarded clock output.  For single-data-rate interfaces, this can be as simple as inverting the clock at the ODDR that forwards it off-chip to center the rising edge in the data window.  For DDR interfaces you'd generally use a DCM or PLL to create a 90 degree phase shifted clock to the ODDR for the clock, and use the normal non-phase-shifted clock for the ODDR's of the data pins.

-- Gabor
0 Kudos
Observer andrewsi
Observer
14,566 Views
Registered: ‎02-05-2012

Re: Need help controlling skew between an internally generated clock output and associated data outputs on Spartan6

Jump to solution

The DCM is being fed by a PLL locked to an external oscillator, so yes, it does ultimately trace back to an input clock.  I'll also look into ensuring that the final registers are being forced into the IOB.  Thanks for the suggestion.

0 Kudos
Observer andrewsi
Observer
14,557 Views
Registered: ‎02-05-2012

Re: Need help controlling skew between an internally generated clock output and associated data outputs on Spartan6

Jump to solution

Actually, I take that back.  It's being fed by another DCM altogether.

 

The chain is:

External 40Mhz Clock ->(FPGA clock pin)->DCM (creates 27Mhz from 40Mhz)->DCM(Creates 148.5Mhz from 27Mhz)-> (logic in this clock domain, and ODDR2 for external forwarding).

 

Anyway, I've been fighting with the whole constraint system all afternoon and I'm a little beaten down. Your suggestions make sense, but I think I need more in-depth help, I'm a little too inexperienced to really be confident in dealing with setting up the right constraints to ensure the behavior of this particular parallel output bus (single clocked), as this is the only part of the design that doesn't appear to be functioning correctly.  In particular you guys are talking about using offset constraints from the input clock (40Mhz) but I've had to create other constraints to keep the timing analysis from thinking that the 148.5Mhz clock domain needs to be synchronous with the 40Mhz one, they're being treated as asynchronous in the design, so how does the timing analyzer get anything useful from the 40Mhz clock in terms of keeping the final clock domain within the desired clock-to-out anyway?

 

I have implemented your suggestion of assigning all signals on that bus to IOBs, however.

0 Kudos
Instructor
Instructor
14,553 Views
Registered: ‎08-14-2007

Re: Need help controlling skew between an internally generated clock output and associated data outputs on Spartan6

Jump to solution

You can ignore timing constraints on cross-clock-domain paths, but that won't prevent the analysis of clock to output timing.  The important thing here is not to constrain the output, but to report the results in the data sheet report at the end of the static timing report.  That way you can verify the skew by comparing the clock to out numbers on the interface.  The actual values are not important as much as the consistency between outputs, which should be quite good if all output registers are pushed into the IOB's.  If you get any outliers, then you need to check why they are different and fix it in the design.

-- Gabor
0 Kudos
Historian
Historian
14,552 Views
Registered: ‎01-23-2009

Re: Need help controlling skew between an internally generated clock output and associated data outputs on Spartan6

Jump to solution

Gabor's suggestion is the one you need to pay attention to.

 

There is no way to use constraints to control the skew of the forwarded data with respect to the forwarded clock. This has to be done by design. The way to do that is to use the IOB FFs.

 

The generated clock is on a BUFG. The BUFG distributes the clock to (potentially) all clockable elements in the design with little clock skew. This includes the FFs located in the IOB. So, using this generated clock, generate the forwarded clock in an ODDR (like you are doing), and clock the outgoing data directly from a FF, and ensure that MAP packs these FFs into the IOB for you. To do this you can do any of the following

  - set the IOB attribute to TRUE in your RTL (using VHDL or verilog attributes)

  - set the IOB attribute in the UCF file

  - ensure that the MAP option to force all outputs is turned on

Look at the IOB attribute in the constraint user's guide (UG625)

 

Now, by design, the skew between the forwarded clock and data is very small - if they are in physically adjacent pins, then the skew will be around 100ps (give or take).

 

If you want to see what the skew is, you can use an OFFSET OUT constraint with the REFERENCE_PIN options. As you mentioned, there is no (meaningful) input clock pin to use for the OFFSET OUT constraint, but that doesn't matter (since you don't even need to specify a value)

 

NET hdmi_data_signals[*] TNM = tnm_hdmi_data_signals;

TIMEGRP tnm_hdmi_data_signals OFFSET = OUT AFTER <name_of_input_clock_pin> REFERENCE_PIN hdmi_clock_signal;

 

Avrum

Observer andrewsi
Observer
14,546 Views
Registered: ‎02-05-2012

Re: Need help controlling skew between an internally generated clock output and associated data outputs on Spartan6

Jump to solution
Ok, I think the key here is really the IOB use. It's clear that not doing that must be what was causing the corruption of the data because there were pins whose waveforms were significantly skewed relative to the clock out pin and I'm betting forcing the output registers into the IOBs will cure that. I'll focus on that and try to get it to rebuild successfully, for some reason that one change causes some of the existing constraints to fail but I think I'll need to dig in a little to see what it's having trouble with. I really do appreciate the help guys!
0 Kudos
Observer andrewsi
Observer
7,976 Views
Registered: ‎02-05-2012

Re: Need help controlling skew between an internally generated clock output and associated data outputs on Spartan6

Jump to solution

Just wanted to thank everyone who responded - Packing the parallel bus into the IOBs solved the problem quite nicely.  The help was much appreciated.

0 Kudos