Programmable clock, FPGA PLLs, and Actel PLL Core

...

... For much of the time precision, latching the value of the DCM's delay line could give extreme input resolution (resolution of a single tap though the accuracy would be slightly worse than one tap). I'd love to get down to ~100ps accuracy for sampling some very low frequency signals. If I could provide multiple phase-shifted outputs based on multiple phase-sampled inputs, I'd be in FPGA heaven. It seems like throwing a SERDES at a signal that toggles well under 100MHz is overkill especially when we need the low cost parts. For now, it's a matter of sampling on several phases to get a

4x or 8x the master clock resolution. Adequate, perhaps, but not awe-inspiring.
Reply to
John_H
Loading thread data ...

It's a figure of merit for reciprocal counters, and you can work backards to an effective timebase, and resolution. Where it is less clear is if a reading of 99.999.999 in 1 second would be counted as the more correct 8 digits/sec, or nudged to

100.000.000 and called 9 digits/sec. Since it's a marketing term, we should assume the latter :)

If a reciprocal counter can read 100KHz as 100,000.000Hz in one second, that's a 1 milli Hz LSB, and it infers a 100MHz/10ns timebase. So 8-9 digits/second is 100MHz/10ns technology then 9-10 digits/second is 1GHz/1ns and 11-12 digits is 100GHz/10ps.

You can also get a reality check on those inferred timebase values, by the single shot time precision. The Agilent models above spec 500ps and 150ps, and the better TTH model I found specs 25ps. These represent the cutting edge, but with some gymnastics, a FPGA should be able to resolve to the smallest discrete time, which I think was 40ps in Spartan II - anyone know the SDT for Spartan 3?

Control of edges to the same LSB should also be possible in theory, but would depend on the HW and SW support to do so.

-jg

Reply to
Jim Granville

sounds reasonable. The PLL in an FPGA might not be as flexible, but it's certainly a more integrated solution. I don't want to give out the details of my design, but I'm using a regular PLL, so you could actually use one on your board. ICS seems to have lots of product, you could look at that too. Some PLLs just require a few IOs or jumpers to configure the frequency.

As a side not, my design has an EEPROM version, so you wouldn't need an I2C interface on the FPGA. You could use a 3 pins connector on your board, and the external I2C board can be used to predefine the frequency in the EEPROM. Then the PLL will start at that frequency at next power-up, no IOs are required on the FPGA.

About the newsgroup, why don't you use the news server from your ISP? my posts appear almost instantly - at least looks like it on my ISP's server, I'm not sure how the posts get distributed through other servers. Jean

Reply to
Jean Nicolle

I wonder if even "serious" frequency counters, with single-shot time resolutions in the 10ps range, could profit from FPGA implementations. What if one were to simply distribute the incoming edge to thousands of flops over routes with various delays, then derive the incoming time from the resulting thermometer-encoded bit vector?

The routing delays aren't known to such high precision, of course, but one could characterize the whole circuit once it's placed and routed: slew an input test signal over some range like 0--5 ns (created perhaps with an external phase microstepper chip), and watch when the bits flip. A random collection of 5000 routes would probably cover the clock interval with pretty good resolution.

Could do this self-calibration every so often to control temperature variations. Or ovenize the FPGA.

Cheers, Peter Monta

Reply to
Peter Monta

Thanks a lot!

--
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405
Reply to
Marius Vollmer

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.