cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
havendream
Visitor
Visitor
12,642 Views
Registered: ‎06-25-2012

OFFSET CONSTRAINS for ADC interface

Hi

 

I used Virtex4 FPGA to handle the data from ADC (AD9222, 50M, 12Bits, 8 channel, Serial Output) . The data clock is 300MHz from the ADC. All the signals from the ADC are differential. I use a DCM to adjust the phase of the data clock and generate another clock with 180 degree phase shift. So I don't used the falling edge of the orignal data clock. 

 

Because the phase can be adjusted by DCM so I think the delay from the data pins to the register are not cared. But I need to guarantee that the delay for all the 8 channels should be the same (the traces on the PCB are of the same length).

What contraints should be used ?

 

I have tried different ways:

 

1) Without any constraints, the system works sometime but fails other time depended on different compile run.

 

2) I used OFFSET IN constraints

    NET "AD1_D?_?"  OFFSET = IN 0.8ns VALID 1.6ns  BEFORE "AD1_DCO_p" RISING;

   In this way, the results depend on the value. I tried 0.8ns/1.6ns , 0.4ns/0.8ns, 0.1ns/0.2ns. In all the cases ,the ISE failed to meet the constraints but the system work. For the value 0.1ns/0.2ns used, the DCM has the largest adjustable range. By the way, how to add OFFSET IN constrains for differential pins?

 

3) I used area constraints. I put all the related registers into an area near the input pins. In this way the system also work but I thought it's not a good method.

 

I was confused after different try. I think I don't care the delay from the pins to the registers. I just need to guarantee they are nearly the same for different channels. But I don't know how to obtain this. 

 

Any suggestions? Thanks a lot.

0 Kudos
13 Replies
chrisz
Xilinx Employee
Xilinx Employee
12,614 Views
Registered: ‎05-06-2008

Hello,

 

You need an OFFSET IN for all inputs to the design and OFFSET OUT for all outputs of the design.

 

The values for the OFFSET IN are associated with the external setup and hold time that the upstream device is creating or managing.  The max clock to out of the upstream device will correlate to the external setup requirement used in the OFFSET IN constraint.  The min clock to out of the upstream device will correlate to the external hold requirement used in the OFFSET IN constraint. 

 

If you are having timing closure type issues, then I would not use an area group to constrain these paths.

 

Thanks,
Chris

juergenatduerr
Adventurer
Adventurer
12,598 Views
Registered: ‎02-09-2012

> If you are having timing closure type issues

which issues do you mean?

 

I got stuck with a similar problem, but managed in the meanwhile to make the system working by something like this here:

 

....

INST "dat_n<12>" TNM = GRP_SENS_INS;
INST "dat_n<13>" TNM = GRP_SENS_INS;
INST "dat_n<14>" TNM = GRP_SENS_INS;

....

INST "dat_p<12>" TNM = GRP_SENS_INS;
INST "dat_p<13>" TNM = GRP_SENS_INS;
INST "dat_p<14>" TNM = GRP_SENS_INS;
TIMEGRP "GRP_SENS_INS" OFFSET = IN 11 ns VALID 18 ns BEFORE "Pclk_p" RISING;    --  40 ... 45 MHz clock frequency

 

I had to play around with the values, because the Clock phase is jittering and I could not use dedicated clock inputs. It is (also) LVDS interface with differential clock inputs. The data is mostly stable now.

 

For input multiplexing purposes and because of the routing issue (non cc-pins), I have to change the design strategy that way, that I will sample all input signals of all sources including thier clocks and post process them asynchronously -  meaning: process their synched copies. I currently somehow fail in finding the right constraints for this. so far I used:

 

INST "dat_p<12>" TNM = GRP_SENS_INS;
INST "dat_p<13>" TNM = GRP_SENS_INS;
INST "dat_p<14>" TNM = GRP_SENS_INS;

INST "Pclk_p" TNM = GRP_SENS_INS;        -- also clock inputs sampled along with data

INST "Pclk_n>" TNM = GRP_SENS_INS;

TIMEGRP "GRP_SENS_INS" OFFSET = IN 6 ns VALID 6.6 ns BEFORE "SYS_CLOCK" RISING;  -- 150 MHz

 

SYS_CLOCK is the OSC_Clock input in front of the DCM. It has 25 MHz, while the sampling clock is provided from the DCM and has 150MHz, which is more than 3times than the maximum clock in (45MHz).

 

I also tried to reference the sampling clock (clk150) but get an error: The constraint is not applied, because the CLK150 "is not found".

 

I the above declarion correct for this case?

 

Or is it better not to constrain at all?

 

 

 

 

 

 

0 Kudos
ditiris
Participant
Participant
12,588 Views
Registered: ‎11-27-2007

I the above declarion correct for this case?

I think you should be using NET instead of INST to group your dat_* pins, otherwise the constraints look correct to me. SYS_CLOCK is the correct clock to use, the tools will trace the path through the DCM. 

 

Or is it better not to constrain at all?

If you prefer not to know whether your design works correctly.

 

What does the datasheet report tell you?

juergenatduerr
Adventurer
Adventurer
12,583 Views
Registered: ‎02-09-2012

The "INS" came from the constraints editor, which automatically produved that after I created a time group.

 

Well the report often says tming not met, but this seems to be a mixture of contraint problems and phanto errors, since today the same design compiled differently after a reboot, as I just found out. Also the strategy "fast compile time" gave me less timing errors, than the "timing performance with iob packing" which ist totally weired to me.

 

Obviously the synthesis option do interact with each other somehow.

 

> SYS_CLOCK is the correct clock to use

Ok, this is what I am doing.

 

But does that mean, also the timing will be "translated"?

 

What I did actually is for example this:

 

NET "SYNCH" OFFSET = IN    xxx   ns  VALID   yyy   ns BEFORE "SYS_CLOCK " RISING;

 

If I sampled with SYS_CLOCK,  I would use   xxx = 10 ns   and yyy = 20ns for 50 MHz.

 

But I am using the times of the derived clock 200 MHz  xxx = 2.5 ns   and yyy = 5 ns

 

 

 

0 Kudos
havendream
Visitor
Visitor
12,577 Views
Registered: ‎06-25-2012

I think that the "OFFSET IN" constrain is not right for my case. As I described before, the absolute delay is not cared and only the difference of the delay between different paths are considered.

 

I found in my project that the OFFSET IN constrain can not be satisfied because the input clk pin was connected to IBUFDS and then DCM, so the delay was quite large. But actually this is not a problem because the "data sample clk" can be adjusted by the DCM.

 

So now I still do not know how to make a correct constrain. I will try to place the first registers for the data close to the data input pins as close as possible, hoping that this can make the delay between different paths to be small enough.

0 Kudos
ditiris
Participant
Participant
12,575 Views
Registered: ‎11-27-2007

I found in my project that the OFFSET IN constrain can not be satisfied because the input clk pin was connected to IBUFDS and then DCM, so the delay was quite large. But actually this is not a problem because the "data sample clk" can be adjusted by the DCM.

 

Adjusting the phase of a sampling clock or delaying the data is a common practice to align the sampling clock edge to the middle of the data valid window. This is precisely why the OFFSET IN constraint exists, to tell you whether or not you're properly sampling your data. In the datasheet report section of the timing report, you will get the setup sack, hold slack, as well as the offset to the center of the window to help you shift the clock/data.

 

So now I still do not know how to make a correct constrain.


You need to be able to express the relationship between your sampling clock and data in terms of the arrival time of the data with respect to the clock and the length of the data valid window. Those are the two pieces of information you need to create a valid OFFSET IN constraint.

 

I will try to place the first registers for the data close to the data input pins as close as possible, hoping that this can make the delay between different paths to be small enough.

You can place registers into the IOB, which will provide the minimum, deterministic delay for sampling data.

0 Kudos
juergenatduerr
Adventurer
Adventurer
12,566 Views
Registered: ‎02-09-2012

 

> You need to be able to express the relationship between your sampling clock and data

>  in terms of the arrival time of the data with respect to the clock and the length of the data valid window

 

Referring to my former question:

What clock will be relevant for this?  The sampling clock, derived from a DCM or der initial osc, driving the DCM?

 

In my case, the osc is 50MHz leading to a constraint like 10ns offset before / 20ns valid

 

but the sampling clock is 4 times faster: will it then be  2,5 / 5?   Or ist this propagated from the osc-spec by the tool?

 

0 Kudos
eteam00
Instructor
Instructor
12,560 Views
Registered: ‎07-21-2009

What clock will be relevant for this?  The sampling clock, derived from a DCM or der initial osc, driving the DCM?

 

According to UG612, OFFSET description:

The Offset (OFFSET) constraint:
Specifies the timing relationship between:
• An external clock, and
• Its associated data-in or data-out pin.
• Is used only for pad related signals.
• Cannot be used to extend the arrival time specification method to the internal signals.

 

Assuming that this should be taken 100% at face value as written, we can still get the necessary and useful timing information for setup and hold time.  Keep reading...

 

In my case, the osc is 50MHz leading to a constraint like 10ns offset before / 20ns valid

 

The input data is truly valid and certain for 20nS out of a 20nS clock period?  There is no switching skew whatsoever?  If so, this is a very special ADC.  Or perhaps you misunderstand the OFFSET IN constraint syntax.

 

If the ADC datasheet says that clock-to-output delay is 0,5nS (min) to 1,2nS (max), this would be represented in an OFFSET IN constraint syntax as:

 

OFFSET = IN 3,8NS VALID 4,3NS BEFORE ADC_CLK

 

The 3,8NS represents the worst-case output delay of 1,2nS, which means that with a 5nS clock period (200MHz) the data output is settled and valid 3,8nS (5-1,2) before each rising clock edge.

 

The 4,3NS represents the worst case time span for which the output data is valid and settled.  This is calculated by subtracting from the clock period (5nS) the interval in which output data is not settled and valid (the 0,7nS period of time between the minimum and maximum output delay, or 0,5nS - 1,2nS).

 

See the excellent description in UG612, in the section covering the Offset In Before Constraint.

 

but the sampling clock is 4 times faster: will it then be  2,5 / 5?   Or ist this propagated from the osc-spec by the tool?

 

Have you looked at the post-PAR timing analysis datasheet report?  All your concerns may be dismissed with a quick glance.

 

Let's start with an assumption:  To maximise timing margins, the ADC inputs will be sampled at the IO logic (rather than fabric logic) with IO logic registers.

 

Another assumption: we are using the DCM (or a PLL) in classic source-synchronous configuration to null out all clock distribution delays.  The primary clock (50MHz) is on a GCLK pin, the actual sampling clock is buffered with a BUFG (which covers everything in the FPGA), and the BUFG driven sampling clock will be forwarded to the DCM/PLL feedback input with a buffer which matches the delay of the source clock from input buffer to DCM/PLL CLKIN input.  In other words, the DCM/PLL will align the buffered and distributed sampling clock to the input source clock at the output of the IBUF input buffer in the IOB.

 

This is as good as it will get for mimimising skews between clock and data for source-synchronous inputs, short of using dynamically-adjusted delay blocks.

 

Just as an experiment, try the following --

 

Next:  configure the DCM (or PLL) for 200MHz clock input (not 50MHz).  Synthesise the design.  The datasheet timing report will provide setup and hold time figures which reflect the the input buffer skews, and the clock generation and distribution skews.  These figures will reference the clock input pin and the data input pins, while accounting for all these skew components.

 

Do the datasheet report numbers match with the output timing specifications of the ADC?  If so, then the fundamental design structure is sound.  If not, then the simple design changes to make are phase shifts in the DCM/PLL output or clock polarity inversion at the sampling registers (using NEGEDGE instead of POSEDGE, for example).

 

Assuming that you can achieve good timing margins using just the DCM/PLL adjustments, then re-configuring the DCM/PLL for 50MHz (tather than 200MHz) CLKIN frequency should not alter the fundamental timing characteristics of the design.  Maybe the datasheet timing report will "reference forward" to the generated 200MHz internal clock, or perhaps not, but your design's timing characteristics are already proven and are unchanged.

 

-- Bob Elkind

SIGNATURE:
README for newbies is here: http://forums.xilinx.com/t5/New-Users-Forum/README-first-Help-for-new-users/td-p/219369

Summary:
1. Read the manual or user guide. Have you read the manual? Can you find the manual?
2. Search the forums (and search the web) for similar topics.
3. Do not post the same question on multiple forums.
4. Do not post a new topic or question on someone else's thread, start a new thread!
5. Students: Copying code is not the same as learning to design.
6 "It does not work" is not a question which can be answered. Provide useful details (with webpage, datasheet links, please).
7. You are not charged extra fees for comments in your code.
8. I am not paid for forum posts. If I write a good post, then I have been good for nothing.
havendream
Visitor
Visitor
12,547 Views
Registered: ‎06-25-2012

Adjusting the phase of a sampling clock or delaying the data is a common practice to align the sampling clock edge to the middle of the data valid window. This is precisely why the OFFSET IN constraint exists, to tell you whether or not you're properly sampling your data. In the datasheet report section of the timing report, you will get the setup sack, hold slack, as well as the offset to the center of the window to help you shift the clock/data.

 

 

You need to be able to express the relationship between your sampling clock and data in terms of the arrival time of the data with respect to the clock and the length of the data valid window. Those are the two pieces of information you need to create a valid OFFSET IN constraint.

 

I use a DCM of which the phase can be adjusted at run time by software. In the DAQ software I will scan all the phase to determine a best value.  In my case, the ADC data sheet tells that the data will be valid 0.8ns before rising edge of data clk and holds for 1.6ns. But if I use these two value in the OFFSET IN constrain it can not be meet. The report will tell that the delay from the input pin to the first FFS is something like 2-3ns.  

 

But I don't need to constrain the relation between the data and sampling clock because I can adjust it by software. But what I need to guarantee is that the delay from the data input pin to the first FFS are nearly the same for all the channels. I can not find out any method instead of locaition constrain, such as placing the FFS close to the input pin manually.

0 Kudos
eteam00
Instructor
Instructor
8,287 Views
Registered: ‎07-21-2009

But what I need to guarantee is that the delay from the data input pin to the first FFS are nearly the same for all the channels. I can not find out any method instead of locaition constrain, such as placing the FFS close to the input pin manually.

 

By placing the input FF in the IO logic (rather than the fabric logic), you guarantee that the delay from input pin to the input FF is nearly the same for all channels.  Here are a few ways to make this happen:

 

  • Manually instantiate IDDR input registers.  IDDR registers must be placed in the IO logic (they exist nowhere else).  There is no way to infer IDDR registers, they must be explicitly instantiated (as primitives).
  • Use the (* IOB="TRUE" *) constraint in your source code when declaring the input registers.  Example (Verilog):

(* IOB="TRUE" *)  reg [15:0] ADC_Reg;


  • Use the -pr i map property option.  In ISE, highlight MAP in the processes window, right-click and select process properties to bring up the MAP process properties configuration window.

You might want to read the IOB section of UG625, the Constraints User Guide.

 

-- Bob Elkind

SIGNATURE:
README for newbies is here: http://forums.xilinx.com/t5/New-Users-Forum/README-first-Help-for-new-users/td-p/219369

Summary:
1. Read the manual or user guide. Have you read the manual? Can you find the manual?
2. Search the forums (and search the web) for similar topics.
3. Do not post the same question on multiple forums.
4. Do not post a new topic or question on someone else's thread, start a new thread!
5. Students: Copying code is not the same as learning to design.
6 "It does not work" is not a question which can be answered. Provide useful details (with webpage, datasheet links, please).
7. You are not charged extra fees for comments in your code.
8. I am not paid for forum posts. If I write a good post, then I have been good for nothing.
garengllc
Voyager
Voyager
8,244 Views
Registered: ‎04-10-2012

 

 

 

Following your lead, would this be accurate?"

OFFSET = IN 2.38 ns VALID 2.12 ns BEFORE "AD0_P_CLK" RISING;
OFFSET = IN 2.27 ns VALID 2.11 ns BEFORE "AD0_P_CLK" FALLING;

 

Or do I need to:

*do something different with the 200MHz since it is DDR?

*Account for the negative mins differently?

 

Thanks!

 

0 Kudos
eteam00
Instructor
Instructor
8,235 Views
Registered: ‎07-21-2009

Assume that the CLKOUT is a perfect 50% duty cycle square wave at 200MHz.

Assume that circuit board trace mismatch (skews) for DOUT and CLKOUT from ADC to FPGA are 0.

 

For the rising edge of CLKOUT, DOUT is valid after (not before) 0.12nS.  Data remains valid until 0.16nS before the next falling edge of CLKOUT.  VALID time is [2.5nS - .16nS - .12nS = 2.22nS]

 

For the falling edge of CLKOUT, DOUT is valid after (not before) 0.23nS.  Data remains valid until 0.26nS before the next rising edge of CLKOUT.  VALID time is [2.5nS - .26nS - .23nS = 2.01nS].

 

Thus:

 

OFFSET = IN 0.12 ns VALID 2.22 ns AFTER "AD0_P_CLK" RISING;
OFFSET = IN 0.23 ns VALID 2.01 ns AFTER "AD0_P_CLK" FALLING;

 

If you want to work 'backward' from the clock edge to the previous data, the timing constraints would be:

 

OFFSET = IN 2.27 ns VALID 2.01 ns BEFORE "AD0_P_CLK" RISING;
OFFSET = IN 2.38 ns VALID 2.22 ns BEFORE "AD0_P_CLK" FALLING;

 

I think the first set of numbers will work better, but experimentation should prove or disprove this assertion.

 

Next time you have a new problem or question to discuss, please start a new discussion thread.

 

-- Bob Elkind

SIGNATURE:
README for newbies is here: http://forums.xilinx.com/t5/New-Users-Forum/README-first-Help-for-new-users/td-p/219369

Summary:
1. Read the manual or user guide. Have you read the manual? Can you find the manual?
2. Search the forums (and search the web) for similar topics.
3. Do not post the same question on multiple forums.
4. Do not post a new topic or question on someone else's thread, start a new thread!
5. Students: Copying code is not the same as learning to design.
6 "It does not work" is not a question which can be answered. Provide useful details (with webpage, datasheet links, please).
7. You are not charged extra fees for comments in your code.
8. I am not paid for forum posts. If I write a good post, then I have been good for nothing.
garengllc
Voyager
Voyager
8,221 Views
Registered: ‎04-10-2012

OK, thanks Bob.  

 

I thought since it was a related question it would be useful to have the similar answers in one place, but I can see your point and started a new thread.

 

Thanks again for the help!

0 Kudos