<xzcvczx>
btw azonenberg someone has said "you need the default" function
<xzcvczx>
and yeah i threw back that that only works in elf
bvernoux has joined #scopehal
<_whitenotifier-1>
[scopehal-apps] azonenberg labeled issue #349: Vertical cursor over extends past right hand end of waveform display window - https://git.io/JsGOj
<_whitenotifier-1>
[scopehal-apps] azonenberg labeled issue #349: Vertical cursor over extends past right hand end of waveform display window - https://git.io/JsGOj
<_whitenotifier-1>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/Jsnt3
<_whitenotifier-1>
[scopehal-apps] azonenberg 6586ffe - Bounds check cursors so they don't get drawn on top of the vertical axis legend. Fixes #349.
<_whitenotifier-1>
[scopehal-apps] azonenberg closed issue #349: Vertical cursor over extends past right hand end of waveform display window - https://git.io/JsGOj
<_whitenotifier-1>
[scopehal-pico-bridge] azonenberg pushed 1 commit to master [+0/-0/±2] https://git.io/JsntB
<bvernoux>
I really love that initiative to build open source silicon (based on 130nm)
<azonenberg>
bvernoux: I'm planning to do some testing and characterization for other people's designs but am not currently working on any tapeouts of my own
<bvernoux>
and all is paid by Google
<azonenberg>
I would love to have somebody come up with an active diff probe amplifier for sky130 though
<bvernoux>
the most amazing is for MPW2 now it is possible to use pad analogic especially for RF stuff
<bvernoux>
I'm pretty sure we can do some amazing RF stuff with 130nm
<bvernoux>
ha yes an active diff probe amplifier for sky130 will be amazing
<bvernoux>
I would love a fast ADC like 100MSPS / 12bits ;)
<bvernoux>
but the MCU to drive it is clearly too slow it is something like 50MHz with 2 clock/cycles ...
<bvernoux>
and there is not any fast enough external peripheral available so far ...
<bvernoux>
anyway the open source library is improving at each step
<azonenberg>
Yeah they're just getting started
<azonenberg>
a few more rounds and i think it will be a nice platform
<azonenberg>
of course at some point google will stop funding it and you'll have to pay for wafer space like anywhere else
<bvernoux>
we can expect GbE someone plan to do it ;)
<azonenberg>
but hopefully by that point it will be a nice process to target
<bvernoux>
but the MCU speed is clearly the blocker ...
<azonenberg>
There's apparently some teams interested in gigabit serdes too
<azonenberg>
i cant wait to get my hands on test chips from them
<sorear>
dangerous to joke about starshipraider io cell asics now
<azonenberg>
It was never a joke, lol
<azonenberg>
It was always "might actually happen but I don't have the time right now"
<azonenberg>
But in general i have ~no experience or knowledge of analog CMOS
<azonenberg>
I live in the land of standard cells and digital logic as much as i can
<_whitenotifier-1>
[scopehal] azonenberg pushed 2 commits to master [+0/-0/±2] https://git.io/JsnS0
<_whitenotifier-1>
[scopehal] mubes 15219a6 - Fix digital levels and waveform offset
<_whitenotifier-1>
[scopehal] azonenberg 59af49d - Merge pull request #479 from mubes/digi_ints Fix digital levels and waveform offset
<_whitenotifier-1>
[scopehal] azonenberg closed pull request #479: Fix digital levels and waveform offset - https://git.io/JsGYY
juli9611 has joined #scopehal
<_whitenotifier-1>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±3] https://git.io/JsceW
<_whitenotifier-1>
[scopehal-apps] azonenberg ad9a3d4 - Trigger position on timeline can now be dragged to adjust delay. Fixes #173.
<_whitenotifier-1>
[scopehal-apps] azonenberg closed issue #173: Make trigger position arrow in timeline draggable - https://git.io/JUBXW
<GenTooMan>
bvernoux, you volunteering to develop said ADC? what architecture do you plan on using? :D
<GenTooMan>
the SkyWater SKY130 PDK documentation has an awful lot of todo's in it. The Python API docs are missing (like KiCAD)
<azonenberg>
GenTooMan: i mean what do you think those free fab runs are for?
<azonenberg>
Beta testing and debugging the PDK
<bvernoux>
GenTooMan, I have clearly not the knowledge to develop an ADC or anything with an ASIC
<bvernoux>
GenTooMan, but if someone is motivated with knowledge/background in ASIC ADC design it will be amazing
<azonenberg>
Yeah I've only done digital ASICs
<azonenberg>
i can write RTL that somebody else fights with synopsys to turn into a chip :p
<bvernoux>
azonenberg, this freefab is clearly doing open source stuff for them at end ;)
<bvernoux>
they sell that as service if you check their website
<azonenberg>
well obviously, the end goal is to improve the open tooling and infrastructure
<azonenberg>
There's rumors skywater is thinking of opening the PDKs some of their higher end processes if 130 goes well
<azonenberg>
which honestly makes a lot of sense: it'd be a big attraction for potential users not dealing with all of the NDAs and such
<GenTooMan>
bvernoux, Oh well now is as good a time as any to learn :D
<bvernoux>
so it is like they will have free "bricks" for their catalog locked to their 130nm stuff
<azonenberg>
and more importantly, it's 130nm
<azonenberg>
it's not like there's many secrets left to keep
<azonenberg>
this is decades-old technology now
<azonenberg>
I think leading edge stuff will always be NDA-encumbered
<azonenberg>
but it would not surprise me if we start seeing more older nodes opened up
<GenTooMan>
azonenberg, they are using silicon not siicon germanium or gallium nitride process?
<bvernoux>
unfortunately it is just silicon not gallium or germanium else it will be amazing for Analog RF stuff ;)
<azonenberg>
My understanding is that sky130 is essentially a rebranding or spinoff of the Cypress S8 process used for the PSoCs and probably more
<bvernoux>
I checked the price at efabless
<azonenberg>
So the process tech itself is mature, they just need to recreate a bunch of open replacements for IP that skywater doesn't own and thus can't distribute freely
<bvernoux>
if you want to do a crappy things with their fab with their blocks it is >80KUSD for 50 chipset ;)
<bvernoux>
you just use their IP and they do all
<azonenberg>
Yeah that seems to be efabless's business model. I'm not entirely sure on the relationships between google, skywater, and efabless on all of this
<bvernoux>
but after for more volume they speak about royalties it is not clear ;)
<bvernoux>
azonenberg, yes it is strange google sponsorize such things
<bvernoux>
they do not need such old process to develop their own chipset ;)
<bvernoux>
maybe it is a way to recruit new talent for less money at end ;)
<bvernoux>
nothing is free on this planet ;)
<GenTooMan>
google is in deep trouble when it comes to recruitment if you aren't aware.
<bvernoux>
I imagine the buisness plan we will pay 6 batch (of at least 100KUSD per batch) for designers to do what they want on 130nm ;)
<bvernoux>
the question is what Google will gain with that ?
<bvernoux>
as they will spend more than 600KUSD ...
<bvernoux>
GenTooMan, yes their politic is you shall live 1000% at work ;)
<azonenberg>
bvernoux: I dont think google wants 130nm tech necessarily
<bvernoux>
GenTooMan, lot of guys come back from that when they was saying it is paradise ...
<azonenberg>
i think they want the *tooling*
<azonenberg>
they probably are paying cadence and synopsys up the nose in chip design tools
<GenTooMan>
bvernoux, eh they also urinated on 90% of their qualified applicants.
<bvernoux>
azonenberg, yes probably to debug the tooling and they will adapt it for better process like 45nm or less ;)
<azonenberg>
Exactly
<bvernoux>
GenTooMan, where have you see that ?
<bvernoux>
Anyway those free 130nm chipset are very fun and interesting
<GenTooMan>
bvernoux, a number of X recruiters for Google lodged serious complaints. The recruiters felt insulted not just the applicants.
<GenTooMan>
as for the 130nm process it would be nice for a RISC-V R32I experiment. nmigen perhaps for getting usable output perhaps?
<bvernoux>
GenTooMan, the caravel already include RISC-V R32I by default but it is slow ...
<bvernoux>
I do not know if they have done test on MPW-ONE batch shall be done now but I do not see any feedback
<bvernoux>
+it
<bvernoux>
they was estimating the MCU to run at 50MHz ...
<bvernoux>
I see also they are interested by someone which will bring a Full USB 2.0 HS Device/Host ;)
<bvernoux>
Of course an open source silicon with USB 2.0 HS will be amazing as such type of core is probably very expensive in IP even today
<GenTooMan>
well the PHY is one thing, the encoder is another. I've seen some work on FS but not HS for USB 2.0.
<GenTooMan>
I think the issue is the PLL those tend to require more black magic than other things.
<GenTooMan>
more on topic I have made some progress with Siglent but things are as yet to work "nicely".
<azonenberg>
GenTooMan: oh?
<azonenberg>
I dealt with a few little things earlier and am going to try and get the pico digital done today
<azonenberg>
i merged the 3000 series stuff from bvernoux and noopwafel and pushed my digital work to date
<azonenberg>
it's not usable but most of what's needed is there
<GenTooMan>
azonenberg, It starts up sort of fine. I have get, save, and restore state code. I fetch channel details at initialization instead of using wave descriptors. I am a bit leery of using the built in commands to save and restore states as those likely write to flash.
<azonenberg>
I wouldnt expect them to but if you think they might, cant hurt to be safe
<d1b2>
<mubes> Added to list of questions for Siglent
<bvernoux>
mubes do you know if some Siglent SDS1000 or 2xxxx have Gigabit Ethernet ?
<GenTooMan>
SDS1104X-E I have built 2020 is just 100T.
<d1b2>
<mubes> We're working on finding out. The question went to Siglent yesterday, but perhaps a bit late for end of day. I'll report back when we find out.
<d1b2>
<mubes> Some of the scopes have WiFi support, so it's possible there's a work around to be had there, if the heart is willing.
<GenTooMan>
hmm let me check to be sure about the 1gbit ethernet on the 1104X-E
<bvernoux>
WiFi is even slower than Ethernet ;)
<bvernoux>
and by nature it is unstable and not reliable ...
* GenTooMan
remains silent as bvernoux already covered his thoughts.
<bvernoux>
If the SDSxxxx are only 100mb they will be always limited to something like 10WFM/s max with 1MS on 1 chan
<bvernoux>
in best case
<d1b2>
<mubes> It depends. There are stupid fast wifi standards out there now.
<bvernoux>
yes high end wifi 5 with MIMO but I doubt any siglent support that ;)
<d1b2>
<mubes> AC2900 is 2900 Mbps, for example (with a following wind)
<d1b2>
<mubes> As I said...if the heart is willing. Most of the work is in the adaptor, and that's connected over USB2-HS, so you're not going to get too far, best case.
<bvernoux>
yes it is last point to check with Siglent to expect to have decent WFM if they fix/improve the Firmware for fast SCPI (locking the GUI if that can help ...)
<d1b2>
<mubes> When flat out Siglent is using about 33% of the Ethernet bandwidth right now....there's some room for improvement.
<bvernoux>
USB2-HS can be pushed to 400mbit/s in streaming if it is done correctly ;)
<d1b2>
<mubes> Test equipment connected over USB....Ugh.
<bvernoux>
it is just for me a scope with less than 10WFM/s is not really usable
<GenTooMan>
good luck with that. I've only gotten 240mbit/s USB2 HS with linux
<d1b2>
<mubes> It depends what you're using it for. If you capture on the scope and post process in the gui then it's fine, but if you want to use the GUI as a proper front end then you're stuffed.
<bvernoux>
GenTooMan, you should try AirSpy it push continuous 400mbit/s data in realtime streaming and it work fine on Linux or Windows even on old computer
<d1b2>
<mubes> However, there are plenty of tricks than can still be played...there's a decimation mode that samples the entire high-res frame and then sends a low-res version. For interactive working (setting triggers etc) that would be fine....its obviously no good if you actually want to use all the detail in those waveforms
<bvernoux>
GenTooMan, evn on RPI4 it works without drop IIRC on RPI3 it was dropping frames as the USB 2.0 HS port is shared ...
<bvernoux>
ha yes interesting the low-res hint
<bvernoux>
it is what Picoscope do IIRC
<bvernoux>
they have a low-res mode in HW to push only part of data
<bvernoux>
but it is not use in glscopeclient as Pico are very fast
<bvernoux>
used
<d1b2>
<mubes> We can also compress with some kind of adaptive-delta which is amenable to FPGA...but that needs Siglent to be on board, and they may start to view this as a differentator between low and high end scopes
<bvernoux>
IIRC it is the famous downsample mode ;)
<bvernoux>
yes compression start to be an other story with unpredictable results ;)
<bvernoux>
depending on data ...
<d1b2>
<mubes> But there's plenty of work to be done before that's the bottleneck... There's a lot of GUI maintenance done that would be better spent doing other stuff when working remotely. So what I'd love is the ability to switch the display over to dumb crt mode and then send stuff to be rendered to it from scopehal
<d1b2>
<mubes> ...gonna be a while before anyone bites on that one 🙂
<bvernoux>
yes they shall stop the GUI to have more power for SCPI
<bvernoux>
like it is done on some high end scope or VNA in SCPI
<bvernoux>
they display a message to exit SCPI mode to return to normal GUI
<d1b2>
<mubes> ...just render HTML that I send it, and send me touches back
<azonenberg>
lol
<d1b2>
<mubes> yeah...we can have a sweepstake on which year someone goes for that.
<bvernoux>
which is clearly a very good idea as we do not need both if that can speedup transfer for scpi commands/data ;)
<bvernoux>
my old HP VNA do that ;)
<bvernoux>
when I send particular SCPI commands it stop ;)
<bvernoux>
so it is not a new feature ;)
<d1b2>
<mubes> scpi is not a differentator today on a low end scope....if its used at all its generally in a static test rig or similar, driven by some bespoke python.
<bvernoux>
and it is doing that on his 68030 CPU with less than 1MB ram haha
<bvernoux>
no it is a 68040 ;)
<bvernoux>
running at 20MHz IIRC ;)
<bvernoux>
it shall be a differentiator to fully manage the scope remotely especially now we have glscopeclient which is very nice even if it not a v0.1 ;)
<bvernoux>
I can say in actual state (even if there is missing complex trigger) glscopeclient is more usable than Picoscope v6 GUI which is awfull ...
<azonenberg>
Yeah i dont use the picoscope gui for anything
<bvernoux>
waiting the MSO of course ;)
<bvernoux>
there is more decoders on glscopeclient than picoscope gui too
<bvernoux>
with very nice realtime display ;)
<bvernoux>
on pisco gui it is so awfull you need to zoomin/out you see nothing ...
<bvernoux>
pisco=pico ;)
<azonenberg>
yeah do they have any intensity grading at all? i dont think so
<bvernoux>
no
<bvernoux>
it is ugly 2D things without any grading ...
<bvernoux>
and very ugly colors no transparency nothing ;)
<bvernoux>
the GUI is probably done in Visual Basic 3.0 ;)
<azonenberg>
lol
<bvernoux>
the only interesting things was their DeepMeasure
<bvernoux>
the concept is interesting
<bvernoux>
maybe it could be a great feature for glscopeclient
<bvernoux>
it display cycle/cycle Cycle Time, Frequency ....
<d1b2>
<mubes> I dont think I want that amount of info in my GUI though...scopes are about conceptual understanding, not measurement (otherwise they wouldn't have 8 or 12 bit ADCs)
<bvernoux>
it is mainly for offline analysis not for realtime check
<d1b2>
<mubes> yeah, agree with that...so you just want the ability to get it into a file somewhere
<d1b2>
<mubes> (Surprised no-ones punched me for the 'conceptual understanding' comment yet)
<bvernoux>
what I would love is to switch to ImGUI for the context menu or options ;)
<bvernoux>
I really hate gtk ...
<bvernoux>
it is so easy and fast with ImGUI
<bvernoux>
and it integrate perfectly in OpenGL windows
<azonenberg>
Other than the one scaling issue we hit in the protocol analyzer, i have not had any issues with gtk
<azonenberg>
you just dont like it :p
<xzcvczx>
maybe bvernoux is just trying to promote the wonders of Qt? :P
<GenTooMan>
if bvernoux knew what windows GDI looked like he probably wouldn't complain about GTK.
<azonenberg>
Lol
<azonenberg>
yeah i quite like GTK
<azonenberg>
Having come from MFC and raw windows GDI
<azonenberg>
way back in the day
<azonenberg>
i cut my teeth on gui development in visual studio '98
* GenTooMan
works carefully not to wretch visibly.
<GenTooMan>
GTK is a lot better. MFC made me shun windows completely.
<azonenberg>
MFC beat raw windows API at least
<azonenberg>
I do find it funny that all of the wizards couldn't parse the raw AST of the source though, and relied on magic comments
<azonenberg>
//{{AFX_MSG_MAP(CFoobar)
<GenTooMan>
windows API changed so much all the time MFC was a necessity to prevent utter lock in into a specific version of the windows API.
<azonenberg>
Oh? that wasn't my experience
<azonenberg>
they almost never changed things, they just kept on adding arguments
<azonenberg>
Which is why there are FooEx() versions of every API
<azonenberg>
but in most cases the old ones still worked
<azonenberg>
MFC just beat the alternative of calling all of the APIs by hand and made things a lot less verbose and painful
<GenTooMan>
which greatly boosted productivity. Apparently people were getting paid in the Windows for Workgroups era salaries that would make a CEO filled with envy.