ring oscillator calibration

I'm trying to frequency match a number of ring oscillators placed over a Xilinx FPGA. The intention is to use the oscillators as thermometers.

Each ring oscillator is a chain of 7 LUTs configured as NOT gates. The problem is that the frequency output varies by as much as 10% (e.g 150 -

165Mhz). While it is not absolutely essential to match the frequencies, I would like to know the source of this difference. Could any of you throw some light on this? Thanks.

The LUTs have been placed using RLOCs, so the oscillators have the same logic structure. Is it possible that the routing method is different? If so, is it possible to constrain them to be the same?

Thanks, Siva

--------------------------- "In the end, everything is a gag." - Charlie Chaplin

Reply to
Siva Velusamy
Loading thread data ...

Siva, you are getting a 7 ns delay from 7 concatenated inverters, about 1 ns per LUT. A 10% difference means about 100 ps. I am not so surprised.You might look at the routing details. Another approach is using the carry chain. It has less "undesirable freedom" of routing, and much finer granularity. So you need more stages, but they involve no discretionary routing, and are automatically floorplanned to be vertical. The only "trouble" could come from the return path. Let me know if this is any better. Peter Alfke, Xilinx

Reply to
Peter Alfke

These will also be sensitive to Vcc, which may change over the chip depending on what else is going on in that area. You could see the effect of this by varying VCC externally, to get some sense of how much this effects frequency.

There could be differences in the speed of the LUTs, but routing is also a major contributor, including the path that leaves the ring oscillator, and goes to whatever you are using to measure frequency, as this must load one of the nodes in the oscillator.

If you are just relying on the normal tool flow for routing, this prpbably is a major part of the variability.

You can hand route the design in the FPGA Editor, where you can make detailed routing decissions, and when you make multiple oscillators, you can manually route them identically. Once you have done this, there is a facility in the FPGA editor to save the routing details as a constraint. This is called a Directed Routing Constraint. This can be placed into your UCF file and providing you dont change the logic of the oscillators, and their final placement (RLOCs + RLOC_ORIGIN), these constraints will give consistent results. You will find it under the Tools menu list, I believe. Read and enjoy.

Also a search of the FPGA-FAQ archive

formatting link
with "directed" turns up lots of articles.

Philip

=================== Philip Freidin snipped-for-privacy@fpga-faq.com Host for

formatting link

Reply to
Philip Freidin

Peter's suggestion is probably the best, but since you are this far under the bonnet, I did see some interesting numbers in an Altera white paper:

formatting link

Here, Altera identify and specify different delays for the various paths into the LUT (Fig 2), whilst Xilinx use a nominal, fixed time. From this, not all LUT paths are equal, and there seems a large variance in delays ( appx 5:1 ). It is not clear if Xilinx have 'no skews', or if their software does not yet support this, so there is no point in them specfying any differences.

You should also start your Ring Osc's from a forced/reset state ( ie use NAND/NOR chain, rather than NOT )

-jg

Reply to
Jim Granville

Why do you have multiple oscillators? Are you trying to take the temperature over several different parts of the die? I would think that the entire die would have the same temperature.

I like Peter's carry chain idea a lot.

-Kevin

Reply to
Kevin Neilson

Thanks everyone for the suggestions.

The problem was clearly due to difference in routing. Using FPGA Editor's directed routing, I obtained the routing information for one particular placement, and simply copied them over for all other instances only substituting the correct net names. Now all the frequencies are in a 2% range, far better than the 10% earlier.

Peter - Could you explain a bit more about how to use the carry chain? From the docs I could see that the carry chain goes up vertically through the slices, so I understand the part about automatic floorplanning - but how exactly should I configure them? There is no local connection between Cin and the CI/DI inputs. So I cannot directly send the carry signal as the select for the subsequent mux. Also, for this application I don't have any target frequency - I only need a predictable response with variation in temperature. So I probably don't need more stages.

Kevin - Yes, I am trying to measure the temperature over different parts of the die. Specifically I am interested in the temperature gradient. There have already been papers (in FPGA 04 for instance) that have shown that a gradient exists.

Siva

--------------------------- ">

Reply to
Siva Velusamy

: Thanks everyone for the suggestions.

: The problem was clearly due to difference in routing. Using FPGA Editor's : directed routing, I obtained the routing information for one particular : placement, and simply copied them over for all other instances only : substituting the correct net names. Now all the frequencies are in a 2% : range, far better than the 10% earlier.

: Peter - Could you explain a bit more about how to use the carry chain? : From the docs I could see that the carry chain goes up vertically through : the slices, so I understand the part about automatic floorplanning - but : how exactly should I configure them? There is no local connection between : Cin and the CI/DI inputs. So I cannot directly send the carry signal as : the select for the subsequent mux. Also, for this application I don't have : any target frequency - I only need a predictable response with variation : in temperature. So I probably don't need more stages.

: Kevin - Yes, I am trying to measure the temperature over different parts : of the die. Specifically I am interested in the temperature gradient. : There have already been papers (in FPGA 04 for instance) that have shown : that a gradient exists.

Well,

if you are interested into the thermal behaviour, you probably don't want to run the stages of the ring oscillator at nearly full gate speed, as this will contribute to (local) heating...

Bye

--
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
 Click to see the full signature
Reply to
Uwe Bonnes

Hi Uwe,

How can he control the speed at which the individual gates are switching? Are you suggesting he should make the inverter chain long to prevent the inverters from switching often or something else?

Thanks, Ljubisa

Reply to
Ljubisa Bajic

Ljubisa Bajic wrote: : Hi Uwe,

: How can he control the speed at which the individual gates are : switching? Are you suggesting he should make the inverter chain long : to prevent the inverters from switching often or something else?

The longer the chain, the less switching per inverter per time. Obvious he can control the spped of a single inverter...

Bye

--
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
 Click to see the full signature
Reply to
Uwe Bonnes

[can't]

The effect may be more subtle than that. Switching power is Sigma(Fn x Cn) x Vcc^2, Fn reduces in proportion with chain count, but the Cn increases, so ignoring buffering effects the ring osc itself will be nominally constant power. The power density will decrease, as that power is spread over more die, and it is probably also a good idea to gate/enable the oscillator, to further minimise the self-heating effects.

That effect could be used to actually measure the local hot-spot effects caused by low node counts, running very fast.

The power to measure the Freq will be another cost, and again that will favour lower frequencies - until you consider gating, and obtaining a fixed resolution / unit time. Here, higher freqs use more power, but allow lower % GATE times for a given resolution/ms.

-jg

Reply to
Jim Granville

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.