Ring Oscillator -> counter differences
in [FPGA]
|
Prev: EMC discussion
Next: USB 3.0 implementation on FPGA
From: Jason Thibodeau on 25 Mar 2010 12:18 On 03/25/2010 01:20 AM, -jg wrote: > On Mar 25, 1:41 pm, Jason Thibodeau<jason.p.thibod...(a)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
From: Thomas Stanka on 26 Mar 2010 11:15 On 25 Mrz., 17:18, Jason Thibodeau <jason.p.thibod...(a)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
From: Jason Thibodeau on 26 Mar 2010 12:04 On 03/26/2010 11:15 AM, Thomas Stanka wrote: > On 25 Mrz., 17:18, Jason Thibodeau<jason.p.thibod...(a)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
From: Antti on 26 Mar 2010 14:12 On Mar 26, 6:04 pm, Jason Thibodeau <jason.p.thibod...(a)gmail.com> wrote: > On 03/26/2010 11:15 AM, Thomas Stanka wrote: > > > > > > > On 25 Mrz., 17:18, Jason Thibodeau<jason.p.thibod...(a)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 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
From: glen herrmannsfeldt on 26 Mar 2010 15:26
Jason Thibodeau <jason.p.thibodeau(a)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 |