azonenberg changed the topic of #scopehal to: libscopehal, libscopeprotocols, and glscopeclient development and testing | https://github.com/azonenberg/scopehal-apps | Logs: https://freenode.irclog.whitequark.org/scopehal
Degi_ has joined #scopehal
Degi has quit [Ping timeout: 268 seconds]
Degi_ is now known as Degi
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<azonenberg> So, the HMCAD1520 seems to be unobtainium right now but there are HMCAD1511s on digikey
<azonenberg> i'm thinking of snagging a few for R&D later this year
<azonenberg> I'm contemplating making a single channel ZENNECK prototype at some point
<azonenberg> i have two XC7A50T's in inventory already i can use (in FTG256 package)
<azonenberg> let me think if that's going to be enough IO
<azonenberg> FTG256 has 170 IOs in four banks, three full and one partial
<azonenberg> HMCAD15xx has eight LVDS data pairs and frame/bit clock so total of ten LVDS lanes per ADC
<azonenberg> So i need 40 LVDS lanes to use four of them
<azonenberg> at 24 LVDS lanes per bank that's almost two full io banks
<azonenberg> which leaves a bit of extra i can use for ethernet and talking to a MCU because there's no way i can fit all of the slow GPIOs i'd need on the FPGA
<d1b2> <thirtythreeforty> Isn't this the ADC in Rigol's scopes? They overclock the hell out of the base level part, if you didn't already know
<azonenberg> thirtythreeforty: Yes. The 1520 is the 1511 plus a lower speed 12 bit mode
<azonenberg> pin and software compatible in 8 bit mode
<azonenberg> I wanted to have the 12 bit mode on all of my scopes, at least as an option (we could make a cheaper SKU that is the same board with a 1511 stuffed to cut $40ish off the BOM)
<azonenberg> Anyway, so the plan for the full ZENNECK system is eight channels, but i'd obviously want to prototype one in isolation
<azonenberg> Four HMCAD15xx fed through splitters and buffers
<azonenberg> giving you 4 Gsps @ 8 bit / ~2 Gsps @ 12 bit
<azonenberg> targeting around 500 MHz bandwidth
sam210723__ has quit [Quit: Leaving]
<d1b2> <thirtythreeforty> Gotcha, nice! Opportunistic related question, do you have an input buffer part or topology picked out? I'm targeting 250MHz and that's still a very vexing part of the design to get right
<d1b2> <thirtythreeforty> Equivalent time sampling on the channels? 8x500MHz would be nuts
<azonenberg> Real time
<azonenberg> A full ZENNECK would be a 3U Eurorack with one card per channel, most likely
<azonenberg> 4x HMCAD1520 and possibly a small FPGA and RAM to buffer the waveform data, or maybe a few bigger ones on the backplane
<azonenberg> total 32x HMCAD1520, 8x 500 MHz channels, with 10GbE or 40GbE to the outside world
<d1b2> <TiltMeSenpai> does that need 10gbe?
<d1b2> <TiltMeSenpai> oh yeah lol that's the plan
<azonenberg> It would be impossible to do full realtime streaming even with 40G probably
<azonenberg> One HMCAD1520 is 1 Gsps * 8 bits = 8 Gbps
<azonenberg> One
<azonenberg> a *single* 500 MHz 4 Gsps channel is 32 Gbps of sample data
<d1b2> <TiltMeSenpai> that's uhh... approximately a fuckton of bits
<azonenberg> The basic architecture for all of my planned scopes is ADC -> big DDR3/4 based FIFO -> TCP offload engine
<azonenberg> ZENNECK would most likely be multiple full sodimms of DDR3/4
<azonenberg> i think i guesstimated quad channel DDR3 or dual DDR4?
<azonenberg> thirtythreeforty: And I have an input buffer designed and prototyped
<azonenberg> a whole analog front end including gain and offset, in fact
<azonenberg> 50 ohm only, no 1meg, although it probably would be possible to add 1m mode too
<azonenberg> This is a prototype of a scalable frontend that with a few part swaps in the antialiasing filter should allow you to run out to 500 MHz
<azonenberg> thus allowing the same AFE design to be usable with the entire family of HMCAD15xx scopes I have planned
<azonenberg> BLONDEL (4x frontend -> 1x HMCAD1520, two acquisition cards in 1U for a total of eight channels - basically two cheap rigols plus 10GbE and 12 bit mode in one chassis)
<azonenberg> that would be ~100 MHz BW
<azonenberg> DUDDELL (1:1 frontend:ADC, allowing full ADC sample rate on every channel at once rather than losing sample rate as you enable more channels)
<azonenberg> and ZENNECK, 1 frontend : 4 ADC with splitters and time interleaving
<d1b2> <thirtythreeforty> Geez that's nuts. Very pretty prototypes!
<azonenberg> I designed it along with Degi and... i'm forgetting who the other contributor was, sorry
<azonenberg> it mostly works, needs a few small tweaks, at 100 MHz because i set the filter up for BLONDEL
<d1b2> <Darius> oooh it has a Gin port
<d1b2> <Darius> excellent
<azonenberg> I'm planning to respin soon with a 500 MHz config to test at full rate, also with a few other bug fixes and tweaks
<d1b2> <thirtythreeforty> Ah okay this answers my question. gets easier if you constrain it to 50 ohm inputs
<azonenberg> That's the general purpose gain input
<azonenberg> the gain stage uses a dual channel amplifier
<azonenberg> so i broke out both legs
<azonenberg> one with just gain and the other with gain+offset and common mode shift to match the HMCAD1520
<azonenberg> This board also includes power supply stuff etc to handle multiple channels, so a quad frontend isn't going to be 4x this size
<azonenberg> anyway I also have two more scopes on the roadmap based on the AD9213, which is 10 Gsps 12 bit JESD204B and costs about $3500 per ADC
<azonenberg> VOLLUM (one ADC per frontend, 1-2 GHz BW) and MURDOCK (four interleaved ADCs, 40 Gsps per channel. I could get 6 GHz BW without any S&Hs but if I added external S&Hs I think 10+ GHz BW might be achievable)
<azonenberg> MURDOCK would cost about $14K per channel in ADCs alone, and the frontend design would be very nontrivial - to say nothing of the amount of DDR4 you'd need to buffer the half a terabit per second of ADC samples
<azonenberg> but if it ever happens, it would be seriously competitive with midrange to even some of the high end scopes from the big names
<azonenberg> the plan is to work my way up hopefully making most of my mistakes on the less expensive systems :p
<azonenberg> And yes, i'm going for all 50 ohm. thanks to the AKL-PT1 and PT2, you can get very nice performanc with low cost passive probes
<azonenberg> i plan to build some lowish bandwidth high-Z active probes to enable probing of signals with pullups etc
<azonenberg> david.lenfesty is working with me to design the active probe interface
<azonenberg> it's a custom variant of USB PD over USB-C providing a control plane channel for calibration, device identification, etc as well as negotiating bipolar DC power, nominally +/- 7V
<azonenberg> using the PD channel to negotiate an alt mode, then switching the analog power onto SSTX and SSRX
<azonenberg> while keeping the 5V Vbus for digital power on the MCU
<azonenberg> the analog power would be low noise and the intent is to drive the probe amplifier right off it with LDOs
<azonenberg> he sent me a prototype to play with the other day that isn't fully debugged
<azonenberg> i havent had time to touch it yet
<azonenberg> on top of this of course i am also planning to design some high performance active differential probes, I have a 4 GHz design in th eworks
<d1b2> <thirtythreeforty> What's your name scheme?
<azonenberg> Famous electrical engineers in the T&M field
<azonenberg> Andre-Eugene Blondel invented the electromechanical oscillograph
<azonenberg> William Duddell invented the moving coil mirror oscillograph
<azonenberg> Jonathan Zenneck invented the CRT oscilloscope
<azonenberg> Howard Volum and Melvin Murdock co-invented the triggered-sweep oscilloscope
<azonenberg> Vollum*
<azonenberg> and MAXWELL's namesake should be obvious
<azonenberg> The logic analyzer pods are named MEAD (50 ohm input) and CONWAY (high-Z input, I need to find some time to work on that variant)
<azonenberg> after Mead & Conway
<d1b2> <thirtythreeforty> Ha that's great
<azonenberg> i scrapped a few very influential people because they gave their names to companies and i wanted to avoid associating my stuff with them
<azonenberg> e.g. LeCroy
<azonenberg> The inventor of the DSO
<azonenberg> These may or may not end up being final system names
<azonenberg> for now they're dev codenames
<azonenberg> Probes for the most part haven't had code names, just part numbers
<azonenberg> e.g. AKL-PT1 = Antikernel Labs, Passive, Transmission line, model 1
<d1b2> <j4cbo> how much does the cost of something like the AD9213 go down in quantity?
<d1b2> <j4cbo> I know with big FPGAs there can easily be a decimal order of magnitude price difference between qty1 digi-key price and negotiated manufacturer direct price
<azonenberg> I dont know
<azonenberg> i'm not at the point i'm ready to even think about reaching out to AD about samples or volume pricing
<azonenberg> That's the kind of thing i'd do after i had ZENNECK working reliably
<azonenberg> To prove i was capable and serious
<d1b2> <j4cbo> nod
<azonenberg> Even a single channel VOLLUM prototype would be a five digit R&D outlay
<azonenberg> $3500 for the ADC, the frontend almost certainly won't be cheap, then a very large ultrascale fpga
<azonenberg> probably a 12 layer board for the digital side
<azonenberg> i'd have to figure out the split between analog and digital subsystems
<azonenberg> in order to maximize the probability of saving either the FPGA or the ADC if something goes catastrophically wrong and i have to respin
<azonenberg> ideally, i'd split the design up into several boards each of which is relatively low risk
<azonenberg> and have mostly passive/low cost amplifiers etc on the more sketchy sections
<azonenberg> i don't know how doable that would be
<azonenberg> An FPGA board with ram, 10/40GbE, power, and jesd204 on a connector is very doable
<azonenberg> i'm less sure i could split the adc and the frontend without introducing issues
<azonenberg> so i'd probably want to build the frontend first in isolation and verify it extensively
<azonenberg> At least my VNA is fast enough to verify a 1 GHz frontend well
<azonenberg> I'd want to maximize linearity as much as i could, but i fully expect to require some DSP based correction to flatten the response in the end
juli969 has joined #scopehal
juli969 has quit [Quit: Nettalk6 - www.ntalk.de]
bgamari_ has quit [Ping timeout: 245 seconds]
bgamari has joined #scopehal
massi has joined #scopehal
<d1b2> <theorbtwo> For what it's worth, I can see some value deploying the front and backends in isolation. Put the stuff that needs to be near your DUT inside the Faraday cage / anechoic chamber. Stream full-speed samples directly out over fibre outside the cage to the part with all the ram, smarts, and unwanted emi.
<d1b2> <theorbtwo> Depends on how much you can avoid buffering, even when you have a dedicated zero-contention link, and how much duplication you need / how much it drives up the cost.
<azonenberg> Buffering is required
<azonenberg> even a single HMCAD1520 can pretty much saturate 10GbE
<azonenberg> The links from the acquisition boards to the main FPGA are going to be multi lane
<azonenberg> either a lot of LVDS lanes at ~1 Gbps for the HMCAD15xx, or JESD204B lanes at ~10 Gbps for the AD9213
<azonenberg> running those over fiber would not be practical or cost effective
<d1b2> <theorbtwo> Ahvell. Was just a crazy idea, and a fairly niche one at that.
<azonenberg> All of these scopes are intended to have as little intelligence in the box as possible
<azonenberg> but the ram controller and tcp stack have to be in the box
<d1b2> <theorbtwo> Just enough to run glscopeclient on a real computer?
<azonenberg> simply because the adc data rate of even a 2ch 1gsps scope exceeds any reasonable transport to the outside world
<azonenberg> Yeah thats the idea
<azonenberg> There will be some minimal smarts in the control plane MCU to do things like converting from a requested channel voltage range or offset to raw DAC codes
<azonenberg> and probably apply some calibration coefficients
<azonenberg> and there's a small chance i might have the otherwise unused multipliers in the FPGA do some filtering to flatten the frequency response of the frontend a bit
<azonenberg> but my real plan is to just VNA the frontend, store that on the scope, have a scpi command to retrieve the s2p
<azonenberg> and then do a deembed in glscopeclient to invert that response
<d1b2> <theorbtwo> Makes a lot of sense.
<azonenberg> especially since i'm not lecroy with some monster ultrascale on my scopes, at least in the low end stuff
<azonenberg> the small artix/kintexes i use on the HMCAD15xx based scopes will be pretty busy just running the adcs, ram, and ethernet i expect
<azonenberg> while i'll have free DSP slices, i'm not sure i will have the LUTs to make use of them
<d1b2> <theorbtwo> ...and little reason not to run the DSP stuff on the real-computer end. Though now I'm wondering how something like FLAC does with things like scope traces and baseband recordings.
<azonenberg> I think we would have better luck, if we chose to compress
<azonenberg> with simple delta coding followed by huffman or something
<azonenberg> the theory being most samples are kinda close to the previous one
<azonenberg> and we can represent the delta with less bits than the full adc resolution
<azonenberg> but this should be optional, not default - it might help over a WAN or wifi, but over 10GbE i suspect it would cost more cpu to compress than just to send raw data
<azonenberg> e.g. if uncompressed, we can convert raw adc samples to volts in parallel on the GPU
<azonenberg> if delta coded you introduce serialization
<d1b2> <theorbtwo> Yeah, that makes a lot of sense. I was thinking latency, which is not horrible, but serialization hurts much more.
<d1b2> <theorbtwo> Feel free to tell me that I am putting out too many crazy ideas, BTW.
<azonenberg> I'm always open to ideas
<azonenberg> I don't want to come across as dismissive or defensive, i'm explaining the rationale for my decisions. Which always has a chance of being wrong
<azonenberg> but it helps if we are debating a decision based on the same facts and constraints :)
<azonenberg> I figure either you learn something or i'm caught in a mistake, but either way we're closer to where we want to be
<d1b2> <theorbtwo> Nah, you aren't being dismissive at all.
sam210723 has joined #scopehal
<_whitenotifier-5> [scopehal] mubes synchronize pull request #402: Changes to support SDS2000+ scope - https://git.io/JYiAM
Stary has quit [Changing host]
Stary has joined #scopehal
<_whitenotifier-5> [scopehal] mubes synchronize pull request #402: Changes to support SDS2000+ scope - https://git.io/JYiAM
massi has quit [Remote host closed the connection]
bvernoux has joined #scopehal
Bird|ghosted has joined #scopehal
Bird|otherbox has quit [Ping timeout: 246 seconds]
<Degi> azonenberg, Digikey has 16 of HMCAD1520
m4ssi has joined #scopehal
m4ssi has quit [Remote host closed the connection]
smkz has quit [Quit: reboot@]
smkz has joined #scopehal
bvernoux1 has joined #scopehal
bvernoux has quit [Ping timeout: 240 seconds]
<azonenberg> Degi: Interesting, they didnt last time i checked
<azonenberg> Definitely gonna snag a few then