<_whitenotifier-f>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JfyTF
<_whitenotifier-f>
[scopehal-apps] azonenberg dbdcc4c - OscilloscopeWindow: avoid null-deref segfault when reconnecting to an instrument with an unimplemented or nonexistent transport
<azonenberg>
there seems to be a bug in which packets show up twice because the protocol decode triggers when either scope updates. Multi-scope in general needs better support
Degi has joined #scopehal
<azonenberg>
So i really want to get the multi-scope sync wizard done soon
<azonenberg>
But i have some prerequisites to do first, like control of trigger offsets
<azonenberg>
also things like per channel deskew are needed on lecroy to do tight enough control of trigger offsets, i think
<_whitenotifier-f>
[scopehal] azonenberg pushed 2 commits to master [+0/-0/±14] https://git.io/Jfym0
<_whitenotifier-f>
[scopehal] azonenberg a9030dc - Moved m_mutex from Oscilloscope classes into base Oscilloscope class, added IDPing()
<_whitenotifier-f>
[scopehal] azonenberg c109823 - Deleted some duplicated variables
<_whitenotifier-f>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±2] https://git.io/Jfymo
<_whitenotifier-f>
[scopehal-apps] azonenberg a2814eb - OscilloscopeWindow: proper lock-step synchronization of multi-instrument setups. Still have lots of dropped trigger alerts that we probably had all along, but didn't notice due to lack of sync. Fixes #71.
<_whitenotifier-f>
[scopehal-apps] azonenberg closed issue #71: Make multi-scope systems handle history/acquisitions better - https://git.io/JvgaG
<azonenberg>
well, that's a major fix for multi scope sync
<azonenberg>
the first instrument specified in the file/command line is now designated "primary" and is the trigger reference for all other "secondary" instruments
<azonenberg>
The user is assumed to have connected trigger out on primary to trigger in on all secondaries, via a splitter if necessary
<azonenberg>
All secondaries have their triggers armed (order irrelevant) before the primary is armed
<azonenberg>
and then i wait for all to trigger before downloading the waveforms and updating filters once
dannas has joined #scopehal
<azonenberg>
no more random race conditions where you'd get filters updating halfway through a download of one instrument's data and the other one still stale
<azonenberg>
possibly triggering garbage data in protocol analyzers etc
<azonenberg>
(and wasting cpu time)
<azonenberg>
Eventually the UI will understand the primary/secondary relationship and force all secondary instruments to "external" trigger configuration, and not let you set any channel not on the primary as the trigger source
<azonenberg>
and of course eventually there will be a fancy setup wizard that deskews channels across instruments etc
<azonenberg>
but that last bit isn't possible until i've implemented - and actually defined - the APIs it will need
<azonenberg>
for example right now there's no way to enable trigger out on the aux port of a lecroy scope (aux can be defined as a fast edge, trigger out, trigger arm, or some other things and you need to configure what you want)
<azonenberg>
so the user is assumed to have done this manually via the scope software
dannas has quit [Quit: leaving]
lukego has joined #scopehal
<azonenberg>
o/ lukego
<lukego>
howdy :-)
<lukego>
lurking atm... getting a picnic ready to take the kids down to the lake... but curious to see what's discussed in here :)
<azonenberg>
Right now the single most well developed backend is for Teledyne LeCroy's MAUI based scopes, as that's what both of the ones in my lab are and it's my daily driver for testing
<azonenberg>
miek has been doing a fair bit of work with an older Agilent and... Degi, i think, has done good work getting the Rigol backend up to snuff
<azonenberg>
there is a somewhat abandoned R&S RTM3000 series driver that might work with other R&S stuff but nobody here has any R&S scopes to test on so it may have bitrotted
<azonenberg>
there's been talk of Tek support but so far no major progress i've seen
<azonenberg>
then tverbeure has been doing a bunch of stuff for Siglent scopes
<azonenberg>
which mostly cloned the LeCroy command set, but have just enough differences to need a different driver
<azonenberg>
i don't know the status of MSO support on any of these instruments, the LeCroy logic probes are well supported and i use them routinely
<azonenberg>
noopwafel is starting to look at picoscope support but there's nothing usable yet
_franck_ has joined #scopehal
<azonenberg>
basically the long and short of it is, at the phase of maturity the project is at now, we can probably support whatever scope you end up buying as long as it has some kind of PC interface capability on it
<azonenberg>
We have transport support for SCPI over USBTMC, SCPI over raw TCP, SCPI over VICP, and i think tverbeure was looking at adding GPIB support too
<azonenberg>
the only thing you really need to have is the programmer's manual for that scope. If you can't find documentation on the command set it will be hard to support, but this is normally only a problem for really old gear
<lukego>
I have to do some reading about the project itself too. I've been so focused on learning to solder that I haven't even started to think seriously about test equipment and software yet. but I've slowed down in spending money on soldering kit so gradually accumulating a budget for test gear. learning to layout my first PCB first...
<azonenberg>
Well like i mentioned there's potential for interop with fpga-based ILA cores as well
<azonenberg>
Right now it's only my own LA but i want to add support for the liteX one as well as proprietary vendor capture cores
<azonenberg>
The latter have completely undocumented interfaces so some RE will be required
<lukego>
I also have some ultrascale+ FPGAs with 32x~25Gbps transceivers and maybe one of those could become a logic analyzer data acquirer at some point... but I've no idea what scale of project that might be :)
<azonenberg>
Lol
<azonenberg>
So in addition to running glscopeclient on commercial hardware we're also building our own test equipment here
<lukego>
where's "here" btw?
<azonenberg>
This channel
<lukego>
cool
<azonenberg>
Physically, I'm in the Seattle area but folks here are all over the globe
<azonenberg>
I'm the main center of hardware dev at the moment although several people have contributed to schematic and design review work
<lukego>
My first babystep into hardware is trying to implement an automatic PCB BGA escape routing algorithm... I have no idea if there's a channel where that kind of thing is discussed
<azonenberg>
Not that i know of. #kicad maybe if that's the tool you're using?
<azonenberg>
anyway the MEAD board i tweeted pics of a few days ago is an 8-channel 4 Gbps active logic probe
<azonenberg>
it's at fab now
<lukego>
Cool :)
<azonenberg>
It's going to plug into a hardware platform named MAXWELL that i'm in the early stages of design on. Connections for something like ten MEAD pods (80 channels) at 1.25 Gsps, one special high speed connector with four channels at 10 Gsps
<azonenberg>
then a SODIMM of DDR3 1600/1866 and 1/10/40G ethernet to glscopeclient
<azonenberg>
In a 1U rackmount chassis
<lukego>
I'm mostly interested in ethernet so the test equipment I'd be more interested in is more in the direction of IXIA etc for testing switches/routers/etc. quite far up the stack compared with an oscilloscope.
<lukego>
but I want to make my own hardware - NICs - and I'll need to debug them somehow.
<azonenberg>
Ah, i see. Well maybe we can also collaborate on my f/oss 1/10G switch fabric project at some point
<azonenberg>
That's kinda on hold while i work on the test equipment stuff more, the hardware design is paused but most of the gateware is done-ish
<_franck_>
azonenberg : hi, what is the Ethernet transport protocol for SCPI ? I can't find details easily. I have a Tektronix DPO5000 and user's guide only talk about VISA
<azonenberg>
and tested on a vcu118
<lukego>
I'll be checking that out in more detail once I have made a dev board and can start thinking properly about gateware
<_franck_>
_franck_ any simple tool I could try to send SCPI commands ? (netcat ?)
<azonenberg>
_franck_: IANA standard is TCP port 5025, just raw SCPI over TCP with no encapsulation
<azonenberg>
you should be ableto just netcat to it
<_franck_>
oh great thanks, I'll try that
<azonenberg>
some instruments have an interactive shell on... 5024 or 5026, cant remember, that is the same command parser but displays a prompt and welcome banner
<azonenberg>
SCPISocketTransport assumes raw SCPI with no prompt or banners
<azonenberg>
Teledyne LeCroy has their own protocol called VICP which runs over TCP but has some sequence numbering and other framing that seems largely redundant
<azonenberg>
as best i can tell it's literally GPIB tunneled over TCP
<_franck_>
so in theory, I could use my DSO5000 with scopehal
<azonenberg>
If we had a driver for Tek scopes? Yes
<monochroma>
lukego: what networking stuff are you working on? :o
<azonenberg>
There's an open ticket on the tracker but nobody here has a tek to test on
<azonenberg>
if you're willing to contribute a driver we'll gladly walk you through developing one
<_franck_>
if SCPI is standard, commands are not ?
<azonenberg>
it's basically one C++ class that bridges SCPI commands to our internal object model
<azonenberg>
Correct. The command sets are entirely vendor specific
<_franck_>
why do we need a driver ?
<_franck_>
oh crap
<azonenberg>
there's some commonality on a few commands like querying the device ID
<azonenberg>
but the vast majority of stuff relevant to scopes is vendor specific. also there's quirks from model to model you have to be aware of, like "sample rate is reduced if all 4 channels are active" etc
<_franck_>
azonenberg : I'll put that on my TODO list
<azonenberg>
scopehal has a unified API internally that tries to abstract away all of this, but you still need the driver class to do the translation
<azonenberg>
all of the protocol decodes and stuff work at a higher level and don't care about specifics of the scope at all, it's a fairly clean layered design
<azonenberg>
we have "transport" classes that move scpi data around without knowing what the commands mean, "driver" classes that convert scpi commands from a transport to "waveform" objects
<azonenberg>
then a filter graph that transforms waveforms into other waveforms, statistics, etc
<_franck_>
so I would have to create a scopehal/TekXXXXOscilloscope.cpp file that it ?
<lukego>
monochroma: my background is doing network dataplane software for telco. have been doing a lot of "kernel bypass networking" i.e. userspace network stacks doing various things like connecting VMs to networks. but I'm a bit burned out on Intel/Mellanox NICs and want to try making my own hardware now
<azonenberg>
_franck_: correct. LeCroyOscilloscope is the best reference material as it's the most complete driver
<azonenberg>
many of the others are missing some features
<_franck_>
ok thanks
<azonenberg>
i use the LeCroy driver on a daily basis because both of my scopes in the lab here are LeCroy's and i'm the original / most active developer
<azonenberg>
so basically all new features are first tested on it, then eventually ported to other drivers
<_franck_>
for now, I just want to talk to my scope to capture power traces (to find a glitch point) :)
<_franck_>
I didn't know about SCPI
<_franck_>
I'll find a python lib
<azonenberg>
oh you're doing power analysis?
<_franck_>
I will try :)
<azonenberg>
i actually am interested in building a DPA workflow on top of scopehal at some point
<azonenberg>
if you're interested in collaborating
<azonenberg>
my day job is embedded systems pentesting and we recently had our main DPA guy quit so i'm trying to learn power stuff to fill the hole
<azonenberg>
we have one guy at another lab who has done a bit with it too
<_franck_>
I'll analyze a stm32f103 bootloader. Find the point where read protection is checked. So it's not DPA
<_franck_>
some people have glitched this test. I would like to find the timing by analysis
<azonenberg>
Makes sense. SPA would be nice to have too
<_franck_>
Shaping the Glitch:
<_franck_>
Optimizing Voltage Fault Injection Attacks
<monochroma>
lukego: oh cool! i have been trying to get azonenberg to build a switch fabric for years ;)
<_franck_>
yes, capture a lot of traces, align them
<_franck_>
then get the average trace
<azonenberg>
monochroma: i have the fabric
<azonenberg>
what i don't have is hardware to run it on yet :p
<monochroma>
azonenberg: nowwww you do
<azonenberg>
it worked well in small scale testing on the vcu118
<monochroma>
:3
<azonenberg>
with 4x 10G ports only and no 1G because there's no rgmii on the vcu118 and i didnt feel like spinning a FMC board for that
<azonenberg>
lukego: btw if you can build a halfway decent pcie 10G NIC that is feasible to make in low volume (high single digit qty) for less than an X520-DA2
<azonenberg>
i'm very interested in splitting the cost of a run
<azonenberg>
i dont even need 2 ports for most applications
<lukego>
azonenberg: seems plausible. I'm leaning open source so thinking of the awkward ECP5-xgmii-PHY with that one PHY that still does XGMII...
<azonenberg>
you found an xgmii phy?
<azonenberg>
i was assuming you'd go ecp5 then tlk10232
<lukego>
yep, have one in my parts bin, a microsemi
<azonenberg>
or similar
<azonenberg>
that's what i plan to use on my artix-based oscilloscope board. Unless i have a change of heart and go kintex there instead
<noopwafel>
heh DPA is my motivation for caring also :)
<azonenberg>
Great
<azonenberg>
Sounds like we'll have a good team for developing the tooling once we have the infrastructure to run it on
<_franck_>
azonenberg : nmap doesn't find any 502x port open on my scope
<azonenberg>
_franck_: it may not be enabled by default
<azonenberg>
i think on lecroy you have to set it up in a config dialog somewhere
<azonenberg>
did you also confirm the scope was on the network and you had the right IP?
<azonenberg>
what other ports are open?
<_franck_>
80/tcp open http
<_franck_>
111/tcp open rpcbind
<_franck_>
135/tcp open msrpc
<_franck_>
2103/tcp open zephyr-clt
<_franck_>
1801/tcp open msmq
<_franck_>
139/tcp open netbios-ssn
<_franck_>
445/tcp open microsoft-ds
<_franck_>
2107/tcp open msmq-mgmt
<_franck_>
2105/tcp open eklogin
<_franck_>
3580/tcp open nati-svrloc
<_franck_>
4000/tcp open remoteanything
<noopwafel>
was wondering how painful it would be to add TDS5104 support as debugging scope
<_franck_>
webpage is only network config
<azonenberg>
So its a windows based scope and you definitely have the right IP
<azonenberg>
any of the higher ports 1801-4000 might be scpi, is there any documentation on that?
<_franck_>
in scope menu I have something about a VXI-11 Server
<azonenberg>
try netcatting to each one in sequence and sending the standard SCPI ID command
<azonenberg>
*IDN?
<azonenberg>
oh
<azonenberg>
Turn that on then. They're probably using LXI not raw SCPI
<_franck_>
it's on
<azonenberg>
we have a LXI driver now
<azonenberg>
tverbeure just added it, i'm not super familiar with LXI in general but he says it works (using liblxi) with his siglent gear
<azonenberg>
so you should be able to use that to talk to your scope
<azonenberg>
a LXI transport*
<noopwafel>
was alarmed that manual only talks about physical GPIB connector, but it seems to also talk vxi-11
<azonenberg>
you'd just need a driver
<noopwafel>
I am kind of helpfully lagging behind here I see :p
<_franck_>
I'll try to find informations about LXI
<azonenberg>
Awesome. So if you can find documentation on the SCPI command set, you and noopwafel should be able to get a driver together between the two of you
<azonenberg>
Let me know if you have specific questions
<_franck_>
ok thanks, I'll sure get back to this later
promach3 has joined #scopehal
<Degi>
Hmm maybe support for UART logic analyzers, like one which sends raw bytes or hex characters, can be added too.
<Degi>
(I made one in nmigen recently which basically fills up a buffer and then when a byte arrives over UART, it sends its buffer as hex data)
bvernoux has joined #scopehal
<bvernoux>
hello
<bvernoux>
I just discovered an amazing big chinese blog
<Degi>
"They all use a CRT pseudo-color screen, that is, a three-layer liquid crystal filter of red, yellow, and green is added outside the CRT, and the polarization of different colors of liquid crystal is controlled by the driving circuit to realize the display of different colors of characters. Of course, It can only display three colors of red, yellow and green."
<bvernoux>
yes lot of amazing things ;)
<Degi>
Huhh, thats interesting
<bvernoux>
Chinese are really transforming the world
<bvernoux>
yesterday they was doing low cost things and now (and since few years) they are designing high tech stuff
<Degi>
Kinda reminds me of a "color LCD" which had alternating backlight colors to make a monochrome LCD colorful
<bvernoux>
What is interesting is the cooperation model
<bvernoux>
we are very far from that in EU ;)
<Degi>
Hmh cooperation? As in between different companies?
<bvernoux>
yes
<bvernoux>
their Win-win strategy
<bvernoux>
it is not only politic BS but reality their
<Degi>
Hmh so the companies there dont try to take eachother down?
<bvernoux>
not really in fact
<bvernoux>
they are more clever that what we are for that ;)
<bvernoux>
I speak in EU but it is also the same for USA...
<bvernoux>
anyway the interesting points is there is tons of article related to high tech stuff
<bvernoux>
but filtering range is not as good as YIG Filters
<Degi>
Hmm I want something like that, like 0-x GHz with at least 500 MHz passband
<bvernoux>
and also the me too ;)
<Degi>
To remove images from mixer output
<bvernoux>
yes
<bvernoux>
I want one from 2Ghz to 26.5GHz ;)
<bvernoux>
compact ;)
<bvernoux>
and cheap
<Degi>
As shown on page 2
<Degi>
Almost that exact thing
<Degi>
Well and the same in reverse... Wonder what they cost
<bvernoux>
but this document is from 2010
<Degi>
A SDR to rule them all haha
<bvernoux>
and it seems nothing has changed for MMIC ...
<Degi>
*holds up ring-shaped SDR*
<bvernoux>
microwave stuff are like locked in year 1990 ;)
<bvernoux>
price are always crazy expensive ;)
<Degi>
Huh, why does it say that yig filters are slow and take 10 ms to tune
<bvernoux>
innovation are not available for all
<bvernoux>
and integrated in ultra expensive materials ...
<Degi>
Maybe soon with 5G
<bvernoux>
yes maybe
<bvernoux>
it should drive some interesting evolution
<Degi>
Oh nice, adjutable passband
<bvernoux>
like Wifi 6E
<bvernoux>
with 1.2GHz BW ;)
<Degi>
Huh, cherries get mold where the green thing is firt...
megal0maniac has joined #scopehal
<bvernoux>
I want ultra fast / low latency Wireless stuff
<Degi>
Hopefully thatll lead to cheaper ADCs
<bvernoux>
for digital needs not for analog old area to listen FM/AM ;)
<bvernoux>
Personally I don't care of HAM stuff to listen Am/FM ;)
<Degi>
I wanna build an SDR sometime in the next years heh
<bvernoux>
I want RF for digital ;)
<Degi>
Like you could listen to AM/FM, GSM, whatever is on radar bands...
<bvernoux>
hehe
<Degi>
The whole 2.45 GHz band at once
<bvernoux>
we need next step processors also some SDR processors ;)
<bvernoux>
maybe based on RISCV
<Degi>
Why channels 1, 6, 11 when you can do all at once
<Degi>
Hmh I thought about using GPUs
<Degi>
But an open source variant would be nice
<bvernoux>
main issue with SDR is we do not have enough horsepower to manage big BW ;)
<bvernoux>
or it requires ultra specialized FPGA/ASIC ...
<Degi>
I wonder how a GPU compares to a FPGA in terms of watt per FLOP
<Degi>
Oh come on, modern GPUs can easily do several TFLOP/
<Degi>
s
<bvernoux>
yes but they are quite specialized
<Degi>
You can use them to compute most parallelizable things
<Degi>
Whether its graphics, particle simulations, FIR filters etc
<bvernoux>
yes but they are power hungry too ;)
<Degi>
Meh mine only uses like 200 W or so
<bvernoux>
but definitely something hybrid FPGA/CPU/GPU specialized for SDR ;)
<Degi>
Why dont they make CPUs with GaAs lol
<Degi>
Probably because of node size etc
<bvernoux>
Carbon NanoTube Transistor ;)
<bvernoux>
to reach THz CPU ;)
<Degi>
Well that one is probably harder to photolithography
<Degi>
Also propagation delay
<Degi>
Tbh OpenCL could be used for SDR
<bvernoux>
I'm not sure OpenCL for SDR provide good gain
<miek>
it already is, check out fosphor
<bvernoux>
but will be interesting to check using FFT and Filters
<Degi>
Like a GPU would be ideal for FFT
<Degi>
"So many logic devices can make my scalp numb" heh these google translation
<Degi>
At like 1 GS/s and beyond, a GPU would definitely be needed for FFT
<Degi>
And the bandwidth would be rather small, maybe a few hundred samples
<Degi>
Though if the bin frequencies are an integer multiple of the reciprocal of the sample time, then preprocessed sinewaves could be used, to speed it up a bit at the cost of RAM
<bvernoux>
it is interesting to see how actual GPU vs CPU can provide for such use case
<bvernoux>
I have not found any complete research about that in fact
<bvernoux>
so far FPGA are the master for that
<bvernoux>
but expensive ones ...
<Degi>
I mean GPU is way faster for parallel
<bvernoux>
yes when it is possible to do it in //
<Degi>
FFT should be easy to parallelize
<bvernoux>
anyaywa GPU have lot of bottlneck
<Degi>
Hmh?
<bvernoux>
like sharing memory
<bvernoux>
and very little internal RAM for each thread
<Degi>
I'm not entirely sure but it could be possible to stream from a SDR PCIe card directly to GPU memory
<bvernoux>
I remember it was a real headach to optimize MD5 bruteforce on GPU ;)
<bvernoux>
using texture memory to speedup things
<bvernoux>
and avoiding any branch of course ...
<Degi>
You dont need branching for fft...
<bvernoux>
yes
<Degi>
And you can do branching by calculating both branches adn then taking the result you want
<bvernoux>
there is optimized FFT for GPU also now
<bvernoux>
but dedicated to CUDA
<bvernoux>
I'm not sure OpenCL is so efficient
<bvernoux>
as there is an other layer of abstraction
<bvernoux>
vs CUDA
<Degi>
The biggest thing I did using GPUs was a particle simulator, IIRC it had around 10-100k particles interacting with eachother, the framerate wasnt very high but above 1 FPS
<azonenberg>
Degi: yeah fft on gpu is totally a thing
<azonenberg>
@miek so how complete is your agilent driver and when do you expect to be ready to merge?
<azonenberg>
I want to get scopehal:#14 closed soonish
<azonenberg>
then we can make separate tickets for improvements to the driver at some point
<miek>
it was merged back in feb :D
<azonenberg>
So do you think we should close the ticket now? there's still a fair bit of missing features, like reading/writnig sample rate/depth
<azonenberg>
setting the channel to use as trigger source
<azonenberg>
setting offset
<azonenberg>
setting bandwidth limit
<azonenberg>
setting probe attenuation
<azonenberg>
just search AgilentOscilloscope.cpp //FIXME
<miek>
true, i'd kinda forgotten about all that tbh - mainly cause it's totally usable as-is
<azonenberg>
Yes, just not in full remote mode
<azonenberg>
you need access to the scope front panel for configuring it
<azonenberg>
We have a lot of drivers that work really well in read-only mode but have limited write support
<azonenberg>
So i'm going to leave the issue open until you finish that, can you do that soonish?
<azonenberg>
also i'm planning to add you to the scopehal/scopehal-apps project at this point so i can assign issues to you. You've proven yourself enough at this point
<azonenberg>
this comes with commit access but it's kinda probationary - I'll want to review code before you push it still just as a matter of policy
<azonenberg>
sound good?
<_whitenotifier-f>
[scopehal] azonenberg labeled issue #140: Derivative math function - https://git.io/JfP7H
<miek>
not exactly sure how soon i can get to it, but i'll try and sort those out over the next week or two. yep, fine by me - i'll still do PRs for any code changes
<azonenberg>
yeah i wish github had a "be tracked as part of the project but no push access" mode. maybe organizations can do that
<azonenberg>
speaking of which longer term i will likely create an org for either the scopehal project, antikernel labs, or both, and move these projects under it
<azonenberg>
what's your github username again? i'm blanking
<azonenberg>
There we go. Don't feel any extra pressure, I'm just trying to manage things
<azonenberg>
now that this isnt a one-man project anymore it helps to know who's doing what
<azonenberg>
Also another thing to start thinking about
<azonenberg>
Right now, setting up a usb decode is a complicated multi-step process
<azonenberg>
Which makes sense in a way because it's a filter graph and you may want to see the lower layers as well as the full packets
<azonenberg>
But down the road, i want to have some sort of system that allows you to create a canned subgraph of multiple filters and drop it into the system
<azonenberg>
so you just specify D+ and D- and you get all of the layers at once
<miek>
yeah, that would be nice. i certainly got tired of making the stack manually :)
<azonenberg>
at least to start it won't have any concept of grouping WRT moving the decodes to other waveform views, deleting them, etc. It will just be a helper for creating stuff
<azonenberg>
for you personally, right now, what helps is if you save the UI setup (not waveforms) to a file
<azonenberg>
you can then run glscopeclient usbtest.scopesession --nodata --reconnect --retrigger
<azonenberg>
which basically says ignore any waveform data in the file, connect back to the instrument instead of running offline, and start trigger immediately
<azonenberg>
this is what i did for all of my recent protocol stack testing
<azonenberg>
it's still live streaming data from the scope but all of the decodes are set up from your last round
<miek>
ah nice, i didn't know about running it from the commandline like that. i'll try that out
<azonenberg>
yeah it was specifically meant for this use case of filter development
<_whitenotifier-f>
[scopehal] azonenberg opened issue #143: Remove Oscilloscope::PollTriggerFifo() since it basically duplicates HasPendingWaveforms() - https://git.io/Jfyix
<_whitenotifier-f>
[scopehal] azonenberg labeled issue #143: Remove Oscilloscope::PollTriggerFifo() since it basically duplicates HasPendingWaveforms() - https://git.io/Jfyix
<_whitenotifier-f>
[scopehal] azonenberg labeled issue #143: Remove Oscilloscope::PollTriggerFifo() since it basically duplicates HasPendingWaveforms() - https://git.io/Jfyix
<_whitenotifier-f>
[scopehal] azonenberg opened issue #144: Add support for per channel deskew - https://git.io/Jfyip
<_whitenotifier-f>
[scopehal] azonenberg labeled issue #144: Add support for per channel deskew - https://git.io/Jfyip
<_whitenotifier-f>
[scopehal] miek closed issue #74: Add Agilent MSO6104A support via SCPI - https://git.io/fjuod
<_whitenotifier-f>
[scopehal] miek commented on issue #74: Add Agilent MSO6104A support via SCPI - https://git.io/Jfyih
<azonenberg>
miek: so here's a question, re the subgraph stuff
<azonenberg>
does that make sense to be syntactic sugar in the UI or should it be in scopehal itself?
<azonenberg>
i feel like scopehal API users wouldn't mind stringing together the filters individually since they probably want to look at the intermediate output streams etc
<azonenberg>
so it would be good to just put in glscopeclient?
<azonenberg>
but at the same time it seems like it's not strictly a UI issue which means it would belong in the library
<miek>
i guess scopehal needs to expose info about which subgraphs exist anyway
<azonenberg>
That was the idea
<azonenberg>
we'd need some kind of a subgraph enumeration API etc for the UI
<azonenberg>
so if we put that in scopehal using a similar discovery method we use for the filters
<azonenberg>
then glscopeclient can just create stuff based on those
<azonenberg>
I think that's the most logical
<miek>
yeah. also we might want to have some more fine grained control in the UI anyway? when you're in the dialog to create a subgraph, it could have checkboxes for which parts to actually display for example
<azonenberg>
That was my thought too
<azonenberg>
Internally everything is refcounted
<azonenberg>
filters are deleted, and stop being evaluated, when the last consumer of their output is destroyed
<_whitenotifier-f>
[scopehal] azonenberg opened issue #145: Allow creation of canned subgraphs of filters for common tasks - https://git.io/JfyPO
<_whitenotifier-f>
[scopehal] azonenberg labeled issue #145: Allow creation of canned subgraphs of filters for common tasks - https://git.io/JfyPO
<azonenberg>
The other thing i want to do is improve support for type-conversions on inputs to filters automatically
<azonenberg>
if a filter expects a digital input, allow you to specify an analog channels and threshold it at the 50% level automatically (creating a new threshold decoder you can then configure as you see fit)
<azonenberg>
this will require, rather than simply a boolean "is this channel OK for this input" function like we have now, some way to ask a filter what it wants
<azonenberg>
so glscopeclient can decide if there's a built in type cast it can use for that
<azonenberg>
i also want to add support for differential inputs but i'm not yet sure what form that will take
<azonenberg>
basically be able to specify two channels instead of one any time you have an analog input
<azonenberg>
and infer a subtraction filter
<miek>
some related stuff for the USB decoder specifically: HS decode should be possible with a single channel & diff. probe, so that might be something to fit into this model
<azonenberg>
HS doesnt have the SE0/SE1 states?
<azonenberg>
it's true diff?
<miek>
also, right now it's quite strict about voltage levels
<azonenberg>
So longer term that's something i want to improve about decodes in general. I want to do two different things
<azonenberg>
1) flag any compliance violations with the spec, however minor - like bad disparity on 8b10b streams
<azonenberg>
2) attempt to decode even mangled traffic, but make it clear something's wrong with it (like voltage level too low)
<miek>
cool, yeah that sounds good
<miek>
it has SE0, which is D+ and D- both low - so you could interpret that as diff. output == ~0. it never intentionally has SE1, and EOP is signalled by a forced bitstuff error
<azonenberg>
if it has SE0 then you cant really decode it meaningfully with a diff probe?
<azonenberg>
as a diff probe could output total garbage in that case
<azonenberg>
USB3 with a diff probe should be doable as it's 8b10b
<miek>
it should just output 0V? so you'd have 3 distinct levels, 400mV, -400mV, and 0V
<azonenberg>
oh sorry i misunderstood what you were saying
<azonenberg>
i was thinking of a digital differential input
<azonenberg>
not an analog
<miek>
aha
<azonenberg>
so yes if you had an active diff probe it should work
<azonenberg>
FS/LS decode should be capable of doing that too, since the SE1 state isn't used there either
<azonenberg>
however it presents a problem for compliance testing as SE0/SE1 are indistinguishable
<azonenberg>
and i'd like to be able to alert on SE1
<azonenberg>
miek: dont worry about interleaved stuff in the channel rate APIs btw
<azonenberg>
right now we do not support interleaving anywhere and i fully expect that API to change to support more flexible interleaving config on BLONDEL, Rigol DS1000Z, etc
<azonenberg>
basically interleaving is not always a boolean on/off, it might have several degrees
<miek>
ah ok
<azonenberg>
I know we need api changes but i don't yet know what they arer
<azonenberg>
need to sit down and design something once that works for everything
<miek>
i haven't actually worked out how my scope does it. sample rate doesn't seem to drop when i turn on all the channels
<azonenberg>
in general i've had to go back and break APIs here and there when an instrument came along that broke my assumptions :p
<azonenberg>
you may just not have interleaving support at all
<azonenberg>
one adc dedicated per channel and that's it
<miek>
yeah, that makes sense. i guess it only uses it for the higher models
<azonenberg>
all of my lecroys support interleaving however the set of interleave-capable channels varies by model
<azonenberg>
for example on wavesurfer 3000 you can merge ch1/2 and ch3/4 but you can pick any channel from either half
<azonenberg>
on waverunner 8000 you have to pick 2 and 3
<azonenberg>
there are also known bugs in scopehal when interleaving is turned on with lecroy hardware
<azonenberg>
it either crashes, doesnt work at all, or both :p
maartenBE has quit [Ping timeout: 258 seconds]
maartenBE has joined #scopehal
ABLomas has joined #scopehal
<_whitenotifier-f>
[scopehal] dnadlinger commented on issue #144: Add support for per channel deskew - https://git.io/JfyXC
<_whitenotifier-f>
[scopehal] dnadlinger commented on issue #144: Add support for per channel deskew - https://git.io/JfyXE
<azonenberg>
so you know what would be really cool? if we had somebody with a recent keysight or similar scope that could do a plug-fest with me at some point in a few months once we have a good driver, multiscope support improved, deskew wizard, etc
<azonenberg>
and demonstrate say a keysight and a lecroy synced together working in one UI
<azonenberg>
that would be absolutely unprecedented :D
bvernoux has joined #scopehal
bvernoux has quit [Quit: Leaving]
<Degi>
I mean you could do it over a VPN hahaha
<monochroma>
haha
<monochroma>
Degi: well you couldn't do them together over a VPN really
<monochroma>
they have to have a sync cable connected
<Degi>
Oh
<monochroma>
hmmm
<monochroma>
could maybe feed them both from a GPS-DO though?
<Degi>
Hmm
<Degi>
Ship a running atomic clock with UPS or so
<Degi>
I wonder if the TSA would be annoyed if you had a running hydrogen maser in your carry-on
<sorear>
atomic clocks aren't that hard to get anyway
<Degi>
But hydrogen masers are
<Degi>
What if you build like a superconducting hydrogen maser haha
<Degi>
You'd probably need a less good quartz bulb
<Degi>
If you could increase cavity power by a few decades
<sorear>
I'm confused on which part you intend to make superconducting
<Degi>
The cavity
<Degi>
If instead of a Q of like 1000 or so you have a Q of 10^9, I think that increases power by 10^6 which should decrease the time it takes the hydrogen atom to interact with the RF field
<sorear>
increasing cavity power is _bad_, the AC Stark shift will eat all of your frequency stability
<Degi>
Oh
<monochroma>
nom
<azonenberg>
Degi, monochroma, etc: so i sat down and did some preliminary i/o planning for MAXWELL
<azonenberg>
the new design calls for 12 total input connectors
<azonenberg>
Pretzel4Ever: let me know what you think
<azonenberg>
so total of 92 1.25 Gsps channels and four 10 Gsps channels
<Degi>
Neat
<Degi>
Does the FPGA run out of pins beyond that?
<azonenberg>
So that's where i was going, lol
<azonenberg>
The fpga has a total of 3 HP banks and 5 HR banks, of 50 pins each. Total 400 pins
<azonenberg>
Each bank has 48 differential-capable pins and 2 single-ended-only pins
<Degi>
Heh why
<azonenberg>
not sure. the outermost on each bank are SE
<azonenberg>
anyway, then there's two quads of GTXes
<azonenberg>
one quad for 40GbE, one quad for high speed sampling. I will likely need some muxing in that path for sync, still thinking about details of that part
<Degi>
Whats HP and HR
<azonenberg>
HP = high performance. Higher Fmax but 1.8V max VCCIO
<azonenberg>
HR = high range, 3.3V compatible, slower
<azonenberg>
virtex-7 are all HP and have no 3.3V capability, artix/spartan-7 are all HR
<azonenberg>
kintex has a mix with the exact ratio depending on the part/package
<Degi>
So we have like 384 pins, 192 diff pairs, after LA pods its 96 diff pairs for RAM (or 192 SE)
<azonenberg>
Well
<azonenberg>
So here's my planned breakdown
<Degi>
Someday I wanna find out how fast an ECP5 can go with overvolting before catching fire haha.
<azonenberg>
each of the banks is divided into four memory byte groups
<azonenberg>
that the hard memory PHY IP uses, with dedicated DQS and DQ pins
<azonenberg>
then there's some non-memory pins, SSTL Vref inputs, etc
<Degi>
It has a hardware mem controler?
<azonenberg>
It has a hard PHY and a soft controller
<azonenberg>
basically just DQS capture logic
<azonenberg>
and a little fifo
<azonenberg>
anyway so with four byte groups per bank i need two banks for a 64-bit DDR3 interface, then i expect to use a third for all of the address/control signals although i'll have a few unused pins there
<azonenberg>
So i'm going to dedicate all three of the HP banks to the DDR3, any unused pins will just be blocked off as unavailable because nothing else on the board will run at SSTL levels
<azonenberg>
Then all of the GTXes are used, this leaves the five HR banks
<azonenberg>
LVDS_25 requires 2.5V VCCO, and we can fit 24 diffpairs per bank plus two LVCMOS25 single ended IOs that i have no immediate term use for
<azonenberg>
With 92 pairs, we're going to need 3 full banks plus 20/24 pairs on a fourth
<Degi>
UART
<azonenberg>
i'm getting there :)
<Degi>
UART over diff pairs haha
<azonenberg>
So, 4 of the 5 HR banks are going to be VCCO=2.5V. We're going to have 8 single ended inputs unused, and four LVDS input pairs available. At least one of those will be used by the system clock oscillator
<azonenberg>
So that's 8 single ended and 3 LVDS pairs free across four banks
<Degi>
Maybe add an extref
<Degi>
Hmm how will the internal clock be generated? Internal pll?
<azonenberg>
Yeah i'll probably do that
<azonenberg>
There will be an external LVDS oscillator at probably 125 MHz that goes into a 1:2 fanout buffer
<azonenberg>
one output to the SERDES block I'm using for the LA input, and one to the FPGA fabric
<azonenberg>
a second 156.25 MHz oscillator for the Ethernet SERDES block
<Degi>
Some way to switch in an extref instead of the oscillator would be good
<azonenberg>
The buffer i'm probably going to use has two inputs
<azonenberg>
So i can easily hook the other one out to an external input
<Degi>
Maybe with a PLL inbetween
<azonenberg>
No, the PLL is in the FPGA
<azonenberg>
i dont need an external one
<Degi>
Like when you input 10 Mhz
<Degi>
ok
<azonenberg>
Anyway the fifth bank will run at LVCMOS33. There will be one lane of RGMII to a KSZ9031
<azonenberg>
one lane of quad SPI to the boot flash
<azonenberg>
and a SPI link to the main STM32
<azonenberg>
probably some random GPIOs etc, leaving 20-odd unused pins in that bank
<Degi>
KSZ9031 is some kinda aux thingie?
<azonenberg>
ethernet PHY
<azonenberg>
There will be three total ethernet interfaces on MAXWELl
<Degi>
Yes, but its only a gigabit
<Degi>
Hm okay
<azonenberg>
1G copper via the ksz9031
<azonenberg>
a 10G SFP+
<azonenberg>
and a 40G QSFP+
<azonenberg>
the 10G and 40G cannot be used at the same time because they're going to share a serdes lane
<Degi>
Hm yeah
<Degi>
So a mux there
<azonenberg>
it's just so you can get 10G without needing an expensive 40G optic and fanout cable
<Degi>
65 $ from china
<azonenberg>
Yeah. I will probably put muxes on all four 40G lanes and just tie off the others, to match propagation delay as much as possible
<Degi>
Is that important?
<Degi>
Arent the 4 channels in a 40G SFP kinda separate anyways
<azonenberg>
It depends on how much the propagation delay through the mux is
<azonenberg>
the official IEEE skew budget leaves most of it in the cable
<azonenberg>
and i mean yeah you can get cheapish QSFPs
<azonenberg>
but having a 10G option just seems handy
<Degi>
Hm yeah
<Degi>
Can the 10G port do 1G too
<azonenberg>
you mean 1000base-X? Not in the initial firmware
<azonenberg>
dual mode would be nice to have at some point
<Degi>
Well I have a random 1G sfp laying around so I wondered
<Degi>
And are the SFPs vendor specific or do they all have some kinda shared protocol for the control?
<Degi>
Heck we could ship it with a SFP preinstalled at these prices
<azonenberg>
SFPs are entirely industry standard and interchangeable. There's an i2c eeprom with some ID information then literally just one diffpair in and one out for raw 64/66b coded ethernet data
<azonenberg>
a sfp is basically just a laser-to-differential-digital converter
<azonenberg>
there's no intelligence at all
<Degi>
Hmm I've heard about DRM issues
<Degi>
Like Vendor B router refuses to work with Vendor A SFP
<azonenberg>
Correct. some NICs are nasty and check the ID eeprom and refuse to work with optics where the vendor ID doesn't match what they expect
<azonenberg>
It's a 24C :p you can fix that easily enough
<Degi>
But thats NIC side?
<azonenberg>
or switches, routers, or anything else
<azonenberg>
fs.com sells their generic SFPs flashed with vendor IDs for any vendor you ask for
<azonenberg>
just specify at time of purchase
<azonenberg>
that's what i do
<Degi>
So we can just ignore that?
<monochroma>
yes
<azonenberg>
on our side it doesnt care. It's not over the wire, there's no way to tell whose sfp is on the far end of the link
<azonenberg>
only the device the optic is plugged into can tell, via the i2c interface
<azonenberg>
and like i said that's trivial to bypas
<monochroma>
Degi: cisco/HP/juniper etc just want to sell their own OEM SFP/QSFPs
<Degi>
Hm yeah, so the SFPs dont have builtin DRM, but the proprietary network interface has...
<azonenberg>
at least on cisco there's an undocumented, but not really secret, command to allow use of any vendor's SFPs
<azonenberg>
you can't get warranty support if that optic is in, but idgaf because my gear is old anyway :
<azonenberg>
:p
<azonenberg>
aaaanyway so basically the fpga is going to be at 90%+ I/O utilization
<Degi>
And QSFPs 40G are like 40 bucks with shipping
<Degi>
Thats neat
<azonenberg>
then we need a dozen uarts to talk to the MEAD boards, some GPIOs, etc. even the stm32f777 only has something like 6 or 8
<azonenberg>
so my plan was to slap a stm32f031 on every single sff8087 socket to manage the power on/off based on the presence detect pin
<azonenberg>
and report present/non-present over i2c
<Degi>
Hm why not soft uart
<azonenberg>
as well as providing an i2c-to-uart bridge for talking to the LA pod
<azonenberg>
because bitbanging is annoying and stm32f031s are practically free?
<Degi>
Or we could make the LA pods work with I2C heh
<Degi>
Hm ok
<azonenberg>
No, i considered that. The bus capacitance of twelve 1m long cables would be a nightmare
<azonenberg>
any kind of multi-drop bus with stubs that long would have reflection issues
<Degi>
Huh?
<azonenberg>
better to have separate point to point segments, thenbridge
<Degi>
Do we have gigabit I2C now
<azonenberg>
I2C has a max capacitance of 400 pF
<Degi>
Hm okayy
<Degi>
(I mean at 400 kHz the wavelength is nearly 1 km)
sorear has quit [Ping timeout: 246 seconds]
<azonenberg>
assume 10 pF per device, times twelve probes is ~120 pF right there
<Degi>
Hm yeah UART doesnt have that limitation
<azonenberg>
Because it's point to point
<Degi>
And push pull
<azonenberg>
then twelve meters of cable , i dont know what the C/meter of a sas cable is
<Degi>
While I2C has pullups
<azonenberg>
but i can only imagine twelve meters of it is substantial
sorear has joined #scopehal
<azonenberg>
cat5 is 52 pF/m
<Degi>
Haha
<Degi>
UART with gate drivers
<Degi>
To drive that 1 µF capacitance
<azonenberg>
so we'd be looking at 624 pF of cable C plus 120 pF of device C plus the mainboard etc
<azonenberg>
this is far in excess of the max allowed C for i2c
<Degi>
Hm yeah
<azonenberg>
So point to point segments make sense. I originally wanted to run the uarts off the fpga
<azonenberg>
then did io budgeting and realized i didn't have 24 free pins
<Degi>
We could keep adding more FPGAs haha
<azonenberg>
I considered that too
<Degi>
Like iCE40s are cheap
<Degi>
Like real cheap
<azonenberg>
i could in theory slap down an ice40 or even an ecp5
<Degi>
ecp5 requires some more infrastructure tho
<Degi>
But yes thats also only 5 € and can run very fast if you dont read the spec
<azonenberg>
so here's the thing, a f031 is $1.49 @ qty 100
<azonenberg>
Lol
<azonenberg>
for a board of this complexity that's literally free
<Degi>
A
<Degi>
ICE40LP384-SG32 is 1.52 $ at QTY 1
<azonenberg>
yes but that's 384 luts
<azonenberg>
can you fit a dozen uarts in that?
<Degi>
Oh
<azonenberg>
if you can't fit at least two uarts and an i2c controller in it, it's not cheaper
<Degi>
ECP5 25F would do
<azonenberg>
how much is that?
<Degi>
8 bucks for the 381 package
<azonenberg>
That's also 0.8mm pitch right?
<Degi>
Yes
<azonenberg>
hmm, because an xc7s6 in ftgb196 is only $14.70
<Degi>
Theres a 0.5 mm pitch variant
<azonenberg>
and is 1mm, and would avoid the need to mix two vendors' toolchains on the same board
<azonenberg>
and that's cheaper than a dozen stm32f031s
<Degi>
I mean the cheapest ECP5 is the 220-2202-ND on digikey, 12F variant with 256CABGA
<Degi>
6.57 $ for 1
<azonenberg>
i'm looking at xc7s6-1ftgb196c
<azonenberg>
realistically a dollar here and there on a $1K+ board is of no importance
<azonenberg>
the question is at an engineering level what makes more sense
<Degi>
ECP5 has full foss reliable toolchain support
<Degi>
And more IOs
<azonenberg>
and the spartan7 still has 100 ios which is overkill for what i'd be doing
<Degi>
And 1280 logic elements (LUT4? Should be enough for 8 UART)
<azonenberg>
can you fit twelve uarts, an i2c or spi slave, and some bridge logic into that?
<Degi>
I dunno?
<Degi>
You probably could into a 12F ECP5 and certainly into a 85F and run it at like tens of MHz (depending on how much headroom you wanna have)
<Degi>
Isnt there bigger STMs with more UART?
<azonenberg>
the f777 is one of the biggest, it has i think 8
<Degi>
A µC would be more practical than a FPGA tbh, because I think that thats better for control
<azonenberg>
but i also wanted to do the power control in the fpga
<Degi>
We could use like two of those with 6 UARTs
<Degi>
power control? Like turning the 12 V on?
<azonenberg>
Yeah
<azonenberg>
and overcurrent monitoring etc
<azonenberg>
i'd rather have that all done in gateware
<Degi>
FPGA has the upside of only being one chip and the downside of extra voltage regulator for 1.1 V needed
<Degi>
And of being faster
<azonenberg>
so thats the other advantage of doing it in a xilinx part with 1.0v vcore
<azonenberg>
we can use the same rails as the main fpga
<Degi>
I mean you could probably run a ECP5 at 1.0 V haha, but itd be out of spec
<azonenberg>
i have nothing against lattice stuff for use in a standalone system
<Degi>
Hmy eah
<azonenberg>
but i dont like mixing fpga families on one board
<Degi>
That makes sense, the toolchain thing is nice too
<azonenberg>
as far as resources go, 106 LUT / 71 FF for my UART IP on 7 series
<Degi>
Hmh okay
<azonenberg>
that's lut6
<Degi>
Kinda sounds like quite a bunch but I havent measured the LUT count the nmigen-stdio Serial takes.
<azonenberg>
that includes some optional status signals that you could probably optimize out
<azonenberg>
then the SPI slave is 17 lut / 35 FF
<azonenberg>
an xc7s6 is 3752 LUT and 7504 FF
<azonenberg>
So i'd be looking at 1289 LUT and 887 FF for just the i/o logic, not counting the bridging between them or power control
<azonenberg>
adding in the logic to drive them, i think i'd end up using a fair fraction of the 7s6
<azonenberg>
a small ecp5 would totally work but adding in the cost and board area of the 1.1V regulator it probably wouldn't be any smaller or cheaper
<Degi>
Yeah
<Degi>
Hmm
<Degi>
Run it off a LDO xD
<azonenberg>
lol
<sorear>
how many voltages do you already have?
<Degi>
I mean you have the 1.8 V or 2.5 V or so right? haha
<azonenberg>
sorear: i am hoping to keep everything on an LTC3374
<sorear>
what's xilinx' favorite core voltage?
<azonenberg>
depends on the generation. 7 series is 1.0
<Degi>
8 channel?
<azonenberg>
6 is 1.2, ultrascale is in the high hundreds of MV
<Degi>
How many is needed for the 1V0? How many amps does the FPGA use
<azonenberg>
8x 1A channels, 4 phases, parallel up to 4 outputs each
<azonenberg>
so up to 4A max
<azonenberg>
and i dont know yet, this is the early stages of design picking parts out
<monochroma>
part pickling
<Degi>
Also dont forget to route the sense wire from somewhere under the FPGA since resisitve drop betwee regulator and FPGA may be significant
<azonenberg>
i may have to do 1v0 on a separate reg and then the rest on a 3374 or something, TBD
* Degi
pickles some inductors in a saltwater jar
<Degi>
Tbh 4 A could suffice
<Degi>
This is not a CPU after all
<azonenberg>
like i said i havent run the numbers, i'm not making any decisions yet
<azonenberg>
Rail wise i will need, at minimum, 3.3V for the stm32, the QSFP+, the SFP+, the Ethernet PHY, and the UARTs
<azonenberg>
2.5V for the LVDS inputs
<Degi>
I wonder if its possible to overload the ECP5 EVN which uses the 85F variant, I think 83.6k LUTs toggling at 800 MHz wont be good haha
<azonenberg>
1.2 for the low voltage side of the ethernet PHY
<azonenberg>
1.0 for the fpga core
<azonenberg>
1.5 for the DRAM
<Degi>
DRAM could use some electricity too...
<azonenberg>
1.2 and 2.5 should be fairly light
<azonenberg>
in fact the phy has an integrated LDO you can use for the 1.2 but i like to avoid using it as it runs hotter that way
<Degi>
And like 8 40 mm server fans for cooling
<azonenberg>
The max current used by a typical DDR3 SODIMM, worst case, is around 2A with all banks working in parallel on reads/writes
<Degi>
And a heating element, so the output air feels like it is actually doing something.
<azonenberg>
i expect to allocate at least 3A to that rail since the FPGA needs some power too, maybe 4 to provide some headroom
<azonenberg>
so yeah i guess i can't fit it all on a 3374
<Degi>
For the IOs?
<azonenberg>
yes, and terminations etc
<azonenberg>
Vref/VTT is not included in that total
<Degi>
The 50 ohms on the RAM side?
<azonenberg>
might not be 50 but yeah
<Degi>
Like 50 / 64 = 0.78125 and at 1.5 V that is 1.92 A
<Degi>
Geez
<azonenberg>
the termination is dynamic and only enabled when needed
<azonenberg>
but yes, dram runs warm
<Degi>
I mean the LTC3374 in a bad package isnt that pricy at qty 100
<Degi>
Cant it use LVDS or something ugh
<azonenberg>
i could always use two of them :p
<Degi>
Or 100?
<Degi>
Then we can supply like 800 A to the FPGA
<azonenberg>
no i mean for all of the rails
<azonenberg>
one for 1.0 and 1.5 and one for 1.2/2.5/3.3
<Degi>
Maybe for 1.0 and 1.5 a different one makes more sense idk
<azonenberg>
Yeah. I'll look into it once i have a full power budget done