<_whitenotifier-3>
[scopehal-apps] azonenberg closed issue #73: Add WFM/s counter to status bar (hidden when not in run mode, running average of past few seconds) - https://git.io/JvgXi
_whitelogger has joined #scopehal
<awygle>
ah, cool
<azonenberg>
The trick being that i'm doing this in parallel with writing my brand new ILA core (complete systemverilog revamp of the old one which dates back to my thesis days)
<azonenberg>
from-scratch rebuild
<azonenberg>
so i have to debug both sides in parallel
<_whitenotifier-3>
[scopehal-apps] azonenberg opened issue #74: Digital channels should be drawn smaller than analog in mixed-signal WaveformGroup's - https://git.io/Jvgh4
<_whitenotifier-3>
[scopehal-apps] azonenberg labeled issue #74: Digital channels should be drawn smaller than analog in mixed-signal WaveformGroup's - https://git.io/Jvgh4
<_whitenotifier-3>
[scopehal] azonenberg pushed 1 commit to master [+0/-0/±2] https://git.io/JvghB
<_whitenotifier-3>
[scopehal] azonenberg 6ec9ae3 - Continued work on AntikernelLogicAnalyzer. Can now capture waveforms but not all trigger stuff is implemented.
<_whitenotifier-3>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±5] https://git.io/JvghR
<_whitenotifier-3>
[scopehal-apps] azonenberg a451205 - Various rendering and UI work to support digital and digital-bus waveforms in main channels vs overlays
<azonenberg>
ok so, at this point my ILA test works in glscopeclient's UI, although i still have some bugs and such to work out
<azonenberg>
there is however no UI to configure triggers on an ILA yet
<azonenberg>
or a LA in general
<miek>
i guess the agilent driver needs some digital channel support now :)
<azonenberg>
The lecroy driver is getting it resurrected (was bitrotted and i think partially commented out) as soon as my other scope comes back on thursday
<azonenberg>
right now it's on a ups van somewhere between my lab and the lecroy factory
<azonenberg>
there's also a lot of tweaks to do, like the fact that digital channels waste a ton of UI space right now
<azonenberg>
because they're treated the same as analog channels but only drawn like 30 pixels high
<azonenberg>
so unless you have a buttload of protocol decodes that's wasted space
<monochroma>
azonenberg: yeah i like the format so far
bvernoux has joined #scopehal
<awygle>
azonenberg: what functionality are you planning for your ILA?
<bluezinc>
ILA?
<bluezinc>
oh, some kind of (I?) logic analyzer?
<monochroma>
integrated iirc, FPGA LA core
<bluezinc>
I heard about the FPGA core, wasn't sure if your were discussing that or if he had a new project.
<awygle>
Internal
bvernoux has quit [Quit: Leaving]
<azonenberg>
awygle: Re the ILA, right now i have arbitrary channel count and power-of-two memory depth
<azonenberg>
one comparator per channel supporting true/false/equal/lessequal/gequal/greater/unequal comparison operators
<azonenberg>
global trigger mux selects either reduction AND of the comparator outputs, reduction OR, or ignoring all comparators and using the external trigger input
<azonenberg>
No RLE yet although i will likely (re-)add that in the future
<azonenberg>
Internal symbol table in block ROM, so no need to use a separate .ltx file or similar like the xilinx ILA does
<azonenberg>
width and name of each signal are stored there
<azonenberg>
(although i dont have fancy code gen so you have to specify that explicitly at synth time)
<azonenberg>
also boom, win. Found some critical info from Twitter
<azonenberg>
pmk.de is the OEM for LeCroy and Pico's probes, very likely others. The PMK 893-250-001 probe positioner exactly matches the two-footed positioner that i already knew LeCroy and Pico sourced from the same vendor (just not who that vendor was)
<azonenberg>
The PMK Tetris series active probe are the OEM source for the LeCroy ZS1000/1500/2500 active probes, PMK Sonic is the ZS4000 (both customized for LeCroy with an ID EEPROM and custom back half of the enclosure with a ProBus header)
<azonenberg>
The ground lead and tip i've been seeking are PMK 890-400-811 and 890-800-000
maartenBE has quit [Ping timeout: 240 seconds]
<azonenberg>
Or PMK 890-400-800 ground
<azonenberg>
i'll have to figure out which fits my design better
<azonenberg>
Then ED10173-ND looks like a good receptacle for the tips, which does not need to be manually dismantled like the previous stuff i was looking at
maartenBE has joined #scopehal
<azonenberg>
But i need to respin the probe, i think, for better mechanical mounting of it
<azonenberg>
Since i only have 2.5mm of depth right now for the tip socket and i need more like 4.5 for that receptacle
<azonenberg>
also the ground receptacle needs a bit more width available
<azonenberg>
Might want to slightly modify the shell as well to handle a slightly fatter tip PCB
<azonenberg>
So far the list of ECOs for v0.7 probe are to provide more width in the ground lead mount, more length for the tip mount
<azonenberg>
less solder paste on the resistors
<azonenberg>
possibly adjust depth of the ground lead mount wrt tip of the probe for better compat with OEM ground accessories
<azonenberg>
and add soldermask over the ground next to the tip so the CPW is less likely to short to the tip socket
<azonenberg>
Also, after a few fixes with my UART at 1.5 Mbaud I'm getting ~10 WFM/s with ILA over UART
<azonenberg>
Up to 15 after some optimizations
<azonenberg>
Still no trigger config download, just hard-coding "force trigger" as soon as i arm it
<awygle>
What exactly does wfm/s mean? I know it means "waveforms per second" but that seems ill-defined, which means I'm missing context.
<azonenberg>
How many triggers per unit time are being processed, downloaded from hardware, and displayed
<azonenberg>
It's a metric of end to end system performance including the scope/LA, the link from it to your PC, and software performance crunching them
<azonenberg>
i.e. if you arm the trigger, wait a second, then stop you'll have 15 captures in the history buffer (assuming history is enabled)
<azonenberg>
obviously this assumes the trigger event occurs frequently enough that "waiting for trigger" isn't a significant amount of time
<_whitenotifier-3>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/Jv2sX
<_whitenotifier-3>
[scopehal-apps] azonenberg 6e9010a - HistoryWindow: calculate RAM usage for digital captures, not just analog
<_whitenotifier-3>
[scopehal] azonenberg pushed 1 commit to master [+0/-0/±2] https://git.io/Jv2sM
<_whitenotifier-3>
[scopehal] azonenberg e5d17f9 - AntikernelLogicAnalyzer: continued initial implementation. Works, but still no proper trigger configuration.
<awygle>
And "captures" here is one cut of all sampled signals, or one fill-and-dump of the capture memory?
<azonenberg>
The latter
<azonenberg>
My test right now is one 8-bit and one 1-bit channel so 9 bits (rounded up to 2 bytes for UART transfer) per sample, 1K points per waveform
<azonenberg>
obviously performance will drop with deeper memory. I'm mostly limited by the speed of the UART
<azonenberg>
Realistically i cant imagine ever needing to trigger an ILA this fast
<azonenberg>
Normally you'd do one trigger then spend a while looking at results. But good to know it can work faster
<awygle>
I see
<awygle>
Frankly this seems like a pretty useless measure. Too many variables. But ah well
<azonenberg>
It's mostly useful to know when optimizing scope drivers etc
<azonenberg>
as an absolute measure it's relatively useless, but deltas in the same experimental setup can be significant
<awygle>
Sure
<azonenberg>
ok so at this point the ILA driver seems to be working well, what's missing now is UI to do the trigger configuration
<azonenberg>
So i'll work on that in a bit after i grab some noms
<azonenberg>
Once that's done i'm going to throw my embedded tcp/ip stack on the DUT and try to probe some more complex signal activity
<azonenberg>
See how the UI handles more signals, and maybe write some protocol decoders for more complex protocols
<awygle>
Approximately how many hours would you say it took to get to this point?
<azonenberg>
a lot of the work was in defining APIs that didn't exist previously etc
<azonenberg>
Adding a new LA driver will be a lot easier
<azonenberg>
i also wasted a lot of time yesterday chasing what turned out to be a metastability issue i had SOMEHOW never run into before
<azonenberg>
tl;dr my uart ip didn't have a synchronizer at the input
<azonenberg>
i've been using it for 10+ years
<azonenberg>
how has this not caused problems before
<azonenberg>
(more likely it did, but i chalked them up to other issues)
<azonenberg>
the actual host-side driver was only a couple hours of work
<azonenberg>
hard to pin it down exactly because i was also building the ILA itself in tandem