<_whitenotifier-1>
[stm32-cpp] azonenberg pushed 1 commit to master [+0/-0/±2] https://git.io/J17KY
<_whitenotifier-1>
[stm32-cpp] azonenberg 08b45ac - Fixed some STM32F031 constructor stuff
Degi_ has joined #scopehal
Degi has quit [Ping timeout: 268 seconds]
Degi_ is now known as Degi
<d1b2>
<Aleksorsist> Hi Everyone! I'm Aleksa, the designer of ThunderScope, an open source oscilloscope that streams all of its sample data to your PC via Thunderbolt. I'd like to add support for it to GLScopeClient and am looking for someone familiar with the codebase who'd be open to helping me out - I'd be happy to compensate you for your time!
<mxshift>
What protocol does ThunderScope use? I'm assuming it's not going to be SCPI
<d1b2>
<Aleksorsist> Custom protocol for scope hardware control, though that can easily be changed to work with SCPI commands. These commands, as well as triggered sample data are currently sent to and from the UI via a named pipe.
<azonenberg>
aleksorsist: My recommendation is that the ultimate interface be via a pair of TCP sockets
<azonenberg>
one using SCPI for control plane, and another raw binary for waveform data. This is what I do for the PicoScope
<azonenberg>
Anything requiring custom hardware drivers (i.e. scope does not have USBTMC or Ethernet natively on it) I try to move outside the libscopehal core
<azonenberg>
because otherwise you're compiling dozens of drivers in and pulling in a ton of dependencies most users won't require
<azonenberg>
having a server application that's separate lets you keep all the low level hardware details there
<azonenberg>
then libscopehal can use the network interface as an API for the instrument
<d1b2>
<Aleksorsist> So it would be Hardware <--PCIe--> ThunderScope Specific Software <--TCP--> libscopehal (which supports using TCP for SCPI control and trigger data already)?
<azonenberg>
You would still need some driver code in libscopehal because your bridge server is not going to support the exact same set of commands, bit depths, sample rates, etc as a PicoScope
<azonenberg>
but you could probably copy paste the PicoScope driver in libscopehal and make relatively small changes to it
<d1b2>
<Aleksorsist> That sounds like a great starting point! Then I just have to set up the TCP stuff on the TS software side
Bird|ghosted has joined #scopehal
<d1b2>
<Aleksorsist> Is the bandwidth a concern, can local TCP ports like this transfer 1 GB/s between programs?
<azonenberg>
I mean, on a 386? probably not :P
<azonenberg>
on a modern CPU, shouldn't be an issue
<azonenberg>
This would actually be a fun performance stress test for glscopeclient. This is going to be the highest volume of data anyone's tried throwing at it to date AFAIK
<azonenberg>
my PicoScope tops out around 2-3 Gbps
<azonenberg>
So we're likely going to find some room for optimization
<azonenberg>
I'm actually working on an OpenCL based renderer now as an alternative to the compute shader based renderer I have now
Bird|otherbox has quit [Ping timeout: 256 seconds]
<d1b2>
<Aleksorsist> Awesome, I'll be happy to throw as much data as I can at it!
<d1b2>
<Aleksorsist> This a USB 3 picoscope? Since those numbers are comparable to my first prototype's bandwidth, which used an FT601 for USB 3.
<azonenberg>
Yes, it's a 6824E
<azonenberg>
Pico has been a good friend of the project
<azonenberg>
They sent me the scope at no cost specifically to use as a dev unit
<d1b2>
<Aleksorsist> Just looked it up, sweet bit of kit!
<azonenberg>
Yeah, MSRP for the configuration I got including MSO probes etc is like $15K. I wasn't going to say no to a free one lol
<azonenberg>
even if i did have to do a bit of coding to justify it :p
<azonenberg>
I have much higher bandwidth scopes but i actually find myself using it quite a bit because of the deep memory
<d1b2>
<Aleksorsist> Off this particular topic, What was the kintex part you were thinking of using again?
<azonenberg>
My main general purpose bench scope is a Teledyne LeCroy WaveRunner 8404M-MS which has much better analog performance (20 Gsps * 4 channels / 40 Gsps * 2 channels, 4 GHz BW) and 16 MSO channels at 1.25 Gsps
<azonenberg>
But it only does 128M points memory max on the analog channels and I think 64M max on the digital
<azonenberg>
on the PicoScope I do 1G point digital captures routinel
<azonenberg>
Which is awesome for studying behavior of a digital system over a long time, potentially several seconds, without missing anything
<d1b2>
<Aleksorsist> Cuz I just had a XC7K160T-2FFG676C fall into my lap today, soldered onto a board, but that can be fixed lol
<azonenberg>
I have several projects in mind using different kintexes
<azonenberg>
I have XC7K70T-2FBG484C, XC7K160T-2FBG484C, XC7K160T-2FFG676C, XC7A100T-1FFG1156C (or is it a 2? i forget) on order now for different projects
<azonenberg>
as well as some spartan7s
<azonenberg>
They have ETAs ranging from next month to next summer
<azonenberg>
And if you want to desolder and reball that chip, go for it. I generally don't use pulled chips because a) the process is labor intensive and I'm short on time between baby and work
<azonenberg>
and b) there's always the chance of something going wrong
<azonenberg>
and I don't want to risk potentially thousands of dollars of other parts on an 8+ layer PCB with an FPGA of unknown vintage
<d1b2>
<Aleksorsist> I really like using modules for that reason, might whip one up for this part after I finish my Artix based one
<azonenberg>
Yeah go for it
<azonenberg>
I have yet to figure out the detail of how the architecture for ZENNECK, my planned 500 MHz scope, is going to work PCB wise
<d1b2>
<Darius> local TCP sockets should have short circuit copies, they are almost "free"
<d1b2>
<Aleksorsist> Keysight puts all the BGA parts on the 1000x series on a module so they save some cost on the main board, I like the approach and might copy it on a design with a more intensive layout
<azonenberg>
the general plan is to have four or eight analog channel modules, depending on how many I can fit side by side in a 19" chassis and whether I go flat pizza box or vertical eurocard form factor (or something in between, like 2U with custom subrack)
<d1b2>
<Aleksorsist> That's good to hear, guess that makes them a great way to communicate across programs
<d1b2>
<Aleksorsist> I really dig the 8 channel idea
<azonenberg>
Each analog module will consist of one or more boards containing a 500 MHz 50 ohm front end, an AD9213 in the 6 Gsps speed grade but clocked at 5 Gsps, whatever clocking is needed for the ADC
<azonenberg>
an XC7A200T in FFG1156
<azonenberg>
i think dual channel DDR3, to keep up with the bandwidth coming off the ADC
<azonenberg>
unsure if the frontend, ADC, and FPGA will be 3 separate boards or some will be combined
<azonenberg>
The FPGA will have 12 GTPs to the JESD204B ADC and then one to the backplane for pulling data off the board. the other 3 are uncommitted and might be used for triggering, the backplane, or something else TBD
<azonenberg>
Then the backplane will have a microcontroller doing high level management stuff and a Kintex-7 to aggregate the data from each channel and stream it out the 10/40GbE uplink to the outside world
<azonenberg>
The other advantage of making the scope modular like this is that I don't need to buy four or eight AD9213s during R&D
<azonenberg>
My wallet will be very happy about that :D
<azonenberg>
Although digikey seems to have dropped the prices - it's "only" $1680 now. And they even have two in stock despite the chip shortage
<azonenberg>
I guess people aren't in a hurry to hoard $1600 ADCs lol
<d1b2>
<Aleksorsist> Exactly! I did my whole first prototype all modular, and did all the dev with only one front end connected
<azonenberg>
this is my frontend prototype from a while ago
<azonenberg>
theoretically capable of 500 MHz but the board is populated with a 100 MHz antialising filter as that's what I initially targeted
<azonenberg>
and it has a few bugs I need to fix in the next spin
<d1b2>
<Aleksorsist> Why such a big artix part for the FE module? Seems like it wouln't need that much IO (or logic either)?
<azonenberg>
Because nothing smaller can run twelve 6.25 Gbps SERDES lanes to the ADC plus enough DDR to buffer that much data
<azonenberg>
5 Gsps * 8b/10b overhead * 12 bit resolution = a buttload of data :p
<azonenberg>
oh and i can't even use some of the smaller ultrascales with 12 GTXs because i also need at least one more transceiver for talking to the backplane
<azonenberg>
I probably wouldn't be using most of the logic, but I'd be using almost all of the I/O
<d1b2>
<Aleksorsist> Ah, limited by the SERDES count
<azonenberg>
Yeah but also DDR pins
<azonenberg>
Let's see... the data rate coming off the ADC is 60 Gbps
<d1b2>
<Aleksorsist> Just dual channel DDR3? that might not be enough for that data rate
<azonenberg>
The Artix I plan to use is a -1 speed which can do 800 MT/s DDR3 or 667 DDR3L
<d1b2>
<Aleksorsist> I had to run 2 x16 chips just to get 1 GB/s reads and writes going simultaneously
<azonenberg>
Times a 64 bit SODIMM gives a raw bandwidth before overhead of 51.2 or 42.68 Gbps per channel
<azonenberg>
Dual channel gives 102.4 and 85.36 Gbps respectively
<d1b2>
<Aleksorsist> Oh you mean two SODIMMS
<azonenberg>
Yres
<azonenberg>
you see why I'm going with FFG1156 now? :)
<d1b2>
<Aleksorsist> Oh yes lol
<azonenberg>
each sodimm needs two banks for data and one for command/address
<d1b2>
<Aleksorsist> Two sodimms per channel is going to be wild
<azonenberg>
So we'll be looking at six I/O banks (300 pins, although the command/address isn't quite full) and twelve GTPs just to handle the data coming off the ADC
<azonenberg>
and this is for the "entry level" version that uses artixes and the lower speed AD9213
<azonenberg>
the full speed AD9213 will need twelve 12.5 Gbps SERDES lanes to handle the 10 Gsps output data
<mxshift>
At work, we're currently using an 8ch tek scope and could easily use 2-3 more channels as we're doing bringup of AMD CPUs
<azonenberg>
and then if i ever build that 40 Gsps monster, you're looking at 480 Gbps of data coming off the ADCs per channel
<azonenberg>
half a Tbps per channel is going to be a buttload of DDR4
<azonenberg>
(of course at digikey prices that scope would also be >$100K of ADCs sooooo...)
<mxshift>
If I could get 4 ThunderScopes with a synchronized trigger, that'd be quite useful right now ;)
<azonenberg>
mxshift: you do know glscopeclient can sync multiple supported instruments right? it's still very experimental, but combining two MSO6's should be within the realm of feasibility especially if you don't mind some time with the code troubleshooting
<mxshift>
currently only have 1 MSO6 rented
<azonenberg>
i was able to sync a MSO64 and a WaveRunner 8404-MS well enough to get a nice looking eye pattern with _P into one scope and _N into the other. Sure, only at 1.25 Gbps
<azonenberg>
but that's still pretty good sync :p
<mxshift>
hmm, might be worth adding to our rental order. We've got a Tek power rail probe coming.
<mxshift>
Apparently AMD Rome and Milan are very, very power sensitive
<d1b2>
<Aleksorsist> I'll have to look into alternate clocking setups to make it work, but it would be a killer feature to load up a mobo full of PCIe scopes and have 12 channels that way!
<azonenberg>
aleksorsist: basically the way glscopeclient's architecture works for this is, you feed all of the scopes a common refclk so their PLLs are synced, configure them to use said refclk if it's not automatic
<azonenberg>
then you pick one scope, define it "primary" (trigger source for all of the "secondary" instruments)
<d1b2>
<Aleksorsist> Right now I don't have a reference oscillator I can send over to another board, since I'm using an all in one chip
<azonenberg>
take a signal like a PRBS or anything with low autocorrelation (i.e. unambiguous phase for shifted copies of itself)
<d1b2>
<Aleksorsist> But if I switch to a regular PLL that'll work a treat!
<azonenberg>
touch a probe from the primary and the first secondary to the same point
<azonenberg>
it'll collect a waveform on each scope and measure the trigger delay
<azonenberg>
then repeat for the next secondary
<azonenberg>
and then calibrate out that delay so all of the waveforms display aligned
<azonenberg>
It doesn't interact well with per-channel fine deskew, so you have to do that manually after the sync is done, and there's some general quirks to iron out
<azonenberg>
But i've done some tests to, for example, decode a DDR3 command bus with two of my scopes
<azonenberg>
mxshift: incidentally i'm surprised you went with tek gear and not LeCroy after all of the bogatin stuff you were watching
<azonenberg>
I <3 my RP4030
<azonenberg>
I wish I could show you some of the traces I've got off power rails on customer boards with it. I could see individual AES rounds on a [redacted]
<mxshift>
LeCroy is sending us a trial set of gear....
<azonenberg>
just from looking at dips in vcore, not even with a shunt resistor
<mxshift>
Our EEs have more experience with Tek gear
<azonenberg>
I did initial measurements with a D420 active diff probe and while i could see some stuff in a spectrogram, the SNR compared to the RP4030 was just unbelievable
<azonenberg>
idk how many dB lower the noise floor was but it was astounding
<azonenberg>
And oh? Definitely try glscopeclient out with it
<azonenberg>
LeCroy is kinda our tier one platform because it's my daily driver
<azonenberg>
What scope are you getting from them? SDA 8Zi-B series?
<mxshift>
AMD SP3 has 10 supplies. One of them is 0.9V +/- 20mV DC +/- 15mV AC.
<azonenberg>
If you mostly wanted it for power measurements maybe a WavePro HD would be the better choice. You can get 4+ GHz BW and 12 bit resolution, the extra LSBs might help a lot for subtle power rail noise
<azonenberg>
And glscopeclient has a really nice spectrogram feature that is good for looking at noise on power rails, you can find all of the spectral lines standing out and correlate it with activity elsewhere in the system
<azonenberg>
so you can see noise when, say, a pcie link comes out of sleep mode or something
<mxshift>
I'm not following the discussion. I know we're looking for both a 6GHz and 65GHz scope
<azonenberg>
The 65 GHz is likely a LabMaster 10Zi then. the SDA 8Zi-B tops out at 30 GHz
<azonenberg>
but it sounds like what you'd need for pcie gen4 SI etc
<azonenberg>
the 6 GHz could be a WavePro 604HD, which would be an excellent choice for the power rail stuff
<mxshift>
and 200GBASE-SR4
<azonenberg>
I don't know much about 200G wrt the PHYs
<azonenberg>
if it's NRZ, PAM4, or something else, how many lanes how fast, etc
<azonenberg>
Guessing from the SR4 name that it's 4x 56G PAM4 lanes?
<azonenberg>
electrically that is, then probably 4x 56G NRZ over the wire
<azonenberg>
(or are they doing PAM4 on the laser side too?)
<mxshift>
yeah, 4x 56G PAM4
<azonenberg>
I would love to add LabMaster support to glscopeclient one of these days *hint hint*
<mxshift>
oh, I meant -KR4. We're doing -SR4 for uplinks out of our rack but -KR4 within the rack
<azonenberg>
(oh and if you can get me any PAM4 waveform captures that aren't NDA encumbered, that would be great for future testing purposes)
<mxshift>
I'm sure I can eventually. We'll be doing 100GBASE-KR4 first
<azonenberg>
I have some code to generate PAM4 waveforms from a digital PRBS but would like at least a few "real" waveforms to ground truth my algorithms against
<azonenberg>
That's 28G NRZ per lane right?
<mxshift>
yep
<azonenberg>
Nice. My SDA 816Zi can barely go to 10G NRZ, but for now 10GbE is the fastest I work with
<azonenberg>
it can be upgraded out to 20/25/30 GHz in the future though
<azonenberg>
Oh also, if you ever get your hands on a HDA125 I'd love to hear your thoughts on it
<azonenberg>
I'm actually wondering if they have a next gen version of it coming out at some point. It's a 12.5 Gsps logic analyzer that's good out to I think 6 Gbps data rates per pin ,but it's oldish hardware (released 2016)
<azonenberg>
connects to a scope to provide high speed MSO capabilities for things like DDR command bus capture while you have the analog probes looking at DQ/DQS
<azonenberg>
I'd love to add support for it to glscopeclient too, i think it might use the same SCPI API as the MSO probes on their slower scopes
<azonenberg>
But who knows until i actually try talking to it
Kliment has quit [*.net *.split]
miek has quit [*.net *.split]
florolf has quit [*.net *.split]
Stary has quit [*.net *.split]
Kliment has joined #scopehal
florolf has joined #scopehal
miek has joined #scopehal
Stary has joined #scopehal
Fridtjof has quit [*.net *.split]
Ekho has quit [*.net *.split]
electronic_eel has quit [*.net *.split]
_whitenotifier-1 has quit [*.net *.split]
electronic_eel has joined #scopehal
Fridtjof has joined #scopehal
Ekho has joined #scopehal
Famine_ has quit [Read error: Connection reset by peer]
massi has joined #scopehal
bvernoux has joined #scopehal
elms has quit [Ping timeout: 264 seconds]
_florent_ has quit [Ping timeout: 260 seconds]
sorear has quit [Ping timeout: 246 seconds]
mxshift has quit [Ping timeout: 260 seconds]
JSharp has quit [Ping timeout: 264 seconds]
esden_ has joined #scopehal
esden has quit [Ping timeout: 265 seconds]
esden_ is now known as esden
elms has joined #scopehal
JSharp has joined #scopehal
sorear has joined #scopehal
mxshift has joined #scopehal
_florent_ has joined #scopehal
someone-else has joined #scopehal
someone-else has quit [Client Quit]
someone-else has joined #scopehal
someone-else has quit [Quit: Connection closed]
someone-else has joined #scopehal
bvernoux has quit [Ping timeout: 264 seconds]
bvernoux has joined #scopehal
someone-else has quit [Quit: Connection closed]
bvernoux has quit [Ping timeout: 265 seconds]
bvernoux has joined #scopehal
<Degi>
How can waveform captures be NDA encumbered?
someone-else has joined #scopehal
<azonenberg>
Degi: if whoever created them is bound by some kind of NDA regarding the protocol or similar, or performance figures of the chip in question, it's plausible. IDK, not a lawyer
<azonenberg>
I just want test data i can freely redistribute :)
<someone-else>
what's the slowest data rate supposed to be used with pam4? 50gbps?
<azonenberg>
I'm not sure what the slowest standard using pam4 is
<azonenberg>
I'm pretty sure i've seen at least one pam4 serdes capable of going down to 40 Gbps
<azonenberg>
but that just might be a limit of how slow the PLL can go rather than anyone having a protocol that does that
<someone-else>
so, that's 20 or 25gbaud then
<someone-else>
yep
<someone-else>
BTW, TI apparently has a not-yet-public DS560DF810 which supports PAM4 up to 56gbps
<someone-else>
and since part naming suggests it's related to DS280DF810 it might have a built-in PRBS generator
<someone-else>
PRBS generator might only support NRZ though
<someone-else>
I have a board with DS250DF810, hoping to see some 25gbps prbs from it soon
<azonenberg>
I see stuff going back to 2019 about it
<someone-else>
DS560DF810 specifically?
<azonenberg>
yeah i was just googling the part number
<azonenberg>
just e2e forum posts, mostly locked quickly
<azonenberg>
sounds like they don't want to talk about it
<azonenberg>
anyway, it's not just waveform generation that's the hard part, it's the capture
<azonenberg>
My SDA 816Zi only does 40 Gsps which is... a bit light for 28 Gbaud data lol
<azonenberg>
When I upgrade it to the 816Zi-B, it will be able to interleave from 4x 40 Gsps to 2x 80 Gsps
<azonenberg>
Which should be enough to actually do data recovery on 28G NRZ data (14 GHz fundamental) although the eye is gonna look sinusoidal as all the harmonics will be gone
<azonenberg>
theoretically I'd also be able to do data recovery on 56G PAM4 that way
<azonenberg>
But again the eye is gonna look like crap
<azonenberg>
Down the road I plan to upgrade bandwidth, the scope can be pushed out to 30 GHz although i probably won't go quite that far
<azonenberg>
But i'd like to get to at least 20 eventually
<someone-else>
yep
massi has quit [Remote host closed the connection]
<azonenberg>
but i actually already knew about the part
<azonenberg>
and how nice it was escaped me
<azonenberg>
I discovered it some weeks ago and had planned to use it as a splitter for the scope-as-VNA project
<azonenberg>
it's already on my BOM
<azonenberg>
When i get moving on that frequency extender board I'll order an extra and would love to decap
<azonenberg>
also see if you can find the referenced pending patent?
<Degi>
Huh, 26 $ per piece
<Degi>
I guess you can't get two 18 GHz RF amps and a resistive splitter for that price?
<azonenberg>
The issue was finding a splitter with good flatness that went to that bandwidth and down to ~DC
<azonenberg>
a lot of the double digit GHz splitters don't go that high
<azonenberg>
correction a lot of the resistive splitters
<azonenberg>
most of the double digit GHz ones are wilkinson or similar
<Degi>
Huh
<azonenberg>
since lower loss
<azonenberg>
and it's pretty rare that you actually have to go down to ~DC but also do double digit GHz
<azonenberg>
test equipment is about the only application :p
<Degi>
Hmm, maybe TDR moisture meters
<Degi>
But when the moisture is really finely divided
<azonenberg>
I would still consider that a T&M application
<Degi>
Hm yes, its basically a TDR scope without a display and some special cables
<bvernoux>
I have received my KC908 SDR/Spectrum Analyzer Upgraded ;)
bvernoux has quit [Ping timeout: 245 seconds]
<Degi>
Nice
<ericonr>
Aleksorsist: hello! azonenberg mentioned in #kicad that they are looking for someone to write a thunderscope interface to scopehal. I will be on vacation during december, and that's a project I would be interested in. Do you have specific plans or anything?
<d1b2>
<Aleksorsist> Hi! We don't have anything specific planned aside from getting our current processing software hooked up to GLScopeClient. It currently uses named pipes to connect to an electron based UI and we want to move it over to use two TCP sockets for SCPI commands and trigger data like the picoscope driver for scopehal.
<d1b2>
<Aleksorsist> I'd be happy to loan you a unit for development, DM me if you have any questions!
<ericonr>
Neat! I suppose I should look into how the current picoscope driver works :D
<d1b2>
<Aleksorsist> I'll be doing the same this week, we already use the boost c++ library so I've also been looking into boost.ASIO for setting up the sockets
<ericonr>
Oh heh, I just completed a project using ASIO, but it was UDP :p
<ericonr>
Hm, shipping might be complicated D: I live in Brazil...
<azonenberg>
ericonr: VPN or remote access to a dev box could also be an option if logistics of trasnportation are hard
<ericonr>
For all parties involved, it's probably best not to risk it; chances of being taxed would make this a significantly more expensive endeavor.
<azonenberg>
ericonr: aleksorsist indicated he was willing to pour a fair bit of budget into funding a driver, i think he can handle a few import duties
<d1b2>
<Aleksorsist> I wouldn't mind the excuse to set up a new dev box that you could remote into! And yes, I'd be more than happy to cover all costs you may incur taking delivery of the prototype, plus compensation for your time
<ericonr>
Sounds awesome! Can you share an invite to the discord group, please? That way I can actually contact Aleksorsist via DM to talk about this. I'm a bit busy this week, but I believe that after Wednesday we can discuss this with more detail.
<d1b2>
<Aleksorsist> I'll also be free after Wednesday this week, looking forward to chatting with you then
<ericonr>
Thanks!
<azonenberg>
ericonr: awesome. Feel free to DM with him directly or in the thunderscope channel to talk about logistics of getting dev units etc
<azonenberg>
but try to keep chat related to driver work in here
<azonenberg>
so everyone else here can stay up to speed with what's going on
<Degi>
Oh neat, its HMCAD1511 based
<Degi>
Huh, it has 13 bits internally?
<someone-else>
cool thing it can do up to 16x digital gain with no loss in snr
<Degi>
ooh
<someone-else>
and up to 50x with some modest loss
<Degi>
Hm yes
<someone-else>
so your frontend suddenly gets much simpler
<someone-else>
too bad it's only 350mhz bw or so
<Degi>
Yes, the HMCAD15xx parts are real nice for that
<Degi>
Hmm, thats limited by sample rate
<Degi>
(The chip can do 650 MHz IIRC)
<someone-else>
650mhz in only in non-interleaved mode or 250msps
<Degi>
IIRC you want low bandwidth to get good waveform representation but I think high bandwidth would be useful for data acquisition, like for cameras
<someone-else>
equivalent time sampling would get around that for repetitive signals
<Degi>
Does the bandwidth decrease with interleaving?
<Degi>
Can you do ET sampling without a special trigger circuit?
<someone-else>
yep, because of increased rc loading I think
<someone-else>
might be fixed with <50ohm impedance driver, dunno
<Degi>
Since the datasheet only mentions 650 MHz
<someone-else>
I did some investigating and found out about 350ish MHz bw in interleaved mode
<Degi>
Interesting
<someone-else>
can dig up some links if interested
<someone-else>
ET sampling is not that difficult
<someone-else>
programmable delay line or perhaps just a pll would suffice
<Degi>
My idea was to charge a capacitor for the time between trigger and clock cycle but that sounds less yanky yes
<someone-else>
there are nice digital lvpecl delay lines around
<someone-else>
not expensive
<Degi>
Hmm, maybe you can use one in the FPGA lol
<Degi>
(At least the ECP5 have 25 ps ones)
<someone-else>
there's also another way - have adc sample with the normal free-running clock and measure trigger delay relative to that via a fpga tdc
<someone-else>
10-50ps resolution fpga tdcs should be possible
<Degi>
I guess you could hook it to a SerDes IO to get a few GS/s
<Degi>
Hmm, would you do that in fabric
<someone-else>
yep
<Degi>
Like make a delay line in the FPGA which then gets sampled at some instant and you see how far the transition got?
<someone-else>
just fan out your signal via random fabric delays into a few dozen flip-flops and then calibrate that
<Degi>
I wonder how PVT invariant that is, like do you need to wait for it to warm up?
<someone-else>
not at all, hence calibration
<someone-else>
often
<Degi>
Hmm, I guess for calibration you could use a somewhat precise IO delay or some phase shifted clock and keep it entirely FPGA-based...
<someone-else>
delay line way is also possible via carry chains (since they usually have the lowest delays) but delay step will be higher this way
<someone-else>
(100ps+)
<Degi>
Hm yes, so sampling with a bunch of random LUTs gets some random delays which might be spaced apart in the 10 ps range?
<someone-else>
yep
<someone-else>
just need enough for a nice random distribution
<someone-else>
anyway, there are a lot of papers about fpga tdcs since they are popular in high energy physics experiments
<Degi>
That is a neat concept. I had problems getting my FPGA-based TDR over 40 GS/s but this way maybe I can get a bit more, if I can somehow calibrate the delay
<azonenberg>
Also JESD204B. Which I think is what we're going to see for most of the good ADCs in the future
<someone-else>
yeah
<Degi>
Hmm okay, the HMCAD1520 would only be like 30 % cheaper. Guess that's not worth the worse performance and hellish routing lol
<someone-else>
makes easy to change ADCs though
<Degi>
yes
<azonenberg>
That was my thought too
<someone-else>
btw, TI now has a $100ish adc with 5GHz FPBW
<Degi>
Maybe we could even have some common interface to swap out ADC boards
<Degi>
Ooh
<azonenberg>
So one proposed design would be to have four boards
<azonenberg>
backplane with kintex, 10GbE, top level clock distribution, and some trigger GPIOs or something
<azonenberg>
and 10 MHz in/out, OCXO, the works
<azonenberg>
then for each channel an FPGA board with FPGA and DDR
<azonenberg>
an ADC board with JESD204 and clock to the FPGA plus some management buses
<azonenberg>
and a frontend board
<someone-else>
looks good
<someone-else>
although lane count can be pretty different between ADCs
<azonenberg>
Yes. We'd probably design a common connector with a bunch of lanes and populate them starting at ID 0
<Degi>
Hm, like the AD9094 has 4 lanes and the AD9213 16, maybe you could have one board with four of AD9094?
<azonenberg>
The AD9213 is 16, but it can run with less
<Degi>
Like you could have a 16 channel scope
<someone-else>
perhaps one can route 4 per connector and then have an option to ADC board to span several connectors if needed
<azonenberg>
depending on clock rate and other stuff
<Degi>
hm yes
<azonenberg>
My proposed ZENNECK design would have used the 6 Gsps speed grade clocked at 5 Gsps
<Degi>
Ooh, the AD9213 even has GPIO. Maybe we can put an RGBW LED on there
<azonenberg>
which gives 12 bits * 5 Gsps = 60 Gbps of data split across 12 lanes at 5 Gbps upper layer throughput each, 6.25 GT/s after line coding overhead
<azonenberg>
The plan is to use an XC7A200T in FFG1156 with 12 lanes to the ADC and the other four to the backplane
<someone-else>
a lot of dram
<azonenberg>
although i will probably only use one of those lanes
<azonenberg>
Yes I was planning on dual channel ddr3 sodimms
<Degi>
Hmm, DDR3?
<azonenberg>
Yeah. Artix can't do DDR4
<azonenberg>
for that you have to go ultrascale and you're talking a $1000+ FPGA not a $450 one
<Degi>
Running DDR4 at slower speeds doesn't work? (Is DDR3 still being produced?)
<azonenberg>
No, DDR4 is a completely different i/o standard
<Degi>
ohh
<azonenberg>
that the io cells in 7 series can't do
<azonenberg>
It's not SSTL anymore, it's POD
<azonenberg>
DDR3 is still being produced, just not the new hotness
<azonenberg>
i bought a bunch of sodimms off newegg just the other day
<someone-else>
I've been thinking about a similar system but with 40gbe instead of 10gbe
<azonenberg>
I could easily throw 40G on there, but it depends on which kintex i use
<azonenberg>
and how many serdes lanes i have available
<someone-else>
which in theory would enable realtime streaming of adc data to host
<azonenberg>
not with any of my scopes it won't :p
<azonenberg>
VOLLUM, the next gen scope, will be 1-2 GHz target BW with a full speed grade 10 Gsps AD9213 per channel
<azonenberg>
That will be ultrascale territory
<someone-else>
well, it could be 4x 40gbe per AD9213 or something :-)
<azonenberg>
it will need a new frontend as well since the planned BLONDEL/DUDDELL/ZENNECK frontend is 500 MHz max
<azonenberg>
someone-else: at that point you start worrying about what's on the other end of that QSFP
<Degi>
Hmm, what if you want to save a bunch of channels to disk, that would be practical for that
<Degi>
And then you have like an array of a hundred PCIe 4 M.2 drives
<azonenberg>
And little details like the fact that even my overkill home network only has four 40G ports *total* on the cisco nexus core switch
<someone-else>
azonenberg: could be 4x computers if nothing else works
<Degi>
Maybe we can put a few M.2 drives on the sample FPGA boards
<Degi>
pseudo open drain sounds interesting, I wonder why they don't just terminate DDR4 to ground at this point
<someone-else>
Degi: might need new M.2 drives (if flash) every couple of days or so :-)
<Degi>
Yeah probably, though you could have RAM too and switch between modes I guess
<Degi>
I guess this would need a pricier FPGA with more lanes though
<someone-else>
if all else fails, we can perhaps just stream that into the internet
<someone-else>
and let someone else sort it out
<Degi>
We'll just lay an SMA cable to the next DC
<someone-else>
might lose too much signal if long
<Degi>
Hmm, air dielectric and superconducting
<someone-else>
maybe optical..
<someone-else>
but OAAS sounds trendier, I think
<Degi>
Oscilloscope as a service? The customers stream the data over the internet to a DAC, which then sends it to the scope and then it gets sent back?
<someone-else>
sure why not
<Degi>
Hmm, waveform generator should be renamed to Descilloscope