Correcting fixture skew using a Tek 11801 - Page 1
Forum section: electronics / general

author: rhb
author_rank: Super Contributor
timestamp: March 27, 2019, 09:40:33 pm
content: I'm getting set up to implement DSP filter chains for my FOSS DSO FW project. This is all completely new to me, though I've been doing a lot of reading.At present I have an 11801 and a pair of SD-22 heads, so I've got 4 channels with a 23 ps rise time and am considering getting four SD-26, 17 ps heads so I have 8 identical channels.The choice of filter topology, placement and routing will govern how fast I can clock the filter chain (these will be stackable a la LeCroy), so I want to be able to measure clock skew across an output word. I'm limited to a maximum of 8 input channels as I don't have the M01 option to allow using an SM11 to increase the channel count. However, I do have plenty of HP SMA SPDT relays so I can multiplex 8 channels across 16 input lines.Unfortunately, the skew adjustment capability of the 11801 appears to be limited to the sample head to sample head skew and nothing more.Obviously all the cables need to be length matched as closely as possible,. However, I don't expect that will be sufficient. I'm looking at a 161 ps skew on the outputs of a 2 port splitter. So I don't expect perfectly matching relays. I'd like to avoid having to measure time delays and make corrections.Does anyone know of affordable ways of physically correcting propagation delays on SMA lines?Edit:I managed to figure out how to adjust the channel to channel skew, but now I'm seeing a 10 ps drift in the timing of two traces coming from the splitter. Over the course of 5-10 minutes the traces will align and drift apart.

author: cyr
author_rank: Frequent Contributor
timestamp: March 28, 2019, 08:05:38 am
content: Sorry - not an answer to your question, but...I'm curious how you are implementing DSP filters if the skew on external pins matter? Are you using multiple chips with parallel buses inbetween?Seems to me your life would be much simpler using a single FPGA (assuming pure software isn't fast enough), the tools will tell you what your maximum clock rate is and what the critical paths are.Or maybe I'm missing the point?

author: rhb
author_rank: Super Contributor
timestamp: March 28, 2019, 11:58:14 am
content: Single FPGA. I plan to generate data, implement a single filter stage and write it to an external word wide port and evaluate the measured skew vs the skew calculated by Vivado and Quartus.As I have no prior experience at this, I want to understand the limitations of the tools I am using before going farther in the design work. In "VLSI DSP Systems" Parhi gives a wide variety of FIR and IIR filter topologies. I plan to implement all or most of them and study what happens as I vary constraints.I spent my career in seismic processing and oil exploration. I have learned not to trust large software packages without independent verification. I also have enough HPC experience to know where to look for the performance bottlenecks. Those are the things I investigate first.Twenty years ago when I started work on a seismic imaging code, I spent 4-6 weeks evaluating the performance of the inner kernel and how the compilers for the DEC Alpha performed with different flags. That work led to the only computed GOTO I have ever written. By experiment I determined that the code would run 10-15% faster if I used temporary variables in the inner loop and a stride of two. But the length of the loop varied during execution so I had a computed GOTO to select the appropriate section of the code. I wrote an awk script to generate the actual FORTRAN file.My choice of experiments was made after reading "Computer Architecture: A Quantitative Approach" by Patterson and Hennessy and more DEC Alpha documentation than I care to remember.Same approach. Different problem. For an arbitrary, user chosen series of filters minimizing transition skew across the word is critical to being able to run at a fast clock rate. Otherwise the result has to be latched between stages. That consumes real estate and clock cycles.Right now I have an 18 ps skew between the two channels on an SD-22 caused by a 1/2 mm difference in cable length. So far I have not found a way to correct that in the 11801, so I'm looking for a physical device that will provide a good 50 ohm match and small adjustable delays in the sub ns range. What's called a trombone line waveguide in microwave vector network analysis in some of my textbooks.

author: cyr
author_rank: Frequent Contributor
timestamp: March 28, 2019, 02:31:10 pm
content: Ah, I see. I think there are serious limitations with trying to "look inside" the chip that way through, If you tell the FPGA tools to bring the signals out on pins they may produce a completely different result than otherwise (especially if you tell them to optimize for I/O skew or delay), and any skew you measure could be dominated by the I/O cells and the routing to them rather than the actual filter logic (especially if you *don't* tell the tools to optimize the I/O paths).You can of course verify if the skew *at the pins* is within the limits promised by the tools, I just doubt that information is very relevant for the final design.

author: rhb
author_rank: Super Contributor
timestamp: March 28, 2019, 03:13:03 pm
content: The goal is stackable math and filter operators such as LeCroy has. So it will probably require partial reconfiguration. of the FPGA to achieve acceptable performance with a reasonable size device.Pasternack, now Brocke, sells phase shifters, but at $140 each a set of those would cost too much. At the moment making a set of solder connection semi-rigid cables and adjusting the timing on a fixture before making the last solder connections seems the most practical option. The good news, bad news is I'm trying to match electrical lengths to fractions of a millimeter. The two cables I'm using at the moment have a 17-18 ps difference. That's a ~3.4 mm difference in electrical length. The 0.01 mm resolution of a metric micrometer is 50 femtoseconds.The 11801 is proving very educational.

author: FriedLogic
author_rank: Regular Contributor
timestamp: March 29, 2019, 01:54:21 pm
content: Quote from: rhb on March 27, 2019, 09:40:33 pm161ps sounds very high. The splitter that I tried with the pulse generator from Leo had very little skew between its outputs. There was a bit from the scope, but IIRC most was from the cables which were a few mm different in length.

author: rhb
author_rank: Super Contributor
timestamp: March 29, 2019, 05:04:12 pm
content: The scope was in a borked state. Certain sequences of operations will lead to the time values being off by a factor of 10x. The "Enhanced Accuracy" calibration being the major culprit. But I've had it happen in at least one other instance. The cure is to initialize the scope in the utility menu and reset everything. Aside from the UI from hell, it's pretty buggy. I expect Tek took a *lot* of heat from early buyers.The specified rise time for the calibrator output is <35 ps. My instrument is fairly early production from what I can tell, but appears to have had a timebase ROM upgrade in 1991. But when the scope is borked it will report 10x larger rise times.There is no measurable delay between the two splitter ports making casual measurements. The cables are RG402 and have a 16-18 ps difference in electrical length. It's very hard to get the cursors at the same point on both waveforms. The spec for jitter is ~1.1 ps, but I can't find that spec at the moment in either the user or service manuals. There is a time varying delay between the head and the horizontal sweep circuit so that cursors move back and forth by 2-3 ps.. The cursors are stable, it's the waveform that is changing.