A High-Performance Open Source Oscilloscope: development log & future ideas

[tom66]

If you need layout help ... or a second pair of eyes. ping me.

Thanks, free_electron.  I'd certainly appreciate a second pair of eyes for the dual channel DDR3 memory controller when I get to that point.  The single channel one was fine,  but had I not done my extensive design review process (given such a complex board I felt this necessary) I would have missed a fatal error.

[tautech]

FE's Altium library is also a very useful resource. 

[tom66]

Jetson Nano arrived.  Probably won't be able to look at it properly until the weekend with my current professional  (i.e. pays the bills) workload.  But excited to give it a play.

I've considered just implementing an x1 PCI-e interface now using the M.2 slot - could be done with a small, probably custom PCB adapter and a Zynq devkit with a PCI-e port.  That said, spinning a board may be the only reasonable way forward, don't know until I do some more research.

[nctnico]

Jetson Nano arrived.  Probably won't be able to look at it properly until the weekend with my current professional  (i.e. pays the bills) workload.  But excited to give it a play.

I've considered just implementing an x1 PCI-e interface now using the M.2 slot - could be done with a small, probably custom PCB adapter and a Zynq devkit with a PCI-e port.  That said, spinning a board may be the only reasonable way forward, don't know until I do some more research.

That is certainly doable. I have made an M.2 key E (IIRC) to key B/M converter to connect an NVME to the M.2 slot. For the final board I have used an USB type C connector as a cheap way to bring a PCI express bus off board in order to have an external (pluggable) NVME slot. The only downside is that USB type C can be plugged in both ways so the plug needs to have the right orientation. A mini-SAS SFF8087 connector is another option.

[tom66]

I've used HDMI ports before for a proprietary interface that needed 4 diff pairs.  I use SATA on this current prototype but there wouldn't be enough lanes for a x1 PCI-e with that unless I used two cables, which could get messy in terms of length matching etc.

[nctnico]

HDMI is also a good option indeed. Lot's of connector choices nowadays to bring high speed interfaces to the outside.

[tom66]

Just got this working.


~130kwaves/sec using the original, buggy GL renderer - that managed to persistently lock up the Pi's GPU driver.  Now, I know we're not necessarily competing on waveform rate here but this has barely been optimised and already outpaces ArmWave by 6x, which should come as no great surprise.  It's doing dot join too (can't necessarily see that from the rendered output as it's a sine wave, but it is joining each point with a vector, which used to kill performance of the older renderer.) 

Caveats:  Internally generated waveform,  not connected to Zynq yet.  Seems to only make use of about half of the GPU's compute units, and is probably inefficiently designed.  Does seem to struggle with longer waveform lengths (>4k points),  need to investigate why.  No zerocopy for now, so every waveform buffer is copied into GPU space on each frame,  but this should be fairly trivial to figure out. 

Currently I render to an offscreen 1536x256 buffer and then scale that up to meet the window size using linear interpolation.  This seems to hide some quantisation artefacts but might be undesirable.  However, comparing e.g. Rigol DS1000Z  and Keysight 2000X,  they both seem to do some kind of linear interpolation in the vertical axis, so I think this is quite normal.  I can use a nearest-neighbour scaler, but it looks awfully ugly.

Next week's challenge, I think, will be to play with some DSP.  But for now,  it's time to sleep. 

[Pitrsek]

PS.  Not worried about differential routing.  The DDR3 memory on the prototype was the hardest part.  CSI-2 bus was comparably easy.  CAD tools, it's all CircuitMaker/Altium.  Am considering whether I should move to KiCad though to keep tools open.

I'd stick to Altium for now. The costs for producing a prototype are so high that it is unlikely many people will be changing the layout and if they do they might want a completely different form factor and start from scratch.

I can produce a lengthy list of why KiCad sucks, but for open source project it makes great difference if the tool is open or not. Not just for collaborators, but also for learning and fooling around - just to download the project and play with it. So although I'm no way KiCad evangelist, I have to suggest to switch to KiCad, as de facto standard open source tool. I'd suggest switch to HorizonEDA - this i use for my hobby projects, so far I like it very much. It supports length matching, but I haven't used it for high speed routing, so I can't attest as to how usable it is in this department.  In some aspects it is much more polished tool than KiCad, although it does not have the breadth of KiCad.

Depending on how things turns out in my life, i might have some spare time on my hands in upcoming months. I can do layout, power integrity/power supply design, analog stuff, reviews... PM me if you'd be interested.

[tom66]

Would certainly be interested in that kind of thing Pitrsek.  I think KiCAD is probably the most developed of the FOSS toolchains.  The problem is DDR3 routing,  differential pairs length matching etc,  is a lot harder without proper EDA tool.   You need to be able to length match in groups,  highlight group colours separately,  confidently DRC check,  and dynamic push/shove routing is really nice too.   I used to use gEDA for open source stuff,  the schematic editor is fine,   but the PCB tool is not modern enough to keep up with many high speed designs and that's problematic, although I last used it in 2015, maybe it has moved on since. 

Apologies for not updating,  just been very busy here and continue to be busy.  I hope to have some proper time to give this project a look soon, the Jetson Nano is sitting on my desk waiting for me.

[Pitrsek]

Length tuning, differential pairs, skew in differential pairs, push and shove, net classes - it's all there. There are quite a few boards with DDR3 already done with Kicad
https://kicad.org/made-with-kicad/categories/Single-board-Computer/ One is actually with Zynq.

The rules are probably the biggest difference so far, as usually the target length is defined manually. I would not call it on par with the pro tools, but it seems definitely usable.
HorizonEDA router is the one from kicad.

[tom66]

I'm aware KiCad can do that, so it makes sense to use that at some point.  Actually, CircuitMaker doesn't even do length matching or tuning, that is reserved for the premium Altium product.  You do at least get length lists, but if you want to length match to the longest group, you have to do it manually, both the calculation and the tuning. Control/address bus needs to be the longest of all of the groups, then the data buses need to be equally matched to each other, including strobe and mask (though data groups can be independent lengths  as they are each tuned on power up by Zynq DDR3 controller.)  So lots of Excel spreadsheets and hand calculations.

I also noticed a recent mistake when reviewing this design as I'm working on a commercial project now that uses a Zynq too.  I didn't terminate ODT ball to Vtt, as I read somewhere that it was a CMOS signal. Wrong, it is high speed. Somehow, the scope board still works OK, but I guess the ODT signal has a lot of reflections on it, which might affect when the termination on the data bus side is enabled.    I'll make sure to terminate ODT in the new design!

[nctnico]

Just wondering... has any work been done on an analog front-end? I have done some work on this in the past; I can dig it up if there is interest. Looking at the Analog devices DSO fronted parts it seems that these make life a lot easier.

I've got a concept and LTSpice simulation of the attenuator and pre-amp side, but nothing has been tested for real or laid out.  It would be useful to have an experienced analog engineer look at this - I know enough to be dangerous but that's about it.

I have attached a design I created based on earlier circuits. IIRC it is intended to offer a 100MHz bandwidth and should survive being connected to mains (note the date!).
Left to right, top to bottom:
- Input section with attenuators. Note sure whether the capacitance towards the probe is constant.
- Frequency compensation using varicaps. This works but requires an (digitally) adjustable voltage of up to 50V and I'm not sure how well a calibration holds over time. Using trim capacitors might be a better idea for a first version.
- over voltage protection
- high impedance buffer
- anti-aliasing filter. Looking at it I'm not sure whether a 7th order filter is a good idea due to phase shifts.
- single ended to differential amplifier and analog offset
- gain control block and ADC.

Nowadays I'd skip the external gain control and use the internal gain control of the HMCAD1511/20 devices. It could be a nice Christmas project to see how it behaves.

Meanwhile I have been slowly moving forward with this and had a PCB made which is based on the schematic I posted earlier. I'm not going to post the schematic of this new circuit yet because some parts are experimental and I don't want a flurry of schematics floating around.

This first version has the following design targets:
- sensitivity from 500uV/div to 20V/div by using 1:2.5, 1:10 and 1:200 attenuators
- constant input capacitance
- DAC driven offset adjust
- target 200MHz bandwidth
- 2 different anti-aliasing filters
- DAC driven voltage adjustable capacitors to make the attenuators have a flat frequency response; however the adjustable capacitors I have found turned out to have a too low resistance path and thus are useless. I have found some low voltage varicaps though which seems suitable as well; these are on the way.
- adjustable, high precission compensator output which can be used for self-calibration of the front-end
- 20x or 2x gain consisting of fixed 2x gain stage and switchable 10x gain stage. I want to see if the 10x can work by switching a feedback resistor (probably not) or an extra amplifier stage is needed. The prototype supports both.
- differential output compatible with tom66's prototype board which uses a SATA connector and the HMCAD15xx ADCs

It will probably take a while before I get it fully tested & tweaked. I just wanted to give an update.

[gf]

- sensitivity from 500uV/div to 20V/div by using 1:2.5, 1:10 and 1:200 attenuators

Do you mean 2.5x attenuation minimum, even for 500µV/div?
(that were only 200µV/div after the attenuator -- aren't that possibly ~8dB of renounced SNR?)

- 20x or 2x gain consisting of fixed 2x gain stage and switchable 10x gain stage. I want to see if the 10x can work by switching a feedback resistor (probably not) or an extra amplifier stage is needed. The prototype supports both.

Hmm, how is 20x gain supposed to suffice for 500µV/div (i.e. 5mV full scale on a 10 div display)?
After 1:2.5 attenuation, a gain of rather 1000x were required to obtain the 2V full scale input voltage for the HMCAD1511 (and without prior attenuation it were still 400x gain).

In 8-bit mode I see the possibility to augment the analog gain by some amount of HMCAD1511's digital gain, with only small SNR degradation, but according to [1] the useful range is still limited to <= 10x.

OTOH, for the 12/14-bit modes of HMCAD1520 (which were discussed in this thread, too), which already utilize (almost) the full DR of the ADC, I don't see digital (coarse) gain as an option, so that the whole amplification to 2V full scale needs to be done in the analog domain. [Digital fine gain can possibly still be used for small calibration adjustments of +/- a few percent, but I'm not sure if "no missing codes" ist still guaranteed in 14-bit mode then.]


[1] https://www.analog.com/media/en/technical-documentation/application-notes/using_digital%20gain_feature_of_hmcad1511.pdf

Lab testing has shown that gain settings up to 8x (corresponding to 0.25Vpp-diff. input full-scale) show minimal loss in SNR (as evident in Figure 5). SNR in dBc starts to degrade rapidly beyond digital gain of 10x, so the user is advised to keep the digital gain setting at 10x or less.

[nctnico]

- sensitivity from 500uV/div to 20V/div by using 1:2.5, 1:10 and 1:200 attenuators

Do you mean 2.5x attenuation minimum, even for 500µV/div?
(that were only 200µV/div after the attenuator -- aren't that possibly ~8dB of renounced SNR?)

Yes. This is to have some protection of the input and provide a constant input capacitance.

- 20x or 2x gain consisting of fixed 2x gain stage and switchable 10x gain stage. I want to see if the 10x can work by switching a feedback resistor (probably not) or an extra amplifier stage is needed. The prototype supports both.

Hmm, how is 20x gain supposed to suffice for 500µV/div (i.e. 5mV full scale on a 10 div display)?
After 1:2.5 attenuation, a gain of rather 1000x were required to obtain the 2V full scale input voltage for the HMCAD1511 (and without prior attenuation it were still 400x gain).

In 8-bit mode I see the possibility to augment the analog gain by some amount of HMCAD1511's digital gain, with only small SNR degradation, but according to [1] the useful range is still limited to <= 10x.

OTOH, for the 12/14-bit modes of HMCAD1520 (which were discussed in this thread, too), which already utilize (almost) the full DR of the ADC, I don't see digital (coarse) gain as an option, so that the whole amplification to 2V full scale needs to be done in the analog domain. [Digital fine gain can possibly still be used for small calibration adjustments of +/- a few percent, but I'm not sure if "no missing codes" ist still guaranteed in 14-bit mode then.]


[1] https://www.analog.com/media/en/technical-documentation/application-notes/using_digital%20gain_feature_of_hmcad1511.pdf

Lab testing has shown that gain settings up to 8x (corresponding to 0.25Vpp-diff. input full-scale) show minimal loss in SNR (as evident in Figure 5). SNR in dBc starts to degrade rapidly beyond digital gain of 10x, so the user is advised to keep the digital gain setting at 10x or less.

For the 500uV/div (which translates to 4mVpp with 8 divisions) the ADC gain will need to be set to maximum indeed and then you still won't get the full range. This is a limitation. Still there is plenty of room to increase the amplification later on. I just had to start somewhere and concentrated on the 8 bit ADC. I would like to avoid using a VGA because that adds extra noise to the signal path. If you translate the SNR to what is being displayed; setting the gain to maximum results in degradation of about 12dB / 2 bits /4 LSB. So basically you get 1/8th of a vertical division of noise on screen (assuming 8 divisions is full range) with the ADC gain set to max. I want to see how the analog front end behaves where it comes to noise first before worrying about the ADC.

[tom66]

In my original sketching of ideas I had always planned for an IC like LMH2832.
https://www.ti.com/lit/ds/symlink/lmh2832.pdf

This would be combined with a single -39dB attenuation relay to get you a 78dB attenuation range in total. 

If you want the precision modes of the ADC, you can't use the gain stages.  For 8-bit mode they may be sufficient.  Not sure if the gain stages vary with the '1511,  if it uses just an 8-bit core internally,  or if the true difference between the parts is only the ability to export that precision data out.

The HMCAD1511 also requires all of its inputs to be centred around VCOM, about 1 volt.  Shouldn't be a problem, just be aware it has a limited common mode range.

[nctnico]

In my original sketching of ideas I had always planned for an IC like LMH2832.
https://www.ti.com/lit/ds/symlink/lmh2832.pdf

This would be combined with a single -39dB attenuation relay to get you a 78dB attenuation range in total. 

The tricky part of VGAs in general is that they need differential inputs with a specific DC offset. Not impossible but it takes some careful planning. I'm also not convinced a VGA is the solution with the lowest noise. DSOs using the HMCAD1511 (without VGA) are consistently showing extremely low noise levels.

If you want the precision modes of the ADC, you can't use the gain stages.  For 8-bit mode they may be sufficient.  Not sure if the gain stages vary with the '1511,  if it uses just an 8-bit core internally,  or if the true difference between the parts is only the ability to export that precision data out.

The HMCAD1511 also requires all of its inputs to be centred around VCOM, about 1 volt.  Shouldn't be a problem, just be aware it has a limited common mode range.

Don't worry, I have catered for a VCOM pin on my design.

[gf]

Not sure if the gain stages vary with the '1511,  if it uses just an 8-bit core internally,  or if the true difference between the parts is only the ability to export that precision data out.

I'm pretty confident that it is the latter. The 1511 digital gain application notes I referenced above also mention higher internal precision. I guess the limitation is rather the maximum LVDS output data rate, which limits even the 1520 to 2/3 of the full sampling rate when it outputs 12-bit high-speed data instead of 8-bit.

14-bit precicsion mode of the 1520 is still a bit different, as it utilizes only single ADC core per analog channel w/o interleaving.

[tom66]

If it was just data rate limit then the 640Msa/s 12-bit unpacked mode only uses ~7.7Gbit/s link rate, which is actually lower than the 8-bit 1GSa/s mode. 

I plan to use the part in a 16-bit padded mode as it's more compatible with a single receiver engine, just need to adjust how the data is unpacked (the SERDES blocks on a Xilinx 7 series part can't be dynamically resized).   This will limit sample rate to 500Msa/s on 12-bit mode.  Further work would be required to move the SERDES to a receiver with a gearbox that could interpret each 8-bit word received differently, which is needed to unlock the 640MSa/s rate (+28%). 

I suspect (if there is a difference at all, which I have yet to validate) that the '1511 has a fuse or laser disable for the additional functions that the '1520 has.  If we're really lucky there is no difference at all, just the '1520 functions in '1511 register space are unqualified and untested (a bit like the 40MSa/s ADC in the old Rigols that was running at 100MSa/s!)

Informally, with the basic on board PLL I have got the '1511 on one board up at 1.2Gsa/s, I suspect the PLL was the ultimate limit as the failure was a loss of lock for the ADC, as if the input amplitude requirement (which was already marginal) was being violated even at 1GSa/s due to my buggy PLL design.  I'll try with a higher amplitude or external clock sometime.

[gf]

If it was just data rate limit then the 640Msa/s 12-bit unpacked mode only uses ~7.7Gbit/s link rate, which is actually lower than the 8-bit 1GSa/s mode.

I think they wanted to avoid an odd number like 666.66666...GSa/s, and decided that 640 is a "nice" number which is close enough.

[tom66]

If it was just data rate limit then the 640Msa/s 12-bit unpacked mode only uses ~7.7Gbit/s link rate, which is actually lower than the 8-bit 1GSa/s mode.

I think they wanted to avoid an odd number like 666.66666...GSa/s, and decided that 640 is a "nice" number which is close enough.

Yes - but point is it's not the LVDS transceivers that limit that data rate.
It's either a difference in the ADC structures, or perhaps more likely just the better parts that are picked to have 12/14 bit modes with good enough INL/DNL/some other parameter?  There may not be any difference at all...

[gf]

Yes - but point is it's not the LVDS transceivers that limit that data rate.

Given the specified 20%-80% LVDS clock an data rise and fall times of 0.7ns in the "LVDS Output Timing Characteristics" I don't see how the LVDS data rate can be significantly more than 1Gbit/s per lane, without violating these specs. At 1Gbit/s the data are stable for only 0.3ns, and at say 1.5 Gbit/s the data had no time to settle, given 0.7ns rise time. These specs apply to both 1511 and 1520. In practice the tranceivers may happen to be faster of course, but they don't guarantee it.

[ And if the data rate must not exceed 1Gbit/s per lane (by definition/specification) then the conversion rate needs to be reduced to <= 666MSa/s when 12 bits instead of 8 need to be transferred per conversion. ]

[nctnico]

Yes - but point is it's not the LVDS transceivers that limit that data rate.

Given the specified 20%-80% LVDS clock an data rise and fall times of 0.7ns in the "LVDS Output Timing Characteristics" I don't see how the LVDS data rate can be significantly more than 1Gbit/s per lane, without violating these specs. At 1Gbit/s the data are stable for only 0.3ns, and at say 1.5 Gbit/s the data had no time to settle, given 0.7ns rise time. These specs apply to both 1511 and 1520. In practice the tranceivers may happen to be faster of course, but they don't guarantee it.

It is differential! In the end it depends on the threshold of the receiver; the pulse width of the receiver will be the full cycle (minus some jitter). If you look at the datasheet there is an intentional 50ps delay between the LVDS clock output and data output as well.

[gf]

Yes - but point is it's not the LVDS transceivers that limit that data rate.

Given the specified 20%-80% LVDS clock an data rise and fall times of 0.7ns in the "LVDS Output Timing Characteristics" I don't see how the LVDS data rate can be significantly more than 1Gbit/s per lane, without violating these specs. At 1Gbit/s the data are stable for only 0.3ns, and at say 1.5 Gbit/s the data had no time to settle, given 0.7ns rise time. These specs apply to both 1511 and 1520. In practice the tranceivers may happen to be faster of course, but they don't guarantee it.

It is differential! In the end it depends on the threshold of the receiver; the pulse width of the receiver will be the full cycle (minus some jitter). If you look at the datasheet there is an intentional 50ps delay between the LVDS clock output and data output as well.

Sure, in the end it depends on the receiver threshold; and the programmable clock phase also enables adjusting the point in time where the clock crosses the receiver threshold. But even if it still happens to work I would no longer call it a "clean" timing when the transition time exceeds the unit interval. And LVDS standards are obviously even stricter.

https://www.ti.com/lit/ug/slld009/slld009.pdf?ts=1612860014236

LVDS/M-LVDS Summary
The  most  attractive  features  of  LVDS  include  its  high  signaling  rate,  low  power  consumption,  andelectromagnetic compatibility. The following sections summarize each of these benefits and Chapter 2, LVDSand M-LVDS Line Circuit Characteristics and Features, offers a more detailed explanation.Signaling RateWe define the number of state changes per unit time as the signaling rate for the interface. Knowing the unitinterval time, tUI, between state changes, you can derive the signaling rate as the inverse of the unit interval.TIA/EIA-644-A and TIA/EIA-899 require that driver output transition times be less than 30% of the unit interval,with a lower limit of 260 ps and 1 ns, respectively. The standards also recommend that the transition time atthe receiver input be less than 50% of the unit interval. The difference between driver output rise time andreceiver input rise time allows for signal degradation through the interconnect media

[tom66]

Well, for what it is worth, the standard speed grade of the Zynq is only rated to 950Mbit/s per pin on SERDES and I haven't yet got the input delay tuning algorithm working, but it works stable whether hot or cold.  On this basis (though, admittedly with no way to measure it) I suspect the LVDS signal is not as marginal as suggested and the specifications are worst case, though I may have just gotten lucky!

[nctnico]

Yes - but point is it's not the LVDS transceivers that limit that data rate.

Given the specified 20%-80% LVDS clock an data rise and fall times of 0.7ns in the "LVDS Output Timing Characteristics" I don't see how the LVDS data rate can be significantly more than 1Gbit/s per lane, without violating these specs. At 1Gbit/s the data are stable for only 0.3ns, and at say 1.5 Gbit/s the data had no time to settle, given 0.7ns rise time. These specs apply to both 1511 and 1520. In practice the tranceivers may happen to be faster of course, but they don't guarantee it.

It is differential! In the end it depends on the threshold of the receiver; the pulse width of the receiver will be the full cycle (minus some jitter). If you look at the datasheet there is an intentional 50ps delay between the LVDS clock output and data output as well.

Sure, in the end it depends on the receiver threshold; and the programmable clock phase also enables adjusting the point in time where the clock crosses the receiver threshold. But even if it still happens to work I would no longer call it a "clean" timing when the transition time exceeds the unit interval. And LVDS standards are obviously even stricter.

https://www.ti.com/lit/ug/slld009/slld009.pdf?ts=1612860014236

LVDS/M-LVDS Summary
The  most  attractive  features  of  LVDS  include  its  high  signaling  rate,  low  power  consumption,  andelectromagnetic compatibility. The following sections summarize each of these benefits and Chapter 2, LVDSand M-LVDS Line Circuit Characteristics and Features, offers a more detailed explanation.Signaling RateWe define the number of state changes per unit time as the signaling rate for the interface. Knowing the unitinterval time, tUI, between state changes, you can derive the signaling rate as the inverse of the unit interval.TIA/EIA-644-A and TIA/EIA-899 require that driver output transition times be less than 30% of the unit interval,with a lower limit of 260 ps and 1 ns, respectively. The standards also recommend that the transition time atthe receiver input be less than 50% of the unit interval. The difference between driver output rise time andreceiver input rise time allows for signal degradation through the interconnect media

Yes and no. The steeper the edges the more noise & heat dissipation (which is what a high speed / precission ADC can do without). Slower edges means more jitter at the receiver's end but since the connection between the ADC and FPGA is basically a synchronous parallel bus over a distance of a few cm at most, the environment is much better defined. The TI document is about using LVDS in multi-drop situations over relatively long distances and likely in a way where the receiver also needs to do clock recovery where jitter could be an issue.