Ring Oscillator -> counter differences

Jason Thibodeau wrote:
> I have a 5 inverter ring oscillator, with its output being fed to a 
> counter. This is run in a continuous process, that is to say it is run 
> at 'gate speed', it is not clocked. I have an enable signal to activate 
> the oscillator, which currently runs for 100ms. I can then clear the 
> counter, and run it again, for 100ms.
> 
> When I run this on my spartan 3e, I get different values for each and 
> every run. I would assume these values would stay the same. What 
> explanation is there for their differences? Power fluctuations?
> 
> Any insight would be great. This is just an experiment, so no practical 
> use.

Ring oscillators are VERY sensitive devices.
The same old trio applies : power variations,
process variations, temperature.
I would expect measurements to vary by 50% or more...

I'm even sure that the frequency will change
by putting your fingers on the chip's surface,
due to capacitive effects.

Now, i'll let the specialists speak^Wwrite ;-)

> Thanks.
yg

-- 
http://ygdes.com / http://yasep.org

I have a 5 inverter ring oscillator, with its output being fed to a 
counter. This is run in a continuous process, that is to say it is run 
at 'gate speed', it is not clocked. I have an enable signal to activate 
the oscillator, which currently runs for 100ms. I can then clear the 
counter, and run it again, for 100ms.

When I run this on my spartan 3e, I get different values for each and 
every run. I would assume these values would stay the same. What 
explanation is there for their differences? Power fluctuations?

Any insight would be great. This is just an experiment, so no practical use.

Thanks.
-- 
Jason Thibodeau

Jason Thibodeau <jason.p.thibodeau@gmail.com> wrote:

> I have a 5 inverter ring oscillator, with its output being fed to a 
> counter. This is run in a continuous process, that is to say it is run 
> at 'gate speed', it is not clocked. I have an enable signal to activate 
> the oscillator, which currently runs for 100ms. I can then clear the 
> counter, and run it again, for 100ms.
 
> When I run this on my spartan 3e, I get different values for each and 
> every run. I would assume these values would stay the same. What 
> explanation is there for their differences? Power fluctuations?

How big are the counts?  If it runs at a few hundred megahertz, 
which might be possible, your counts are on the orders of tens
of millions.  If it changes by 1 part in 1e7 then the count will
be different.  Do this a few hundred times and graph the distribution.
Also compute mean and standard deviation.

-- glen 

On Mar 24, 9:41=A0pm, Jason Thibodeau <jason.p.thibod...@gmail.com>
wrote:
> I have a 5 inverter ring oscillator, with its output being fed to a
> counter. This is run in a continuous process, that is to say it is run
> at 'gate speed', it is not clocked. I have an enable signal to activate
> the oscillator, which currently runs for 100ms. I can then clear the
> counter, and run it again, for 100ms.
>
> When I run this on my spartan 3e, I get different values for each and
> every run. I would assume these values would stay the same. What
> explanation is there for their differences? Power fluctuations?
>
> Any insight would be great. This is just an experiment, so no practical u=
se.
>
> Thanks.
> --
> Jason Thibodeau

I'm surprised you're getting such a wide variation as long as your
enable guarantees one and only one edge is moving through the ring.
Start with a double-check there.  It might take some time for a second
edge to go away.

How do you have a counter that's not clocked?  I used a 3-bit Gray
count on the first stage of my 8-LUT ring, just in case, and my delays
were pretty stable.  The values I got from the single-CLB ring were
around 450ps average (having spent some time to make sure the 8 inter-
LUT routing delays were lowest overall).  The variation was
surprisingly only about 10% with freeze spray (and heat gun?); I
expected a bit more.  Interesting item: the delay measurement could
turn the FPGA into a switch sensor: pressing the eraser tip of a
pencil against the top of the package produced a noticeable change in
the delay that came back when released, a change much larger than the
natural variation.

I used a Spartan3E starter kit and updated the LCD at probably 100ms
intervals (it's been a while) to deliver my delay values visually.

On Mar 25, 1:41=A0pm, Jason Thibodeau <jason.p.thibod...@gmail.com>
wrote:
>
> When I run this on my spartan 3e, I get different values for each and
> every run. I would assume these values would stay the same. What
> explanation is there for their differences? Power fluctuations?

??  Err ?
'stay the same' - did you really mean what you wrote ?
Of course they will change.
 Even an Atomic clock varies...


 Smarter would be to post numbers on how much they changed, as
'different values' has no useful information.

 A ring oscillator, is a Thermometer, and a Voltmeter,
and a process-quantifier - all coming out in one number.

-jg

On 03/25/2010 01:20 AM, -jg wrote:
> On Mar 25, 1:41 pm, Jason Thibodeau<jason.p.thibod...@gmail.com>
> wrote:
>>
>> When I run this on my spartan 3e, I get different values for each and
>> every run. I would assume these values would stay the same. What
>> explanation is there for their differences? Power fluctuations?
>
> ??  Err ?
> 'stay the same' - did you really mean what you wrote ?
> Of course they will change.
>   Even an Atomic clock varies...
>
>
>   Smarter would be to post numbers on how much they changed, as
> 'different values' has no useful information.
>
>   A ring oscillator, is a Thermometer, and a Voltmeter,
> and a process-quantifier - all coming out in one number.
>
> -jg
>
>
>

Thinking about it further, I suppose I didn't mean stay exactly the 
same. I did expect differences, and I guess I confirm with you all that 
what I am seeing is normal. I have typically less than 5% fluctuations 
between runs.

Thanks for all your input. It gives me a bit to think about.

-- 
Jason Thibodeau

On 25 Mrz., 17:18, Jason Thibodeau <jason.p.thibod...@gmail.com>
wrote:
> Thinking about it further, I suppose I didn't mean stay exactly the
> same. I did expect differences, and I guess I confirm with you all that
> what I am seeing is normal. I have typically less than 5% fluctuations
> between runs.
>
> Thanks for all your input. It gives me a bit to think about.

The problem is, that your frequency might be very fast with 5 stage
ring oscillator. Expect the clock frequency to equal the gate delay of
not more than 5 gates :). Your counter will experience very fast clock
cycles which lead to results with no meaning if your counter is not
designed to work with that fast clock frequency.
Second problem, how do you avoid having more than one level
transaction in the oscillation ring?
(e.g. 01010).

bye Thomas

On 03/26/2010 11:15 AM, Thomas Stanka wrote:
> On 25 Mrz., 17:18, Jason Thibodeau<jason.p.thibod...@gmail.com>
> wrote:
>> Thinking about it further, I suppose I didn't mean stay exactly the
>> same. I did expect differences, and I guess I confirm with you all that
>> what I am seeing is normal. I have typically less than 5% fluctuations
>> between runs.
>>
>> Thanks for all your input. It gives me a bit to think about.
>
> The problem is, that your frequency might be very fast with 5 stage
> ring oscillator. Expect the clock frequency to equal the gate delay of
> not more than 5 gates :). Your counter will experience very fast clock
> cycles which lead to results with no meaning if your counter is not
> designed to work with that fast clock frequency.
> Second problem, how do you avoid having more than one level
> transaction in the oscillation ring?
> (e.g. 01010).
>
> bye Thomas
>
>

Yes, I was discussing that with a colleague yesterday. The oscillator 
may be too fast for the counter to read it accurately. I'm using a the 
output oscillator signal to clock the counter, however the oscillation 
frequency may be too fast to meet the required set-up and hold time for 
the counter. I'm investigating that now.

-- 
Jason Thibodeau

On Mar 26, 6:04=A0pm, Jason Thibodeau <jason.p.thibod...@gmail.com>
wrote:
> On 03/26/2010 11:15 AM, Thomas Stanka wrote:
>
>
>
>
>
> > On 25 Mrz., 17:18, Jason Thibodeau<jason.p.thibod...@gmail.com>
> > wrote:
> >> Thinking about it further, I suppose I didn't mean stay exactly the
> >> same. I did expect differences, and I guess I confirm with you all tha=
t
> >> what I am seeing is normal. I have typically less than 5% fluctuations
> >> between runs.
>
> >> Thanks for all your input. It gives me a bit to think about.
>
> > The problem is, that your frequency might be very fast with 5 stage
> > ring oscillator. Expect the clock frequency to equal the gate delay of
> > not more than 5 gates :). Your counter will experience very fast clock
> > cycles which lead to results with no meaning if your counter is not
> > designed to work with that fast clock frequency.
> > Second problem, how do you avoid having more than one level
> > transaction in the oscillation ring?
> > (e.g. 01010).
>
> > bye Thomas
>
> Yes, I was discussing that with a colleague yesterday. The oscillator
> may be too fast for the counter to read it accurately. I'm using a the
> output oscillator signal to clock the counter, however the oscillation
> frequency may be too fast to meet the required set-up and hold time for
> the counter. I'm investigating that now.
>
> --
> Jason Thibodeau

it depend the architecture and routing
its a good idea to run the ring oscillator to single flip flop that
divides by 2
the output of that FF is more likely in the range that is ok to use
in the same FPGA as "system clock"

the plain ring oscillator may run too fast

Antti

Jason Thibodeau <jason.p.thibodeau@gmail.com> wrote:
> On 03/26/2010 11:15 AM, Thomas Stanka wrote:
(snip)

>> The problem is, that your frequency might be very fast with 5 stage
>> ring oscillator. Expect the clock frequency to equal the gate delay of
>> not more than 5 gates :). Your counter will experience very fast clock
>> cycles which lead to results with no meaning if your counter is not
>> designed to work with that fast clock frequency.

With routing delay being one of the slower parts of newer FPGAs
that doesn't seem so likely, unless...

>> Second problem, how do you avoid having more than one level
>> transaction in the oscillation ring?
>> (e.g. 01010).

That would speed up the count.  If you can route to an output
pin without changing the oscillator too much, then look at it
on a scope.
 
> Yes, I was discussing that with a colleague yesterday. The oscillator 
> may be too fast for the counter to read it accurately. I'm using a the 
> output oscillator signal to clock the counter, however the oscillation 
> frequency may be too fast to meet the required set-up and hold time for 
> the counter. I'm investigating that now.

It would be best to use the built-in clock distribution.

Otherwise, a ripple counter (from the 7493 days) should avoid
clock skew problems.  Another idea is to use a gray code counter.
I can see cases where clock skew on a very fast clock would give
strange results, but the OP never actually posted any counts.

To use a ripple counter, one would have to gate the clock, and
stop it long enough to read out the result.  If you use one
input to all five LUTs as a gate, that might make it more
likely to start in the desired state.  (And also might avoid
the optimizer removing inverters from the loops.)

-- glen