Spartan® Family FPGAs

[watman]

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

[eteam00 · Accepted 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

[watman]

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.

[eteam00]

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

[watman]

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

[eteam00]

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

[watman]

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

[bassman59]

---

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. 

[watman]

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

[eteam00]

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