<azonenberg>
tl;dr thinking of ripping out the import code in MockOscilloscope
<azonenberg>
and replacing it with a file import filter series similar to what i do for touchstone
<azonenberg>
this provides an easy way to twiddle knobs on an import
<azonenberg>
like sample rate and data format for raw i/q
<azonenberg>
it also is just a lot nicer from the API perspective
<Degi>
It also sounds more consistent
<Degi>
Hmm, not sure what a user would do with "make/model/serial metadata" but maybe these could be passed as signals or so? Or somehow be accessible as a property of the filter (though I haven't used filters myself yet) in case you want to do oscilloscope specific things
<azonenberg>
yeah there is currently not any properties api for filters
<Degi>
Hmh yes, that would be good to add, at least in this case
<azonenberg>
at least, read only
<azonenberg>
more precisely there are properties but no way to designate them as read only
<Degi>
Hmm, throw an error when somebody attempts to write?
<Degi>
Is there a way to tell glscopeclient to stop the scope, get all configuration and then read the trace? Like that you're able to adjust the waveform on the scope and then use glscopeclient to do further analysis? Especially since the Rigol MSO5000 is a bit slow (it seems to be a processor issue, since the GUI hangs during large waveform transfers)
<azonenberg>
Stop, do your config on the scope, then hit the "refresh cnofig" button in glscopeclient
<_whitenotifier-e>
[scopehal] azonenberg fa4d92d - Fixed sign in GetOffset()
<_whitenotifier-e>
[scopehal] azonenberg a00ccf2 - Added initial IBIS driver filter. Still needs parameters for a whole bunch of stuff to be actually useful.
<_whitenotifier-e>
[scopehal] azonenberg 25c720d - IBISDriverFilter now uses parameters for model path and model ID. Fixes #206. Fixes #207.
<_whitenotifier-e>
[scopehal-apps] azonenberg a990a20 - Refactoring: FilterDialog now does not have a close button. Changes mostly commit when the dialog is closed, but will be moving towards real time application in the future.
<_whitenotifier-e>
[scopehal-apps] azonenberg 285a2f5 - FilterDialog: send OnParameterChanged notifications any time a file or enum argument is altered
<azonenberg>
Ok that's a good start, it needs a bit more work to be where I want it still
<azonenberg>
In another hour or two I should have the ability to send an arbitrary digital waveform generated by a filter or acquired from real hardware into an IBIS model to produce an analog waveform
<azonenberg>
with your choice of min/typ/max corners and termination conditions
<azonenberg>
Had to do a lot of refactoring and debugging to handle filters that have enums which can change depending on other parameters
<azonenberg>
and i don't think i'm 100% debugged WRT file load/save etc yet
<azonenberg>
ok there we go, minimum usable IBIS support complete
someone-else has quit [Quit: Connection closed]
<d1b2>
<dannas> @azonenberg Impressive... Uhm, wait a minute. You're in Seattle. Don't you sleep during the night?
<azonenberg>
Lol
<azonenberg>
yes, my sleep schedule is all kinds of messed up right now
someone-else has joined #scopehal
<d1b2>
<dannas> For someone who's never encountered IBIS models before: Am I correct in saying that they are like SPICE models but more used for high-frequency simulations? If so, why would you want to have a IBIS filter? To create a signal with some known characteristic to mimic the behaviour of some circuit/board you don't posess? I can understand that you might want to introduce noise into a signal for testing a board/chip. But why would you need
<d1b2>
something as an IBIS model?
<d1b2>
<dannas> googles for AWG and IBIS
<azonenberg>
IBIS models are dumbed down behavioral models that don't give away details of the internals of the circuit
<azonenberg>
it's used for when you don't want to give out a full netlist of your i/o structure
<azonenberg>
basically it's just tables of data without any details on where the data came from
<azonenberg>
(often a spice sim of the real silicon)
<azonenberg>
so you have I/V curves of the high and low side drive transistors
<azonenberg>
V/T curves of rising and falling edges
<azonenberg>
etc
<azonenberg>
The goal is to allow you to do signal integrity work prior to making the board
<azonenberg>
So you generate a digital test waveform, use the IBIS block to convert it into an analog waveform with edge shape matching that of your real chip
<d1b2>
<dannas> Ok, so it's not more capable than SPICE than? Rather it hides more details that the manufactureres don't want to expose?
<azonenberg>
Yeah
<azonenberg>
it's actually less capable than spice
<azonenberg>
but good enough for i/o signal integrity work
<azonenberg>
Anyway. so you use the ibis model to convert an abstract digital test waveform into analog voltages
<azonenberg>
add noise to simulate power supply noise on the tx side
<azonenberg>
add jitter to the clock of the test waveform going into the ibis (I estimated jitter for a 7 series FPGA PLL)
<azonenberg>
then apply an s-parameter model of a channel
<azonenberg>
and now you know what your signal should look like at a receiver
<azonenberg>
in the screenshot the channel model is a VNA measurement of one of my SMA connector test boards
<azonenberg>
but in the more typical use case it would be an EM simulation of a board you're designing
<azonenberg>
So you can do a full channel model and predict what the waveforms will look like before you spend thousands of dollars building a prototype
<d1b2>
<dannas> Ok... So IBIS provides parts of the characteristics. The S-parameter model provides the model of the channel... It will be so cool when all these pieces fall into place for me.
<azonenberg>
Yeah
<azonenberg>
then the final piece, which i didn't show here
<d1b2>
<dannas> s-parameters provides behaviour of passive interconnects. ibis provides behaviours of transistors..
<azonenberg>
of output buffers
<azonenberg>
not single transistors
<azonenberg>
(and input parasitics but i'm ignoring that part for now)
<azonenberg>
Also for now i am modeling the behavior of the signal at the die pad
<azonenberg>
IBIS also includes information about the package including RLC parasitics between die pad and BGA land
<azonenberg>
Which i am ignoring
<azonenberg>
and even crosstalk parasitics from one ball to another
<azonenberg>
So there's lots more work to be done WRT higher fidelity modeling
<d1b2>
<dannas> Cool, thanks for the explanation.
<_whitenotifier-e>
[scopehal] azonenberg opened issue #545: IBIS: support package RLC parasitics rather than outputting waveform as seen by the die pad - https://github.com/azonenberg/scopehal/issues/545
<_whitenotifier-e>
[scopehal] azonenberg labeled issue #545: IBIS: support package RLC parasitics rather than outputting waveform as seen by the die pad - https://github.com/azonenberg/scopehal/issues/545