<nemanjan00[m]>
I just wrote a tutorial for myself, for implementing applets, and I guess someone might find it useful, and also, hope someone will find my mistakes in understanding how glasgow works
<dav_818[m]>
yes, very good idea, a gigeth or 10gig? wouldn't hurt. especially as the fpga can handle TSN time-stamping, having several ethernet equipped glasgow's could run with very tight sync on the same network (assuming the switch in use supports tsn)
<whitequark[cis]>
gigeth
<dav_818[m]>
I guess as old as the standard ~2009? FX3 probably performs well, power might not be best in class though...
<dav_818[m]>
some pcie based usb phy's seem slightly more up2date, check for example ASmedia
<whitequark[cis]>
and what is the PCIe host?
<whitequark[cis]>
(also what is going to be implementing XHCI? who's adding DRAM? that is ~required for XHCI to work)
bvernoux has quit [Quit: Leaving]
<dav_818[m]>
ehrm.. ecp5? an efinix Ti120..? true re dram, FX3 sounds like a pick
<whitequark[cis]>
there is no foss pcie host for ecp5 so that would have to be developed, effectively from scratch
<whitequark[cis]>
that has been on my plans but it's a huge project in and of itself. just for USB PHY? why not put the PHY on the FPGA in that case?..
<galibert[m]>
ecp5 is fast enough?
<whitequark[cis]>
USB and PCIe are pretty similar anyway, and then you skip having to add DRAM and implement the extraordinarily complex XHCI spe
<whitequark[cis]>
s/spe/spec/
<whitequark[cis]>
ECP5 can do USB 3 (barely), yes
<whitequark[cis]>
it would have less trouble with 2.5 GT/s PCIe but like, just, why?..
<galibert[m]>
ok, I had a feeling that pcie/thunderbolt/usb 3 required rather high speeds or beefy hard blocks
<whitequark[cis]>
ECP5 has a hard block (SERDES) that can do PCIe (2.5 or 5) or USB 3 (5 only, not 10)
<whitequark[cis]>
you have to do a part of your design at 250 MHz for 5 GT/s PCIe or USB 3
<whitequark[cis]>
and that really strains the FPGA
<whitequark[cis]>
then working with a 32-bit datapath at 125 MHz isn't easy either
<whitequark[cis]>
and then you still have to do the rest of your design somewhere near
<galibert[m]>
Oh yeah. On the cyclone V it would be hard too, I think
<whitequark[cis]>
Wonka: that's Altera Stratix specific, worthless for this scenario
<galibert[m]>
I don't know how a cyclone V and an ecp5 compare actually
<Wonka>
ah, damn
<whitequark[cis]>
also in general not keen on using random Verilog cores for Glasgow
jwise0[m] has joined #glasgow
<jwise0[m]>
no OSS synth for Ti120 (also, Ti120 PCIe isn't on the market yet, iirc)
<whitequark[cis]>
I think in these discussions people often misunderstand what's difficult
<whitequark[cis]>
I, too, can do a Google search for something like "PCIe FPGA open source", that's not hard
<galibert[m]>
Oh, I thought the answer to what is difficult is "everything"?
<whitequark[cis]>
and I have in fact done that before, the hard part is fitting all of that landscape to a particular set of tradeoffs Glasgow is dealing with
<whitequark[cis]>
it is not that difficult to cobble something together for an expensive prototype on your desk
<galibert[m]>
The physical layer with timings annoyances, the interfacing with the high speed differential serial, the core itself with the high speeds, the protocols which are a ton of stuff...
<jwise0[m]>
the thing with high speed serial PHYs / link layers is indeed that it is not super difficult to have a PHY train up to one Intel system, on typical silicon, at 25C, and send most of its packets correctly
<whitequark[cis]>
it is much, much harder to bring it to production to everyone at decent cost and be field configurable in a reliable way
<whitequark[cis]>
galibert: honestly if it was just about implementing a PCIe PHY+MAC I would consider that "easy" in comparison to what it is to bring it to *everyone*
<galibert[m]>
Catherine: what's your definition of everyone in context? Every capable fpga, every pcie device?
<jwise0[m]>
having a PHY train up on whatever chaotic combination of PLX bridges you can imagine, and send all of its packets correctly (at least, within the bit error rate * checksum bounds), on every part and board that is in spec, from -25C to 100C, and do it in a way that it is recoverable from a bad firmware flash, and that is plausible to implement a driver for on MacOS, Windows, and Linux, ... well...
<whitequark[cis]>
galibert: everyone purchasing a revE Glasgow device
<whitequark[cis]>
jwise0 gets it
<jwise0[m]>
this is not even 'every capable FPGA' or 'every PCIe endpoint', this is simply 'every reasonable PCIe root complex, for one given piece of hardware that one wishes to manufacture'
<jwise0[m]>
although I do not know that Catherine is, I'm even willing to exclude PCIe root complexes that misbehave!
<galibert[m]>
Catherine: so it's on fixed hardware, slightly less insane
<whitequark[cis]>
jwise0: the same thing makes using LUNA USB 3 a nonstarter for the time being
<jwise0[m]>
I have done no investigation of LUNA so I cannot really comment
<whitequark[cis]>
it works with most hubs and hosts. I think. after Maya spent a month redesigning every bit of the PHY and some of the bits of the MAC
<whitequark[cis]>
but this is by no means something that's actively tested on a hardware suite for example
<whitequark[cis]>
as far as I know
<whitequark[cis]>
it was just a one time thing where she went thru a bucket of hubs and tested each one, plus used two hosts, neither of which was an AMD one
<galibert[m]>
OTOH, there's no chance that you'll have the hardware to test anything as wide as you'd like, whatever the protocol.
<whitequark[cis]>
and things as simple as "the Linux machine spent some milliseconds more trying to enumerate the device" could make or break it
<galibert[m]>
Well, maybe GigE is wide enough and stable enough to require less testing, I guess
<whitequark[cis]>
getting reliable PCIe or USB 3 communications requires a concerted, multi-month effort by a developer or better a team of dedicated developers who put wayyy much time into testing it on everything you can imagine
<whitequark[cis]>
at the moment there is just no OSS cores that fit those requirements
<whitequark[cis]>
not daisho, not LUNA, not LitePCIe
brolin has quit [Ping timeout: 255 seconds]
<jwise0[m]>
one thing to think about is that, if you think about commercial silicon (think GPUs, but even sometimes think PLX PCIe bridges), many of them will 'mostly' work without a firmware ROM, but if you have a firmware ROM, that ROM will set a large number of chicken bits on the PCIe controller that will make it work on 'almost everything'
<whitequark[cis]>
yep
<galibert[m]>
I love ethernet, it tends to just work when it works, and over that it's just a matter of software bugs, not hardware
<whitequark[cis]>
GigE is nice and simple and straightforward
<whitequark[cis]>
and piping the same GigE data over FX3 is equally straightforward
<jwise0[m]>
I mean, this does not disqualify using PCIe or USB3 for a product in general. and you can have much lower latency for realtime applications with USB or PCIe. but, indeed, what it means is that you don't want to do the implementation on your FPGA
<whitequark[cis]>
terminate one TCP stream on the FX3 itself (for controlling the FPGA etc), another on the FPGA, you're done
<whitequark[cis]>
put all the weird stuff you don't want to deal with (like DHCP) on the FX3 too
<jwise0[m]>
is there a ULPI-like standard for USB-SS?
<whitequark[cis]>
PIPE, yes
<galibert[m]>
You can even implement a web server on the fx3 :-)
<whitequark[cis]>
it supports PCIe, USB3, and in newer revisions even DisplayPort and some others
<whitequark[cis]>
there is also "SerDes PIPE" which is really just a standardized interface for a SerDes with some clocking defaults, a register interface to configure e.g. the equalizer, etc
<jwise0[m]>
that seems like it solves at least the PHY problems? not sure how bad the USB-SS link layer is
<whitequark[cis]>
the thing that Maya wrote for LUNA was a PIPE adapter for the FPGA SerDes
<whitequark[cis]>
I think it was GTP, GTX, and ECP5 transceivers
<whitequark[cis]>
it doesn't support power management but that's fixable
<whitequark[cis]>
the PIPE part is the easy one
<galibert[m]>
cyclone V has a hard-ip pcie, but somehow none of the evaluation boards connect to pcie, imagine that
<whitequark[cis]>
the hard part is the USB3 MAC
<jwise0[m]>
ahh
<whitequark[cis]>
LUNA has one too, which can enumerate and do basic control and bulk requests
<jwise0[m]>
I have not read any of the spec for usb3
<whitequark[cis]>
however timing closure on it is very difficult and in the default configuration it doesn't actually reach the required 125 MHz on ECP5
<whitequark[cis]>
she had to run nextpnr with --ignore-timing-fail
<jwise0[m]>
well that seems bad
<whitequark[cis]>
it gets up to something like 118 MHz which means it still mostly works
<whitequark[cis]>
but obviously that won't work in every PVT corner
<jwise0[m]>
re: TCP: I assume if I were doing this I would not speak IP to the FX3? I would speak The Glasgow Stream Protocol, and then I would encapsulate The Glasgow Stream Protocol in either TCP or in fx3-usb?
<whitequark[cis]>
IIRC she mentioned to me that you would have to do some nontrivial changes to the design for it to be a good option for ECP5
<whitequark[cis]>
jwise0: the idea I had was that Glasgow would be connected over Ethernet no matter what
<whitequark[cis]>
however the Ethernet pipe would be either "cat5" or "usb3"
brolin has joined #glasgow
<whitequark[cis]>
also re: all the USB3 talk, do not forget that you also have to implement the fallback to USB2
<jwise0[m]>
i.e., have the usb3 guy be a CDC-NCM or some such?
<whitequark[cis]>
yes
<whitequark[cis]>
I think NCM drivers are now in the default OS config everywhere and we can just do that
<jwise0[m]>
well, ok, you can also encapsulate The Glasgow Stream Protocol inside bulk usb2 transfers too
<whitequark[cis]>
so I think that for buffering purposes it probably makes sense to have a TCP engine per applet
<whitequark[cis]>
otherwise you get head of line blocking for example
<whitequark[cis]>
or maybe you don't care about reliability, you want to use UDP, you can do that too if it's terminated on the applet
<jwise0[m]>
j4cbo (@_discord_741012983479795834:catircservices.org) probably can speak to whether that is actually a good idea, Ether-Dream was a device that was born as an ethernet device and then had a USB protocol later
<whitequark[cis]>
so all the FPGA has to do at the base level is an IP packet cut-through router
<jwise0[m]>
I sort of wonder about, from a usability standpoint, permissions for user apps to configure a network interface. USB user mode drivers are pretty easy and common on Linux and MacOS (on Windows I think your life still sucks).
<whitequark[cis]>
well, a little more complicated than that, it would also need to transfer data from the GigE RGMII/SGMII to the FX3 when it's connected via the ethernet jack
<whitequark[cis]>
but only a little
<whitequark[cis]>
jwise0[m]: I think USB ones are autoconfigured
<whitequark[cis]>
the FX3 needs to have a trivial DHCP server
<galibert[m]>
jwise0: why configure an interface, you just go connect() :-)
j4cbo[m] has joined #glasgow
<j4cbo[m]>
etherdream is still ethernet-only; i experimented with USB-ethernet and got it working well cross-platform, but had to use a mix of NCM + RNDIS
<whitequark[cis]>
yeah NCM+RNDIS was what I was thinking of as a backup option
<j4cbo[m]>
(didn't release the USB-over-ethernet stuff due to insufficient performance without a high-speed PHY)
<jwise0[m]>
(also in corp environments, where connecting to a foreign network may be bad)
<whitequark[cis]>
I think that's entirely
<whitequark[cis]>
* that's entirely feasible
<whitequark[cis]>
jwise0: re corp environments: we could release a special version of revE for those companies in particular :3
<jwise0[m]>
but a bulk transfer even with prepended 'this is to applet n' could be internally routed to the applet can solve your HoL blocking problem
<jwise0[m]>
that sentence had grammatical issues but you get the idea
<galibert[m]>
You know tcp has a method to route to different endpoints, it's called "ports"
<whitequark[cis]>
I don't like that idea because in order to take e.g. 1 MB of data and add that prefix to each 511 byte chunk you have to do a lot of operations in pure Python
<whitequark[cis]>
(this applies to the current Glasgow too)
<jwise0[m]>
no, correct link, it's just buried in my rant
<j4cbo[m]>
apparently sufficiently-new windows has CDC-NCM support out of the box
<whitequark[cis]>
also re: github 2FA, i simply put the TOTP secret into my password manager, right next to my password
<whitequark[cis]>
so it adds no real friction, but somewhat surprisingly, it actually does improve security
<jwise0[m]>
(I was the author of the RNDIS driver for macos, and I regret ever releasing it)
<whitequark[cis]>
because now someone who phishes me can only log in once
<galibert[m]>
I mean with ports, zeroconf, web servers, all the needed capabilities are available and already supported by your os
<whitequark[cis]>
rather than anytime
<jwise0[m]>
if you ahve to use a network, zeroconf does make it easier than ever before
<whitequark[cis]>
zeroconf is a good option too yep
<jwise0[m]>
i.e., if everybody involved speaks v6, you can have link local addressing and be done with it
<whitequark[cis]>
oh yeah, the idea was to be v6 only
<j4cbo[m]>
zeroconf is widely-supported by OSes but surprisingly poorly-understood by users (expect lots of "how do i set the IP address?"), not helped by windows and osx (and maybe linux too?) having a *very* long timeout before assigning a link-local address
<jwise0[m]>
one thing to think about of course is that if you're going to do that, there are many options that are not an fx3 and therefore do not involve writing your own NCM peripheral. you can just have a LAN7801 or something, which speaks RGMII. then have a second RGMII interface on Glasgow -- one to your real PHY, one to LAN7801 (or analogous).
<tpw_rules>
linux with networkmanager afaik doesn't even have a timeout
<whitequark[cis]>
jwise0: then we still need an MCU onboard, and we lose on flexibility
<jwise0[m]>
why do you need an MCU onboard?
<whitequark[cis]>
e.g. what if our ethernet over usb experiment fails and we have to go back to bulk transfers?
<whitequark[cis]>
jwise0[m]: because the board must still be usable even if the FPGA bitstream is fucked
<jwise0[m]>
yes, you cannot do tha tin that case, that is true
<whitequark[cis]>
it must have all of the safety features monitored, be addressable to reload the bitstream with something that isn't fucked, etc
<whitequark[cis]>
the FX3 is a free MCU sitting right at the heart of the system
<whitequark[cis]>
which can itself run TCP/IP
<jwise0[m]>
oh, right. if the FPGA can do A/B boot that certainly can help but it brings up its own set of engineering challenges
<whitequark[cis]>
the FPGA should ideally have only applet code, not the management code
<whitequark[cis]>
as much as that's at all feasible
<jwise0[m]>
oh, right, because not partial reconfig
<whitequark[cis]>
yep
<whitequark[cis]>
in the design with the FX3, you would still need the FPGA to run a bit of management code to bridge GigE to the FX3
<whitequark[cis]>
but that is probably acceptable; it would be a golden bitstream sitting in the flash somewhere
<whitequark[cis]>
an amusing complication with the FX3 is that it doesn't have enough RAM to store a complete ECP5 bitstream
<whitequark[cis]>
so it'd need to write it to an external QSPI PSRAM
<jwise0[m]>
yeah ok I was thinking 'resilience against bad bitstream flash', but 'being able to recover without a power cycle' is what you care about
<whitequark[cis]>
being able to recover remotely without a power cycle, yeah
<galibert[m]>
using the fx3 as a bridge between gige and the fpga is possible or it's too slow?
<whitequark[cis]>
I don't think it has anything you can connect a GigE PHY to
<whitequark[cis]>
I might be wrong
<galibert[m]>
oh
<whitequark[cis]>
well, other than the main 32-bit parallel bus, but that goes to the FPGA
<whitequark[cis]>
I don't think we can like... branch it
<galibert[m]>
ah I see, it's designed as a usb device, not a ethernet one
<whitequark[cis]>
yes
<jwise0[m]>
well Microchip has you covered once again, KSZ9893 is a 3-port GbE switch with one of those ports usable as a RGMII. feed the RGMII to a FPGA, feed one to the outside world, feed one to ENC424J600 hooked up to the FX3
<whitequark[cis]>
not THAT fucking thing
<jwise0[m]>
YES THAT FUCKING THING
<j4cbo[m]>
yeah it seems like the robustness requirements mandate a view of the system as "glasgow is a system that contains a user-programmable FPGA" rather than "glasgow is a system contained within an FPGA"
<whitequark[cis]>
that's covered by NDAs right?
<galibert[m]>
now that's an interesting reaction, feels like there's a story there
<whitequark[cis]>
they don't actually tell you anything about the MII registers right?
<whitequark[cis]>
that thing?
<jwise0[m]>
I have no idea, I just googled for parts
<whitequark[cis]>
that abomination?
<whitequark[cis]>
oh ok
<whitequark[cis]>
actually I might be misremembering the p/n
<whitequark[cis]>
j4cbo[m]: yes, this is absolutely correct
<jwise0[m]>
that does seem to trend towards answers like 'actually, what if another ECP5 as the management chip', though
<whitequark[cis]>
glasgow is a top-down software/firmware/gateware framework built for supporting a user programmable FPGA
<j4cbo[m]>
having worked with ENC_J_ parts from Microchip, i would encourage avoiding them
<jwise0[m]>
('...and an FX3 to handle the USB-SS parts')
<whitequark[cis]>
well
<whitequark[cis]>
if you go for the cheapest ECP5 without 5G capability then that's feasible
<j4cbo[m]>
the ENC28J60 was the biggest "the datasheet giveth and the errata taketh away" i have ever seen
<whitequark[cis]>
jwise0[m]: this ... is maybe not actually the worst idea
<whitequark[cis]>
wait
<galibert[m]>
what about a mcu with gige and no usb?
<whitequark[cis]>
that's Fast Ethernet
<whitequark[cis]>
hold on do you expect there to be two IPs?
<whitequark[cis]>
one for the FX3 and another for the FPGA?
<jwise0[m]>
sure, why not? it's all v6, they're free. or they could share a MAC address if you wanted to and know not to step on each other's prots
<jwise0[m]>
s/prots/ports/
<whitequark[cis]>
would the switch not get angry at shared MAC in this case?
<vegard_e[m]>
sounds like a great way to get the ARP table in the switch really confused
<jwise0[m]>
an excellent question
<jwise0[m]>
the 'system ECP5' solution being: sysECP5 has RGMII on one side connecting to ethernet PHY; FX3-USB interface on one side; wide-parallel interface to userECP5 on the other side
<vegard_e[m]>
if you need both fpga+fx3 for management, lifcl-33u suddenly becomes a more viable alternative
<whitequark[cis]>
the only thing against the sysECP5 solution that I have is cost
<jwise0[m]>
topologically this is pretty similar to the 'how many Microchip parts can we stuff into one design' approach, and the only question is which is cheaper. the sysECP5 really is just a big old I/O mux
<vegard_e[m]>
assuming it's usable
<jwise0[m]>
yeah, I have no idea how expensive the Microchip parts are.
<whitequark[cis]>
jwise0[m]: it could also run a riscv or something with smoltcp on it
<whitequark[cis]>
fx3's cpu core is surprisingly slow, you could exceed its performance on an fpga
<whitequark[cis]>
then the fx3 becomes solely a programmable usb-parallel bus adapter
<jwise0[m]>
you could also do this, there would be a lot of logic left over on the sysECP5
<whitequark[cis]>
you could actually potentially use something like ft600, if not for the name of the project
<jwise0[m]>
pfft
<whitequark[cis]>
(glasgow started as ftdi hate mail)
<whitequark[cis]>
galibert: it's USB3 that's the limiting factor here
<whitequark[cis]>
we all know we can easily do this with just gige (and potentially hs usb) without any difficulty
<galibert[m]>
Yeah but, do you really want usb3?
<whitequark[cis]>
yes?
<jwise0[m]>
yeah, all the USB-SS devices that run Linux are really expensive
<whitequark[cis]>
it would be the fastest way to get data on and off board by far
<whitequark[cis]>
3x the speed of gige
<whitequark[cis]>
well, technically 1.5x if you count both ways, but it'll usually be 3x
<whitequark[cis]>
for example, you could tap into pcie and stream it in real time (one direction only) at max throughput with usb3
<galibert[m]>
It the difference in complexity worth the difference in difficulty?
<jwise0[m]>
I think there is a real portability question as well
<whitequark[cis]>
well, my original view is that fx3 is a well characterized common part, and everything else is pretty jellybean
<galibert[m]>
and the difference in cost too
<whitequark[cis]>
plus we've had an excellent experience with the fx2
<jwise0[m]>
my Shenzhen Thinkpad has GbE, but this is not broadly the case
<whitequark[cis]>
so if you do fx3+fpga+rgmii or something, it's low cost, it's relatively low complexity, and you just need to write some gateware/firmware which is not too bad either
<jwise0[m]>
and, like, if everyone bought x2100s, I think the world would be much cooler, but this is not the way of things
<galibert[m]>
ok, the nice thing about usb* is that it provides power too
<j4cbo[m]>
KSZ9893 has some fairly sophisticated mirroring and filtering support; it looks like it could do things like "forward inbound TCP to the micro and UDP to the FPGA"
<whitequark[cis]>
we can always add a type-c connector just for power :p
<whitequark[cis]>
that doesn't need an fx3 or really anything except a pd phy
<jwise0[m]>
yes there is definitely a question as to whether you can use a cheaper PLD than ECP5, and if you do not demand open source tooling for sysFPGA, Roger would sell you Trion T8s for pretty cheap, I'm sure
<galibert[m]>
(and usb-pd is an absolutely trivial thing to support :-) )
<whitequark[cis]>
you can buy an off the shelf pd phy
<whitequark[cis]>
that's easy to program
<whitequark[cis]>
that is a solved problem
<whitequark[cis]>
jwise0[m]: all of the toolchains for all of the logic on the board shall be open source
<jwise0[m]>
so the only thing that makes me anxious about the 'use the entire catalog of chips that Microchip will sell you' solution is that specialty chips, in general, seem to have shorter lifetimes
<whitequark[cis]>
yes
<whitequark[cis]>
we could potentially go for Microchip Get Launched or sth
<whitequark[cis]>
and get them at cost or even less than that
<whitequark[cis]>
which is a beneft
<whitequark[cis]>
* which is a benefit
<jwise0[m]>
like Microchip tomorrow could say 'KSZ9893 is EOL because nobody bought them, and you shall now use the pin-incompatible KSZ9894'
<jwise0[m]>
which is pretty unlikely with ECP5 and FX3.
<whitequark[cis]>
yes, this is very much a concern
<whitequark[cis]>
microchip is pretty good about supporting their ancient designs
<whitequark[cis]>
i believe they keep a manufacturing line somewhere afloat just for ATF15xx CPLDs
<jwise0[m]>
for USG volume, I'm sure they would
<whitequark[cis]>
the line from late 90s is so old they don't have anything else to use it for, so they just keep making those devices
<jwise0[m]>
for Glasgow volume, I'm not so sure they would
<whitequark[cis]>
oh I just mean that in general they're not as aggressive about EOLing their parts as, for example, TI
<jwise0[m]>
yeah, I certainly would not design in a TI part if I did not have to
<whitequark[cis]>
so it's less of a concern regardless of the specific relationship
<whitequark[cis]>
we actually designed in a fuckton of TI parts on the revC
<whitequark[cis]>
almost all of the power/analog parts are TI
<whitequark[cis]>
and a lot of it was by me <,<
<jwise0[m]>
yeah, I'm sure esden loved that when he was trying to source them in 2021
<whitequark[cis]>
the parts that were the hardest to source were also without a functional replacement
<whitequark[cis]>
like the LDO with the foldback curve we needed
<vegard_e[m]>
I had some bad experience with KSZ8893 at a previous job
<whitequark[cis]>
no one else makes an LDO quite like that
<galibert[m]>
vegard_e: fucked your dog and killed your wife? ;-)
<vegard_e[m]>
we picked KSZ8893 because of the «repeater mode» feature to do some low latency ethernet stuff, and it turns out that it just **doesn't work**
<whitequark[cis]>
lmfao classic
<galibert[m]>
Ah yeah, I was close
<whitequark[cis]>
ultimately the delay was useful for giving me time to emigrate and get my life into a viable shape, so it's not all bad
<jwise0[m]>
($FORMER_CLIENT made the same error in the same timeframe, with the general arc of it being 'we called Arrow to ask them for part selection hlep; they suggested some TI stuff; we designed it in; we sent it all off to our CM in Asia; the CM had their own relationship with TI and it was low-$ stuff so we just told them to do whatever they wanted; 2021 happened; TI was like "your lead time for your product is now: 96 weeks"; we called Arrow
<jwise0[m]>
and we were like "help"; they were like "maybe you should ask your CM who isn't sourcing it through us for help, we can't pull any strings since you're not named as the customer of record with TI"; $FORMER_CLIENT was like "fuck"')
<whitequark[cis]>
and I do like what we got with revC3
<jwise0[m]>
and of course they were little specialty parts that were generic in general function, but the specifics of pin configuration etcetera were not *quite* jelly bean enough that we'd find the same from anyone else.
<whitequark[cis]>
a big problem with the LDO is that the form factor is fixed
<whitequark[cis]>
and it was just not feasible to put a less integrated replacement in the area we had remaining
<whitequark[cis]>
without going insane with WLCSPs and like 6- or 8-layer board which wasn't happening
<jwise0[m]>
yeah, classic
<whitequark[cis]>
the good thing about this LDO is that it means that shorting the onboard supply never brownouts the board itself
<whitequark[cis]>
which was a significantly more complex issue than i thought at first
<whitequark[cis]>
onboard supply as in provided for external use
<whitequark[cis]>
it is very much a goal of Glasgow to be as robust to misuse as we could get it, and honestly I can't imagine how much more robust we could have possibly made it
<whitequark[cis]>
it is extremely difficult to damage or even get to misbehave
<whitequark[cis]>
heh, back 3 years ago i had an argument with esden over using type-c connectors because i was concerned that non-pth connectors could be easy to lift off the board
<jwise0[m]>
I wonder where 'dftu.jpg' is
<whitequark[cis]>
we ended up with a pth type-c connector soldered using paste-in-hole i htink
<whitequark[cis]>
which is basically impossible to tear off without breaking the board
<whitequark[cis]>
good for the kind of person who just shoves the board and cable still connected in their backpack
<jwise0[m]>
I'm pretty sure that j4cbo (@_discord_741012983479795834:catircservices.org) once blew up the USB port on a macbook by feeding a saleae 5V on the ground pin. never underestimate how hard you can try
<whitequark[cis]>
jwise0: no, i didn't say it's *impossible* to damage
<whitequark[cis]>
i'm saying that i don't know how much more effort could we reasonably spend to make it harder
<whitequark[cis]>
obviously the universe can always produce a greater fool
<whitequark[cis]>
however what i'm saying is that i think we picked all of the low-hanging and a lot of the medium-hanging fruit
<galibert[m]>
It's nearing the "apple laserwriter" levels of resilience?
<whitequark[cis]>
kinda yes
<whitequark[cis]>
5v on ground could still blow an external usb host I think
<whitequark[cis]>
we don't have anything protecting against that
<whitequark[cis]>
jwise0: however it's like... you could remove the protective resistors and dead short any or all of the level shifters for 2 days and they still work and are in spec after that
<whitequark[cis]>
so we're pretty confident you're not gonna blow the level shifters in reasonable use otherwise
<galibert[m]>
I like the "for 2 days" aspect
<whitequark[cis]>
yes, you should still not connect your car battery to them, but there's a limit to what can reasonably be done
<galibert[m]>
Feels so much like the kind of tests we do I my lab
<whitequark[cis]>
galibert[m]: marcan literally left it running basically red hot for 2 days and then checked every specification he could
<whitequark[cis]>
these are tiny things in tiny packages so of course some level of concern was warranted
<whitequark[cis]>
but they seem to be very robust
<galibert[m]>
(like open and close a door a million times. I think the target was 5M but there were issues before reaching them)
<whitequark[cis]>
not the only problem but that has a cold joint
<whitequark[cis]>
four of them in fact
<j4cbo[m]>
specifically it wound up being a 12 volt differential (from an isolated PoE supply) between the ground pin on one side of the laptop and the ground pin on the other side of the laptop
<whitequark[cis]>
five?
<whitequark[cis]>
j4cbo[m]: yeah I mean glasgow is rated at 5V
<whitequark[cis]>
any input above 5.5V is straight out of spec and we can't do much about it (though @electroniceel was working on an addon that would protect from that too)
<j4cbo[m]>
this wasn't a glasgow, it was an earlier USB misadventure
<jwise0[m]>
'dftu.jpg' might be a figment of my imagination?
<jwise0[m]>
there was a picture of the corrective action that I was looking for
<whitequark[cis]>
j4cbo[m]: yes, I realize; I mean this is a situation I've explicitly thought about before
<whitequark[cis]>
"what if someone connects a car battery to a pin"
<whitequark[cis]>
the answer is that the device is fucked
<j4cbo[m]>
joshua: it is not a figment of your imagination, i still have those post-it notes
<jwise0[m]>
I also have those post-it notes, I think there was one specific photo that I am looking for
<whitequark[cis]>
it;s unclear whether that kills the shifter, the entire port, or the entire device
<whitequark[cis]>
I'm sure someone will eventually run this experiment unintentionally and submit the results
<jwise0[m]>
of, like, this annotating a connector
<galibert[m]>
Send a glasgow to mystbusters?
<galibert[m]>
s/mystbusters/mythbusters/
<whitequark[cis]>
well the idea is that someone else pays for it <.<
<galibert[m]>
Huhuhu
<jwise0[m]>
Catherine -- I assume the pins have ESD diodes? so 'yes, then yes, then yes'?
<j4cbo[m]>
the real tricky situation is not when an I/O pin is misconnected, it's when the device's ground is connected to something that is severely not ground
<whitequark[cis]>
jwise0: they have ESD diodes but the ports have LDOs with backflow protection
<whitequark[cis]>
so the question is whether 12V blows the LDO, which I think it might not
<jwise0[m]>
ahh
<whitequark[cis]>
let me check the spec for that
<whitequark[cis]>
however
<jwise0[m]>
so 'yes, then yes, then maybe'
<whitequark[cis]>
there are also pull resistors
<whitequark[cis]>
and those are managed via I2C, and that's on the main I2C bus
<whitequark[cis]>
but the pull values are like 10k
<whitequark[cis]>
so you get 12V thru 10k and then an ESD diode and then on the main 3V3 I2C bus
<whitequark[cis]>
which I think doesn't do much
<galibert[m]>
And there's a genie that comes out and slap you if you're being really too stupid
<jwise0[m]>
ah, good. the closest I got in my IRC log search was
<galibert[m]>
I'm reading a stack overflow page that says hydrogen is way more slutty than helium and thus helium penetrates more while hydrogen reacts to something on the way
<whitequark[cis]>
... technically wouldn't the one that penetrates more be the more slutty one ...
<galibert[m]>
in chemistry, no :-)
twix has quit [Ping timeout: 264 seconds]
esden has quit [Ping timeout: 264 seconds]
Foxyloxy_ has quit [Ping timeout: 264 seconds]
cyrozap has quit [Ping timeout: 264 seconds]
puck has quit [Ping timeout: 264 seconds]
yuriks has quit [Ping timeout: 264 seconds]
esden_ is now known as esden
<whitequark[cis]>
I must have learned a very different chemistry in school then, all I had was romantic things like "bonding", none of this filth
<galibert[m]>
hydrogen goes everywhere and bonds to everything
<galibert[m]>
helium goes everywhere but doesn't care about anyone
yuriks has joined #glasgow
<whitequark[cis]>
anyway, I guess to summarize the earlier discussion, we would at some point need to decide whether we want only Ethernet on USB or have a generic USB protocol
<whitequark[cis]>
which makes it the difference between "1GBASE-T + USB Ethernet PHYs + sysECP5" and "1GBASE-T + FX3" as management approaches
<whitequark[cis]>
in either case we'll run smoltcp on some CPU in the system and have a bunch of bits routing TCP packets back and forth for management purposes
dirbaio[m] has joined #glasgow
<dirbaio[m]>
smoltcp <3
<whitequark[cis]>
dirbaio: back when I wrote it, glasgow revE was one of the intended uses
<whitequark[cis]>
IIRC
<dirbaio[m]>
🤯 wut
<whitequark[cis]>
sometimes my projects just take multiple years to really come together
<whitequark[cis]>
I have an entire series of overarching plans which tie all of the things I've built together in complicated ways
<whitequark[cis]>
some of these may take decades
<whitequark[cis]>
but, such is life
<galibert[m]>
Is rust any better than C at running on embedded/softcore environments?
<whitequark[cis]>
I would not use C with the FX2 if the FX2 wasn't so fantastically good it outweighed just about every other issue with the 8051
<galibert[m]>
(a 8051, drink)
<whitequark[cis]>
stack usage is similar to C or C++ (and depends on careful design, but as always) + you actually have tools to assess it, the stdlib is so much more suited to embedded environments it's not even funny (except for some bits which are less so, like the formatter that likes to pull in floating point stuff)
<whitequark[cis]>
you have things like subtract-with-overflow-flag built into the language
<whitequark[cis]>
or saturating-subtract
<whitequark[cis]>
and you have lots of quality-of-life things in the core library that make embedded development much more bearable
<galibert[m]>
that's tempting
<whitequark[cis]>
plus, there's this whole "safe code" deal. smoltcp doesn't have any unsafe code so you know it's not going to write all over your stuff if you fuck up
<whitequark[cis]>
which is less clear with lwIP
<whitequark[cis]>
(also it's just a better stack than lwIP)
<galibert[m]>
how good is rust at poking at ports are fixed addresses in memory in a non-mmu environment?
<galibert[m]>
s/are/at/
<whitequark[cis]>
the language gives you volatile_read and volatile_write as functions
<galibert[m]>
ok, that's nice, real nice
<whitequark[cis]>
how you wrap that into a higher level primitive is up to you. you can even use them unwrapped
<whitequark[cis]>
people make abstractions for registers, some of these are better, some are worse, they tend to be heavyweight in syntax and compile time
<whitequark[cis]>
but nothing stops you from going full-on C and just define a bunch of constants and use those two functions
<whitequark[cis]>
perfectly viable way to write a firmware in rust
<whitequark[cis]>
you should also check out dirbaio's "embassy"
<galibert[m]>
yeah, I'm thinking of the control programs I'm flinging at minerva in my toy designs
<whitequark[cis]>
you know how in embedded code you have to write all the state machines by hand for coroutines?
<whitequark[cis]>
well, now you can write them as sequential code
<whitequark[cis]>
(without weird standard-violating hacks people do to make coroutines in C)
<whitequark[cis]>
whitequark[cis]: (amusingly, i actually wrote the PR that introduced these functions; I don't think anyone seriously entertained the idea of embedded Rust before me, or at least if they did they didn't submit their code upstream)
<whitequark[cis]>
(many many years ago)
<tpw_rules>
it's so nice to have those as functions rather than variables
<tpw_rules>
cause that's what they are
<whitequark[cis]>
yep
<tpw_rules>
plus the barrier arguments
<j4cbo[m]>
i'm kinda amazed that lwIP hasn't been unseated
<galibert[m]>
yeah, volatile in C in misguided, it's the accesses that have the property, not the variables which pretty much don't exist in the first place
ar-jan has joined #glasgow
<galibert[m]>
Oh, an amusing thing: the ks0164 by samsung is a custom cpu used to do a wavetable synthesizer in a number of arcade games and in the Samsung Omniwave waveblaster card. The firmware in the waveblaster actually uses cooperative coroutines (coroutine id 1 is hardware voice management, 100 is midi recieve, 101 is midi send)
puck has joined #glasgow
<galibert[m]>
The code is amazing in a way. There's clearly no function call ABI, sometimes they pick up a value which is essentially to frames up in the stack, yet it's reasonably clean
<galibert[m]>
what they love to do also is to push registers on the stack and pop them at the end, but change on the stack some of them in the middle to use as return values