Programmable clock, FPGA PLLs, and Actel PLL Core

"Jim Granville" <no.spam@designtools.co.nz> wrote in message
news:puWWb.23870$ws.2959636@news02.tsnz.net...
Austin Lesea wrote:
....
How many people need GHz divide by capability?

Frequency synthesisers would be one, and precise time/phase measurements
could be another. Precise time is a little more difficult, as you
need to capture, but this would, of course, clock on both edges :)
....
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.
 
Marius Vollmer wrote:
Jim Granville <no.spam@designtools.co.nz> writes:


Just to give you a target, to fully challenge the grey matter, :)
this company offers 10 digits/second ($2K), and 12 digits/second
models($3K).


Could you explain what "10 digits/second" means? I have no idea...
Thanks!
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
 
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
 
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
 
Jim Granville <no.spam@designtools.co.nz> writes:

Marius Vollmer wrote:

Could you explain what "10 digits/second" means? I have no idea...
Thanks!

It's a figure of merit for reciprocal counters, [...]
Thanks a lot!

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

Welcome to EDABoard.com

Sponsor

Back
Top