<Degi>
Hmm, I guess maybe not so good for a scope since it has built-in digital conversion and the interface would be too slow for full bandwidth anyways
<Degi>
(Nevermind that last point, I miscalculated, with JESD204C it should have 198 Gbps link bandwidth and 192 Gbps data bandwidth)
<Degi>
Actually the built-in digital conversion can be skipped too, this might be neat for a 4 channel scope
bvernoux has joined #scopehal
bgamari has quit [*.net *.split]
bgamari has joined #scopehal
* azonenberg
looks
<azonenberg>
quad 16 bit 12 Gsps dac, 12 bit 4 gsps adc?
<azonenberg>
looks expensive
<azonenberg>
serdes out to 24.75 Gbps... you'd need ultrascale+ transceivers to keep up with it
<azonenberg>
that is also fast enough i couldnt even properly assess it with my scope lol
<azonenberg>
digikey lists it as a rf frontend, not an adc. which is probably why i hadnt seen it before
<azonenberg>
It's "only" $2500 and is in stock at digikey
<azonenberg>
(in the jesd204c version)
<azonenberg>
The xcku3p or 5p both have 16x 32.75 Gbps GTY transceivers, enough to keep up with it
<azonenberg>
They also have 208 max HP I/O which can do DDR4 2400 in the -2 or -3 speed grade
<azonenberg>
(assuming you pick the right package)
<azonenberg>
i think that's only enough for a single channel x64 sodimm (dual channel would need 128 data pins, plus the command/address bus i'm pretty sure puts you over the edge)
<azonenberg>
so your max ddr bandwidth is 153.6 Gbps
<azonenberg>
and thats before overhead
<azonenberg>
qdr-iv xp is dual port x36 = x72, max 2133 MT/s gives 153.5 Gbps
<azonenberg>
Still not enough
<azonenberg>
and again i think probably not enough pins to do >1 channel
<azonenberg>
Degi: so basically, i think to actually be able to use that much jesd204 on a single chip you would need something beefier than free vivado supports
<azonenberg>
the xcku11p, maybe, which has 32x GTH, 20x GTY, and 416 HP I/O
<azonenberg>
or the xcvu3p which has 40x GTY and 520 HP IO
<Degi>
Ah well, gotta wait for open source support then
<electronic_eel>
i guess nextpnr will have a hard time routing that...
<Degi>
And it was 1000 something € on Mouser
<Degi>
Or maybe with two FPGAs
<Degi>
Hmm, at least for Lattice nextpnr performs way better than lattice diamond in terms of time for routing
<azonenberg>
Yes but what about QoR?
<azonenberg>
And yes, dual xcku3p/5p is an option
<electronic_eel>
time for routing is nice for working on it, but doesn't help you at all if it doesn't fit
<azonenberg>
write half the data to on chip ram and the other half send out via transceivers to the second fpga
<Degi>
Quality of routing? Not sure, didn't compare them there yet
<azonenberg>
which is basically would just be ddr-on-a-serdes
<azonenberg>
you might even be able to use a lower end fpga for that
<Degi>
Or put two or four JESD pairs per FPGA
<electronic_eel>
using this chip for just a scope seems a bit wasteful - with all the 12gsps dacs on it
<azonenberg>
electronic_eel: oh it would not be just a scope
<Degi>
It would be nice to have an AWG too
<azonenberg>
if we did anything with it, it would be a scope + monster awg
<Degi>
Hmm neat, then you could prototype a 1-2 GHz radar with just a few antennas
<electronic_eel>
the analog frontend for such a monster awg wouldn't be easy to implement
<Degi>
true
<Degi>
Is it possible to hook a JESD204 ADC to a DAC?
<Degi>
(Without an FPGA inbetween)
<d1b2>
<louis> PR-ing diagnostics window shortly. Sneaking in before my last final :)
<d1b2>
<louis> Just PR-ed support class for timekeeping to xptools, that needs a merge, then there will be paired PRs for glscope and scopehal for the actual diagnostics support and UI
<azonenberg>
You can send the PRs for scopehal/-apps when you're ready
<azonenberg>
very interested in getting stats out of some of my drivers with it
<azonenberg>
I also think i found a bug in the lecroy driver that can lead to stale trigger data from a queue not being flushed right
<azonenberg>
so i have to investigate that
<azonenberg>
it seems like under some conditions when i stop triggering the queue is not flushed, so when i re-arm the trigger i instantly get an old waveform rather than a new one
<azonenberg>
but unsure on root cause there. it happened once earlier in the week
<azonenberg>
Having live buffer stats should help
<d1b2>
<louis> Oh yeah, the last thing I was gonna ask you about before PRing
<d1b2>
<louis> is it would be handy to be able to capture LogDebug etc into the diagnostics window
<d1b2>
<louis> not sure what the best way to go about this is, because we (presumably?) don't want to collect all logging output, so a global log sink isn't really appropriate...
<d1b2>
<louis> I was thinking about intentionally shadowing LogDebug etc in Oscilloscope, doing the vastrprintf there, then dispatching the resulting string to both the scope's log queue and to the global handler(s)
<_whitenotifier-e>
[scopehal] 602p 5702809 - Scopehal changes for info window stuff
<_whitenotifier-e>
[scopehal] 602p 3561868 - Support Tek MSO56 AFG
<_whitenotifier-e>
[scopehal] 602p 2ed792c - Working happy diagnostics for DSLabs
<_whitenotifier-e>
[scopehal] ... and 3 more commits.
<azonenberg>
Also, i'm trying to think of the best way to share more metrics for dslabs vs globally for all scopes
<azonenberg>
i feel like we could move some of that stuff into base classes?
<d1b2>
<louis> Thought about that, but it would need to grow an ability to also pass the this pointer, otherwise can't distinguish between logging from different instances of the scope class
<_whitenotifier-e>
[scopehal-apps] mubes 4ff4877 - Make 'reload configuation from scope' option refresh views
<_whitenotifier-e>
[scopehal-apps] azonenberg 1ed6e62 - Merge pull request #400 from mubes/refresh_with_update Make 'reload configuation from scope' option refresh views
<d1b2>
<louis> Yeah, I'm definitely game for that. There's a facility for the scope diag window to show diags that are computed there (e.g. because they involve state (FPS) from the OscWindow), so either that can grow to add more, or we could have some standard set of diagnostics managed in the Osc base
<azonenberg>
@louis: hmmmm maybe we could add a separate LogScopeTrace macro or something internally that does that somehow
<azonenberg>
And yeah i think there should be some standard info in the base class
<azonenberg>
then we can add driver specific stuff like, say, board temperatures
<azonenberg>
let me finish revieiwng and merging the baseline to start
<d1b2>
<louis> Sounds good.
<azonenberg>
we could probably also remove the wfm/s and fps counters in the OscilloscopeWindow and replace with your stuff? as they're now redundant
<azonenberg>
or did you do that already asp art of this PR
<azonenberg>
(still reading)
<d1b2>
<louis> They're still useful at a glance, I think
<azonenberg>
yeah i meant the separate counters
<azonenberg>
m_lastWaveformTimes is now gone
<azonenberg>
is m_totalWaveforms used for anything now that you deleted that though?
<azonenberg>
i guess it cant hurt to keep around for now