<azonenberg>
All back from service with the 2009-vintage resistive touchscreen replaced with a modern panel, the ancient core2quad motherboard running vista replaced with a modern mobo with an i7-10700E running win10 embedded
<azonenberg>
and the main acquisition board replaced with the current generation version
<azonenberg>
which reduces noise as well as fixing a frontend offset issue i had had for a while that i didn't want to repair because i knew it was gonna get replaced anyway
<d1b2>
<Darius> sounds a bit like a "my grandfathers axe" situation
<azonenberg>
the scope of theseus?
<d1b2>
<Darius> hehe
<azonenberg>
it's still the original chassis and power supply lol
<azonenberg>
and the trigger board was kept during this upgrade, since i had upgraded it to current generation when i first bought the scope
<azonenberg>
there's still one more round of upgrades to do in the future, some other component in the signal path has to be swapped to turn it into an 8Zi-B
<azonenberg>
which adds 2x 80 Gsps interleaving capability
<azonenberg>
(right now it's 4x 40 exclusively w/ no interleaving)
<monochroma>
golden bridge board
<azonenberg>
lol
<monochroma>
(that might literally be it, iirc my DDAs have bridge boards to sync channels together)
<azonenberg>
there is a bridge board you can purchase external
<azonenberg>
it's like $10K for the pair which is a bit of a ripoff
<d1b2>
<Darius> that's a lotta samples per second
<azonenberg>
yeah but if i want to be able to look at things like modern PAM4 serdes i'll need that
<azonenberg>
or 25/100G ethernet
<azonenberg>
(I'd want a bandwidth upgrade too probably)
<azonenberg>
The scope in its current state is great out to 10ish Gbps but one day i'm going to want to go faster
<josuah>
rackable lab equipment... such a great idea!
<josuah>
I am reading a bit about PAM4... so we are hitting the limits of what can be acheived at physical level, so need to be clever, as well as need incredible lab equipment.
<josuah>
even as a carrier frequency for radio signals, 100G is very high! ^_^'
<azonenberg>
josuah: oh?
<azonenberg>
josuah: and yeah when you have as much gear as i do in as few square feet of lab space
<azonenberg>
racking it - or in general going vertical - is the only practical option
<josuah>
I ordered one scope from them, said thanks and said that I wanted to try it with scopehal-apps, they asked more info about it
<azonenberg>
oh cool
<josuah>
so I pointed them this link as well as your public contact info
<azonenberg>
ah cool
<miek>
fwiw, their track record with open source isn't great. one of the big promises in their original crowdsourcing campaign was to upstream sigrok support, but instead they released with a closed source fork of sigrok/pulseview. it took a lot of work to get them to actually release the code, and it was such a mess nothing could be upstreamed. hopefully they're better these days
<josuah>
miek: yes, that too :(
<josuah>
they might be trying to fork scopehal-apps right now :D
<josuah>
only to later realize they do not have the manpower to keep-up with its evolution
<azonenberg>
lol yes. what we'd much prefer is to work *with* vendors
<azonenberg>
Oh, so another blocker just cleared for upcoming scopehal hardware R&D
<azonenberg>
I have an XC7A200T-2FFG1156C shipping from digikey now, just got tracking
<azonenberg>
this FPGA has sixteen 6.6 Gbps capable SERDES lanes which means it's able to drive the lower speed grade AD9213 that Arjen bought for me months ago
<azonenberg>
So in the not too distant future I will probably start designing boards for each
<azonenberg>
I want to separate things so i have room to swap components out and make a modular scope for R&D
<azonenberg>
so one board with basically just the ADC and maybe some minimal signal conditioning
<azonenberg>
one board with just the FPGA, RAM, and some kind of high bandwidth PC interface (10GbE?)
<josuah>
still heading toward that rackable headless oscilloscope?
<azonenberg>
Yes. that's always been the endgame, but slow progress b/c other projects and component shortage
<azonenberg>
So i want to build a frontend board, an adc board, and an fpga board over the next few months and test them all with each other
<josuah>
I slowly discover how much supply chains are critical
<azonenberg>
and in theory once i've iterated a bit on the frontend, we should have a solid 1 GHz 5 Gsps 12 bit oscilloscope design we can scale up to a multichannel instrument
<azonenberg>
anyway i'll let you guys know when i've cleared my plate of higher priority items and am ready to start
<azonenberg>
i think i'll start with the FPGA board since that's all digital and straightforward
<d1b2>
<Aleksorsist> How long until your Artix ultrascales come in? Artix 7 can't drive 10GbE directly so I imagine you'd need another FPGA or a xaui chip.
<azonenberg>
aleksorsist: last estimate i saw was january 5th 2024
<azonenberg>
the plan was to use the 7a200t with either 1gbe or xaui in the meantime, this is a prototyping platform and not intended to be the final scope or anything resembling it
<azonenberg>
And that module is off the table, it looks like it only has two ddr4 chips
<azonenberg>
i'm looking at two *sodimms* lol
<azonenberg>
of ddr3 on the prototype and ddr4 on the ultrascale based final version
<d1b2>
<Aleksorsist> Makes sense, I'm very interested in the xaui route since I'm unfortunately fully committed to the artix 7
<azonenberg>
5 Gsps * 12 bits = 60 Gbps of data. So right on the edge of what's plausible to fit in a single channel of ddr3 on the prototype
<azonenberg>
i'd likely dual channel to provide headroom
<azonenberg>
with ddr4 it might be possible to single channel the 5/6 Gsps version but the 10 Gsps version (120 Gbps) will likely need dual channel
<azonenberg>
and again this is memory channels *per adc*
<azonenberg>
we're talking an xcau25p or similar per adc
<azonenberg>
So it's going to be a lot of fpgas and a lot of ram lol
<d1b2>
<Aleksorsist> My next step is an Artix ultrascale with a sodimm of DDR4 and https://www.ti.com/product/ADC12QJ1600 for max 1.6 gsps on each channel for a total of 8*12= 96 gsps (past limit of 4 lanes of PCIe 3)
<d1b2>
<Aleksorsist> Sounds like my next scope's FPGA architecture is similar enough to one channel of yours
<d1b2>
<Aleksorsist> I'd suggest we could come up with a common artix ultrascale architecture
<d1b2>
<Aleksorsist> I don't think an Artix ultrascale can do two sodimms though
<azonenberg>
let me look again, sec
<azonenberg>
xcau25p in ffvb676 is 72 HD, 208 HP, 12 GTY. so yeah it can do one sodimm
<azonenberg>
and in the -1 speed grade whic hi ordered, it can do 1866 in a single rank dimm or 1600 in a dual rank
<azonenberg>
Times 64 bits gives a max throughput of 119.4 / 102.4 Gbps respectively of memory bandwidth
<azonenberg>
Which makes sense, thinking a bit more the artix ultrascale+ version is what i had planned for the 1 GHz 5-6 Gsps scope
<azonenberg>
and the 2 GHz 10 Gsps would be kintex based
<d1b2>
<Aleksorsist> I was also looking at ffvb676 doing one sodimm, four lanes of jesd and four lanes of pcie
<azonenberg>
Ok yeah so very similar. in my case i was looking at 12 lanes of jesd to the fpga
<azonenberg>
(the adc is 12 lanes)
<azonenberg>
then LVDS from it to the root FPGA which would do triggering and 10gbe
<d1b2>
<Aleksorsist> Oh, iirc the 676 has 8 xcvr lanes
<azonenberg>
due to not having any more serdes left
<azonenberg>
no, the au25p in fffvb676 has 12
<d1b2>
<Aleksorsist> Ah, I was looking at au10p
<azonenberg>
For the higher end scope with the 10 Gsps ADC i'd need dual channel ddr4, and so for that i'm thinking of the ku035 in fbva900 or ffva1156
<azonenberg>
both of which have 16 transceiver lanes and 364 / 416 HP IOs respectively
<azonenberg>
that would give me 12 for the adc and 4 to use for connection to the root (i probably wouldn't use all 4)
<azonenberg>
but perhaps i could have one to each of the three other channels for cross triggering or something, idk
<azonenberg>
i havent figured out what the trigger system would look like yet
<d1b2>
<Aleksorsist> But yah, it's a little ways away for both of us I think but we should definitely trade schematic notes once we get to designing with the artix ultrascale
<azonenberg>
absolutely
<azonenberg>
the point of the 7a200t based platform was to gain experience with the adc and jesd204 in general, and to validate the frontend
<azonenberg>
not to be the final system
<d1b2>
<Aleksorsist> Gotya, looking forward to hearing your work on jesd, I haven't touched it before
<azonenberg>
Me neither
<d1b2>
<Aleksorsist> And if you end up doing some xaui stuff with the artix 7 let me know
<azonenberg>
My plan is to put a 1000baseT RGMII PHY on the base board with the fpga
<azonenberg>
then have the last four GTPs pinned out to a samtec q-strip
<azonenberg>
i may or may not bother putting a xaui chip on there, i have a ton of TLK10232s i'm never going to use
<azonenberg>
but idk if its worth the effort given this is a prototype
<azonenberg>
it may make more sense to spend the time working on the next gen platform at that point
<d1b2>
<Aleksorsist> Similar again to my xaui plans, I've got four high speed lanes and a couple io reserved on an m.2 for later
<azonenberg>
The other thing i have to do is spend more time on my fpga TCP stack
<d1b2>
<Aleksorsist> Also fair, xaui is a bit of a dead end given everything else is an easy direct connection
<azonenberg>
if memory serves me right it's functional as long as you never drop a packet from FPGA to client
<azonenberg>
but it doesnt implement retransmits in that direction
<d1b2>
<Aleksorsist> Ah, TCP is a pain that way, I choose to do UDP when I was playing around with rgmii from an foga
<azonenberg>
yeah udp is easier but then you have to roll your own retransmit protocol if a packet is lost
<azonenberg>
and it ends up basically being the same
<azonenberg>
aleksorsist: I do kinda wish xilinx hadn't killed the xc7a350t
<azonenberg>
they probably didnt want it competing with kintexes
<d1b2>
<Aleksorsist> There was a 350t? That's wild
<azonenberg>
it never launchee
<azonenberg>
launched*
<azonenberg>
but was mentioned in a bunch of prerelease docs
<azonenberg>
this is why the 7a200t in the largest (ffg1156) package has a bunch of NC pins
<azonenberg>
those were to have been additional IO banks in the 350t
<d1b2>
<Aleksorsist> There's 3 au10p in stock right now at mouser btw, I'm thinking of grabbing one tonight
<azonenberg>
Go for it. The au10p is too small for the stuff i'm interested in
<d1b2>
<Aleksorsist> Makes sense since you're doing all the triggering and stuff in there
<azonenberg>
So thats an open question
<azonenberg>
My initial concept was to do some kind of pre-triggering to distill the full rate digital data stream down to something less heavyweight
<azonenberg>
then send that reduced data - whatever it is - to the top level FPGA
<d1b2>
<Aleksorsist> Seems like the right call to not have to stream full rate data to the main fpga
<azonenberg>
which will handle the final triggering and the 10GbE interface
<azonenberg>
it's not possible
<azonenberg>
its not just simplifying things
<d1b2>
<Aleksorsist> Yah, you're already using all 12 gtys
<azonenberg>
the only way i could get full rate data into the main FPGA, for a 4 channel scope, is if i have 48 GTs on a single giant virtex
<azonenberg>
and like eight sodimms of ddr4 hanging off it
<azonenberg>
and if i want to do a 6/8 channel design even that becomes impossible
<d1b2>
<Aleksorsist> Def better to have per channel modules imo
<azonenberg>
so it has to be a hierarchical structure and thus the paths up to the root have to be skinnier
<azonenberg>
Yeah
<azonenberg>
The only question is exactly how to do the breakdown of the data between the various subsystems
<azonenberg>
and also how to get good low latency trigger sync across all of the modules so they all trigger at the same time
<d1b2>
<Aleksorsist> That's tricky, my first thought is to do an edge trigger on the first FPGA since almost all the more complicated triggers are based off of edges
<azonenberg>
accounting for trace/cable latency
<d1b2>
<Aleksorsist> Oof yah, clocking will be a challenge
<azonenberg>
Clocking is easy actually
<azonenberg>
nice stable OCXO on the root board then a multi channel PLL with adjustable phase on each output
<azonenberg>
feed each leg to one channel board as an LVDS pair
<d1b2>
<Aleksorsist> Oh then what makes the trigger sync hard?
<azonenberg>
All of the clock domain crossing and such will add nondeterminism to the latency
<azonenberg>
so if you want to maintain sub sample alignment between channels it will get tricky
<azonenberg>
This is something i'm going to have to spend more time thinking about, but now is not the time
<d1b2>
<Aleksorsist> Ah, advanced FPGA voodoo
<azonenberg>
Anyway generally speaking, few triggers are both fast and multichannel
<azonenberg>
(brb)
azonenberg has left #scopehal [#scopehal]
azonenberg has joined #scopehal
<azonenberg>
ok
<azonenberg>
anyway, so my thought was that low speed triggers like i2c etc would be done on the root fpga
<azonenberg>
with the channel FPGAs decimating the data then sending sub-rate digital samples back to the root
<azonenberg>
(and thresholding)
<azonenberg>
Higher speed serial triggers like, say, 8B10B would be implemented in gateware on the channel FPGA and just send a sync pulse to the root
<azonenberg>
edge triggering, pulse width, etc are all single channel and trivial
<azonenberg>
So the hard part would come if you wanted to do a multi channel high speed trigger
<azonenberg>
as an example (although the 1 GHz scope is too slow for this to be an issue) a multi lane PCIe link
<azonenberg>
if you wanted to trigger on a pcie x2 or x4 link
<azonenberg>
when it hits a particular data sequence
<azonenberg>
but for these scopes i cant think of any multi lane serial protocol that you'd want to work with in 1-2 GHz of bandwidth
<d1b2>
<Aleksorsist> Sdio comes to mind
<azonenberg>
That's something you would normally use with a logic analyzer though
<azonenberg>
All of the MSO inputs will go to the root FPGA
<azonenberg>
so you can do arbitrarily complex triggering of digital channels on the single FPGA
<d1b2>
<Aleksorsist> Ah, going to add a digital section too
<azonenberg>
(root will double as a MSO)
<azonenberg>
yeah why not, i'm gonna have this big fpga with the serdes all used but most of the GPIO wasted
<azonenberg>
so i'll throw some ddr on there and some LVDS inputs and connect some logic pods
<azonenberg>
i already have a logic pod design, i want to do a second generation of it that's smaller but it's something i'm pretty happy with
<d1b2>
<Aleksorsist> Nice, may as well at that point
<azonenberg>
it'll be 5 Gsps / 1.25 Gbps max data rate
<azonenberg>
there will be two pods, MEAD (50 ohm coaxial input, for higher speed using transmission line probes or active probes) and CONWAY (high impedance input, details TBD)
<azonenberg>
which will be drop in compatible at the scope side
<azonenberg>
I already have prototypes of MEAD although it's bulky and i think i can make it smaller
<azonenberg>
i have not tried to build CONWAY yet
<azonenberg>
MEAD has a B&W LCD on the top of the pod, btw
<azonenberg>
which displays channel names (which sync w/ scopehal) and attenuations
<azonenberg>
since color coding doesnt scale to a dozen channels or more
<azonenberg>
It also has an 8 channel i2c DAC allowing per channel thresholding
<azonenberg>
anyway, so yeah the ultimate plan for VOLLUM, the first ad9213 based scope, is 4-8 channel modules each with an 5-6 Gsps ad9213, a 1 GHz frontend, an artix ultrascale+, a sodimm of ddr4
<azonenberg>
and then the root FPGA will connect to all of the channel modules plus 1-2 MEAD/CONWAY pods and have 10GbE to the outside world
<azonenberg>
exact max channel count depends on PCB size, i want it to fit in 1U
<d1b2>
<Aleksorsist> I really like the lcd for channel names, that's definitely a big frustration with LAs using lots of signals
<azonenberg>
Yeah
<azonenberg>
It works, it's just larger than i want
<d1b2>
<azonenberg> these were intended for my MAXWELL logic analyzer that never got built
<d1b2>
<azonenberg> but I still have the pods, and i intend to use them as the MSO for my next generation of scopes. I will probably make some changes for production though
<d1b2>
<azonenberg> one thing i'm on the fence about is the choice of MMCX as the input connector. I don't like how similar MMCX and SMPM look
<d1b2>
<azonenberg> but SMPM costs more
<d1b2>
<azonenberg> so the question is, do i want to go all SMPM for consistency even if it raises the price by a biT?
<d1b2>
<azonenberg> another option is of course to have MMCX based low cost probes
<d1b2>
<Aleksorsist> That PCB is beautiful!
<d1b2>
<Aleksorsist> I'd say consistency is best once you're already targeting high end professional users
<azonenberg>
Yes exactly. I'm not aiming at the folks who would otherwise buy a rigol
<azonenberg>
The current ones are MMCX but i think i'll move away from that
<azonenberg>
The other thing i still want to do is come up with a good high impedance solder in logic analyzer probe