azonenberg changed the topic of #scopehal to: libscopehal, libscopeprotocols, and glscopeclient development and testing | Online hackathon December 19th all day | | Logs:
juli966 has quit [Quit: Nettalk6 -]
<_whitenotifier> [scopehal-docs] azonenberg pushed 1 commit to master [+0/-0/±1]
<_whitenotifier> [scopehal-docs] azonenberg ab039d6 - Added typical performance data for Rigol MSO5000
<azonenberg> noopwafel: yeah i think picoscope has great potential for being the best streaming performance of any COTS instrument available today
<azonenberg> Because unlike literally every other scope realtime streaming *was* a design goal
<azonenberg> Looks like the probe clips should be coming tomorrow and the new probe overmold should be coming christmas eve
electronic_eel has quit [Ping timeout: 240 seconds]
electronic_eel has joined #scopehal
Degi_ has joined #scopehal
Degi has quit [Ping timeout: 272 seconds]
Degi_ is now known as Degi
<azonenberg> miek: btw lecroy at least did make fast streaming a priority at one point
<azonenberg> they have a proprietary interconnect called "LSIB" (lecroy serial interface bus)
<azonenberg> idk if it's supported in any current gen stuff
<azonenberg> but at one point the higher end scopes has it, and you could get an interface card for a pc that connected via a cable
<azonenberg> my understanding is that it was basically just pcie over a custom connector
<_whitenotifier> [scopehal-apps] hongshui3000 forked the repository -
<_whitenotifier> [starshipraider] azonenberg pushed 1 commit to master [+2/-0/±3]
<_whitenotifier> [starshipraider] azonenberg 77b05d0 - Initial board design for AKL-PT2 v0.5
<_whitenotifier> [starshipraider] azonenberg pushed 1 commit to master [+0/-0/±1]
<_whitenotifier> [starshipraider] azonenberg 033018c - Fixed nonexistent layer mentioned in fab notes
<azonenberg> Just sent the v0.5 AKL-PT2 design off to Multech for a quote. Not going to order until i've done a little bit more testing, but i wanted to at least get a price
<azonenberg> I'm working on doing some analysis of the glscopeclient performanc edata folks have submitted
<azonenberg> lain: ^
<azonenberg> if you could get some data from your old DDA that would be quite helpful too
<lain> ah
<lain> cool, I'll poke it when I get some time, probably after xmas as I'm waiting on some adapters before I'll be using the DDA again
<azonenberg> And just uploaded MSO64 data. While it's the best bandwidth next to the LeCroy's, it's... quite distant
<azonenberg> it does beat miek's Agilent in throughput at higher memory depths but the O(1) overhead is such that at shallow memory depths performance is mediocre
<_whitenotifier> [starshipraider] azonenberg pushed 1 commit to master [+0/-0/±1]
<_whitenotifier> [starshipraider] azonenberg 2567439 - Changed export settings to not use gerber x2 (why was this on in the first place?)
<tnt> Mmm, something is broken in the cmake magic. I specified a CMAKE_INSTALL_PREFIX and it still tries to copy stuff in /usr/lib "/usr/lib/": Permission denied.
<azonenberg> grep cmakecache for /usr/lib?
<azonenberg> also possible you have the old value cached and need to just do a clean build?
<tnt> Well ... looking at lib/scopeprotocols/CMakeLists.txt:install(TARGETS scopeprotocols LIBRARY DESTINATION /usr/lib)
<tnt> lib/scopehal/CMakeLists.txt:install(TARGETS scopehal LIBRARY DESTINATION /usr/lib)
<tnt> lib/graphwidget/CMakeLists.txt:install(TARGETS graphwidget LIBRARY DESTINATION /usr/lib)
<tnt> so that seems just hardcoded.
<azonenberg> that's certainly part of it :p
<tnt> question now is which magic variable is it supposed to be ...
<azonenberg> what about just CMAKE_INSTALL_PREFIX/lib?
<azonenberg> is that not the right way?
<tnt> I think some distro change lib into lib64 ? and so I'd expect that magic var to be set correctly.
<tnt> also, relative path (so just 'lib' ) would be automatically relative to instal prefix.
<tnt> INSTALL_LIBDIR worked at least.
<tnt> Now I just need to figure out why it only build libraries and not glscope :/
<tnt> Oh it built just not installed.
<tnt> Do I have to put something else than the IP in 'path' ?
<tnt> Ok, apparently I need to specify ip:5025 (i.e. with port) despite the manual saying it's the default if not specified.
<azonenberg> tnt: interesting, it should default to that. wonder if that's a gui issue, does it work if you specify no port on the command line?
<azonenberg> and idk if the glscopeclient binary right now even has an install path specified :p
<tnt> 0.17 WFM/s with 4 Channels.
<azonenberg> with what, mso5?
<tnt> Agilent 3000X (older non-T model)
<azonenberg> ah ok
<azonenberg> sorry i'm losing track of who has what scope lol
<tnt> hehe, np
<tnt> What's annoying is AFAICT I can't control capture depth.
<tnt> When I zoom in, I can get smaller capture depht, but the triggering is very inconsistent. I get some time as low as 2 WFM and up to 20.
juli966 has joined #scopehal
<agg> tnt: what sort of settings get you close to 20wfm/s?
<tnt> 1ch 8kS
<agg> Is that usb or ethernet?
<agg> Ah I see ethernet
<agg> What trigger do you have? Wonder why my 3000t wouldn't get above 5
<tnt> It's the probe just in the probe compensation output of the scope, default setup.
<tnt> Ok, so apparently my laptop being on wireless what an issue ... I plugged in ethernet cable and now I get a somewhat more stable results at ~ 20 WFM/s
<azonenberg> ah yeah, badn etwork could cause it
<tnt> Note that the fw I'm running is kind of ancient ... never felt the need to update and I'm kind of worried I'd loose my options if I did so ...
<azonenberg> What's the full model number here?
<azonenberg> i just see 3000x
<tnt> MSOX3054A
<azonenberg> also agg: is your 3104T an agilent or keysight brand?
<agg> keysight
<agg> the 3000T x-series scopes were released in 2015 after agilent's T&M division became keysight
<azonenberg> Ok
<azonenberg> Let me add the T's to the list of supported models under keysight then
<azonenberg> also spreadsheet updated
<azonenberg> interesting the T performs so much worse than the older 3000x
<agg> the SCPI commands are essentially identical to the non-T and I believe almost all are common across the x-series family, the programming manual indicates which are 'core commands' supported across almost all scope families and which are non-core "that provide specific features, but are not
<agg> universal across all Keysight InfiniiVision oscilloscope models
<azonenberg> also another thing to think about in the not too distant future is either renaming the agilent driver or aliasing it
<azonenberg> i'm thinking maybe renaming the driver to "keysight" then aliasing it so you can also use it as "agilent" with the same code
<agg> makes sense to me
<tnt> azonenberg: mmm, seems you made a mistake when transcribing in google docs. The number of samples for the 4ch version is always half the one of the 1/2ch version.
<agg> the -A seems similar performance to the -T at the larger sample depths, so I wonder what's going wrong on mine at low sample depths
<agg> tnt: i assume that's ch1+3 for two channels?
<tnt> agg: yes
<azonenberg> tnt: that look right?
<tnt> agg: can you control capture depth as a setting ? On mine, AFAICT, I can't ... it's automatic just depending on the horizontal timebase (i.e. I have to zoom)
<azonenberg> and yeah i suspect what's happening is there is a higher O(1) overhead which is lost in the noise at deeper memory
<tnt> azonenberg: yup.
<agg> tnt: do you have 'digitize' as an option under acquire?
<azonenberg> but with small depths it dominates
<agg> acquire menu -> digitizer
<tnt> agg: let me check ...
<agg> mine is relatively new firmware, could be that a recent firmware has added some overhead
<agg> or that I'm just not doing something quite right...
<tnt> agg: nope. acquire just has mode (normal/peak/avg/hires) and segented
<agg> hmm, I don't think that's a licensed option, might be a T thing or might be a newer firmware thing
<agg> it lets you just program a specific sample rate and memory depth, instead of basing it on the time division
<tnt> I have all licenses installed anyway.
<tnt> agilent shipped the private key along with the public key used to check license files in the first version of the firmware ...
<agg> not like you even need the keys, as I understand it, you just modify the shortcut file that starts the scope software and add extra options to the argument list
<agg> mine was a fully optioned refurb anyway so haven't looked really
<agg> interesting, I just tried 5GS/s 4Mpt 1ch on the default setup with the probe on the cal output and got the same 5WFM/s I was getting last time, compared to your 20 or so, but if I set TCP_NODELAY it goes up to 8.5WFM/s
<agg> scopehal is still 3.5WFM/s in the same configuration
<tnt> 5WFM/s at 4Mpt ? that's pretty good.
<azonenberg> > if I set TCP_NODELAY
<azonenberg> where, in scopehal?
<azonenberg> or your own code?
<agg> no, my python script
<azonenberg> oh
<azonenberg> i was gonna say scopehal already uses that
<agg> tnt: sorry, I meant to say 8kpt, to match your fast setup
<azonenberg> or should anyway
<azonenberg> with 4M points if you are seeing 3.5 WFM/s instead of 8.5 that's quite a slowdown. You might find it helpful to have a look at timing of packets on the link
<azonenberg> does it look like scopehal is getting cpu limited somewhere?
<azonenberg> it's very possible that the waveform download code is unoptimized and horridly slow
<azonenberg> the lecroy waveform cracking code (raw ADC samples -> fp32) uses AVX2 when possible and is probably going to move to GPU soon
<agg> glscopeclient is using 9% of one core
<azonenberg> overall cpu time isnt what matters
<azonenberg> if i get cpu bound for 50ms then idle for the rest waiting on the network
<azonenberg> that could still be the cause of the slowdown
<azonenberg> But its also possible that scopehal has room to optimize more on the scpi side of things. in fact it's practically guaranteed
<azonenberg> also do a pcap and see if any of the config settings are not being cached and re-polled every frame
<azonenberg> that is also a horrific slowdown
<agg> it looks sane enough, here's one full cycle
<agg> basically asks for a single trigger, polls until the scope says it's stopped, then asks for channel 1, gets the channel config, gets the channel data, re-triggers
<agg> from the :SING to the scope saying done is 0.225 seconds
<azonenberg> agg: So have a look at the lecroy driver to get an idea of some of the optimizations i've done
<agg> another .141s until the data arrives
<azonenberg> assuming the scope has an input fifo that actually works (tek, i'm looking at you...
<agg> it specifically documents that it does and so far my experience is that it does
<agg> you can send it commands without waiting for a reply or ack and it processes them in order
<azonenberg> So in that case what I would suggest you try doing
<azonenberg> is ask for *all* of the preambles up front
<azonenberg> then all of the data
<agg> this is with only one channel enabled, so there's only one preamble and one data block anyway
<azonenberg> ah ok
<azonenberg> basically minimize round trips as much as you can
<azonenberg> if you know you have to read two things ask for them both
<azonenberg> and only then read the replies
<agg> it takes the scope some 109ms just to respond to :WAV:PRE?
<azonenberg> If you do this with a tek mso6 it will barf on you because it thinks it's connected to gpib running on a 68k with no ram
<azonenberg> but a sane, well adjusted scope will just leave the command in a fifo until it's ready
<agg> so yea, maybe you can shave all that off by sending :WAV:PRE?;:WAV:DATA?
<agg> if you stick things together with a semicolon it says it processes them "in the same thread"
<azonenberg> yeah but more to the point you can send the WAV:SOU too
<azonenberg> so wave:sou, wav:pre, wav:data
<agg> sure
<azonenberg> Little things like this add up over time. i forget just how much faster the lecroy driver is now
<azonenberg> but it was substantial. tens of percent if not double
<azonenberg> another thing that helped was re-arming the trigger *before* processing the downloaded waveform in "normal" mode
<agg> but my python script should already be as fast as it can, excluding discovering further oddities like setting TCP_NODELAY, heh
<agg> hmm
<azonenberg> so as soon as you have the adc samples
<agg> how do you ensure you don't have new data overwrite the buffer before you can download it?
<azonenberg> You download the data, arm the trigger, then in the same thread without releasing any mutexes convert the raw samples to fp32
<agg> ah, I see what you mean
<azonenberg> the key is to have the scope be processing the arm command simultaneously with you doing the type conversion
<agg> yea understood
<azonenberg> especially on deep waveforms that conversion can take a fair bit of itme
<azonenberg> time*
<azonenberg> The scope should always be busy
<azonenberg> if it's not, your host-side code needs to be faster
<agg> btw if I change windows back and forth I find glscopeclient's chrome doesn't get drawn until I minimise and re-show the window
<azonenberg> minimize turnarounds between response from scope and next command that depends on response
<agg> and is instead now showing most of wireshark, except for the status info bottom-right and the 'run' button
<azonenberg> and if the next command doesnt depend on the response, send it before you even get the response
<azonenberg> Interesting. File a bug, include details on gpu setup etc. also is this with waveform captures in progress or halted?
<azonenberg> also look at wireshark while this is happening, see if maybe it's doing some blocking io call
<agg> capture in progress, the waveform area is rendered fine
<azonenberg> interesting so it's only the chrome that's problematic
<azonenberg> that smells like an opengl bug not restoring some state
<azonenberg> gtk does compositing in GL
<agg> it's also 'only sometimes'
<azonenberg> so if gtk expects some buffer to not be touched and i mess with it by acicdent i could see that being a problem
<azonenberg> i have seen a few opengl and gtk errors that i havent got tothe bottom of yet
<azonenberg> this might be related to those?
<agg> seems likely something along those lines
<agg> putting :WAV:PRE and :WAV:DATA into the same command works but doesn't make much difference
<azonenberg> File a ticket and make a screenshot. I'd do it anyway because it might matter more with faster instruments
<azonenberg> but if its notsignificantly faster i guess you can just hold off
<azonenberg> and we'll see if it helps on faster, more modern keysight gear
<_whitenotifier> [scopehal-apps] adamgreig opened issue #303: glscopeclient chrome not drawn after changing applications -
<_whitenotifier> [scopehal-apps] azonenberg labeled issue #303: glscopeclient chrome not drawn after changing applications -
<_whitenotifier> [scopehal-apps] azonenberg labeled issue #303: glscopeclient chrome not drawn after changing applications -
<azonenberg> Very interesting. never seen that before
<tnt> What windows manager ? Also wayland or X11 ?
<agg> awesome wm, x11
<_whitenotifier> [scopehal-apps] adamgreig edited issue #303: glscopeclient chrome not drawn after changing applications -
<agg> I haven't seen this in any other GL apps, though
<_whitenotifier> [scopehal] adamgreig forked the repository -
<tnt> agg: I use awesome and x11 too so, I guess that's not it.
<agg> o/
<agg> azonenberg: the agilent change is pretty small,, it seems to give a small improvement here but is basically lost in the noise to be honest, and I can only test it on my scope, but happy to click the 'pr' button if you'd like
<agg> ideally the re-arming trigger would happen slightly before as the floating point conversion still happens slightly earlier but that's a marginally bigger change
<azonenberg> How about hold off until you've implemented and tested that? then send a PR for both if it looks good
<azonenberg> Also woo looks like one of my two shapeways orders is out for delivery. It's either the clip or the mold, the other is coming tomorrow
<azonenberg> lost track of which tracking number is which :p
bvernoux has joined #scopehal
<azonenberg> woop, just got the install info for sonnet l2 silver (put in the order for the upgrade yesterday)
<azonenberg> also it appears that klayout can export DXFs in a somewhat sonnet friendly format, experimneting to get the scale factors right
<azonenberg> Yeah ok i got a valid import
<azonenberg> it took a little tweaking but this looks like a viable workflow for now. no need to buy the GDS option ordeal with kicad's broken DXF export
<azonenberg> you can use klayout to import the gerbers, merge overlapping polygons so sonnet doesn't choke on excessively complex geometry, then export to a single multilayered dxf
<noopwafel> bvernoux: I won't be at home [with code/pico] for a week or so, but I basically just hacked something like AntiKernelLabsOscilloscope together with a more-functional version of the picoscpi bridge on my github
<noopwafel> so if you're in a hurry / have time now, then I think it's likely easy enough to just redo that, just not worth it for me right now since I don't have the hw to actually try the result
<noopwafel> (and most of the interesting work is probably the triggers which I definitely did not implement because the framework was not there when I did it)
<azonenberg> Aaaand of course the very first design i try to simulate in sonnet silver doesn't work. Support ticket time
<azonenberg> As with when i first bought basic, i started cashing in the support contract before the ink was even dry on my payment :p
<bvernoux> noopwafel, the idea was to not restart from scratch but I will check what I can do
<tnt> Oh I didn't know KLayout was used for PCBs ... I've been using it for much smaller stuff :)
<azonenberg> tnt: i became acquainted with it for silicon work, that's what it's *meant* for
<azonenberg> (I've never tried using it as an editor, only to view GDS's others created)
<azonenberg> But it can import gerbers and export DXF
<azonenberg> during the demo period i was using klayout to convert gerber to GDS (yes, a GDS of a PCB) then importing that into sonnet
<azonenberg> Which worked, if you had a license for the ~$1K GDS importer
<azonenberg> the DXF importer is free
<azonenberg> i either missed that klayout could generate DXFs or i had the settings wrong before
<miek> azonenberg: lol, going for another xmas eve support ticket response? :p
<azonenberg> we're gonna find out lol. i actually joked about that in the opening of my email
<azonenberg> saying i could only dream of what bugs i might encounter in the holidays of 2021
<noopwafel> bvernoux: yeah, it kind of sucks, but I'm happy to help once I can, if you want to restart from scratch or almost-scratch - don't let me be more of a blocker :x
<bvernoux> noopwafel, ok at least I can reuse your picoscpi bridge
<bvernoux> I need to study the performance of picoscpi bridge I'm afraid it have major performance issues
<bvernoux> between TCP socket to USB 3.0 for big transfer
<bvernoux> to be checked
<noopwafel> the one uploaded is also a dumb PoC. the real one is not much better.
<noopwafel> I didn't find the TCP to be a bottleneck even in streaming mode
<noopwafel> you do have to be careful not to run out of RAM..
<noopwafel> there's also the question of how to deal with non-3000 series scopes (is it worth limiting it to just the common API instead?), whether it's worth having a bridge at all, etc
<bvernoux> yes so far I do not want to investigate on how to support other non-3000 series scope
<bvernoux> the idea is to do a POC to check how many WFM we have on 3000 series
<bvernoux> other series with USB 2.0 are not interesting and will be very limited I think and anyway I do not have HW to test
<bvernoux> so it could be done later by someone with other series ...
<bvernoux> interesting point so far is to have a usable scope with glscopeclient with at least 10WFM/s I think with GUI decoupled from WFM (slowness of the scope) which is WIP
<bvernoux> for example Rigol MSO5000 is not very usable so far ...
<bvernoux> with 1 WFM/s
<bvernoux> can be useable only not in realtime
<bvernoux> anyway advantage of Rigol MSO5000 is 8GSSPS and 200Mpts if we could speedup the SCPI stuff to retrieve chan data faster ...
<bvernoux> maybe it can be hacked with reverse engineering and rewriting a dedicated SCPI/direct mode ... but that will need lot of work and lot of contributors
<noopwafel> yes it's way way faster than the Rigol haha
<noopwafel> I mean I often pull >100wfm/s from *python* when doing SCA
<noopwafel> and it would be nice to have a better UI than the pico one
<bvernoux> me too I saturated the USB 3.0 link ;)
<bvernoux> doing SCA
<bvernoux> with my own realtime algorithm on PC side
<bvernoux> doing billions of traces ;)
<bvernoux> which is 10 to 100x times faster than what we can don on High End Scope like LeCroy ...
<noopwafel> running code on the scope?
<bvernoux> no I was running the code on PC using Pico SDK API
<bvernoux> with native C code optimized
<bvernoux> fully automated to do SCA ;)
<bvernoux> the main drawback of Picoscope3000 is it have only 2GSPS and 8bits ADC ;)
<bvernoux> and PicoScope 6 is clearly not very good and the GUI is awfull
<azonenberg> noopwafel, bvernoux: if you two are interested in building out side channel capabilities in glscopeclient i'd love to have that be another area of focus in addition to the high speed serdes analysis i've mostly been doing so far
<bvernoux> yes it will be nice to have some sort of Side Channel features
<azonenberg> $dayjob is interested in getting more side channel capabilities in the seattle lab, our main SCA guy quit and i'm going to have to take his place
<azonenberg> and i'd like to build a workflow around glscopeclient/libscopehal
<azonenberg> first i have to learn more of the practical side of SCA though. i understand the theory at a very high level but have never actually tried *doing* one
<bvernoux> the best for that is to practice on simple target ;)
<bvernoux> like ATMEGA328P
<bvernoux> the leak a lot
<bvernoux> they
<azonenberg> i was thinking stm32f031 as the initial target. or maybe an 8-bit PIC
<azonenberg> i don't have an atmega toolchain set up
<bvernoux> the only easy to use tool so far is QSCAT ;)
<bvernoux> done by my friend
<bvernoux> it is done in Qt ;)
<bvernoux> advantage vs other available tools which are much more advanced is it is visual
<bvernoux> but there is always a learning curve to understand how that work
<bvernoux> it is limited to CPA only anyway
<bvernoux> anyway I started to learn alot on Side Channel using ChipWhisperer
<bvernoux> with the diff probe ;)
<bvernoux> state of the art is to do a very clean measurements with ultra low power supply ;) (that avoid to do lot of filtering and to capture tons of traces for nothing)
<bvernoux> for extreme case I'm using 1uV noise 5V PSU
<bvernoux> and with such setup you can break/recover 128bits AES with only 16 traces which is world record I think ;)
<noopwafel> and then you encounter real target and suddenly you need 100k :p
<bvernoux> yes ;)
<bvernoux> even more
<noopwafel> there's definitely some niceties which would be lovely to have in gui directly
<bvernoux> on some challenge it was required to capture more than 500k traces
<noopwafel> (I miss Inspector)
<bvernoux> as there was some counter measure
<bvernoux> to understand different effect and what is the algorithm/obfuscation used ;)
<bvernoux> especially when doing that like a black box without any access to firmware
<bvernoux> as it was heavily protected and impossible to extract easily
<bvernoux> it is a cat and mouse game ;)
<azonenberg> bvernoux: I'm eyeing a LeCroy RP4030A for other purposes
<azonenberg> do you think it would be useful for SCA too?
<bvernoux> interesting stuff about cheap Fault Injection =>
<bvernoux> I will probably build something like that one day ;)
<bvernoux> azonenberg, yes it could be interesting
<bvernoux> but +/-800mV is too much
<bvernoux> it requires ultra high resolution
<bvernoux> anyway it depends on the target
<bvernoux> the hard part is to have lot of bits for some target
<bvernoux> to have a big dynamic range
<bvernoux> I doubt 4GHz is useful for SCA but will be interesting as usually we do not such high BW probes
<bvernoux> for SCA we use less than 100MHz BW probes
<bvernoux> which is enough to recover AES ...
<bvernoux> depending on leakages processor ...
<bvernoux> each target is different
<bvernoux> I know FPGA (old ones) are very vulnerables to SCA and we can recover easily the AES key ...
<bvernoux> I doubt it is so easy with newer FPGA which are hardened now
<bvernoux> will be fun to test that on ECP5-5G I do not know if there is crypto features to protect the bitstream with crypto ...
<d1b2> <TiltMeSenpai> some of them even have hard crypto blocks. I would hope they are more resistant to SCA, but I have no clue
<bvernoux> ha yes ECP5 have such type of protection => Readback security and encryption for design protection
<bvernoux> it is fun ;)
<bvernoux> here I speak about encryption for design protection
<bvernoux> but yes crypto block exist with some protections/counter measures too now but they are not available as open source ...
<bvernoux> such things are not open sourced by company
<d1b2> <TiltMeSenpai> oh lol. I was talking about things like the new MachNX, which has a "enclave" with a bunch of crypto stuff
<d1b2> <TiltMeSenpai> yeah... 😦
<bvernoux> ha yes such enclave are interesting
<bvernoux> it started with PS3 ;)
<bvernoux> and the famous secure enclave was totally destroyed ;)
<bvernoux> and everything was extracted
<bvernoux> using SPU code
<d1b2> <TiltMeSenpai> how do you even do sca resiliency in FPGA fabric? ensure that roughly equal numbers of gates flip in every operation?
<bvernoux> SPE
<bvernoux> I really liked the design of the Cell processor
<bvernoux> totally amazing
<bvernoux> but it was too complex for developers
<noopwafel> SCA resistance in the hard crypto blocks is definitely a concern for modern FPGA designers.
<bvernoux> yes
<bvernoux> as it often requires HW protections too
<bvernoux> like on Secure Elements which so far are the most advanced against SCA
<bvernoux> I know guys who have worked on that and it is amazing how many protection and time they spend to secure the chipset
<azonenberg> 7 series at least the bitstream crypto is totally broken by sca
<bvernoux> yes ;)
<bvernoux> anyway FPGA manufacturer are often not specialized in such stuff ;)
<bvernoux> like we see on MCU/CPU there is often no any protection/counter measures ...
<bvernoux> ST is better than others anyway on that ;)
bvernoux1 has joined #scopehal
bvernoux has quit [Ping timeout: 272 seconds]