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: 
Participant watman
Participant
14,732 Views
Registered: ‎05-19-2010

How to deal with a clock input that stops/starts (Spartan-6)

Jump to solution

I have a situation where the input clock starts and stops, and I would like to know the best way to deal with this. Currently the FPGA logic stops running when the clock stops then restarts, but not always. Device is a Spartan-6 XC6SLX45.

 

Most of the FPGA is driven by a normal oscillator (that never stops), but there is a separate part that receives parallel data from a camera (using the clock supplied from the camera) then passes it via FIFO.

The clock is buffered by a DCM_SP before being used to sample the data, and the CLK_VALID signal is used to enable the data reception.

 

When the camera mode is changed, the data and clock stop for a while (thousands of cycles) so the DCM loses lock. The clock frequency when it returns is also different (between 20 MHz and 80MHz)

I have tried monitoring the CLOCK_STOPPED signal and resetting the DCM (using the other clock to delay then send slow RST pulses continually) but it doesn't seem to be reliable.

 

What I _think_ I should be doing is holding RST until the clock returns (datasheet mentions resetting until 3 valid cycles have come in), but I don't know how to detect when the clock starts again. The CLOCK_STOPPED doesn't come back again while the DCM is "stuck" (checked with chipscope).

 

Is there a better way to deal with this situation?

 

Daniel

 

Tags (3)
0 Kudos
1 Solution

Accepted Solutions
Teacher eteam00
Teacher
19,367 Views
Registered: ‎07-21-2009

Re: How to deal with a clock input that stops/starts (Spartan-6)

Jump to solution

I think a DCM is a poor choice for applications with a very wide input clock frequency range.  I would strongly suggest you use a PLL instead of a DCM.

 

At what frequency is your "normal" system clock running?

 

Detecting the presence and frequency of the transient camera clock is pretty simple.  Use the input clock (after a proper clock buffer) to drive a counter.  Use the "normal" clock to check the toggling and the frequency of one or more of the counter bits, taking the normal precautions for crossing clock domains.

 

-- 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.
24 Replies
Teacher eteam00
Teacher
19,368 Views
Registered: ‎07-21-2009

Re: How to deal with a clock input that stops/starts (Spartan-6)

Jump to solution

I think a DCM is a poor choice for applications with a very wide input clock frequency range.  I would strongly suggest you use a PLL instead of a DCM.

 

At what frequency is your "normal" system clock running?

 

Detecting the presence and frequency of the transient camera clock is pretty simple.  Use the input clock (after a proper clock buffer) to drive a counter.  Use the "normal" clock to check the toggling and the frequency of one or more of the counter bits, taking the normal precautions for crossing clock domains.

 

-- 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.
Participant watman
Participant
14,724 Views
Registered: ‎05-19-2010

Re: How to deal with a clock input that stops/starts (Spartan-6)

Jump to solution

I chose a DCM because I thought it was the simplest thing to use for simply buffering the clock. I originally tried using the input clock with IBUFG to directly drive the input capture  logic but it didn't work well at all.

I will change to a PLL if you recommend it, but could you tell me why it is better suited than a DCM?

 

I have several main clocks available: 18MHz, 120MHz, 133MHz, and 240MHz. The oscillator input is 133MHz.

I used the 18MHz clock for generating resets to the DCM.

 

Using a counter is a good idea, I'll try that.

If I understand correctly, the simplest form would be:

The input clock goes to an IBUFG, then to the PLL input and counter input.

One of the high counter bits then goes to 2 flip-flops clocked by the main clock (120MHz?) which is monitored for transitions.

Then I reset the PLL if LOCKED transitions from high to low, and stop resetting if there are a few transitions of the counter.

0 Kudos
Teacher eteam00
Teacher
14,719 Views
Registered: ‎07-21-2009

Re: How to deal with a clock input that stops/starts (Spartan-6)

Jump to solution

I will change to a PLL if you recommend it, but could you tell me why it is better suited than a DCM?

 

A DCM, at its root, is a ring oscillator.  The length (or period) range of the oscillator ring is set at configuration time, and the locking mechanism is used to make small (very small) changes in the length of the ring oscillator.  The Spartan-6 PLL is a VCO with a very broad range.  Locking is accomplished by adjusting the oscillator frequency rather than (for the DCM) inserting and removing delay links in a ring.

 

This is my understanding.  I may be wrong, I am not an authoritative expert on Xilinx DCMs and DLLs.

 

I have several main clocks available: 18MHz, 120MHz, 133MHz, and 240MHz. The oscillator input is 133MHz.

 

This number of clocks and clock frequencies is quite unusual.  Is this by choice or are you using IP blocks over which you have no control?  Just idle curiosity on my part.  I'm a fan (proponent) of using clock enables with a minimum number of clcoks, rather than proliferating clocks for various functions or blocks.

 

The input clock goes to an IBUFG, then to the PLL input and counter input.

 

Unless available BUFIO2 and BUFG buffers are exhausted, the IBUFG output will be buffered by either BUFIO2 or BUFG before input to the PLL or DCM.  If you do not infer either of hese buffers, XST will do this automatically.  On this technical point, I have authoritative knowledge :)

 

If you explicitly instantiate or infer a BUFG, then driving a multi-bit counter with this input clock becomes simple.

 

-- 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.
0 Kudos
Participant watman
Participant
14,710 Views
Registered: ‎05-19-2010

Re: How to deal with a clock input that stops/starts (Spartan-6)

Jump to solution

I didn't know that DCMs worked like that, it certainly makes more sense to use a PLL then.

There doesn't seem to be a way to indicate to the tools that a clock is in a frequency range, so I set up the PLL at the highest input frequency.

 

I have made the counter/reset logic and it seems to work well in simulation, I'm adding it to the hardware design now.

 

I guess I could use clock enables for some things, but it seemed simpler this way. There is a MCB in the design so there are actually more clocks. The 133 MHz clock is only used in the MCB to generate the clocks it needs, then it comes to a PLL for generating the others.

 

I wanted a 240MHz clock because I need to do some DSP as fast as possible, and BRAMs/DSP48s limit the max frequency to 250MHz. Most of the design uses 120MHz, I thought it would use less power than running everything at 240 (?) as that speed is not needed for everything. The MCB is using most of the power though.

 

The 18 MHz clock is so that I can use the same code in this design and another design for an image transmission/reception function.

 

Daniel

0 Kudos
Teacher eteam00
Teacher
14,703 Views
Registered: ‎07-21-2009

Re: How to deal with a clock input that stops/starts (Spartan-6)

Jump to solution

I have made the counter/reset logic and it seems to work well in simulation, I'm adding it to the hardware design now.

 

It will be interesting to hear of your actual hardware results.

 

I guess I could use clock enables for some things, but it seemed simpler this way. There is a MCB in the design so there are actually more clocks. The 133 MHz clock is only used in the MCB to generate the clocks it needs, then it comes to a PLL for generating the others.

 

I will not give you a hard time for using an approach with which you are comfortable and confident.

 

The MCB_PLL, as instantiated in the MIG-generated Spartan-6 memory controller code, is greatly under-utilised.  It may help you in your next design to know that you can modify the MCB_PLL configuration to provide additional clocks, and to use an input oscillator frequency much different than the MIG default.

 

I wanted a 240MHz clock because I need to do some DSP as fast as possible, and BRAMs/DSP48s limit the max frequency to 250MHz. Most of the design uses 120MHz, I thought it would use less power than running everything at 240 (?) as that speed is not needed for everything. The MCB is using most of the power though.

 

I do not know if power consumption is a great concern in your design, or not.  It sounds like you have already run the XPA (Xilinx Power Analyser) on your design.  When I had last run XPA, I remember that global clock distribution (BUFG plus interconnect) ate up a considerable amount of power.

 

One of the nerd experiments on my "when-I-have-the-time" list is to crank a two clock design (a fast and a slow clock) through XPA, and then modify the design to run all logic with a single (fast) clock, and compare the two power results.

 

  • You will save power by running some logic at a lower clock frequency, but the extra (slow) clock will cost power
  • You will save some power by merging two global clocks into one, but running all logic with higher clock will cost power.

I wonder which approach is a net "win".

 

I wish you well with your design.

 

-- 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.
0 Kudos
Participant watman
Participant
14,701 Views
Registered: ‎05-19-2010

Re: How to deal with a clock input that stops/starts (Spartan-6)

Jump to solution

It will be interesting to hear of your actual hardware results.

 

It's been happily handling clock stop/restarts every 5 sec for the last hour (hardware) so all seems well. I haven't tried any frequency changes yet, but it should be ok.

 

The MCB_PLL, as instantiated in the MIG-generated Spartan-6 memory controller code, is greatly under-utilised.  It may help you in your next design to know that you can modify the MCB_PLL configuration to provide additional clocks, and to use an input oscillator frequency much different than the MIG default.

 

I did modify the MCB_PLL a bit (to use 133MHz input rather than 333) but I needed more clocks than the number spare so it was just easier to generate them all together (the frequencies/divisions work out ok). Actually I remembered theres also a 0 and 180 degree 24MHz clock for driving the camera clock input through an ODDR2.

 

There are clocks all over the place but I was getting errors I didn't understand when I tried to combine things. When I have more time I'll clean up the design.

 

I do not know if power consumption is a great concern in your design, or not.  It sounds like you have already run the XPA (Xilinx Power Analyser) on your design.  When I had last run XPA, I remember that global clock distribution (BUFG plus interconnect) ate up a considerable amount of power.

 

XPA estimates 0.9W dissipated by the FPGA.

It's not a battery powered design, but It's a very small board (5xm x 5cm) so things are getting a bit toasty.

PLLs are the biggest users (0.377W). Probably reducing the number would help as there are currently 4, and there isn't much power difference between the high speed and low speed ones.

MCB uses 0.19W, IO 0.1W, but the actual logic only uses 0.01W.

So probably reducing the number of PLLs and running all the logic at 240MHz will result in lower power.

I'll try it once things are all working properly!

 

Thanks for your help,

 

Daniel

0 Kudos
Historian
Historian
14,684 Views
Registered: ‎02-25-2008

Re: How to deal with a clock input that stops/starts (Spartan-6)

Jump to solution

@watman wrote:

I have a situation where the input clock starts and stops, and I would like to know the best way to deal with this. Currently the FPGA logic stops running when the clock stops then restarts, but not always. Device is a Spartan-6 XC6SLX45.

 

Most of the FPGA is driven by a normal oscillator (that never stops), but there is a separate part that receives parallel data from a camera (using the clock supplied from the camera) then passes it via FIFO.

The clock is buffered by a DCM_SP before being used to sample the data, and the CLK_VALID signal is used to enable the data reception.

 

When the camera mode is changed, the data and clock stop for a while (thousands of cycles) so the DCM loses lock. The clock frequency when it returns is also different (between 20 MHz and 80MHz)

I have tried monitoring the CLOCK_STOPPED signal and resetting the DCM (using the other clock to delay then send slow RST pulses continually) but it doesn't seem to be reliable.

 

What I _think_ I should be doing is holding RST until the clock returns (datasheet mentions resetting until 3 valid cycles have come in), but I don't know how to detect when the clock starts again. The CLOCK_STOPPED doesn't come back again while the DCM is "stuck" (checked with chipscope).

 

Is there a better way to deal with this situation?

 

Daniel

 


I guess I'm not clear on why you need a DCM (or a PLL) at all. I assume that the clock is synchronous with your incoming sensor data. If you're not using frequency synthesis or other DCM features, then you don't need a DCM. 

----------------------------Yes, I do this for a living.
0 Kudos
Participant watman
Participant
14,675 Views
Registered: ‎05-19-2010

Re: How to deal with a clock input that stops/starts (Spartan-6)

Jump to solution

I guess I'm not clear on why you need a DCM (or a PLL) at all. I assume that the clock is synchronous with your incoming sensor data. If you're not using frequency synthesis or other DCM features, then you don't need a DCM.

 

That is what I thought, and what I originally tried. On an oscilloscope I can see that data is stable on the rising edge of the clock, but the image data received by the FPGA was pretty messed up. Adding the DCM/PLL fixed it immediately.

 

The image is processed a bit (interpolation of bayer pattern etc) using the pixel clock before it is FIFOed, would it maybe be better to just capture the data then FIFO it immediately and process it with another clock?

 

Daniel

0 Kudos
Teacher eteam00
Teacher
14,673 Views
Registered: ‎07-21-2009

Re: How to deal with a clock input that stops/starts (Spartan-6)

Jump to solution

The image is processed a bit (interpolation of bayer pattern etc) using the pixel clock before it is FIFOed, would it maybe be better to just capture the data then FIFO it immediately and process it with another clock?

 

Architecturally, it's a matter of "six of one vs. half-dozen of another" (i.e. no difference).

As an engineer, I would recommend "if it ain't broke, don't fix it".

 

-- 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.
0 Kudos
Participant watman
Participant
8,509 Views
Registered: ‎05-19-2010

Re: How to deal with a clock input that stops/starts (Spartan-6)

Jump to solution

It's just irritating that it _should_ work without a PLL.

When I have more time I'll try again without the PLL and modify the counter logic to reset everything when there's no clock.

Things probably just got into a wierd state when the clock stopped and restarted before.

0 Kudos
Teacher eteam00
Teacher
8,508 Views
Registered: ‎07-21-2009

Re: How to deal with a clock input that stops/starts (Spartan-6)

Jump to solution

I'm guessing there is more at play than simple PLL vs. no PLL.

 

Clock vs. data timing, combined with clock buffering and distibution, are likely to be of major consequence.  The ability of the PLL to phase align the (buffered and distributed) sampling clock to the input clock (at the IBUFG output) is a significant simplification of the distribution skews.

 

I assume that you are not using the IDELAY2 dynamically variable input delay blocks to align the input data to the IO 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.
0 Kudos
Participant watman
Participant
8,506 Views
Registered: ‎05-19-2010

Re: How to deal with a clock input that stops/starts (Spartan-6)

Jump to solution

I assume that you are not using the IDELAY2 dynamically variable input delay blocks to align the input data to the IO clock.

 

No just an IBUFG. I am testing with a 20MHz input clock, the data is perfectly aligned, and the electrical path is only 20mm so I don't think an IDELAY2 should be needed. I know there will be some skew, but 20MHz is very slow compared to what the FPGA can do.

0 Kudos
Teacher eteam00
Teacher
8,502 Views
Registered: ‎07-21-2009

Re: How to deal with a clock input that stops/starts (Spartan-6)

Jump to solution

No just an IBUFG. I am testing with a 20MHz input clock, the data is perfectly aligned, and the electrical path is only 20mm so I don't think an IDELAY2 should be needed. I know there will be some skew, but 20MHz is very slow compared to what the FPGA can do.

 

In the Static Timing Report, what are the "datasheeet" numbers for input data vs. input clock?

 

How do they compare with actual (worst-case) data vs. clock timing as measured with a 'scope?  If they match up, you should have no problem -- and the head-scratching begins.

 

-- 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.
0 Kudos
Historian
Historian
8,494 Views
Registered: ‎02-25-2008

Re: How to deal with a clock input that stops/starts (Spartan-6)

Jump to solution

@watman wrote:

I guess I'm not clear on why you need a DCM (or a PLL) at all. I assume that the clock is synchronous with your incoming sensor data. If you're not using frequency synthesis or other DCM features, then you don't need a DCM.

 

That is what I thought, and what I originally tried. On an oscilloscope I can see that data is stable on the rising edge of the clock, but the image data received by the FPGA was pretty messed up. Adding the DCM/PLL fixed it immediately.

 

The image is processed a bit (interpolation of bayer pattern etc) using the pixel clock before it is FIFOed, would it maybe be better to just capture the data then FIFO it immediately and process it with another clock?

 

Daniel


Oh, it sounds like you're not meeting input setup without the DCM -- was the DCM providing delay/phase shift? If it wasn't, then the DCM output would line up with the DCM input and you would still lose. 

 

Instead of the DCM, use a simple input delay on the clock so that the rising edge of the clock is in the middle of the bit time. I'm working with an image sensor which does exactly that -- the serial data bits are output on a DDR clock and the bits change coincident with the clock. Adding a few nanoseconds of delay on the clock put the sample point where it needed to be.

----------------------------Yes, I do this for a living.
0 Kudos
Participant watman
Participant
8,482 Views
Registered: ‎05-19-2010

Re: How to deal with a clock input that stops/starts (Spartan-6)

Jump to solution

In the Static Timing Report, what are the "datasheeet" numbers for input data vs. input clock?

 

How do they compare with actual (worst-case) data vs. clock timing as measured with a 'scope?  If they match up, you should have no problem -- and the head-scratching begins.

 

I couldn't find info on the input data/input clock in the static timing report, and I realised that there isn't a timing constraint on that clock! I have been developing this project in modules and must have forgotten to copy the UCF into the larger design.

Perhaps the only effect of the DCM/PLL was to add a timing contraint to the clock net...

I have added a constraint at the highest expected clock frequency now.

 

Oh, it sounds like you're not meeting input setup without the DCM -- was the DCM providing delay/phase shift? If it wasn't, then the DCM output would line up with the DCM input and you would still lose.

 

The data is SDR so I wasn't using a phase shift, it shouldn't be necessary right?

On an oscilloscope I can see the data changes on the falling edge, so sampling on the rising edge with no delay should be perfect I would think (?).

0 Kudos
Teacher eteam00
Teacher
8,479 Views
Registered: ‎07-21-2009

Re: How to deal with a clock input that stops/starts (Spartan-6)

Jump to solution

Oh, it sounds like you're not meeting input setup without the DCM -- was the DCM providing delay/phase shift? If it wasn't, then the DCM output would line up with the DCM input and you would still lose.

 

The data is SDR so I wasn't using a phase shift, it shouldn't be necessary right?

 

Reading this makes me cringe.  Setup and hold time (data input timing with respect to the register clock edge) must be observed equally for SDR (a single clock edge is used) and DDR (both clock edges are used) interfaces.  Agreed?

 

On an oscilloscope I can see the data changes on the falling edge, so sampling on the rising edge with no delay should be perfect I would think (?).

 

The only timing comparison which is important is inside the FPGA at the input registers.  Without knowing the clock frequency and the path delays from package pin to input register (for both clock and data), setup and hold time cannot be calculated or evaluated.

 

  • At very low clock frequencies, the internal delays will be insignificant, and timing should be safe.
  • At very high frequencies, the internal clock delay is enough to shift the clock edge to the point where data is switching, which will guarantee inconsistent and indeterminate behaviour.

-- 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.
0 Kudos
Participant watman
Participant
8,476 Views
Registered: ‎05-19-2010

Re: How to deal with a clock input that stops/starts (Spartan-6)

Jump to solution

Setup and hold time (data input timing with respect to the register clock edge) must be observed equally for SDR (a single clock edge is used) and DDR (both clock edges are used) interfaces.  Agreed?

 

Yes I agree, what I meant was that SDR data is already aligned with the rising edge of the clock in the middle of the data. So I thought that no additional alignment would be needed...

 

I replaced the PLL with an IBUFG and added a timing constraint, but now I am getting 2 timing errors which seem to be due to very high skew and I don't understand why:

 

 Paths for end point CAM_IN/DISP_SEL/data_B_b_6 (SLICE_X23Y103.C5), 31 paths
 --------------------------------------------------------------------------------
 Slack:                  -1.317ns (requirement - (data path - clock path skew + uncertainty))
   Source:               CAM_IN/CALC_GRADS/GRADCALC/GRAD_Y_4 (FF)
   Destination:          CAM_IN/DISP_SEL/data_B_b_6 (FF)
   Requirement:          12.500ns
   Data Path Delay:      4.580ns (Levels of Logic = 4)
   Clock Path Skew:      -9.202ns (4.261 - 13.463)
   Source Clock:         CAM_IN/CLK_1 rising at 0.000ns
   Destination Clock:    PCLK rising at 12.500ns

 

The clock goes to an IBUFG -> PCLK, and everything in CAM_IN uses PCLK.

In the map messages there is a warning which seems to be repeated for all the modules clocked by PCLK:

PhysDesignRules:372 - Gated clock. Clock net CAM_IN/CLK_1 is sourced by a combinatorial pin. This is not good design practice. Use the CE pin to control the loading of data into the flip-flop.

 

I don't know what this "combinatorial pin" is, the clock comes from a clock-capable pin straight to an IBUFG then to the clock input. I assume CLK_1 is the clock going into the CAM_IN module, but that is PCLK. Any ideas what might be going on?

0 Kudos
Teacher eteam00
Teacher
8,474 Views
Registered: ‎07-21-2009

Re: How to deal with a clock input that stops/starts (Spartan-6)

Jump to solution

The largest part of the problem is the 9nS or so of clock interconnect skew.

 

Are the data input registers located in the FPGA fabric, or in the IO blocks?

  • If they are in the IO blocks in a single IO bank, then use a BUFIO2 to buffer and distribute the input clock.
  • If they are in the main fabric logic, then use a BUFG to buffer and distribute the input clock.

An IBUFG is not a clock distribution buffer.  It is only a plain IBUF input buffer, with an additional constraint that it be located at a GCLK pin.  The output of an IBUFG (or IBUF) is a simple logic signal.  Either a BUFIO2 or BUFG will be needed to provide low-skew clock distribution.

 

-- 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.
Participant watman
Participant
8,471 Views
Registered: ‎05-19-2010

Re: How to deal with a clock input that stops/starts (Spartan-6)

Jump to solution

An IBUFG is not a clock distribution buffer.  It is only a plain IBUF input buffer, with an additional constraint that it be located at a GCLK pin.

 

Oh I see I misunderstood the function then, I thought it was the same as a BUFG but connected to an input pin.

Changing that fixed the clock skew, thanks for the information.

 

Daniel

0 Kudos
Visitor jwilkinson7
Visitor
5,431 Views
Registered: ‎11-20-2008

Re: How to deal with a clock input that stops/starts (Spartan-6)

Jump to solution

you said: "An IBUFG is not a clock distribution buffer.  It is only a plain IBUF input buffer, with an additional constraint that it be located at a GCLK pin.  The output of an IBUFG (or IBUF) is a simple logic signal.  Either a BUFIO2 or BUFG will be needed to provide low-skew clock distribution."

 

Really?  Are you sure?   That's now how I understood it either, and the docs seem to say it can drive global clk networks directly without an additional BUFG.  .

 

Here's a bit from the Virtex-5 LIbraries Guide for HDL Designs... (UG621, v 14.1)

 

IBUFG

Primitive: Dedicated Input Clock Buffer

 

The IBUFG is a dedicated input to the device which should be used to connect incoming clocks to the FPGA's global clock routing resources. The IBUFG provides dedicated connections to the DCM_SP and BUFG providing the minimum amount of clock delay and jitter to the device. The IBUFG input can only be driven by the global clock pins. The IBUFG output can drive CLKIN of a DCM_SP, BUFG, or your choice of logic.

 

The DCM_BASE section of that same doc lists just the options for what can drive to the CLKIN input of a DCM...

 

The source clock (CLKIN) input pin provides the source clock to the DCM. The CLKIN frequency must fall in the ranges specified in the Data Sheet for this architecture. The clock input signal comes from one of the following buffers:
• IBUFG - Global Clock Input Buffer. The DCM compensates for the clock input path when an IBUFG on the same edge (top or bottom) of the device as the DCM is used.
• BUFG/BUFGCTRL - Internal Global Clock Buffer. Any BUFGCTRL can drive any DCM in the device using the dedicated global routing. A BUFGCTRL can drive the DCM CLKIN pin when used to connect two DCM in series.
• IBUF - Input Buffer. When IBUF drives CLKIN input, the PAD to DCM input skew is not compensated and increased jitter can occur. This configuration is generally not recommended.

 

 

--
jeff wilkinson
jwilkinson@mail.com
0 Kudos
Visitor jwilkinson7
Visitor
5,429 Views
Registered: ‎11-20-2008

Re: How to deal with a clock input that stops/starts (Spartan-6)

Jump to solution

FWIW, yes, I quoted from the Virtex-5 doc, since that's what I'm using and have handy here...  hopefully the IBUFG's aren't that different in the Spartans...?

--
jeff wilkinson
jwilkinson@mail.com
0 Kudos
Teacher eteam00
Teacher
5,419 Views
Registered: ‎07-21-2009

Re: How to deal with a clock input that stops/starts (Spartan-6)

Jump to solution

Really?  Are you sure?

 

Yes.  The Xilinx documentation is my source, confirmed many times over in these forums.

 

...  the docs seem to say it can drive global clk networks directly without an additional BUFG.

 

No, they do not.  Read them more carefully.  This applies to Virtex and Spartan devices alike, they are no different in this aspect of their architectures.

 

-- 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.
0 Kudos
Historian
Historian
5,412 Views
Registered: ‎01-23-2009

Re: How to deal with a clock input that stops/starts (Spartan-6)

Jump to solution

it can drive global clk networks directly without an additional BUFG

 

No, it says

 

The IBUFG is a dedicated input to the device which should be used to connect incoming clocks to the FPGA's global clock routing resources

 

These are not the same thing. The IBUFG has a dedicated route (that other IBUFs don't have) to the global clocking resources. These include things like MMCM/DCM/PLLs and the clock buffers, like BUFG, BUFR, BUFIO. These latter buffers then, in turn, can clock the different clock networks within the FPGA.

 

Avrum

Highlighted
Visitor jwilkinson7
Visitor
5,397 Views
Registered: ‎11-20-2008

Re: How to deal with a clock input that stops/starts (Spartan-6)

Jump to solution

Hmm, I see.   That's useful to know. 

 

I'd recommend that the description there could use a sentence or two to make it explicitl6y clear that the IBUFG's can NOT drive global clk nets directly. 

 

Obviously at least two of us didn't get that important detail from reading the current descriptions, and probably others would make the same mistake.  

 

Maybe one of you Xilinx guys can pass that on to the documentation folk. (for all the families where it applies)

 

thanks for the clarification.

jeff

--
jeff wilkinson
jwilkinson@mail.com
0 Kudos