<whitequark[cis]>
also why are those things more interesting, broadly speaking? most people have little to no use in processing that much data
<whitequark[cis]>
i'm not disputing that there are plenty of highly specialist applications for all of these protocols, requiring months of upfront investment and an extremely good FPGA skillset, but that's such a tiny minority
redstarcomrade has joined #glasgow
<whitequark[cis]>
sure, you have a USB3 or even USB4 or TBT uplink and can sink 10 GbE, at the cost of development effort largely unjustifiable even at community scale (compared to just buying a TBT+XGMII card for everyone who has a use for it). what now?
<whitequark[cis]>
unless you're pretty good at writing stuff in C++ you're not going to be able to process that data in real time, and if you can process it, you're going to quickly have issues storing it, and it goes on
<whitequark[cis]>
there's a huge utility in being able to do "fast ethernet" (SGMII), "fast USB" (USB3), "fast [not really] PCI" (5 GT/s), "fast SATA" (3 Gbps, can't do 6 on ECP5), etcetc
<whitequark[cis]>
* there's a huge utility in being able to do "fast ethernet" (SGMII), "fast USB" (USB3), "fast \[not really\] PCI" (5 GT/s), "fast ATA" (3 Gbps, can't do 6 on ECP5), etcetc
<whitequark[cis]>
there's much less incremental utility in supporting "faster X" for X being all of the above
<whitequark[cis]>
instead of getting a completely new capability, you're getting a slightly improved capability where the improvement doesn't matter or is outright detrimental in most practical applications, and only makes it a functionally new capability in a narrow slice of cases, under the assumption of engineering time being free
<whitequark[cis]>
also, and this is going to echo the previous statement, while making an OSS, modular "Tek killer" which can in principle replace dozens of specialized instruments for working with high-speed serial, I... don't think I have the time, the skill, or even the ambition (on its own yes, combined with leading the frontend team of a semiconductor startup? lol) to lead that effort
<whitequark[cis]>
and i don't really want to end up with a dozen of badly made instruments made by individual developers to scratch their itch, disparate and largely unsupported due to similar lack of time
<whitequark[cis]>
this is already a problem for us to some extent, but at least it's pretty easy, comparatively, to find people who are really good at writing, say, interface cores for iCE40 speeds. it's quite hard to find people who are really good at writing interface cores for ECP5 speeds. it is essentially impossible to find people who are really good at writing interface cores for Kintex speeds because they're all busy drowning in cash (and/or
<whitequark[cis]>
drowning someone else in their own blood, since a lot of this work that's not from telcos is from the MIC)
<whitequark[cis]>
provided i'm correct in these inferences, i think it's implausible we'll have a community effort to have a >10G grade reconfigurable instrument any time soon (we may end up standardizing on hardware for disparate individual efforts, but i don't know if that's appealing to me; hardware like that requires compromises, people with that degree of skill get rather opinionated, and even if that's not the issue, a key part of Glasgow's
<whitequark[cis]>
success is the high degree of vertical integration. if that's lost you might as well standardize on a kcu105 or something, what's the point? it has FMCs too)
<whitequark[cis]>
all of the above assumes that we get an excellent quality FOSS toolchain targeting that kind of FPGA, which in itself isn't clear--at least at the moment I'm unaware of active efforts to get us there
<whitequark[cis]>
realistically, I feel that I could probably develop that kind of instrumentation to the level of quality I expect in a commercial company with a team of 5 or more full-time engineers, all of whom are more qualified for the job than I am. I don't see doing it as a sum-of-its-parts community effort at all
DragoonAethis has joined #glasgow
<whitequark[cis]>
---
<whitequark[cis]>
a related observation is that i think open source software/hardware generally lacks a culture of instrument-building
<whitequark[cis]>
e.g. people often remark how good glasgow's interface feels to them (both the CLI and the internal ones). i actually consider them rather poor; quick hacks that didn't clear my lowest bar even at the time when i introduced them, but which i still committed in the name of actually getting something to work. i don't regret it, but i don't particularly like them either, and most of the reasons why i don't like them are both not obvious
<whitequark[cis]>
to a newcomer evaluating them (often for months) and are difficult to fix when you do bump into them
<whitequark[cis]>
i had to come up with concepts and methodologies essentially from scratch because, to my knowledge, no one's done quite this kind of modular instrument before, at this usability/quality target. at least no one did an open source one
<whitequark[cis]>
and i shouldn't be starting from scratch! morally, it feels like there should've been a wide area to draw ideas and implementations from, to learn from the errors recorded. maybe there is and i've just completely missed it. but if that is the case i've been very lucky in continuing to miss it for years
<whitequark[cis]>
some of the academic instruments are probably the closest (the ones they give to undergrads) but it's not quite the same thing, not with the same constraints. though i've definitely seen academia move towards the same general attractor recently
<whitequark[cis]>
for sure i cannot just ask TI to come up with a design and then get the taxpayer to pay for it
<whitequark[cis]>
there's just not a lot of shared understanding of what it means to build an instrument, much less what it means to build a good instrument
<whitequark[cis]>
lots of people still tolerate openocd! the rust folks have finally started making a dent against it at least. for a while i hoped sigrok/pulseview could improve things in the more traditional headless instrument area, but it seems to have stagnated quite early on several fronts
<whitequark[cis]>
and without a shared understanding of instrument-building, you can't really get ten individual contributors to work on a shared instrument. at that level they don't really have the time (and sometimes the will) to first spend a year or two or more building up a shared language and working out all the compromises in the area between each other
<whitequark[cis]>
cyrozap: as is probably evident from the two blog-post-length irc rants, i feel that the cost is the least of concerns there
<whitequark[cis]>
i need to mention also that i shouldn't be too harsh on openocd. peculiar and difficult to explore interface aside (tcl is just a small, largely insignificant part of it), it's a very flexible tool that lets you do really clever things for hardware bringup and debugging. it's fairly well documented too. it's just that there is a massive disconnect between what openocd is (a maximally configurable instrument for low-level silicon
<whitequark[cis]>
probing) and what 99% of people are using it for (flashing an STM32, but like in a really miserable way because they don't want to learn how to do fine-grained low-level silicon probing for that)
<_whitenotifier-6>
[glasgow] github-merge-queue[bot] created branch gh-readonly-queue/main/pr-554-9ef9d672584c98d4245713414895ffabc8462fce - https://github.com/GlasgowEmbedded/glasgow
<whitequark[cis]>
local catgirl finds the bleediest of bleeding edges of open source development and complaints that there's not a well developed culture on it
redstarcomrade has quit [Read error: Connection reset by peer]
<cyrozap>
whitequark[cis]: I see. I guess my motivation is I'd like to be able to use a device like that for both development work (e.g., being able to use it as a protocol exerciser to test an in-development PCIe/USB/10GbE/whatever core running on another FPGA) and infosec work (e.g., physically connecting to a GPON or XGS-PON network to see if the ISP has enabled encryption or if they're transmitting all their
<cyrozap>
customers' data to them and 15 or more of their neighbors in the clear), so it's not so much "being able to process tens to hundreds gigabytes of data at 10 Gbps" as it is "being able to send and receive specific, relatively short messages at 10 Gbps, and also being able to perform link training and speed negotiation in order to get up to those speeds". Like, just for one example, while 2.5 GT/s and 5
<cyrozap>
GT/s PCIe are mostly the same protocol (same PHY but with a faster clock), 8 GT/s changed several aspects of the PHY (8b/10b encoding to 128b/130b encoding being just one of them) so even though a 5G Glasgow could still poke at the upper layers of the PCIe device (data link layer, transaction layer, etc.), it would not be able to be used to test that negotiating up to 8 GT/s speeds works or that the data
<cyrozap>
encoding and scrambling is correct. All that said, I *totally* understand it not being worth all the time and energy that would be needed to create that marginal increase in utility, especially if the number of people who could even take advantage of that extra utility is so small.
<whitequark[cis]>
how would you even test the LTSSM corner cases?
<whitequark[cis]>
you'd need some of that 10k+ range equipment yourself and sink a great deal of time into exercising the glasgow implementation. basically the same effort as developing a new pcie endpoint, but with next to no compensation
<whitequark[cis]>
cyrozap: right but ... for ethernet, switches exist
<whitequark[cis]>
for pcie, in fact, switches exist! although broadcom would really like to pretend they don't, and the situation is a little grim
<whitequark[cis]>
it's just like... i started Yumewatari as partly a first step towards an open-source PCIe development suite, including things like exercisers
<whitequark[cis]>
and these days I even have enough experience to, with enough effort, get it all to work
<whitequark[cis]>
buuuuuut when you're buying that 10k device you're not really buying the hardware, you're buying decades of access to customers with weird ideas about how the protocol works and weird bugs, not to mention access to all the test engineers whose knowledge is embedded in the UI choices and decoders and exercisers whatnot
<whitequark[cis]>
it's not something that is replicable on the scale of individual contributors
<whitequark[cis]>
in my view, it is an organization-sized problem
<whitequark[cis]>
(that or like one extremely dedicated someone who sunk literal decades of their life into that one thing, but see above, and it's not like you're spoiled for choice here either. it doesn't scale at all)
<whitequark[cis]>
mind you, it's still absolutely possible and worth it to build PCIe dev tooling, even on IC scale
<whitequark[cis]>
the field is basically untrodden, anyone who does anything serious there is going to benefit from it in so many ways
<whitequark[cis]>
but it's going to be a different class of tooling. it would not be "an instrument" in the sense that i aim to build; one whose reliability can be trusted to exceed the reliability of your DUT
<whitequark[cis]>
this reminds me of Maya, who i've watched debug the LUNA USB stack, using an USB analyzer, which was hitting the exact same problem as the DUT itself. i don't know if Beagle 5000 is a worse-than-usual example (it's certainly on the cheaper side, though not *cheap*) or if people just accept a much lower level of reliability than what i would expect of my tools, but i really don't like being in situations where half the problems are in
<whitequark[cis]>
the DUT and half are in the instrument, and it's kind of a miracle imo that she managed to reliably produce useful work
<whitequark[cis]>
i think ECP5 is probably not a serious FPGA to build a high-end instrument around, chiefly because it cannot do offset sampling and therefore won't let you measure the eye
<josHua[m]>
hm does this channel primarily exist on IRC? that would be a much better interface for me than Discord. I thought that it was primarily Matrix
<whitequark[cis]>
you can still do it by adding a delay line and some dc offset (which i don't actually know how to do exactly but it seems feasible) but i know both xilinx and plx devices have that as standard
<whitequark[cis]>
josHua: it exists on irc, matrix, and discord simultaneously
joshua_ has joined #glasgow
<whitequark[cis]>
i don't touch discord if i can avoid it so this is a compromise to avoid community fractures
<whitequark[cis]>
also the logs live on the irc side because discord's logs are "lol" and matrix's logs are "lmao, but also somehow worse"
<joshua_>
I am not a huge fan of discord and indeed prefer open platforms, so let's see how the experience is over here
<sorear>
is "difficulty building an ESD and more general misuse tolerant frontend" not considered a showstopper for very high speed interfaces?
<whitequark[cis]>
it doesn't seem that much more difficult than for what we have now
<whitequark[cis]>
i mean, we famously have 40G capable ports that don't die from ESD, we have silicon that can do it (fascinatingly, we are already using that silicon on revC, despite many orders of magnitude lower rates. i think the ESD diodes are rated for like 8G or something)
<joshua_>
I also find myself generally of the belief that pad ESD diodes are often good enough for a great deal of abuse these days, and that one way or another we seem to have gotten much better at it than the bad old days when looking at a board funny was enough to kill it
<whitequark[cis]>
also it was my understanding is that a lot of the new serdes stuff uses current mode logic, which is less prone to the catastrophic accumulation of charge on the gate in first place
<whitequark[cis]>
but i'm not a physical designer so i dunno how accurate that intuition is
<whitequark[cis]>
either way, i just don't feel super concerned about the ecp5 given that we have so much evidence of being able to protect usb and hdmi and etc ports from much worse
<joshua_>
like I think I can count on one hand in nearly a decade and a half of doing this professionally the number of times I have had a part misbehave in a way that I can attribute to ESD-related damage, and I have pretty bad ESD practices. obviously if you want to subject a device to 'maximally abusive conditions' with an ESD gun then that may require some thinking
<whitequark[cis]>
we could also just put a redriver in the path
<whitequark[cis]>
belt and suspenders: redriver and ESD diodes
<joshua_>
I think the thing that is perhaps more interesting to me is maintaining the same level of capability of being able to use an I/O as single-ended across many differnet logic families, and also being able to use that same external I/O pin as a low voltage high speed differential pin
<whitequark[cis]>
that sounds infeasible
<joshua_>
indeed
<whitequark[cis]>
ecp5 gives you 4 lanes, even if you have 16 pins only, that's a really big multiplexer
<whitequark[cis]>
plus you aren't hooking up usb3 with dupont wires
<whitequark[cis]>
i mean... you could... but realistically its one of those samtec connectors with a usb or pcie or whatever on the other end. or i guess just some pads at the edge and some magnet wire
<joshua_>
USB3 probably not. you would be surprised at what you can get away with up to like 1.5 GT/s or so
<whitequark[cis]>
oh i've seen USB3 crimes
<whitequark[cis]>
you could do it. it's very tenuously functional but it's technically capable of ... some form of data transfer
<whitequark[cis]>
it definitely trains the link. usually. sometimes
<joshua_>
I mean, I am thinking not just for USB3, but for analyzing MIPI D-PHY
<whitequark[cis]>
that cursed thing
<joshua_>
oh come on, D-PHY is just a differential mode and also a single ended mode. same thing as USB2 kind of shenanigans.
<joshua_>
but, I guess I mean, it would really be nice to be able to handle SE and differential stuff on the same pin for the reason of USB2 / D-PHY. (C-PHY can go fuck off a bridge, I don't care about that)
<whitequark[cis]>
note that for revE i plan to ditch the whole "20 pin IDC connector" concept
<whitequark[cis]>
well not entirely, you'd still be able to get it as an option
<whitequark[cis]>
idea is that you get an attachment point for a SYZYGY-like (mechanically and electrically identical, not functionally identical) mezzanine
<whitequark[cis]>
then you put whatever the hell you want on it
<whitequark[cis]>
want to put a diff receiver between each two pins? why not
<whitequark[cis]>
for the SERDES, there's probably going to be all 4 pairs routed to all 4 mezzanines via one of those USB muxes or ... something like that
<whitequark[cis]>
because of how scarce the SERDES pins are in ECP5
<whitequark[cis]>
you know, the DP cross point switches
<cyrozap>
whitequark[cis]: I must admit I haven't thought all of this through so deeply. I should probably try to write my FOSS PCIe core first, then hopefully I'll have a better understanding of the problem domain.
<whitequark[cis]>
for USB2 you also have the problem that the ECP5 is not fast enough to bitbang it in fabric, and the transceivers can't lock onto the stupid encoding it uses
<whitequark[cis]>
i think that the only way to do soft-USB2 on ECP5 is to sample it with the CDR free-running then subsample, do a pipelined soft-PLL, then the usual
<whitequark[cis]>
which is like the digital equivalent of a beautiful painting by Hieronymus Bosch. amazing to contemplate, less amazing to participate
<whitequark[cis]>
if i ever am responsible for that, possibly by my own hand, i will consider it the divine punishment for my sins
<whitequark[cis]>
i don't want to even think about approaching d-phy in this fashion
<whitequark[cis]>
c-phy has the energy of the assia terabit dsl guys
<joshua_>
the Qualcomm guy who proposed it was like singlehandedly responsible for it I think
<joshua_>
he decided he was going to make 'fetch' happen, got the Qualcomm lawyers to patent it, and then started strongarming sensor vendors
<whitequark[cis]>
sometimes theres a standards committee guy with a strong angel girl energy and it's truly terrifying
<whitequark[cis]>
it's not always effective but you've gotta admire it the way you admire like a tornado or a firestorm
<whitequark[cis]>
USB PD 1 had the same deal
<joshua_>
(I know of this particular angel girl qualcomm guy because I was sent there to make it stop on behalf of nvidia)
<whitequark[cis]>
did you get him drunk repeatedly
<joshua_>
I think that like there are really two sources of bad ideas in hardware standards committees. one is people who have never heard of computers before, and the other are terrorists
<joshua_>
this guy was clearly like a San Diego state-funded terrorist
<joshua_>
there were a lot of image sensor vendors who were trying to suggest ideas about how to read out subsets of a raster scan, including tagged data with image sensor recognized features, who were less in the 'terrorist' camp and more in the 'have never heard of computers before' camp, and just clearly had never considered that it was possible to have ideas that are not bad
<whitequark[cis]>
i like this classification
<whitequark[cis]>
how do you feel about usb audio
<joshua_>
getting them drunk repeatedly works better on sensor vendors because they mostly are in Japan, for which getting them drunk is the generally accepted way to do business, and in fact, you can often convince them that their interests (i.e., selling image sensors) align with yours (i.e., having a protocol that does not suck raw eggs). white male religious extremists from large SoC manufacturers in San Diego do not need to drink, and in fact, their intere
<joshua_>
(I say this, by the way, with no particular animus for George in particular, he's a perfectly friendly guy. I do not know if he is a religious extremist in reality and do not actually accuse him of this, other than by the hyperbole of, like, what it must take to be on a standards board on behalf of Qualcomm.)
<joshua_>
I have no opinion on USB audio, I have not read this thing
<whitequark[cis]>
"their intere[cut off]"
<whitequark[cis]>
joshua_: i highly recommend it, if you ever need a way to self-harm like real quick
<whitequark[cis]>
the fact that it's almost but not entirely wrong makes it just that more infuriating
<joshua_>
interests are to hasten the rapture
<whitequark[cis]>
disturbing parallel. thank you
skipwich has quit [Quit: DISCONNECT]
skipwich has joined #glasgow
<tpw_rules>
"tagged data with image sensor recognized features" ?
<tpw_rules>
like putting objects in the picture?
<joshua_>
yeah, they had good ideas like doing face detection on the image sensor
<joshua_>
why they thought they could do that better than whatever the 16MP image sensor is hooked up to, I have absolutely no idea
<tpw_rules>
edge-er computing
<SnoopJ>
I can't speak for face stuff but in manufacturing the time you can save doing inference right there at the sensor (assuming they've put a decent amount of compute there and the software stack doesn't suck) can be appreciable
<SnoopJ>
quality of vendor ecosystems for this is… all over the place.
<tpw_rules>
i uh, would not put money on especially that last thing
<SnoopJ>
yea, it's generally not great
redstarcomrade has joined #glasgow
redstarcomrade has quit [Changing host]
redstarcomrade has joined #glasgow
duskwuff[m] has joined #glasgow
<duskwuff[m]>
… edge-detection computing?
Emantor has left #glasgow [#glasgow]
<theorbtwo[m]>
Yey, I have an actual Glasgow in my hands! (Before I got the tracking number from Mouser.)
<theorbtwo[m]>
Hm, floppy first or prom... Floppy seems a little more straightforward. Or do I jtag for a bit...
<FireFly>
\o/
<FireFly>
hopefully same soon
notgull has joined #glasgow
q3k[cis] has joined #glasgow
<q3k[cis]>
<joshua_> "C-PHY is the chaotically bad..." <- what in the fresh fuck am i looking at
<FireFly>
ETA monday for mine apparently
notgull has quit [Ping timeout: 268 seconds]
redstarcomrade has quit [Read error: Connection reset by peer]
mwk has joined #glasgow
<Attie[m]>
that C-PHY slide deck is eye opening, thanks for sharing!......
tomkeddie[m] has joined #glasgow
<tomkeddie[m]>
I needed to study c-phy for work - it's a thing. Crazy idea but seems to becoming real.