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
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
> From: Siva Velusamy <[email protected]>
> Organization: University of Virginia
> Newsgroups: comp.arch.fpga
> Date: Wed, 25 Aug 2004 14:27:02 -0400
> Subject: 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
On Wed, 25 Aug 2004 14:27:02 -0400, Siva Velusamy <[email protected]> wrote:
>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.
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.
>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.
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.
>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?
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.
Peter Alfke wrote:
> 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
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 )
"Siva Velusamy" <[email protected]> wrote in message
news:[email protected] rginia.EDU...
>
> 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.
>
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.
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
---------------------------
"In the end, everything is a gag."
- Charlie Chaplin
On Thu, 26 Aug 2004, Kevin Neilson wrote:
>
> "Siva Velusamy" <[email protected]> wrote in message
> news:[email protected] rginia.EDU...
> >
> > 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.
> >
> 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
>
>
>
: 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...
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
Uwe Bonnes <[email protected]> wrote in message news:<cgk5oq$m6m$[email protected]>...
> Siva Velusamy <[email protected]> wrote:
>
> : 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
: 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...
Uwe Bonnes wrote:
> Ljubisa Bajic <[email protected]> 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...
[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