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
Visitor mikejohnson
Visitor
2,515 Views
Registered: ‎11-11-2008

Problems with Spartan3e production board and CLKDV DCM_SP output

Jump to solution

I have to admit I'm somewhat stumped on this now. I have a production board with an XC3S1600E-FG320-4

The device is ~95% full.

There are two clock domains. The first, clk A which is ~114MHz. One DCM is used to buffer this, and create a /4 clock which drives most of the chip. There are a couple of places where data is transferred between the clk_a_dcm_0_bufg  and clk_a_dcm_div_bufg domains. The two BUFGs are located beside the DCM.


  -- CLK A
  --
  u_a_dcm : DCM_SP
    generic map (
      CLKDV_DIVIDE => 4.0,
      CLKIN_PERIOD => 10.0 **
    )
    port map (
      CLK0     => clk_a_dcm_0,
      CLK180   => open,
      CLK270   => open,
      CLK2X    => open,
      CLK2X180 => open,
      CLK90    => clk_a_dcm_90,
      CLKDV    => clk_a_dcm_div,
      CLKFX    => open,
      CLKFX180 => open,
      LOCKED   => dcm_locked(0),
      PSDONE   => open,
      STATUS   => open,
      CLKFB    => clk_a_dcm_0_bufg,
      CLKIN    => clk_a_ibuf,
      --
      DSSEN    => '0',
      PSCLK    => '0',
      PSEN     => '0',
      PSINCDEC => '0',
      --
      RST      => por_rst
    );
  u_dcm_a_clk_0_bufg   : BUFG port map (I => clk_a_dcm_0,   O => clk_a_dcm_0_bufg);
  u_dcm_a_clk_90_bufg  : BUFG port map (I => clk_a_dcm_90,  O => clk_a_dcm_90_bufg);
  u_dcm_a_clk_div_bufg : BUFG port map (I => clk_a_dcm_div, O => clk_a_dcm_div_bufg);

 

The second domain is an async video clock. At low speeds everything is fine. As I've increased the speed to 108MHz on this domain (DCM is located on the other side of the die) I've seen glitches between the two A clock domains. ** Reducing the A clock speed from 113MHz to 100MHz actually makes things worse, hence the period constraint above.

 

I added a counter on the fast clk_a which is reset using a signal from the divided clock, and some code which detects an error.

The pictures below show the chipscope capture of the error, and some 'scope pictures. The fast and divided clk A are forwarded out using side by side ODDR2 flops. Poor grounding on the scope, but you can see the phasing. One shows a long persistence plot and the jitter is reasonable. The second shows the scope triggered by the counter error.

 

The DCM remains locked. The divided clock is ok before the glitch and after. During one cycle, the DIV output comes one cycle too early (3/5) rather than (4/4). This causes the whole system to crash.

 

I have tried the CLK_FX output, same glitch. I've tried taking the DCM feedback before the BUFG. No change.

 

I've reduced the slew and drive on some IO which appears to improve things, so my thinking is I'm on edge power-wise. I see no dip or excessive noise on the BGA power pins. Decoupling is pretty good and the power supply is overrated for the core supply.

 

One idea I have is to move everything over to the fast clock and use clock enables, but this is a complex design and it is quite some work.

 

Another is to use flops to produce a divided clock and forward it onto the BUFG, but I can't use this divided clock as FB to the DCM (skew is important between the two nets)

Any ideas ?

 

 

Thanks,

Mike

 

 

 

 

clock_error.gif
img_20170714_230954.jpg
20170714_223200.jpg
0 Kudos
1 Solution

Accepted Solutions
Visitor mikejohnson
Visitor
4,381 Views
Registered: ‎11-11-2008

Re: Problems with Spartan3e production board and CLKDV DCM_SP output

Jump to solution

Measuring the power rails on the balls of the BGA shows slightly increased noise when the system is busy.

Measurements of the input clock looped out show additional noise, but I can't tell if that's from the IO supply driving the clock out.

 

I've increased the slew rate of the clock driver so it passes through threshold quicker and reduces jitter a littler in my measurements. Doing this has appears to have stopped the DCM producing the odd single cycle glitch on the DV output,

 

/Mike

0 Kudos
2 Replies
Visitor mikejohnson
Visitor
2,388 Views
Registered: ‎11-11-2008

Re: Problems with Spartan3e production board and CLKDV DCM_SP output

Jump to solution

No idea anybody? Can somebody point this Austin's way?

There is quite some volume of these boards which have this issue. Perhaps I should open a support case.

 

I see no evidence of any power distribution or decoupling issues at this stage, certainly I have not been able to measure a dip on any rail (although this is tricky to do). The board is a six layer PCB with decent decoupling and solid ground plane. Point of load DC/DCs which are running well under rated limits. What power rails drive the DCMs? I see on fpga_editor there is a local power pad for the DCM?

 

Thanks,

/Mike

0 Kudos
Visitor mikejohnson
Visitor
4,382 Views
Registered: ‎11-11-2008

Re: Problems with Spartan3e production board and CLKDV DCM_SP output

Jump to solution

Measuring the power rails on the balls of the BGA shows slightly increased noise when the system is busy.

Measurements of the input clock looped out show additional noise, but I can't tell if that's from the IO supply driving the clock out.

 

I've increased the slew rate of the clock driver so it passes through threshold quicker and reduces jitter a littler in my measurements. Doing this has appears to have stopped the DCM producing the odd single cycle glitch on the DV output,

 

/Mike

0 Kudos