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: 
Visitor bahayhoe
Visitor
6,396 Views
Registered: ‎09-12-2007

What is the correct way to constrain an interface with clock and mux'ed data?

Jump to solution

Apologies if this has already been covered elsewhere.

 

I have a video capture application based on a Spartan 3E chip and the interface consists of a low(er) frequency clock  line with a x15 multiplexed data line. My question is: what is the correct way to constrain this interface?

 

The clock is multiplied up by x15 using the frequency synthesizer of a DCM and the x15 output clock registers the mux'ed data in from the PADs(differential pair).

 

I have tried constraining the input clock globally using OFFSET-IN-BEFORE and also applying a FROM-TO constraint between the data pads and the data flip-flops.

 

Although they appear to be doing something (according to the timing analyzer), I have reason to beleive that it is not fully constrained.

 

I have set up the variable fine phase shift of the DCM to be configurable via an on-board USB interface. By adjusting this I can define a range of capture for the video data.  However, after making some fairly trivial mod's. and recompiling I found that I could no longer manage to reliably capture the data with any fine phase shift value and it is this that makes me think something is still not being constrained correctly (or maybe at all!).

 

Has anyone had any similar experiences to this? ... and is my approach to the constraints methodology correct?

 

Thanks in advance.

 

Brent Hayhoe

 

 

 

0 Kudos
1 Solution

Accepted Solutions
Xilinx Employee
Xilinx Employee
7,656 Views
Registered: ‎04-15-2008

Re: What is the correct way to constrain an interface with clock and mux'ed data?

Jump to solution

Hi Brent,

 

The OFFSET IN constraint is the correct constraint to use for your inputs.  Do not use a FROM:TO.  The OFFSET IN will constrain the paths between your input pads and your first stage capture flip-flops.  Ideally, you would place those flops in the IOBs, where the routing between the pads and flops will not vary.  At that point, the primary effect of the OFFSET IN will just be to show the paths in the timing report as opposed to actually constraining the path since, as I mentioned, those path delays will not vary.  Usage of the DCM fine phase shift is a valid method for positioning the clock within the data eye.  However, unless the interface is running at hundreds of Mbits per pin, you probably do not need to dynamically change the shift value.  A static value may be good enough.

 

Don't forget to use the VALID keyword in your OFFSET IN constraint if the interface is source-synchronous.

 

Also, don't forget to apply a PERIOD constraint to your input clock so that all of the synchronous paths inside the FPGA are correctly constrained.

 

Regards,

-Hobson

0 Kudos
4 Replies
Xilinx Employee
Xilinx Employee
7,657 Views
Registered: ‎04-15-2008

Re: What is the correct way to constrain an interface with clock and mux'ed data?

Jump to solution

Hi Brent,

 

The OFFSET IN constraint is the correct constraint to use for your inputs.  Do not use a FROM:TO.  The OFFSET IN will constrain the paths between your input pads and your first stage capture flip-flops.  Ideally, you would place those flops in the IOBs, where the routing between the pads and flops will not vary.  At that point, the primary effect of the OFFSET IN will just be to show the paths in the timing report as opposed to actually constraining the path since, as I mentioned, those path delays will not vary.  Usage of the DCM fine phase shift is a valid method for positioning the clock within the data eye.  However, unless the interface is running at hundreds of Mbits per pin, you probably do not need to dynamically change the shift value.  A static value may be good enough.

 

Don't forget to use the VALID keyword in your OFFSET IN constraint if the interface is source-synchronous.

 

Also, don't forget to apply a PERIOD constraint to your input clock so that all of the synchronous paths inside the FPGA are correctly constrained.

 

Regards,

-Hobson

0 Kudos
Visitor bahayhoe
Visitor
6,341 Views
Registered: ‎09-12-2007

Re: What is the correct way to constrain an interface with clock and mux'ed data?

Jump to solution

Hi Hobson and thanks,

 

Your information confirmed what I had thought, but I had omitted the 'VALID' keyword and after sorting out my 'BEFORE' and 'AFTER' keywords now have timing closure.

 

So I thought that I ought to add a bit more clarification as to what I am doing for anyone else viewing this discussion.

 

This is the basic serial interface:

 

#          _______________________________                             ___
#    CLK _|                               |___________________________|
#
#           0   1   2   3   4   5   6   7   8   9   A   B   C   D   E   0
#          ___ ___ ___ ___ ___ ___ ___ ___ ___ ___ ___ ___ ___ ___ ___ ___
#   Data  X___X___X___X___X___X___X___X___X___X___X___X___X___X___X___X___X
#
#          _   _   _   _   _   _   _   _   _   _   _   _   _   _   _   _
# CLK*15 _| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_
#

 

Where 'CLK' and 'Data' are differential input signals and the 'CLK*15' is generated via the DCM frequency synthesizer.

 

The video capture application is used to test various devices with this common interface.

 

The DUT that I am currently using has a clock rate of 20MHz leading to x15 rate of 300MHZ inside the FPGA (close to the limit for Spartan 3E -4 parts).

 

Perhaps you can now see the need for the variable fine shift phase to position the eye for various families of DUT.

 

On top of this, we are actually using an Opal Kelly Inc. Xilinx FPGA development board which is piggybacked onto our own board. The design is inherited and with all this taken into account, the clock differential inputs are not at the best I/O site to utilize the DCM fast links, thus putting slightly more of a load onto the MAP and PAR tasks (hence the 'CLOCK_DEDICATED_ROUTE' constraints below).

 

FYI here are the constraints that I am now using for this interface. I am assuming that because the 'CDP_CLKN_i' 'PERIOD' constraint is defined using that of the 'CDP_CLKP_i', then I only need to use an 'OFFSET IN' constraint on the 'CDP_CLKP_i' clock pad. The interface does now complete with timing closure and more importantly, the variable fine shift phase value does remain reasonable constant between modifications and re-compiles.

 

   NET "CDP_CLKP_i" TNM_NET = "TNM_CDP_CLKP";
   TIMESPEC "TS_CDP_CLKP" = PERIOD "TNM_CDP_CLKP" 20 MHz HIGH 53.3333%;                   # 8/7 mark/space

 

   NET "CDP_CLKN_i" TNM_NET = "TNM_CDP_CLKN";
   TIMESPEC "TS_CDP_CLKN" = PERIOD "TNM_CDP_CLKN" "TS_CDP_CLKP" * 1 PHASE + 26.6667 ns;   # 8/7 mark/space

 

   NET "CDP_CLKP_i" CLOCK_DEDICATED_ROUTE = FALSE;
   NET "CDP_CLKN_i" CLOCK_DEDICATED_ROUTE = FALSE;
   PIN "CDP_IF_inst/CDP_DCM_FX15_inst/DCM_inst.CLKIN" CLOCK_DEDICATED_ROUTE = FALSE;

 

   OFFSET = IN 0.0000 ns VALID 2.7033 ns AFTER "CDP_CLKP_i";
   # VALID = x15 period - clk-clk jitter - clk-D jitter
   # x15 period = 3.3333ns, clk-clk jitter = 0.3000ns, clk-D jitter = 0.3300ns


One further point: I am currently using ISE v10.01.03 and have all my constraints in an XCF file to constrain the synthesis, with XST enabled to write out constraints to the implementation phase. The 'VALID' keyword is not recognized by XST, but importantly, it is forwarded through to the PCF file. However, unless you use the 'Project -> Cleanup Project Files' tab, the translate phase (NGDBuild) will fail with the following error:

 

   FATAL_ERROR:NgdBuild:Portability/export/Port_Main.h:143:1.6 - This application
      has discovered an exceptional condition from which it cannot recover.
      Process will terminate. For technical support on this issue, please open a
      WebCase with this project attached at
http://www.xilinx.com/support.

 

This may have been a cause of me omitting the 'VALID' keyword in the past. I may now be able to take the hit and move to ISE v11 and see if the problem still exists. If so I'll raise a WebCase.

 

Cheers,

 

Brent.

 

 

0 Kudos
Highlighted
Visitor bahayhoe
Visitor
5,798 Views
Registered: ‎09-12-2007

Re: What is the correct way to constrain an interface with clock and mux'ed data?

Jump to solution

I thought that I'd better take some time to tie up the loose ends and wrap up this thread

 

With regards to the following error:

 

   FATAL_ERROR:NgdBuild:Portability/export/Port_Main.h:143:1.6 - This application
      has discovered an exceptional condition from which it cannot recover.
      Process will terminate. For technical support on this issue, please open a
      WebCase with this project attached at
http://www.xilinx.com/support.

 

I did submit a WebCase (811995) and the solution to this little problem is that it is fixed in ISEv12.

 

I'm still waiting for the release to check it out!

 

I took the hit and moved up to ISEv11.4 without any problems.

 

However, I tripped over this little error:

ERROR:Pack:1107 - Pack was unable to combine the symbols listed below into a
   single DIFFS component because the site type selected is not compatible. The
   component type is determined by the types of logic and the properties and
   configuration of the logic it contains. In this case an IO component of type
   DIFFS was chosen because the IO contains symbols and/or properties consistent
   with differential slave usage. Please double check that the types of logic
   elements and all of their relevant properties and configuration options are
   compatible with the physical site type of the constraint.

   Summary:
   Symbols involved:
    PAD symbol "CDP_IF_inst/CDP_D0N_i" (Pad Signal = CDP_D0N_i)
    SlaveBuffer symbol "CDP_IF_inst/CDP_D0_IBUFDS_LVDS_25_inst/SLAVEBUF.DIFFIN"
   (Output Signal = CDP_IF_inst/CDP_D0_IBUFDS_LVDS_25_inst/SLAVEBUF.DIFFIN)
   Component type involved: DIFFS
   Site Location involved: E6
   Site Type involved: DIFFSI


 

The engineer handling my WebCase pretty quickly referred me to this little snippet:

 

    http://www.xilinx.com/support/documentation/user_guides/ug331.pdf

On page 351 and the last paragraph entitled "On-Chip Differential Termination", the last sentence states:

 

   "On-chip differential termination is not supported on input-only pins."

 

My initial reaction to this was - AAAAAARGH!

 

And so after reassigning the differential data pins and adding some twisted pair straps onto the board, everything now works perfectly.

 

THE END

 

0 Kudos
Visitor bahayhoe
Visitor
5,683 Views
Registered: ‎09-12-2007

Re: What is the correct way to constrain an interface with clock and mux'ed data?

Jump to solution

Just to finally wrap up and with regards to WebCase 811995: ISEv12 looks like it might have been delayed, but I have just tried the 'Rerun All' drop down option in ISEv11.5 and it seems to have been fixed.

 

Cheers,

 

Brent.

 

0 Kudos