<d1b2>
<fox.sabrina> i did some benchmarking of the latest fw, it does seem better on the network side but ultimately still limited by the trigger system/cpu
<d1b2>
<fox.sabrina> i will say the read time does seem improved looking at the network traffic, but you ultimately can't go faster than the 0.45s trigger delay
<azonenberg>
I wonder if that can be optimized in FW or if its an inherent architectural limitation they can't fix without a pcb/asic spin?
<d1b2>
<fox.sabrina> i'd be surprised if it couldn't be optimized
<d1b2>
<fox.sabrina> it's odd to me the delay is roughly constant regardless of memory depth, so it's not sampling/moving sample data making up most of it
<azonenberg>
Unless it always runs at max memory depth and just doesnt always display it?
<azonenberg>
but internally it always downloads the full depth?
<d1b2>
<fox.sabrina> maybe, one test for that could be checking how multiple channels are affecting the trigger length, which i didn't look as much into
<d1b2>
<fox.sabrina> i have ssh access on the scope so i'm going to also just poke around and see if there's any insight to be gained, particularly pulling off the primary scope application binary
<azonenberg>
Go for it
<azonenberg>
Long term though, i think if we want good remote-friendly scopes the best option will be either leaning on vendors or making our own. I'm pursuing both in parallel
<d1b2>
<fox.sabrina> i agree, and i expect leaning on vendors is only going to work for higher end scope vendors
<azonenberg>
Yeah
<azonenberg>
We have had positive results from several of the big names we've talked to, i cant share all of the details yet but there's faster firmwares in the pipeline from a couple of vendors
<azonenberg>
but i wouldnt expect that from e.g. siglent or rigol
<d1b2>
<fox.sabrina> my hope is for an ethernet or usb3/4 open source scope, thunderscope looks extremely promising but as it's using xdma it seems unlikely to ever be usable on macos
<Darius>
why would xdma preclude working on macos?
<azonenberg>
We've been talking to the thunderscope folks about a 10GbE backend for the same acquisition subsystme
<d1b2>
<fox.sabrina> from what i understand the drivers for xdma are windows linux only
<azonenberg>
It would not be that difficult hardware wise given how modular the design is
<azonenberg>
And then further down the road I am planning my own 10GbE attached high performance scope. but it's not gonna be thunderscope class pricing
<azonenberg>
considering i'm looking at an ultrascale+ FPGA and an AD9213 on every channel
<azonenberg>
it's going to be a low to mid 5 figure price tag in low volume, 10 Gsps and hopefully 1-2 GHz BW
<azonenberg>
with 12 bit ADC
<Darius>
ah right... well I guess you can write a custom driver for it but it does raise the bar a bit
<d1b2>
<fox.sabrina> yeah, 10gbe would make it relatively trivial to get working across all platforms
<Darius>
the linux driver is open source so I imagine it could be ported..
<azonenberg>
more like rewritten than ported, i expect
<Darius>
"just" software ;)
<Darius>
yeah probably
<azonenberg>
but yeah certainly the open driver will contain all the info you'd need to make a suitable driver for another OS
<d1b2>
<fox.sabrina> if i buy a thunderscope when it's released might be a project i undertake, but if i had a choice between using 10gbe or rewriting a pcie driver for macos i know which i'd take
<azonenberg>
Yeah
<azonenberg>
My understanding is that the thunderscope is going to have the serdes going out to a second IO board
<azonenberg>
which will be stuffed with a thunderbolt board initially
<azonenberg>
but a 10GbE board could be made that would fit the same connector
<azonenberg>
you'd probably need a XAUI PHY because the artix doesnt have 10G SERDES
bvernoux has joined #scopehal
sorear has quit [Server closed connection]
sorear has joined #scopehal
<d1b2>
<aleksorsist> Azonenberg: Yup, there should be everything needed for an XAUI PHY on the m.2 daughterboard connector. I have the chips on hand too, but have yet to design the XAUI daughterboard
<d1b2>
<aleksorsist> @fox.sabrina Sven from the asahi Linux project will be taking a look at writing a Linux litepcie driver for us to use once we switch over to liteX for our fpga cores, that way more open source projects will benefit then doing so for the xdma core. We will also be developing a Windows litepcie driver to get all the platforms covered. If you're interested in helping out with driver dev or want to stay updated on our development, feel free to
<d1b2>
join our discord server!
syscall has quit [Server closed connection]
syscall has joined #scopehal
Fridtjof_ is now known as Fridtjof
<d1b2>
<svenpeter42> I was gonna help with the macOS driver but happy for someone else to do it as well 🙂 I also wanted to try to get the litepcie upstream into Linux though so that users don’t have to install that out of tree kernel module
t4nk_freenode has quit [Server closed connection]
t4nk_freenode has joined #scopehal
<d1b2>
<hansemro> @sven happy to test upstream linux driver
<d1b2>
<246tnt> @svenpeter42 wrt to litepcie one issue is that IIRC it uses default Xilinx PCI IDs. You can't just go put a driver that would associate to all users that happen to use the xilinx pcie core ...
<d1b2>
<svenpeter42> yeah, I’m aware. We briefly talked about that in the thunderscope discord
<d1b2>
<svenpeter42> same issue for the Mac OS driver, apple won’t sign it without a separate pci vid
<d1b2>
<svenpeter42> I think it makes sense to get everything ready without that pci vid and then only get the driver approved by apple or submitted upstream if/when they have their own pci I’d
<d1b2>
<aleksorsist> I think that's the best way to do it, it'll be useful to others if they can compile it with their own ID, and we can upstream one for ThunderScope once we get a PCI ID for ourselves
<d1b2>
<aleksorsist> I'm not sure if we could do a general LitePCIe device ID, but if we can that might be better actually
<d1b2>
<246tnt> LitePCIe is very "dynamic", like the driver itself is generated from template depending on SoC options and stuff like that.
<d1b2>
<svenpeter42> Depending on PCI SIG regulations it might be possible to at least get a litepcie VID and share the PID space
<d1b2>
<svenpeter42> I know the USB IF hates that but I dunno about pci sig
<d1b2>
<246tnt> yeah, that'd be nice to have a registry like the openmoko thing.
<d1b2>
<aleksorsist> LitePCIe as a vendor makes sense
<d1b2>
<aleksorsist> Then yah, we can hand out PIDs like openmoko!
<d1b2>
<svenpeter42> yup, and share that pci sig fee and the bureaucracy once for openhw projects
<azonenberg>
aaaand this is why I like 10GbE ;)
<azonenberg>
No drivers, no fees, no NDAs, no kernel development
<azonenberg>
just a fiber and a socket
<d1b2>
<aleksorsist> Before we get started on this we should bring this convo over to the LiteX server, I know Florent has been interested in drivers for other platforms
<d1b2>
<svenpeter42> hm, yeah, Ethernet would make this much easier
<d1b2>
<svenpeter42> But I guess there are more thunderbolt port in consumer hw out there than 10GbE ports
<d1b2>
<svenpeter42> Good point 🙂
<azonenberg>
Yes, but there are also thunderbolt 10GbE dongles
<azonenberg>
i have one on my work laptop
<azonenberg>
i dream of seeing a thinkpad or similar "work type" laptop with a SFP+ cage on the side but i doubt that will happen any time soon
<d1b2>
<svenpeter42> huh, and they are not even that expensive. There are a bunch of tbt to 10gbe adapters for 200-300€
<d1b2>
<246tnt> well that's not inexpensive either 😅 That's like 1/3 of the price of my laptop.
<d1b2>
<246tnt> Any with SFP ? I found some with 10GbaseT.
<d1b2>
<david.rysk> There’s pid.codes for USB in addition to the openmoko registry
<azonenberg>
Yes, I am not aware of any with SFP
<d1b2>
<aleksorsist> This was my logic of going thunderbolt vs. 10GbE once USB 3 proved impractical
<d1b2>
<svenpeter42> oh, right, sfp. I didn’t check the details and just looked for 10gbe
<d1b2>
<david.rysk> iirc it was a buyout of some bankrupt company that had a VID
<d1b2>
<david.rysk> or something of that nature
<azonenberg>
yeah as far as i'm concerned baseT dead ended at 1G
<azonenberg>
fiber is superior for anything faster
<d1b2>
<246tnt> QNA-T310G1S seem good.
<d1b2>
<svenpeter42> yeah, and the usb if just blacklists these vids but they also can’t really redistribute them so it kinda works out anyway 😉
<d1b2>
<david.rysk> That was the case for a while but in recent years 10GbaseT as well as 2.5 and 5 has been becoming more popular
<d1b2>
<david.rysk> (Known as NbaseT)
<azonenberg>
I still can't get PHYs for them on digikey qty 1 with no NDA
<azonenberg>
so they're dead to me
<azonenberg>
but sfp cages are cheap, very easy to drop down on a board, and need almost no support components
<azonenberg>
just hang it off a GTX and i'm done
<d1b2>
<david.rysk> Definitely can’t for 10, but I think you can get SFP modules easily
<azonenberg>
sure i could get an nbaset sfp if i wanted to
<azonenberg>
the question is what benefit it would have over going all optics? higher latency, higher power consumption, more picky about less-than-perfect cabling than 1000baseT
<azonenberg>
about the only advantage it brings is PoE and i can't think of anything i'd be doing any time in the foreseeable future that would need >1G + PoE
<d1b2>
<david.rysk> From what I can tell, simplifying cabling in enterprise/datacenter environments, and yeah PoE
<d1b2>
<svenpeter42> I hate that the same is true for those intel tbt controller chips. you can buy them but you don’t get any datasheets :/
<d1b2>
<david.rysk> Often uplinks are still 10 or 40 GbE fiber
<azonenberg>
Yep. This is why my ethernet switch project is using an FPGA and not a switch asic
<azonenberg>
Because those are impossible to get docs on as well
<azonenberg>
microchip has some cheap like 7 port 1000baseT switch chipsets that are fully documented
<azonenberg>
but nothing suitable for e.g. a 24x 1G + 2x 10G switch
<azonenberg>
So i'm working on managing instrument lifecycles a bit better in ngscopeclient
<azonenberg>
in particular, instrument connections should not be tied to the properties dialog
<azonenberg>
once you connect you're attached, if you close the dialog you should be able to reopen it
<azonenberg>
and you should also be able to remove any instrument, including a scope, from the current session
<azonenberg>
(without segfaulting if it's in use by other filter blocks etc)