Ring Oscillator -> counter differences
in [FPGA]
|
Prev: EMC discussion
Next: USB 3.0 implementation on FPGA
From: Chris Maryan on 26 Mar 2010 15:28 On Mar 26, 12: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- Hide quoted text - > > - Show quoted text - The rule of thumb (at least for brand X FPGAs) is 500ps of propagation delay per LUT. Assuming your ring buffer is actually getting generated as you expect (and synthesis isn't reducing it to a single LUT not gate), not including routing, I'd guess you're looking at ~400MHz as an upper bound. Depending on your FPGA, this may or may not be acceptable fundamentally in the fabric. Moreover, your counter has to run at least this fast. Chris
From: John_H on 26 Mar 2010 16:54 On Mar 26, 3:26 pm, glen herrmannsfeldt <g...(a)ugcs.caltech.edu> wrote: > > >> 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. There's a strong possibility the I/O won't have the bandwidth to pass the full signal. A short back and forth for a small pulse might get lost in the I/O.
From: Gabor on 26 Mar 2010 17:09 On Mar 26, 4:54 pm, John_H <newsgr...(a)johnhandwork.com> wrote: > On Mar 26, 3:26 pm, glen herrmannsfeldt <g...(a)ugcs.caltech.edu> wrote: > > > > > >> 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. > > There's a strong possibility the I/O won't have the bandwidth to pass > the full signal. A short back and forth for a small pulse might get > lost in the I/O. Normally a ring with a single enable input wouldn't behave that way. The ring consists of one NAND (or NOR) gate and the rest of the elements are just inverters. When the ring is disabled all elements find a static state and the gate element injects just one edge into the ring, assuming the enable signal is not glitchy itself.
From: -jg on 26 Mar 2010 18:41 On Mar 27, 9:09 am, Gabor <ga...(a)alacron.com> wrote: > > Normally a ring with a single enable input wouldn't behave that > way. The ring consists of one NAND (or NOR) gate and the > rest of the elements are just inverters. When the ring is > disabled all elements find a static state and the gate > element injects just one edge into the ring, assuming the > enable signal is not glitchy itself. Correct, you should use an Enable to ensure correct 'start' of a Ring oscillator. Even tho you might think a Tphl/tplh shift should remove narrower pulses, that's only true if the path is monotonic, and local LCR effects mean there can be 'stable' regions. You can also code a Ring oscillator, as alternating inverters, and nand/nor elements, and that can sometime help persuade to tools to not optimize things away... The best way to test Osc stability is to probe a Divided pin, NOT the raw Osc, as in most cases, it will not make it out in any useful way. A divided pin easily shows errant effects, and a scope is important. A ring oscillator will locally heat, so for best stability use a Power- Up Enable and gate the divider, not the oscillator itself. -jg
From: Symon on 26 Mar 2010 21:34
On 3/26/2010 3:15 PM, Thomas Stanka wrote: > On 25 Mrz., 17:18, Jason Thibodeau<jason.p.thibod...(a)gmail.com> > Second problem, how do you avoid having more than one level > transaction in the oscillation ring? > (e.g. 01010). > > bye Thomas > > Isn't the 01010 thing gonna resolve itself PDQ? It must be an unstable state. Syms. |