32 bit 1GHz counter?

Do you really need to count that fast, or could you count the period of 'n' input cycles? A 50MHz counter is a lot easier (n=20).

Also, 32 bits implies a maximum time of almost 1/4 second at 1GHz.

Xilinx and their free Webpack is one way (get an evaluation board with the chip and other stuff on it). I've had little trouble putting together things with VHDL. One of my guys has done Cordics, huge filters and all sorts of other stuff and he's run into certain limitations, but for a simple counter and some stuff to get the data out, Robert's your uncle.

There might be some laser TOF ASICs that do something like this.

Best regards, Spehro Pefhany

Make that 4 seconds..

Best regards, Spehro Pefhany

-- "it's the network..." "The Journey is the reward" snipped-for-privacy@interlog.com Info for manufacturers:

Four of these or similar ones maybe?

Another trick is to use several slower counters but stagger them in phase. Then you could pour it into an FPGA but since you aren't familiar with those you'd have to have someone around that can do that for you.

I believe Xilinx has done Johnson counters at better than 1GHz. Not easy, to be sure but since they can do significantly higher than that on the I/O, it shouldn't be impossible for mere mortals either.

"The Journey is the reward"

eff.com

I very much like the idea of measuring the period of n input cycles to return to a more sane clock frequency. I'll run it past my client this week, but I don't know why he wouldn't agree.

Thanks for that.

And thanks for the Xilinx lead. I'll be looking at that in the morning.

Check out the Motorola/ON-semiconductor ECLinPS range. The first generation parts were good for more than 500MHz in a in a wide synchronous counter, and the current generation is appreciably faster.

Getting a wide synchronous counter to run reliably at the top of its specified frequency range can take some fiddling. I never actually used delay lines to slightly delay the "synchronous" clock fed to the counter chips looking after the more significant bits, but that kind of trickery can sometimes be useful. Tolerancing the design for worst case propagation delays and set-up times can get interesting.

-- Bill Sloman, Nijmegen

-- Bill Sloman, Nijmegen

The 1 GHz is not very fast; there are discrete ripple counters for the frequencies over 10 GHz. Look prescaler ICs for frequency synthesisers.

However, why can't you measure over 10 periods instead of one? The required clock would be 10 times slower for the same accuracy.

Vladimir Vassilevsky DSP and Mixed Signal Design Consultant

I probably can. The client came to me with the 1GHz clock idea, and for whatever reason, it just stuck in my head. Thanks to you and Spehro for unsticking it. In reality, I could probably prescale the input by 2048 or even 4096 and still meet the client's requirements, and then be measuring the period of a KHz range signal which is a WHOLE lot easier.

Still, I will look at the Xilinx Webpack as an exercise in doing the counter and registers.

Universal counters have continuously variable gate widths--they just count input and reference pulses, and divide one count by the other. Usually they reclock the gate by the reference, so they get exactly an integer number of cycles. There are lots of analogue range-extension tricks for this, as well, as used in digital delay generators. There's a fair amount about that in the archives of this group.

Cheers

Phil Hobbs

Getting a precise 1GHz clock takes a little work.

Fifteen years ago I was planning on buying an off-the-shelf packaged crystal oscillator - using a thinned crystal - that ran at 500MHz and offered sub-picosecond jitter and tolerably good frequency stability.

If you want real frequency stability, you've got to phase-lock your

John Larkin likes dielectric resonantors in that frequency range.

I've not yet had a chance to play with one, and I've go no idea whether you can pull the resonant frequency at all, let alone far enough to use them as part of a voltage-controlled osicllator in a phase-locked loop.

-- Bill Sloman, Nijmegen

You can prescale with this upto 2GHz, then count with a 100MHz micro.

If you intend to latch the whole counter, you need to use a synchronous counter, thus the whole counter has to operate at the full clock frequency.

Pre-scaler + slow counter would be a ripple counter and more and less useless for count capture.

If you can get a clean 500 MHz source, why not use a 2x (push-pull) or

How about using a slower counter and handling the +/-1 digit issue with an analog integrator at the beginning and end of the pulse and use an ADC to the get the fractional bits ?

Frequency multipliers do tend to inject jitter. You used to be able to buy tolerably high-Q magnetically tuned YAG-based oscillators that ran at frequencies in the 1 to 10GHz range. They were bulky and expensive, but I had a couple of schemes where they would have been very handy. Sadly, nobody seems to sell them any more.

-- Bill Sloman, Nijmegen

You can still not do continues capture, but if is OK to do start/stop capture and measure only every other cycle, this should be doable.

The signal to be measured needs to go through a divide by two flip-flop to generate prescaler enable pulses that are as long as the cycle time. With the 8 bit ECL counter and some 16 bit internal uC capture counter should be enough to measure every other cycle. Maximum count with 1 MHz signal and 1 GHz clock is one million, so 20 bits total is enough.

A delayed version of the enable pulse should be delayed and used as an interrupt signal for the uC. The uC should then read the internal 16 bit counter and the 8 bit ECL counter, and reset both. The total ISR latency for the 4 MHz signal should be less than 250 ns.

a écrit dans le message de news: snipped-for-privacy@4ax.com...

That's exactly what I was going to propose... As an alternative you can also use a slower counter (say 100MHz) and manage the missing resolution with a

Friendly yours,

Using a ripple counter is practical, provided you can stop it counting and wait for the last count to ripple through before you read the content. Defining the accumulate time, the settling time before read and the reset time after read involves another messy counter, most of which you can bury in a programmable device. Synchronous counters are tidier, albeit not as fast.

-- Bill Sloman, Nijmegen