azonenberg changed the topic of #scopehal to: ngscopeclient, libscopehal, and libscopeprotocols development and testing | https://github.com/ngscopeclient/scopehal-apps | Logs: https://libera.irclog.whitequark.org/scopehal
<_whitenotifier-4> [stm32-cpp] azonenberg pushed 1 commit to master [+0/-0/±3] https://github.com/azonenberg/stm32-cpp/compare/7e9b962e7338...b5def6b12b85
<_whitenotifier-4> [stm32-cpp] azonenberg b5def6b - Initial STM32L031 flash support
Degi has quit [Ping timeout: 252 seconds]
Degi has joined #scopehal
_whitelogger has joined #scopehal
<_whitenotifier-4> [stm32-cpp] azonenberg pushed 1 commit to master [+0/-0/±2] https://github.com/azonenberg/stm32-cpp/compare/b5def6b12b85...fff78c9246a6
<_whitenotifier-4> [stm32-cpp] azonenberg fff78c9 - Minor fixes to STM32L031 flash erase
<d1b2> <josHua> this would also be a nice toy to have libscopehal support for https://www.crowdsupply.com/andy-haas/haasoscope-pro
<d1b2> <azonenberg> if someonee gets one and writes a driver i'll merge it. but disappointingly it appears to be usb2 only
<d1b2> <azonenberg> So despite having halfway decent analog performance wfm/s won't be great
<d1b2> <azonenberg> this is surprising to me
<d1b2> <azonenberg> normally you see bad PC interface performance on scopes that have a built in UI so it's fast on the scope but slow to a PC
<d1b2> <azonenberg> headless scopes tend to have really good pc interfaces (e.g. usb3, 10gbe, thunderbolt) because their performance with the official UI is bottlenecked on that
<d1b2> <azonenberg> usb2 means it'll *never *be fast
<dingwat> if I'm reading that right, 40k sample depth? so at full sample rate you have 12.5us of capture :(
<d1b2> <azonenberg> yeah i didnt see external ram on the pcb
<d1b2> <azonenberg> so probably just on the FPGA
<d1b2> <azonenberg> like, whatever adc they're using could make a really nice scope
<d1b2> <azonenberg> they just didn't do what they needed to do to make the most of it
<d1b2> <azonenberg> low transfer BW and low memory depth kinda go together, because deep memory and a skinny pipe mean awful WFM/s
<dingwat> yeah, BRAMs ain't enough. Duct tape some DDR to it and add a PCIe link :)
<azonenberg> Yeah. The AYRTON system I'm building is my first take on the high performance scope backhaul concept
<azonenberg> i forget if i mentioned it here yet? it's still early stage
<azonenberg> digital board will be a stm32mp257 + x32 LPDDR4 chip paired with an xc7k160t-2ffg676 + x64 DDR3L SODIMM
<azonenberg> since it's somewhat of a testbed i'm being a bit flexible with interfacing. there will be an RGMII PHY hanging off both the FPGA and SoC, plus a SFP+ on the SoC
<azonenberg> FPGA and SoC connected by both the parallel memory bus I use in my existing designs, and also PCIe gen2 x1 which will be an adventure to bring up in a bare metal no OS environment
<d1b2> <vegard_e> SFP+ on the FPGA you mean?
<azonenberg> Oops yes
<azonenberg> anyway, then some assorted odds and ends for system management and four Samtec AcceleRate (ARF6 et al) high speed twinax cables going to the analog modules
<azonenberg> plus probably a PicoBlade with a spi bus or something for low speed control
<azonenberg> The overall planned system architecture is a 1U with sixteen BNC or SMA (TBD) probe inputs on the front
<azonenberg> four to each of the four analog modules
<azonenberg> each analog module will contain one AD9656 ADC (4 channels 125 Msps JESD204, but downclocked to 100 Msps so I can fit all the ADC samples into a single JESD204 link rather than going multi lane and needing more transceivers on the FPGA) and four frontends
<azonenberg> details of frontend are TBD but it'll be targeting ultra low noise and high ENOB for max dynamic range on the 16 bit ADC
<azonenberg> analog boards will take rough power from the system power board and LDO it to what's needed internally. No switchers
<azonenberg> System power board will take 12V out of the 48 -> 12V step down module and pass 12 directly to the digital board for PoL DC-DC conversion
<azonenberg> as well as contain some switchers to step the 12 down to convenient positive and negative voltages for the analog board to LDO from
<azonenberg> then the digital board will have a SPI bus and some GPIOs going to the front panel
<azonenberg> which will have a little micro to run the LEDs and maybe a little e-paper display with some firmware version / IP address info
<azonenberg> Back panel will have cross trigger sync in/out ports, 10 MHz ref in, maybe 10 MHz ref out, uart console, baseT ethernet, SFP, and 48V DC power in
<azonenberg> Anyway, so the goal now is to get the digital board designed and ordered before SHTF wrt import tariffs in the US when the new administration takes over
<azonenberg> firmware and the rest of the board may take more time
<azonenberg> This board will take quite a while to bring up because it's got so much new stuff on it... this is my first multi core processor, my first cortex-a soc, my first flash-less processor that boots from external memory, first processor with external dram, first design with pcie, and then some
<d1b2> <josHua> yes, I suggested this. that aprticular FPGA supports only DDR2, so you' dneed 16 of them to keep up with the bandwidth. he notes: > Indeed. Limiting it to block RAM helps keep the costs way down. 40k samples is enough for many things. > IF this campaign does well, I have in the back of my mind plans for the Pro Max 🙂 It would be based on the Agilex 3 FPGA, which will do LPDDR4 x32 even on the lowest-end model.
<d1b2> <azonenberg> yeah this is why my scope plans are all kintex-7 or ultrascale+ based
<d1b2> <azonenberg> with full dimms of memory
<dingwat> sad :( my fiber optic illuminator from eBay is missing the lamp base
<dingwat> might be a good opportunity to stuff an COB LED module in there...
<d1b2> <josHua> I think the goal is to be low cost though I'll be quite curious what price point he actually achieves