I am designing a digital scope. This is just for learning. I already have a nice 200MHz scope. I will be using a pair of ADS5410 ADCs (80MHz 12 bit 1GHz analog bandwidth). I need to be able to deal with signals above 40MHz so I will need some form of trigger. My idea is to use a fast comparator for the trigger, and start integrating when the trigger occurs. I could have the second ADC sample the voltage on the integrator each clock cycle. The integrator reset would be controlled from the FPGA. (Reset it a few cycles after the trigger and hold it for a fixed number of cycles) This would allow the the exact time the trigger occurs to be determined. Is there a better way of doing this? Also, any suggestions for the trigger comparator? I would like to be able to have AC/DC coupling and selectable positive/negative slope.
The ADC will be running continuously with the data being stored to SDRAM (circular buffer). The problem with software triggering is the aliasing of signals over 40MHz. I plan to use equivalent time sampling. I should have noted that in the original post. I need the trigger data so I can know where to put each data point on the screen, and 12.5ns is not precise enough. For instance, what I need to know is that the trigger occurred 3.4ns before the 12345678th clock cycle of the ADC. This is one of those problems I see no digital solution to.
I realize the limitations of undersampling/equivalent time sampling, and most of them will not matter for this particular application.
Tek has some info on equivalent time sampling here:
I will be publishing this design on my website once it is built and working.
Equivalent time sampling can be extraordinarily difficult and here are some of the reasons why.
Your trigger system bandwidth has to be as high as the equivalent time frequency response.
You have many more sources of error and jitter. Individual components must be a LOT better than the equivalent time resolution multiple to stay within the total very much smaller error budget.
Your trigger threshold has to be absolutely independent of the input waveform. Small cycle-cycle variations in the input waveform can cause catastrophic shifts in the effective trigger threshold even when those changes happen far outside the area of interest. This is common when looking at digital signals. Fixing this is harder than it sounds.
So, now that you have your trigger jitter plus A/D timing jitter down to some fraction of the equivalent time clock interval and it's all independent of input signal level and waveform, you're ready to build the interpolator. Oh, don't forget that the aperture time of your A/D has to be compatible with the equivalent time sampling interval. Otherwise you'll have excellent time resoluton on a smeared out version of the actual input.
In the TEK TDS540, they do it this way. At the trigger event, start two fast positive ramps and store the acquisition memory reference pointer. At the next positive clock, start discharging the first ramp at a slower rate and time how long it takes to discharge. At the next negative clock, start discharging the second ramp at a slower rate and time how long it takes to discharge. This eliminates all the problems you get when the clock and the trigger are almost coincident. You always have at least one good ramp interval. But you need two of everything. And you need an absolutely symmetrical clock.
Remember that if you're not saving all the samples, you also have to remember the time since the last saved sample to do the interpolation.
I can't give you any more info on how they do it 'cause it all disappears inside a massive custom IC.
You also have to manage the acquisition memory. You have to sample continuously until you get the trigger, then continue to fill the post-trigger memory. Then save the interpolation value. Then map into a different memory space to start the pretrigger acquisition for the next run. At some point, you have to retrieve all this info and map the multiple acquisition memory spaces into the display space properly interleaved. If you're not in a hurry and don't need to scroll the screen and don't need the info later, you can use one memory and transfer to the screen after each acquisition cycle.
Judging from the cal procedure, there's a huge amount of internal calibration and firmware to make all this interleave properly.
If you go back 40 years and look at some sampling oscilloscope schematics, you'll find a different scheme. Start with two matched current sources, one positive, one negative. Discharge your holding cap to ground. Start the positive current on the trigger signal. Start the negative current on the next clock edge. Turn off both sources before the mismatch causes the cap voltage to drift. The volts on the cap is a function of the relative timing of the trigger and clock. Sounds simple, but doing all that switching without introducing errors is a real trick.
I once implemented a crude version of this with a GAL20V8. Use the output tristate control. Tie resistors from two outputs to a cap. Turn on both outputs...the voltage divider holds the cap at vcc/2. Tristate one output on the trigger and the second one at the next clock. Voltage on the cap is a measure of the difference. It's not a linear ramp, but the shape is known. Works better than I'd expected. Sounds like redundant functionality, but when your trigger rate approaches the clock interval, it can be useful to sense clocks that happen before the trigger and just throw away the ones where the clock is way too early. The early sampling scopes used a sort of PLL/FLL that predicted where the next trigger would be. Not so important if you have digital memory. The project died because I couldn't come up with a cheap sample/hold to put ahead of the PIC A/D...and a TDS540 fell into my lap.
Happy sampling, mike
Return address is VALID.
Wanted, PCMCIA SCSI Card for HP m820 CDRW.
That all sounds good. Maxim and Analog Devices make screaming fast ECL comparators, which you could level-shift up to the FPGA input. If your FPGA has LVDS inputs, that would be especially nice... level shift but no gain required.
You should be able to get 1 GHz equivalent-time bw if you handle the analog front-end properly. You're essentially doing random sampling here, since the ADC triggers are asynchronous from the signal trigger. Your analog ramp will need to be very linear, as any curvature will translate to measurement jitter; that may be the hardest part... 12 bits accuracy at 1 GHz requires sub-picosecond jitter!
Lets see... 40 MHz is a 25 ns period; say you go for a 50 ns ramp. A couple hundred ps of ramp linearity should be easy, and something like
25 ps will be hard work. For lowest jitter, don't route the trigger signal through the FPGA, but use a separate 'hit' flipflop to unleash the ramp.
Don't use the bottom 10 ns or so of the ramp; it will be curvier and ringier than the later stuff. Throw those samples away. You *could* software un-curve the ramp to reduce jitter. Yeah, definitely do that.
It won't work if he wants to measure frequencies well above 40MHz. The only way to do that with a slower ADC is via multiple shots delayed by a sliver each time. For that the clock of the ADC needs to be precisely started by the trigger signal, plus x many pico- or nanoseconds for the subsequent acquisition and so on.
Do you really need exact or is very good repeatability what you are after?
Working through it in steps:
(1) When the trigger happens, the integrator starts up. This is really a lie. Some short time after the trigger happens the integrator takes a step due to charge injection. It then squiggles around as the op-amp or whatever gets its act together. Finally is settles into rising along something that looks like a straight line.
(2) On the clock cycle 2 (or perhaps 3) after the trigger, the ADC samples the voltage on the ramp. Really the sampling happens when the signal makes it through the FPGA and the switch of the sample and hold. We'd like to think that the sampling time is fixed but in real life it isn't exactly but this just makes the slope of the ramp appear larger or smaller that it really is.
(3) The scope is triggered so the trigger circuit isn't needed for a bit and we would like to use this time to calibrate the trigger circuit so we switch over to the calibration circuit. This means that the triggering stuff involves an extra layer of logic. We really want to make sure that the same chip and the same number of gates and etc are in the two paths to remove the skew error in the interpolation.
(4) The integrator is reset for several clock cycles and then allowed to start. The exact same components are used for this switching as for the (1) so the shape should be the same. Notice that I only said that it should. The fact that the ramp circuit operated just a short time ago can effect the ramp it makes this time. You need to use expensive capacitors and be careful about any heating effects in the semiconductors. Some current feedback op-amps have a long thermal tail. Don't use one of them.
(5) We digitize at the 2nd and 3rd clock cycles to get the end points for the ramp. We really hope that the ramp is nearly straight between these two points. If it isn't, we also digitize on the 4th clock cycle. We then make the unfounded assumption that the curve is second order only and correct the time value assuming that is true.
(6) The triggering circuit can now be returned to normal service.
Darrell's scheme sounds a lot simpler. ADCs are cheap these days.
Just stream samples from both ADCs into FIFOs. One ADC samples the signal, the other samples a ramp. When you get a trigger, start the ramp. Everything you need to know is now strolling through the FIFOs.
It seldom is. My Tek 11801 can use a 50 GHz sampling head, but its trigger circuit bandwidth is under 2 GHz. It won't trigger at 50 GHz, but it will display a 1 GHz rep-rate signal with 50 GHz fidelity. You always want a scope to have more bandwidth than the reprate of the signal.
Random jitter adds as a square root/sum of squares sort of thing, so things aren't all that grim. Even the old tube sampling scopes, like the HP185, had RMS jitters below 10 ps. The 185 with the 188A dual-channel sampling plugin had an analog bandwidth of 4 GHz, in
It's not that hard. I had a student intern build a sampler breadboard one summer. His soldering and construction were ghastly, but we got a very clean 70 ps (5 GHz) sampler using fairly ordinary parts. Agoston Agoston (the guy who did the Tek SD-series heads) retired and started a little company of his own, Hyperlabs, and did a 20 GHz sampler on FR-4.
Ok, I think I see what I did wrong. I mixed apples and oranges. There is indeed a large class of sampling oscilloscope where you have A/D converters and fast ram to hold the data. You can have an analog bandwidth approaching Nyquist. If you interpolate samples, you can get a better looking display, but you still can't get any more analog effective bandwidth than your input filter can allow. To get more effective bandwidth you have to improve the analog input bandwidth. True, if you don't need more bandwidth, the time interpolation problem becomes much easier. If you don't need to trigger on faster signals, the trigger problem becomes much easier. You fill in the spaces between the samples, but you don't get much additional information. You do make it easier for a human to interpret.
Your 50 GHZ sampling head works because the input circuitry was designed to have 50 GHZ analog bandwidth from the start. Not the same as an attempt to take an existing design and interpolate it's bandwidth up by orders of magnitude.
I'm much more interested in the case similar to the sampling scopes of 40 years ago. The effective sampling rate and the actual bandwidth are orders of magnitude better than the fastest rate you can take a sample. In particular I'm interested in using a 15uS A/D in a PIC processor to realize a TDR system with a resolution of a few inches in coax for cheap, cheap, cheap. Triggering is not such an issue for me as I control the source and the acquisition. The biggest challenge appears to be the sample/hold input.
As for triggering, the accuracy of your trigger is dependent on the bandwidth of path between the DUT and the trigger comparator. If the input signal has bandwidth far greater than the trigger circuit, you'll trigger on an integrated...sort of...version of the signal. That makes the trigger level dependent on the shape and/or vairability of the input waveform. Even with noiseless triggering circuits, you'll still be vulnerable to what looks like jitter induced by input signals that are not exactly repetetive... as most digital signals are. As before, if you don't need to trigger on higher rep rates or varying inputs, your problem is much simpler.
The maximum rep rate for triggering is more dependent on the bandwidth of the trigger arming circuitry. One possible method is to arm the trigger on one slope of the input then trigger on the opposite slope. The delays in this arming loop limit the minimum time between those two events and thus the maximum input frequency for stable triggering. This is an entirely different problem not to be confused with the bandwidth of the trigger input. mike
Return address is VALID.
Wanted, PCMCIA SCSI Card for HP m820 CDRW.
You could even use an FPGA and fast static RAM do looks sort of like a FIFO but that averages the values into their correct time slots. Since he is only after a 80MHz convert and 10nS times in RAMs and FPGAs are not to hard to get these days, he could end up with something that doesn't have to be processed very much after the fact.
Sorry this is late. I thought I'd posted a response yesterday but it still hasn't shown up, so here it is again.
We built a very similar system for a stroboscopic electron microscope at Cambridge Intruments (Cambridge U.K.) from 1988 to 1991.
I've still got a copy of the circuit diagram for the Trigger Board that included the trigger comparator - two of them in fact, since we had both a scope-type high impedance input (1M/10pF +/-15V) and a 50R terminated input.
Neither input was directly connected to a comparator - we used discrete components to protect the inputs against over-voltage, to provide common mode rejection, to inject the programmable trigger offset (effectively the trigger threshold) and to level shift the signal into the limited common mode range of the comparator.
The high impedance input eventually fed into an Analog Devices AD96685 ECL-output comparator, which limited that input's frequency response to
140MHz - nowadays I'd look at the (now) Fairchild SPT9689 which is good to 900MHz.
The terminated input fed into a receiver on a Gigabilt Logic GBL 10G002 quad line receiver, which was much faster, though it had less gain, and that input was good to a least 500MHz (the limit of our test gear). I'd probably use an ECLinPS part these days. This is essentially John Larkin's preferred solution.
I was also responsible for the basic design of the ramp generating circuit, but I never actually worked on that board, which is why I haven't got a circuit diagram.
Our ramp generator depended on a long-tailed pairs of wideband transistors as switchable current sources. In the reset state, a pair of BFT92 PNP transistors fed some 2mA (IIRR) into a capacitor which was clamped at a stable (but programmable) voltage by a Schottky diode.
At trigger, the PNP source turned off, and a 10mA (?) NPN source - a long-tailed pair of BFR93 transistors - generated the timing ramp. On the second clock edge after the trigger pulse, this source was turned off, and we digitised the (buffered) voltage across the capacitor. A couple of clock edges later, we turned the PNP source back on to recharge the ramp.
We used an 800MHz clock and a 12-bit ADC for a - theoretical - timing resolution of 5psec. In practice we were limited by the 60psec jitter on the 800MHz clock.
If I were doing the job today I'd buy a crystal-controlled 500MHz clock from Vectron or someone similar - I might even push this up to 700MHz depending on how fast ECLinPS+ actually is these days. This ought to push the jitter down to the picosecond level.
The problem with using bipolar transistors for the current source is that the current becomes temperature dependent. We solved this problem by getting the system to self-calibrate itself every few minutes - our machine also included a vernier delay generator which we could cross-couple into the trigger input to generate a calibration sequence.
Today I'd use the ECLinPS MC100E195 for this job - it is guaranteed to span the 2nsec period of a 500MHz clock. The delays it generates are also temperature dependent, but a calibration sequence covering a full clock period is guaranteed to cross a clock edge, so a plot of nominal delay versus ADC output has to include a 2nsec step when the trigger inputs coincides with a clock edge, and the magnitude of that step calibrates the ADC outoput agains the crystal-controlled clock.
If you want to test for non-linearities you'd want two independently programmable 100195's in series, though a random trigger source might work as well if you had the time to build up statisically significant histograms of the number of times each delay interval was hit ... Fun stuff.
Histogramming the ADC codes is a good way to estimate ramp nonlinearity. Heterodyne walking can work, too. But the bottom line is RMS jitter.
I've also tended to make fast ramps by charging a cap with a cc source. But maybe it's time to revisit the opamp integrator; for ramps in the 10s of ns, fast enough opamps are probably now available, and problems with nonlinear junction capacitances - the bane of fast ramps
The classic fast s/h is a 2-diode half-bridge driven by a step-recovery diode, with analog DC feedback. That's how the majority of equivalent-time sampling scopes still work. You can get down to maybe 70 ps Tr with cheap surfmount parts. More interesting is creating a fast, clean, truly 50-ohm step source.
If you make the thing PC-based, you can do signal processing to make up for a lot of nasties in the sampler and step generator, specifically a deconvolution thing that makes ugly pulses look pretty. A PIC wouldn't be up to that.
The slideback sampler might work for TDR; it just uses a fast strobed comparator as a 1-bit digitizer. It's slow (from a sample rate standpoint) but you might get close te to 100 ps risetime with one of the newer comparators. That's the thing Mike Monnett thinks he invented.
I'd tell you more, except someday I might want to do this myself and sell it to PC board houses or something.
You can do slightly better than this. In digital land, you can make a filter with a zero right on the -3dB point of the analog input. This can shift the corner up a little. You not going to get decades this way but you can take out some of the effects of an anti-alias filter this way.
Since you don't need a result in a huge hurry, you can repeat the pulse many-many times to get the result. This makes the sample and hold a little easier because it doesn't have to recover very quickly. You can force the sample and hold to zero between samples. This can let you turn frequency responce issues into scale factor issues which are easier to handle.
It's been a couple of years, but IIRC, I needed .1ns aperture time and had to hold for 15,000 ns for the PIC. Just couldn't make it work without exotic parts on a +5V only system. Never occurred to me to sit in the same place for as long as it took. That should work even with very low sampling efficiency. Good idea. mike
Return address is VALID.
Wanted, PCMCIA SCSI Card for HP m820 CDRW.
I think Darrell wants to clock two ADCs continuously at 40 MHz; one ADC snags the signal, the other ADC digitizes a linear ramp that's started by the trigger. (Pipeline ADCs don't like to be randomly triggered.) There will be enough info in the digitized samples to grab a series of 25 ns waveform points and to determine the skew, for this batch, between the local clock and the trigger. So you plot these points on a screen with the horizontal position tweaked by the observed trigger-to-clock time offest. Then go back and do it again until a high-resolution image emerges. Each set of 40 MHz points is randomly positioned with respect to any other, so all intermediate times are eventually explored and plotted.
That should work. As a bonus, it nabs pre- and post-trigger waveform data, as much as you have memory for.