Sign In

Don't have a Xilinx account yet?

  • Choose to receive important news and product information
  • Gain access to special content
  • Personalize your web experience on Xilinx.com

Create Account

Username

Password

Forgot your password?
XClose Panel
Xilinx Home
Reply
Regular Contributor
airturk
Posts: 68
Registered: ‎09-12-2011
0

Hold Time Failure (due to Clock Path Skew) in a design using Video Frame Buffer Controller

Dear Members;

 

 I am having an hard time fixing a hold path failure in my design. I have a design that uses Video Frame Buffer Controller to access SDRAM. I have copied the detailed timing result down below.

 

The data path delay is not the problem, and looks like the problem is the Clock Path Skew. And I think the reason behind the clock path skew is that the design crosses clock domains at this point. I made sure that both clocks go through the clock dedicated route. Here is more data about the source and destination clocks:

 

Source clock: VFBC2_Cmd_Clk_pin

hp_ioclk -> IBUFG -> DCM -> BUFG      (as a result assigned to BUFGMUX X2Y10)

 

Destination Clock: mpmc_clk

external_clk (n&p) -> IBUFGDS -> PLL -> BUFG     (as a result assigned to BUFGMUX X3Y16)

 

There is no constraints on this path. Is it a good idea to constraint it and how?

 

Any recommendation is appreciated!

 

Report:

 

Paths for end point Inst_cpu/sdram_0/sdram_0/VFBC2_INST.vfbc/VFBC1_PIM_NGC/UVFBC/GEN_WRDATA_FIFOS[1].GEN_WRDATA_PORT_ENABLE.UWrDataFifo/ProdObjPtr_sync2cons_0_1 (SLICE_X11Y61.BX), 1 path


--------------------------------------------------------------------------------


Slack (hold path): -5.376ns (requirement - (clock path skew + uncertainty - data path))
Source: Inst_cpu/sdram_0/sdram_0/VFBC2_INST.vfbc/VFBC1_PIM_NGC/UVFBC/GEN_WRDATA_FIFOS[1].GEN_WRDATA_PORT_ENABLE.UWrDataFifo/ObjFifo_prod_ctl_comp/GrayObjPtr_1 (FF)
Destination: Inst_cpu/sdram_0/sdram_0/VFBC2_INST.vfbc/VFBC1_PIM_NGC/UVFBC/GEN_WRDATA_FIFOS[1].GEN_WRDATA_PORT_ENABLE.UWrDataFifo/ProdObjPtr_sync2cons_0_1 (FF)
Requirement: 0.000ns
Data Path Delay: 0.825ns (Levels of Logic = 0)
Clock Path Skew: 5.723ns (4.655 - -1.068)
Source Clock: VFBC2_Cmd_Clk_pin rising
Destination Clock: mpmc_clk rising
Clock Uncertainty: 0.478ns

Clock Uncertainty: 0.478ns ((TSJ^2 + DJ^2)^1/2) / 2 + PE
Total System Jitter (TSJ): 0.070ns
Discrete Jitter (DJ): 0.487ns
Phase Error (PE): 0.232ns

Minimum Data Path at Slow Process Corner: Inst_cpu/sdram_0/sdram_0/VFBC2_INST.vfbc/VFBC1_PIM_NGC/UVFBC/GEN_WRDATA_FIFOS[1].GEN_WRDATA_PORT_ENABLE.UWrDataFifo/ObjFifo_prod_ctl_comp/GrayObjPtr_1 to Inst_cpu/sdram_0/sdram_0/VFBC2_INST.vfbc/VFBC1_PIM_NGC/UVFBC/GEN_WRDATA_FIFOS[1].GEN_WRDATA_PORT_ENABLE.UWrDataFifo/ProdObjPtr_sync2cons_0_1
Location Delay type Delay(ns) Physical Resource
Logical Resource(s)
------------------------------------------------- -------------------
SLICE_X8Y61.AQ Tcko 0.384 Inst_cpu/sdram_0/sdram_0/VFBC2_INST.vfbc/VFBC1_PIM_NGC/UVFBC/GEN_WRDATA_FIFOS[1].GEN_WRDATA_PORT_ENABLE.UWrDataFifo/ObjFifo_prod_ctl_comp/GrayObjPtr<4>
Inst_cpu/sdram_0/sdram_0/VFBC2_INST.vfbc/VFBC1_PIM_NGC/UVFBC/GEN_WRDATA_FIFOS[1].GEN_WRDATA_PORT_ENABLE.UWrDataFifo/ObjFifo_prod_ctl_comp/GrayObjPtr_1
SLICE_X11Y61.BX net (fanout=2) 0.393 Inst_cpu/sdram_0/sdram_0/VFBC2_INST.vfbc/VFBC1_PIM_NGC/UVFBC/GEN_WRDATA_FIFOS[1].GEN_WRDATA_PORT_ENABLE.UWrDataFifo/ObjFifo_prod_ctl_comp/GrayObjPtr<1>
SLICE_X11Y61.CLK Tckdi (-Th) -0.048 Inst_cpu/sdram_0/sdram_0/VFBC2_INST.vfbc/VFBC1_PIM_NGC/UVFBC/GEN_WRDATA_FIFOS[1].GEN_WRDATA_PORT_ENABLE.UWrDataFifo/ProdObjPtr_sync2cons<0><3>
Inst_cpu/sdram_0/sdram_0/VFBC2_INST.vfbc/VFBC1_PIM_NGC/UVFBC/GEN_WRDATA_FIFOS[1].GEN_WRDATA_PORT_ENABLE.UWrDataFifo/ProdObjPtr_sync2cons_0_1
------------------------------------------------- ---------------------------
Total 0.825ns (0.432ns logic, 0.393ns route)
(52.4% logic, 47.6% route)

Expert Contributor
eteam00
Posts: 7,505
Registered: ‎07-21-2009
0

Re: Hold Time Failure (due to Clock Path Skew) in a design using Video Frame Buffer Controller

Please describe the target FPGA, the development board you are using, and the source of the clcok and input data.

 

This is all needed information.

 

-- 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.
Regular Contributor
airturk
Posts: 68
Registered: ‎09-12-2011
0

Re: Hold Time Failure (due to Clock Path Skew) in a design using Video Frame Buffer Controller

Hi Bob;

 

 I forgot to add that information.

 

Target FPGA is XC6SLX45T.

The development board I am using is SP605. 

 

This design receives 16bit data (hp_data) from an external device with its external clock (hp_clk) and this data is written to the SDRAM via Video Frame Buffer Controller using another clock (mpmc_clk) derived from an external clock source (external_clk).

 

First clock is VFBC2_Cmd_Clk_pin which is a result of an external clock coming to FPGA running at 30 Mhz. The clock comes from a clock dedicated pin, and goes through hp_clk -> IBUFG -> DCM -> BUFG -> VFBC2_Cmd_Clk_pin.

 

Second clock is mpmc_clk which is a result of another external clock coming to FPGA running at 62.5 Mhz. This clock comes from clock dedicated pins, and goes through external_clk (n&p) -> IBUFGDS -> PLL -> BUFG -> mpmc_clk.

 

Regards,


 

Expert Contributor
eteam00
Posts: 7,505
Registered: ‎07-21-2009
0

Re: Hold Time Failure (due to Clock Path Skew) in a design using Video Frame Buffer Controller

Sounds like you need a TIG (Timing Ignore) constraint for the clock domain crossing paths (logic clocked with one clock being synchronised to the second clock).

 

-- 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.
Regular Contributor
airturk
Posts: 68
Registered: ‎09-12-2011
0

Re: Hold Time Failure (due to Clock Path Skew) in a design using Video Frame Buffer Controller

I don't think i can use a TIG constraint. Because of this hold time failure, the VFBC doesn't work properly, and I am writing garbage to the SDRAM. i was thinking about putting a FROM TO constraint on the path.

 

Maybe I did not understand your recommendation, please correct me if I didn't. 

Expert Contributor
eteam00
Posts: 7,505
Registered: ‎07-21-2009
0

Re: Hold Time Failure (due to Clock Path Skew) in a design using Video Frame Buffer Controller

[ Edited ]

When crossing from one clock domain to another, setup and hold time cannot be evaluated because the phase relationship of the two clocks (source and destination domain clocks) are constantly and dynamically changing.

 

If this interface is not working, it's not a timing constraint problem.  It's a design problem.

 

A typical solution for clock domain crossing is to use a FIFO.  In the case of the Spartan-6 MIG-generated memory controller, all user ports to the controller are via FIFO, and the clock domain crossing problem is resolved with the use of the FIFOs.  If the hp interface clock and data are directly interfacing to the Spartan-6 memory controller, the clock which should be used is the hp input clock.  Is this how your design is structured?

 

A block diagram would be very helpful to describe your problem, illustrating

  • the hp input bus and clock connection and usage
  • which clocks are used where
  • the point of the hold time 'failure'

Clock skew is certainly a design problem, but it would only be a problem for re-clocking the hp input data with the hp input clock.  Clock skew cannot be an issue with clock domain crossing, because the solution must presume and address indeterminate phase relationship between the two clocks. [note: I've glossed over some second-order considerations, to focus attention on the primary principles.]

 

-- 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.
Expert Contributor
rcingham
Posts: 2,010
Registered: ‎09-09-2010
0

Re: Hold Time Failure (due to Clock Path Skew) in a design using Video Frame Buffer Controller

Is the data being consumed at the same average rate that it is being produced?

Or does domain1 through it over the chasm at its rate, and domain2 repeats or drops data as required for its rate?

------------------------------------------
"If it don't work in simulation, it won't work on the board."