Monday, April 11, 2011

Running Rings around the Oscillators

Working from home today because my car battery is dead. :(

Today, SUCCESS at building a fast ring oscillator on the DE2 board (in VHDL). The speed of course depends on a lot of things (placement, routing, temperature), and so differs quite a bit between runs, but the fastest speed I have seen so far is 666 MHz.

I measured the frequency by building a fast counter with a carry-save architecture, which can keep up with the ring oscillator. Bit 6 of the counter goes 128x slower than the underlying clock and was measured at up to ~5.2 MHz using my cheapo home oscilloscope (which in theory can measure signals up to 25 MHz but which in practice has trouble getting above 10 or so, due I think to crappy probes.)

To get this working, I had to learn how to set the KEEP attribute in VHDL, to keep it from compiling away my ring oscillators and clock fanout buffers.

The Stratix II should be able to go even faster, I'm guessing pretty close to 1 GHz at least.

If I use dual-edge-triggered flip-flops in my counter (I should try that soon), we could count half-cycles, and so effectively measure time at 2 GHz (every 0.5 nanosecond).

So what I'm thinking now is that we could just directly sample the comparator outputs at the frequency of one ring oscillator to get nanosecond time resolution, without even having to worry about fine-tuning two different ring oscillators to be close together in frequency, and then counting cycles until the phase crossover to get sub-cycle resolution, like Sachin has been trying to do. This seems like it would be a lot easier and more straightforward.

The ring oscillator frequency can be easily calibrated against the time sync signal by simply latching the counter value when the time sync goes high, just like how we are registering the OCXO against the GPS PPS signal now.

So basically, what I'm thinking now is, we should completely redo Sachin's Quartus design with a totally different architecture. Maybe even just use the serial port for communication, like we were planning to do originally (and then we can use Wi-Fi instead of Wireless USB, and get better range). However, this might mean we have to redo all the LabView interface stuff (assuming we still want to use LabView).

If we can, also get a Nios II core on there, so that we can manage the I/O and high-level functionality in C, instead of having to do custom gelware for that part.

We do still need to interface with the DACs to set the comparator thresholds, but that shouldn't be too difficult.

Here's a video of today's test:

No comments:

Post a Comment