equivalent time sampling

I am designing a data aqu system using an fpga and adc sampling at 250MHz.
I want to use equivalent time sampling to increase the sampling rate to a
few GHz for repetative signals. I am not sure how to go about implementing
it though.

Any info would be welcome, thanks.

Jon

"maxascent" <maxascent@yahoo.co.uk> wrote in message 
news:kYydnaQMQMIAzmveRVn_vQ@giganews.com...
>I am designing a data aqu system using an fpga and adc sampling at 250MHz.
> I want to use equivalent time sampling to increase the sampling rate to a
> few GHz for repetative signals. I am not sure how to go about implementing
> it though.
>
> Any info would be welcome, thanks.
>
> Jon

Are the aquisition triggers deterministic?  You have different requirements 
for a general purpose piece of test equipment versus an eye-diagram 
analyzer.

A general purpose piece of test equipment would tend to continuously acquire 
data and decide which "bins" to put the samples in based on where the 
trigger actually occurs within the acquisition clock period.  This provides 
the ability to "bin" as precisely as one can determine where in the period 
the trigger occurs.

A dedicated piece of equipment with known trigger points such as a telecom 
analyzer can slave the sampling clock to the waveform being sampled and 
"force" the alignment relative to the sample clock period (or conversely 
align the sample clock to the bins).  PLLs and DDS work beautifully here.

So - do you want general purpose?  Do you just want data 20 ns after the 
trigger and later only?  Do you want large pretriggers?

I've seen equivalent time equipment (no real time permitted) where the 
samples were 1 point per trigger with the data 10 ns or more after the 
trigger.  In this case, the single sample event could be delayed from the 
trigger event precisely on a point-by-point basis.  Since the trigger is 
usually the point of interest, that test equipment used a high fidelity 
delay line to sample the delayed channel a precise delay after the trigger 
allowing a small pre-trigger.

There are many ways to skin this cat.  Engineering tradeoffs can't yet be 
made with the information supplied. 

The system I am designing is a pc scope. I guess I will know the trigger
point. What I dont really understand is how you can generate precise
offsets from the trigger if you want to sample in the GHz region as you
are talking about picosecond values. I guess I dont fully understand the
procedure

Jon

>"maxascent" <maxascent@yahoo.co.uk> wrote in message 
>news:kYydnaQMQMIAzmveRVn_vQ@giganews.com...
>>I am designing a data aqu system using an fpga and adc sampling at
250MHz.
>> I want to use equivalent time sampling to increase the sampling rate to
a
>> few GHz for repetative signals. I am not sure how to go about
implementing
>> it though.
>>
>> Any info would be welcome, thanks.
>>
>> Jon
>
>Are the aquisition triggers deterministic?  You have different
requirements 
>for a general purpose piece of test equipment versus an eye-diagram 
>analyzer.
>
>A general purpose piece of test equipment would tend to continuously
acquire 
>data and decide which "bins" to put the samples in based on where the 
>trigger actually occurs within the acquisition clock period.  This
provides 
>the ability to "bin" as precisely as one can determine where in the
period 
>the trigger occurs.
>
>A dedicated piece of equipment with known trigger points such as a
telecom 
>analyzer can slave the sampling clock to the waveform being sampled and 
>"force" the alignment relative to the sample clock period (or conversely

>align the sample clock to the bins).  PLLs and DDS work beautifully
here.
>
>So - do you want general purpose?  Do you just want data 20 ns after the

>trigger and later only?  Do you want large pretriggers?
>
>I've seen equivalent time equipment (no real time permitted) where the 
>samples were 1 point per trigger with the data 10 ns or more after the 
>trigger.  In this case, the single sample event could be delayed from the

>trigger event precisely on a point-by-point basis.  Since the trigger is

>usually the point of interest, that test equipment used a high fidelity 
>delay line to sample the delayed channel a precise delay after the
trigger 
>allowing a small pre-trigger.
>
>There are many ways to skin this cat.  Engineering tradeoffs can't yet be

>made with the information supplied. 
>
>
>

On Sat, 18 Feb 2006 06:23:28 -0600, "maxascent"
<maxascent@yahoo.co.uk> wrote:

>The system I am designing is a pc scope. I guess I will know the trigger
>point. What I dont really understand is how you can generate precise
>offsets from the trigger if you want to sample in the GHz region as you
>are talking about picosecond values. I guess I dont fully understand the
>procedure

One solution for triggering is to have a fast, continuous time trigger
comparator start an analog ramp voltage (like in a monostable).  This
ramp voltage is then digitised with an ADC similar to the ones
digitising the input voltages.

Inspecting the values of the digitised ramp voltage will allow you to
estimate the trigger point with respect to the sample instants.

The accuracy is limited by the comparator jitter, which might be as
low as some picoseconds.

Regards,
Allan

Allan Herriman wrote:
> On Sat, 18 Feb 2006 06:23:28 -0600, "maxascent"
> <maxascent@yahoo.co.uk> wrote:
> 
> 
>>The system I am designing is a pc scope. I guess I will know the trigger
>>point. What I dont really understand is how you can generate precise
>>offsets from the trigger if you want to sample in the GHz region as you
>>are talking about picosecond values. I guess I dont fully understand the
>>procedure
> 
> 
> One solution for triggering is to have a fast, continuous time trigger
> comparator start an analog ramp voltage (like in a monostable).  This
> ramp voltage is then digitised with an ADC similar to the ones
> digitising the input voltages.
> 
> Inspecting the values of the digitised ramp voltage will allow you to
> estimate the trigger point with respect to the sample instants.
> 
> The accuracy is limited by the comparator jitter, which might be as
> low as some picoseconds.
> 
> Regards,
> Allan

And an extension to that: for a single point per trigger acquisition, 
the trigger comparator could start the precise ramp and another 
comparator (with a programmable comparison) gives the trip point on that 
ramp for a precise delay.  This allows the position of the single point 
to be deterministic.

If I were to design an eye-diagram scope, I'd probably use a two-channel 
DDS to phase shift the sample clock precisely through an IQ modulator. 
I love the technique; it provides a precise phase shift of high 
frequency clocks though it does need a little extra RF-type work to get 
the harmonics and such eliminated.

Thanks for your thoughts. Would it not be possible to implement this purely
in software using the fpga rather than have to design additional hardware?

Jon

maxascent wrote:

> Thanks for your thoughts. Would it not be possible to implement this purely
> in software using the fpga rather than have to design additional hardware?
> 
> Jon

No.  You need something in the way of extra hardware.  Either precision 
ramps or I/Q modulators - both hardware elements to interface with the 
trigger logic.

On Sat, 18 Feb 2006 06:23:28 -0600, "maxascent" <maxascent@yahoo.co.uk> wrote:
>The system I am designing is a pc scope. I guess I will know the trigger
>point. What I dont really understand is how you can generate precise
>offsets from the trigger if you want to sample in the GHz region as you
>are talking about picosecond values. I guess I dont fully understand the
>procedure

In a general purpose scope, the trigger event arrives as a surprise, i.e.
the scope does not know when the trigger event will occur. Typically you
want to capture data immediately after the trigger event, and usually
you would like to see some data before the trigger event. To see stuff
before the trigger event, you must have been already sampling the data,
or you need an analog delay line (high quality coax of suitable length)
to delay the signal by the amount of pre-trigger acquisition you want.
10's of nanoseconds is doable. Microseconds/miliseconds probably not.

Since you don't know when the trigger will occur, there is no relationship
between your clock that you are using for sampling and the instant of
triggering. (Note that you could theoretically have a clock that is
stalled until the trigger event, and then is started synchronous with the
trigger event, but such clocks do not have instant startup to stable
precision frequency, which is a requirement for this type of application).

So lets say you have a 100 MHz acquisition clock and a really great A/D
that has a really really really great S/H in front of it. The S/H and A/D
are running continuously at 100 MHz, and dumping data to memory set up
as a ring buffer. Lets say the ring buffer is 10K long. When the trigger
occurs, you record the current ring buffer address, and take 5K more
samples, then stop. Your FPGA+CPU can now go digging through the ring
buffer and re-arange the data to show you 5K * 10 ns of pretrigger info
and 5K of post trigger info.  But there is the problem that you have
10 ns of jitter in your system, because the trigger could have happened
anywhere in between two ticks of your 10 ns clock.

Here are two solution to this issue that also can guide you to an
equivalent time sampling system that can get you into equivalent sample
rates in the gigahertz. (Your bandwidth is still limited by the S/H and
A/D).

Technique 1). Since you know the exact level of the trigger voltage,
look at the samples before and after the trigger event, and interpolate
between the samples imediately before and after the trigger event to
find the virtual sample that occured at the trigger voltage, and the
virtual sample time.

For example (trivial example), trigger voltage is 2.0V. Sample before
trigger is 1.0V, and sample after trigger event is 5.0V . Samples 10ns
apart. Assuming a straight line between the samples, we will have
crossed through 2.0V at 2.5ns after the sample at 1.0V. Better curve
fitting than straight line is possible. We could therefore treat ALL
the samples of this acquisition as 7.5 ns late, which effectively
shifts all the samples in time. Now do multiple acquisitions. Each
one will interpolate the trigger point to some random time between two
samples. As you take more acquisitions, you get to fill in your
virtual acquisition buffer with samples that have been time aligned
to much finer resolution than the 10ns of your acquisition clock.

In fact this system depends on the fact that the trigger and
acquisition clock are uncorrelated, to give you the random
interpolation delays that let you have the interleaved acquisition
waveforms.

Technique 2). Concurrent with your 100 MHz acquisition clock you
run a 100 MHz sawtooth waveform. I.E. a ramp that repeats at the same
rate as your acquisition clock. At the time of the trigger, use a S/H
to sample the sawtooth, and it has its own A/D. The result of
sampling the sawtooth wave form tells you what the delta time of the
trigger versus the 100 MHz clock is. i.e. the sawtooth runs from
1.0V to 2.0V and magically drops back to 1.0V in 0.0000 ps, and
repeats. At the time of the signal passing through our trigger
level (what ever it is) the S/H takes a snapshot of the sawtooth.
The A/D on this S/H reports 1.35V . So we can say that the trigger
actually occured 6.5 ns before we took the first sample after the
trigger event. Reconstruct the equivalent time sampling data the same
was as Technique 1.


This should keep you busy,

Philip Freidin






Philip Freidin
Fliptronics

Philip Freidin wrote:
<snip>
> Technique 2). Concurrent with your 100 MHz acquisition clock you
> run a 100 MHz sawtooth waveform. I.E. a ramp that repeats at the same
> rate as your acquisition clock. At the time of the trigger, use a S/H
> to sample the sawtooth, and it has its own A/D. The result of
> sampling the sawtooth wave form tells you what the delta time of the
> trigger versus the 100 MHz clock is. i.e. the sawtooth runs from
> 1.0V to 2.0V and magically drops back to 1.0V in 0.0000 ps, and
> repeats. At the time of the signal passing through our trigger
> level (what ever it is) the S/H takes a snapshot of the sawtooth.
> The A/D on this S/H reports 1.35V . So we can say that the trigger
> actually occured 6.5 ns before we took the first sample after the
> trigger event. Reconstruct the equivalent time sampling data the same
<snip>

Rather than a sawtooth where "turning the corner" leaves you with an 
unknown voltage-to-time conversion, a sine and cosine at the sample 
clock rate can be sampled by the trigger.  The phase is extracted 
readily.  Another method used is to start a precision ramp after the 
trigger and sample it at two spots after the ramp is established.  They 
can give a precise timestamp as well.

Ok thanks once again for the info, think I have a better understanding of
what is going on

Jon