tverbeure2 has quit [Remote host closed the connection]
<noopwafel>
azonenberg: re picoscope: does it make sense licensing-wise to start by wrapping their libs? would you accept such a driver in the tree?
<noopwafel>
(I would ping bvernoux but I guess they're not here right now)
<noopwafel>
tempted to write vds1022 driver too, since I already REed that, but it's ridiculously low-end (the better models just talk SCPI)
<azonenberg>
noopwafel: what is the license on the pico libs?
<azonenberg>
as a general rule with any third party component there's three options
<azonenberg>
an in-tree driver that we link with directly
<azonenberg>
an in-tree driver that is disabled by default and only turned on if the user enables it, say for something with a GPL'd component we dont want to contaminate the normal binaries with
<azonenberg>
and a completely standalone (separate binary) server that bridges whatever API out to SCPI commands over TCP
<azonenberg>
thus allowing use of the existing scopehal "lan" driver
<noopwafel>
license is $proprietary (+ use with pico hw only)
<noopwafel>
server probably makes a lot of sense
<azonenberg>
is it SCPI under the hood or a custom API?
<azonenberg>
i dont like the idea of converting to text and back, that seems super inefficient
<azonenberg>
one possibility is to design a two-port API like i use on the BLONDEL prototype
<azonenberg>
a text scpi interface for control plane then a binary pub/sub interface for waveform data
<noopwafel>
it's custom (the lib talks directly to usb)
<azonenberg>
So in that case let's try to avoid needless conversions to/from text on the data plane
<azonenberg>
What do you think of the 2-port scheme i mentioned?
<azonenberg>
we can do a simple text scpi protocol for control plane then some kind of minimal binary framing around the data. preferably pub/sub rather than polling based
<noopwafel>
it would also ease streaming
<azonenberg>
yes, that was the idea
<noopwafel>
thinking a bit about whether the scopehal end needs to care about scope-side memory management, but I guess .. probably not, and another problem anyway
<azonenberg>
noopwafel: IMO the ideal solution is to define a single dual socket protocol that we can use for our in house instruments as well as third party stuff, with some quirks based on specific instrument classes
<azonenberg>
i.e. the pico bridge, blondel, all of our future projects, and any future bridges from third party APIs to scopehal would have a single driver of "scope over IP"
<azonenberg>
ascii scpi control plane, raw binary samples on another socket
<azonenberg>
then we'd just write servers for this protocol for each device we want to support
<azonenberg>
Thoughts on that vs making one specifically for pico?
<noopwafel>
the only advantage of one specifically for pico is that you don't end up copying stuff over the socket again
<azonenberg>
no i'm saying we would still make the pico driver a tcp server
<azonenberg>
the question is do we define a single protocol for that server and use it everywhere?
<noopwafel>
but you could actually just switch the raw binary samples to shared memory or so, if that were ever a problem
<azonenberg>
i.e. one scopehal driver for all pico and custom devices, with some special casing for sample rate options etc
<azonenberg>
one tcp protocol
<noopwafel>
but I think a single protocol is a much better idea than something custom :)
<azonenberg>
then all of the pico specific stuff would be in the server side
<azonenberg>
the client would be the same
<azonenberg>
I have some code in the current BLONDEL driver (AntikernelLabsOscilloscope) that's far from complete but might be worth using as a baseline then
<azonenberg>
we'll have to think of a generic name for the driver
<azonenberg>
right now that driver doesnt do full pub/sub, i do not want to actually use THAT protocol
<azonenberg>
and it hard codes one channel with 16k 8-bit samples and a bunch of other stuff
<azonenberg>
But i want to use this as a baseline for a full protocol specification. I originally was thinking protobufs but i think SCPI is fine to use for the control plane socket as that's not performance critical
<azonenberg>
then the data plane socket we need to define a protocol for
<azonenberg>
If you have some time, how about you sit down and start drawing up a proposed specification? fork scopehal-docs and make a new directory "protocol"
<azonenberg>
as of right now all of the stuff in doc/ is in the root of scopehal-docs but i plan to refactor that so we have a subdir for the manual and other subdirs for other stuff like the prtoocol spec
<azonenberg>
maybe i'll do that later otday once this board is done
<noopwafel>
I figured first I might actually try hacking up a prototype
<noopwafel>
just something pretty dumb, but enough that I make sure I know what has to actually be supported
<azonenberg>
fair enough
<noopwafel>
but my first worry was "oh no, this is going to end up with some weird protocol that only I'm ever going to use", much better if it's something actually shareable
<azonenberg>
The scopehal hardware's protocol isn't yet defined
<azonenberg>
we will need to be flexible, for example BLONDEL will support the left 4 and right 4 channels having different sample rates
<azonenberg>
and even separate 8/12 bit resolution
<azonenberg>
and obviously not every scope this protocol interfaces with will have that capability
<azonenberg>
we'll need some sort of discovery scheme
<azonenberg>
the big thing i want to avoid is the problem literally every current scpi protocol has
<azonenberg>
namely, busy-polling a status registr until the scope triggers
<azonenberg>
pub/sub is IMO the way to go
<azonenberg>
tell the instrument you want to see data from channel 3, arm the trigger
<azonenberg>
then any time it triggers *it pushes a waveform to you*
<azonenberg>
on a separate socket to avoid confusion with the control plane
<azonenberg>
What i'm shooting for is the level of protocol compat that LeCroy has
<azonenberg>
where monochroma's early 2000s DDA-5005 with a floppy drive and windows XP can use the same scopehal driver as a modern million-dollar LabMaster
<azonenberg>
sure, there's new features, but the API hasn't really changed
<azonenberg>
This will require a lot of careful design and futureproofing to avoid needing to retrofit older instrument bridges/firmware
<noopwafel>
right, the busy-polling is absurd when you're doing thousands of triggers a second
<azonenberg>
Yep
<azonenberg>
Speaking of which once we reach >60 triggers/sec on any instrument we're going to have to do both optimization and UI work on glscopeclient
<azonenberg>
(none of my current scopes can do this)
<azonenberg>
Figuring out how to handle a trigger rate in excess of the video update rate
<azonenberg>
i think we're going to need to do some kind of "digital phosphor" persistence where we render many waveforms stacked on a single video frame
<azonenberg>
then when you stop triggering, freeze the single most recent waveform
<azonenberg>
the alternative is to do what i do right now (bit of a hack) which is to, whenever more than X pending waveforms are ready, put them into the history but don't do any rendering on them
<azonenberg>
i dont know if i skip decodes on them too or not, it's never really been tested
<noopwafel>
so glscopeclient has ScopeThread which just loops on PollTrigger, so as a hack I guess the scope code could also just block for a short time for now
<noopwafel>
(I know this is totally irrelevant to the wire-level design, just wondering how painful it would be to prototype)
<azonenberg>
noopwafel: so actually fixing this for a push based protocol is already kinda in the works
<azonenberg>
right now what i do is, PollTrigger always returns "triggered"
<azonenberg>
then AcquireData() is a blocking read on the data-plane socket
<azonenberg>
(in AntikernelLabsOscilloscope, which is a very early WIP)
<azonenberg>
this eliminates the wire-level polling and uses the OS-level socket as a sync object, essentially
<_whitenotifier-f>
[starshipraider] azonenberg pushed 1 commit to master [+1/-0/±5] https://git.io/JfMkv
<_whitenotifier-f>
[starshipraider] azonenberg c93bff2 - Final version of integralstick-mead board
<azonenberg>
Boards and stencils ordered
juli965 has joined #scopehal
<electronic_eel>
oh, yeah, the digital phosphor thing is something I wondered about how best to do it too
<electronic_eel>
even cheap current scopes have like 100.000 wfms/s and use that to build the digital phosphor display
<electronic_eel>
we'll have a hard time pushing that much data to the pc
<azonenberg>
why do you think i wanted 10/40GbE? :p
<electronic_eel>
but even a 8ch DUDDEL will blow the 40 GbE, also you need quite a powerful pc to process it
<electronic_eel>
but you know in advance if you want single shot data or digital phosphor
<azonenberg>
of course. But we don't need that high WFM/s i think
<azonenberg>
You're suggesting integrate on the scope?
<electronic_eel>
yes, for some small time window
<azonenberg>
while that's possible, at that point you're essentially outputting a persistence map like an eye pattern
<azonenberg>
the data becomes useless for protocol decodes etc
<electronic_eel>
yes, of course
<azonenberg>
my thought was to limit wfm/s to the max rate we can keep up with doing full analysis on
<Degi>
Make it configurable
<azonenberg>
then switch to digital phosphor mode for rendering only if WFM/s > display framerate
<electronic_eel>
the user knows if he wants protocol decoe or phosphor
<Degi>
*they but yes
<Degi>
Maybe we can even 8b10b decode on the FPGA or something
<electronic_eel>
o sorry, old habits die hard
<Degi>
Hmm something to detect seldom glitches would be good
<azonenberg>
I would love to have 8b10b and similar advanced triggering on the fpga in our higher end models
<electronic_eel>
another option would be to set apart a block of ram to integrate and use the rest for single samples
<azonenberg>
in the <1 GHz scopes i suspect 8b10b is useless though
<azonenberg>
the slowest things i know that use it are SGMII, 1000base-X, SATA gen1, and PCIe gen1
<azonenberg>
all are >1 Gbps
<azonenberg>
meaning too fast for 500 MHz scope to decode
<Degi>
1000base-x is above 1 Gbps?
<azonenberg>
Degi: the physical signaling rate is 1.25 Gbps
<azonenberg>
so you'd need 625 MHz bandwidth, minimum, to decode
<Degi>
Do we have USB 0.7 decoding heh
<azonenberg>
and significantly more for SI work
<Degi>
Hm yes
<electronic_eel>
doesn't it also have some weird echo cancel thing where you need to know which port is sending which data?
<azonenberg>
That's 1000base-T you're thinking of, over copper
<electronic_eel>
yes
<azonenberg>
1000base-x is the signaling used over optical media or backplanes
<electronic_eel>
ah, right, sorry
<azonenberg>
8b10b coded raw ethernet frames at 1.25 Gbps over one diffpair each way
<azonenberg>
anyway VOLLUM/MURDOCK could definitely benefit from hardware serial triggers
<Degi>
And for the LA
<azonenberg>
The higher speed LA (DENNARD) yes
<azonenberg>
MAXWELL at 1.25 Gsps not so much
<azonenberg>
well, 8b10b in particular
<azonenberg>
hardware triggers for i2c/spi etc are very much good to have
<miek>
i'm hoping all the models will have the ability for some triggering/decode in the fpga. being able to write a custom trigger for something on the fly would be amazing
<azonenberg>
miek: so i've started to think about that. I think we could probably make some kind of microcode engine that can download firmware at run time to do pattern matching
<electronic_eel>
on the other hand the scopes have so much more ram than conventional scopes that you can live with a few false triggers in the fpga if you segment the memory
<electronic_eel>
then you can do the decode trigger on the pc
<Degi>
Hm we can sample like what 4 seconds?
<electronic_eel>
and throw away the rest of the data
<Degi>
yeah thatd probably work too
<Degi>
Or even do multiple different triggers heh
<electronic_eel>
yes, that's what I meant with segmented memory
<azonenberg>
So yes that is an option but you still risk missing triggers IMO
<azonenberg>
i think a microcoded pattern matching engine is the way to go
<Degi>
Just add more sample memory
<Degi>
hm yes partial FPGA reconfiguration would be neat
<Degi>
Or a second FPGA for triggering which can be fully configured
<electronic_eel>
yeah, more memory, more, more, more
<azonenberg>
Not PR. PR means either open fpga tools for 7 series - a long way out
<azonenberg>
or requiring end users to have vivado and endure long rebuild cycles
<azonenberg>
I'm proposing using reconfigurable LUTs (SRL32s) in a fixed topology
<Degi>
(That's why I'm trying to make a PCIe card middle part between the front end board and a PC with massive amounts of RAM or a fast GPU)
<azonenberg>
to implement something akin to the greenpak async state machine
<azonenberg>
Degi: there's a fundamental problem that we can fill the memory faster than we can dump it
<azonenberg>
we cannot process full line rate on the PC
<azonenberg>
thus any advanced triggering, to avoid missing stuff, has to be on the fpga
<Degi>
Sure that the foss tools are a long way out? heh
<azonenberg>
fully usable ones we can just deploy and use casually like glasgow does? yes
<azonenberg>
also PR has a lot of constraints. it's meant for coarse grained functions
<azonenberg>
it's not suitable for something like this
<azonenberg>
and the chip is too big to do a full-bitstream rebuild like glasgow does
<azonenberg>
without very long wait times
<Degi>
Well a second trigger FPGA thats already fully FOSS supported like ice40 or ecp5 could work
<azonenberg>
no, i want to do something akin to what my old RED TIN logic analyzer core did
<azonenberg>
dynamically generate lut truth tables at run time, load into SRL32s
<electronic_eel>
a second fpga would need to be fast enough to retrieve and work through all the data
<azonenberg>
but have the flipflops and interconnect between them be hardwired
<azonenberg>
this is a known, established technique
<azonenberg>
we just have to design the architecture to be suitably flexible
<Degi>
I mean an ECP5 would be with 8 data lines and one trigger feedback line (even though it would be slightly out of the spec which doesnt specify what speed grade its for (I assume the lowest?) but works)
<azonenberg>
Degi: no, we'd need way more than that
<Degi>
At least for blondel thatd work
<azonenberg>
BLONDEL alone will have (assuming we threshold ADC data in the scope FPGA) 8 digital lines and 16 digital so that's 24
<Degi>
Although I've heard that all ECP5s in the 285 package and onwards are basically the same chip between the U, UM and UM-5G variants (even when it says it has no serdes, it actually has one)
<Degi>
Ah yes the 16 digital lines
<azonenberg>
and that's at 1/1.25 Gsps. So you'd want to parallelize the data down to lower bit rates
<Degi>
Idk the ecp5 chips have like a hundred DDR receivers
<azonenberg>
so say 48 lines at 625 Msps
<Degi>
It theoretically works at like 1.6 Gbit/s though I did no BER testing on that
<azonenberg>
putting a second fpga on the board seems like a huge amount of work though
<Degi>
hm yeah
<azonenberg>
why not just use the 7 series?
<Degi>
Because it doesnt have a FOSS toolchain and is way pricier
<azonenberg>
we need the 7 series part anyway for the main scope
<azonenberg>
i'm saying why add a second fpga
<azonenberg>
we just need to build a pattern matching engine on the artix
<Degi>
For the trigger, one that can be fully reconfigured
<Degi>
Or like that
<azonenberg>
This is a solved problem at a high level, the only question is the details of how the pattern logic is constructed
<electronic_eel>
but do you want the user to write the trigger in verilog or nmigen or something like that?
<electronic_eel>
I think that is too much for using a scope
<azonenberg>
So at least to start my plan was to procedurally generate it from a list of canned protocols
<electronic_eel>
you want some more limited interface language I think
<azonenberg>
so have a "code generator" that emits a trigger for "I2C address 0xa0"
<azonenberg>
or "K28.5 in 8b10b data"
<electronic_eel>
yeah, and that code can be in a limited fsm config language
<azonenberg>
well like i said to start my plan was to generate raw lut truth tables from a code generator we wrote
<azonenberg>
we can then design a user facing DSL for custom triggers later
<azonenberg>
My basic proposal is to start with a crossbar layer that takes all of the analog and digital channels and selects a fixed number, let's say 8 for the sake of discussion, in a specific order
<azonenberg>
so input 0 to the pattern engine is always SDA and input 1 is SCL for the I2C trigger, regardless of which physical instrument channels are in use
<azonenberg>
then the pattern engine would have a state register, the N inputs to the matching engine, and a bunch of registers for storing old signal values to detect transitions etc
<Degi>
Would the ADC provide 8 inputs?
<azonenberg>
and some lut logic allowing you to decide when to move to the next state, when to write one of the 8 input values or a constant 1/0 to the temp registers, etc
<azonenberg>
Degi: my initial thought was to have the crossbar have a 1-bit input from each digital channel, as well as a 1-bit output from each analog channel
<azonenberg>
we could then have a separate thresholding/hysteresis block on each analog channel to produce a digital output from it
<electronic_eel>
Degi: I guess there needs to be a comparator stage that creates 1 bit from an adc channel
<azonenberg>
we might want separate high- and low-going thresholds
<electronic_eel>
there could also be stuff like hysteresis and filtering of course
<azonenberg>
Yeah
<Degi>
Hmm okay
<azonenberg>
I'm envisioning a fixed filter graph where we have configuration settings at each step in the flow
<Degi>
Like what if you wanna trigger on a signal with a rise of 1 V/ns to 10 V/ns or so
<azonenberg>
This is a digital pattern matching engine
<Degi>
Hmm okay
<azonenberg>
we can have separate blocks for analog triggering and then muxing on the outputs to select one or another
<azonenberg>
also in addition to just outputting boolean triggers we will be able to output a fractional trigger timestamp
<azonenberg>
e.g. the level trigger will be able to interpolate to find the nominal position of a rising edge between samples
<azonenberg>
But at least to start the digital trigger won't do that
<azonenberg>
ooook so, now that the MEAD boards are ordered... at some point i need to start work on MAXWELL but I feel like now might not be the best time for that
<azonenberg>
I still have to do more linearity testing etc on the BLONDEL prototype, and do more debugging on the probes for the KS
<Degi>
Hm yes, a frequency response test would be neat too
<Degi>
Preferably to like 1 GHz
<noopwafel>
hm, simple-trigger + stream only trigger area to the host + more advanced matching to see if you want the buffer is a nice idea
<Degi>
In case there is some parasitic coupling
<azonenberg>
noopwafel: my thought was to have a bank of trigger engines that are all fed all the time by the signal from the adcs + digital channels
<azonenberg>
then a mux on the output to decide which one you want to use
<Degi>
Maybe with the ability to turn unused ones off cause otherwise thats gonna use a bunch of energy probably
<azonenberg>
i doubt it will be significant
<azonenberg>
There will need to be some parallelism in the trigger engine as well, because the sample rates on even BLONDEL are faster than the fpga core can clock
<azonenberg>
So we're going to be processing multiple samples per edge of a slower clock
<Degi>
Hm yeah
<Degi>
Or maybe only the analog triggers that fine?
<noopwafel>
would be nice to have :)
<azonenberg>
Which means the output needs to be a trigger enable signal as well as a phase value saying which of the, say, 8 samples we processed was the source of the trigger event
<Degi>
Does it really matter where exactly the trigger happened when you have the necessary sampled data and can retrigger on the PC
<Degi>
Hm yes
<Degi>
8 samples?
<azonenberg>
Just using that as an example (trigger logic at 1/8 Fsample)
<azonenberg>
And yes, it does. Because we need to output the trigger timestamp to the PC so we can do things like persistence maps, also we need to output a trigger event pulse on the trigger-out port for syncing multiple instruments
<azonenberg>
so we're going to use a SERDES that steps the phase back up to an edge occurring at the full sample rate resolution
<Degi>
Ah yes
<azonenberg>
There will of course be some latency in the trigger engine but we can quantify and document the end to end trigger latency
<azonenberg>
as long as it's constant we can cal it out
<azonenberg>
by having the next instrument in the chain trigger X time before the trigger pulse
<Degi>
Well its gonna vary by like 1 ns
<azonenberg>
what do you mean vary?
<azonenberg>
the trigger latency should be constant
<Degi>
Depending on where exactly it happens between two samples
<Degi>
Or serdes output clocks
<azonenberg>
Oh. Yes there will be sample rate jitter. On the PC side we can compensate for this by outputting a phase value to software
<azonenberg>
and displacing the displayed waveform by a fraction of a sample. I do this already on the lecroy driver using the TDC output in the waveform header
<azonenberg>
as far as trigger sync goes, it may be possible to use a delay line for this on the higher end instruments to actually do sub-sample phase resolution on the trigger output. But i believe this is unnecessary for BLONDEL
<Degi>
Hmm why would such precise trigger sync be necessary
<Degi>
IF you sync the instruments with a clock and then timestamp the sample values, even with a rather loose trigger, as long as the triggering instrument knows the timestamp exactly, it should work
<azonenberg>
Yeah sub-sample sync between instruments probably isnt needed
<azonenberg>
Just a thought
<azonenberg>
in any case a shared refclk will definitely make sync easier