electronic_eel has quit [Ping timeout: 240 seconds]
electronic_eel has joined #glasgow
PyroPeter has quit [Ping timeout: 260 seconds]
PyroPeter_ is now known as PyroPeter
Stormwind_mobile has quit [Ping timeout: 260 seconds]
sambristow_nz[m] has quit [*.net *.split]
eddyb[legacy] has quit [*.net *.split]
varesa has quit [*.net *.split]
jpa- has quit [*.net *.split]
ender| has quit [*.net *.split]
Foxyloxy has quit [Ping timeout: 264 seconds]
Foxyloxy has joined #glasgow
sambristow_nz[m] has joined #glasgow
eddyb[legacy] has joined #glasgow
varesa has joined #glasgow
jpa- has joined #glasgow
ender| has joined #glasgow
varesa has quit [Max SendQ exceeded]
varesa has joined #glasgow
thaytan has quit [Ping timeout: 240 seconds]
thaytan has joined #glasgow
Stormwind_mobile has joined #glasgow
Stormwind_mobile has quit [Ping timeout: 256 seconds]
Getorix_ has joined #glasgow
Getorix has quit [Ping timeout: 244 seconds]
Stormwind_mobile has joined #glasgow
Getorix has joined #glasgow
Getorix_ has quit [Ping timeout: 240 seconds]
bvernoux has joined #glasgow
bvernoux has quit [Quit: Leaving]
<awygle>
Is the Rev D (or E?) plan still an FX3 to configure the ECP5?
<whitequark>
revE, and yes
<whitequark>
with an intermediate framebu^W configuration PSRAM
<whitequark>
this way, the FX3 can be booted from USB (the same way as FX2), and also, magic packet detection in GigE PHY can be used to trigger reconfiguration over Ethernet, which would make it essentially as unkillable as over USB
<whitequark>
the goal is to have complete certainty that, if you leave it in an office connected to a DUT and then COVID-19 happens and you don't visit it for months it would work all that time
<whitequark>
well, it wasn't originally phrased in terms of COVID-19 but you get the idea
<whitequark>
with the FX2 design you baaaasically get it, with the exception that in some cases the USB host can fuck its state up in a way unrepairable from software (this is rare, but occasionally you'd get the linux kernel panic when you reinsert xhci_hcd), which i can't do anything about, and also the fact that if you intentionally corrupt the boot EEPROM in an extremely specific way and then power cycle the
<whitequark>
board somehow it won't come back (which is why we have the testpoints near the EEPROM)
<whitequark>
this is not trivial. you'd have to read the FX2 manual and pick the combination of boot flags that would specifically do this. i don't think any CLI flow can leave your device unbootable. i guess we could add an EEPROM key protecting the boot flags in firmware to guard against semi-intentional corruption
<sorear>
assuming the kernel doesn't panic, you can't unfuck the USB host with a PCIe reset?
<whitequark>
sorear: you ca, but if it fucked itself up so badly that you need a PCIe reset, the chances are fairly good that the kernel will oops or hang or something
<whitequark>
*you can
<whitequark>
it doesn't happen *often*, but it does occasionally definitely happen
<whitequark>
i mean it's also not unusual to have xhci_hcd DMA into places where sun doesn't shine
<whitequark>
actually, i had the Alpine Ridge xhci_hcd thrash recently on my machine, and PCIe AER reported some ACS violations
<whitequark>
i have IOMMU on so that didn't really do anything, but i've seen people report that (presumably without IOMMU) it can and will write over something the kernel needed to work
<whitequark>
... now that you mention it, i wonder if IOMMU (which i've always had enabled on this laptop) is the reason i've never personally seen a fatal kernel fault as a result of xhci_hcd thrashing
<sorear>
this is starting to seem like a use case for watchdog timers
<whitequark>
i mean yes something as complex and fragile as x86+linux could use a watchdog timer if you expect it to be actually available
<whitequark>
for glasgow i think the current measures are basically good enough
<electronic_eel>
ouch, I think I found a bug
<electronic_eel>
I did schematic review of the current revC2 and compared it to revC1
<electronic_eel>
the problem is the interrupt line of the INA233. in current revC2 we use it to directly shut off vio
<electronic_eel>
but in revC1 the interrupt of the old adc is used for the voltage mirror mode, the interrupt triggers when the voltage goes out of a defined range
<electronic_eel>
the ina233 can do this too of course, but when the interrupt triggers it will now switch off vio instead of just notifying the fx2 to adjust the dac output
<electronic_eel>
I think we have two ways to solve this:
<electronic_eel>
1) remove the diode logic to directly switch off vio, just relying on the fx2 to always switch off vio
<electronic_eel>
2) add a switch that allows to select between direct vio off (for the modes with vio set and stuff like overcurrent limit) and just interrupt (for mirror mode)
<electronic_eel>
this would be a global switch for both ports, we could use the ice led / cdone io port as discussed earlier for this
<electronic_eel>
we could use a 74lvc1g66 little logic mux for it, it would go between the diode and the enable line
<electronic_eel>
whitequark: esden: any preferences?
<whitequark>
electronic_eel: "but in revC1 the interrupt of the old adc is used for the voltage mirror mode" i'm fairly sure this isn't the case?
<electronic_eel>
hmm, the way I read the firmware code for mirror mode, it sets up a window alert and once the voltage goes out of the window, it triggers the interrupt
<whitequark>
voltage mirror mode does exactly one measurement when you request it, then it sets up a ±10% range to make sure that you don't drive the target out of spec
<whitequark>
well
<electronic_eel>
the interrupt handler then adjusts the dac
<whitequark>
yeah but when the interrupt triggers it just turns off Vio
<whitequark>
this just sets every alerted port to 0V
<whitequark>
it definitely *could* work the way you are describing, but it currently isn't and i personally never planned for it to be that way
<whitequark>
(this is not to say anything about the behavior you are describing, just talking about the history of the feature)
<electronic_eel>
I think you are right and I misread the code
<whitequark>
so in abstract, something with Vsense and Vio/Vout could definitely do what you're mentioning here. but for Glasgow specifically I'm skeptical and here's why:
<whitequark>
how often do you encounter a single DUT that has its Vcc/Vio change dynamically over the course of its operation? in general, DUT Vcc/Glasgow Vio changes when you either (a) change DUT, or (b) ramp power up and down
<whitequark>
both of these cases would be fine with an alert alone and no tracking
<electronic_eel>
yes, duts that change their vio during operation do exist, but are rare
<whitequark>
on the other hand, Vsense is a high impedance input (I believe it's even higher impedance now without the filter of the discrete ADC, is that right?)
Stormwind_mobile has quit [Ping timeout: 265 seconds]
<whitequark>
so noise on it is to be expected, especially over long ribbon cables or stuff like that
<electronic_eel>
yes, it is higher impedance now, IIRC around 800K
<whitequark>
tracking that *noise* will range from "spurious undervoltage of DUT" (bad) and "overvoltage of DUT if you have a 3.3V DUT and a 5V noise spike" (extremely bad)
<electronic_eel>
oh, and it could create oscillations
<whitequark>
also true, good catch
<electronic_eel>
right, so live tracking is probably not a good idea
<whitequark>
looping Vio to Vsense is actually a pretty good design in most cases, since this lets you easily sense overload on revC1
<whitequark>
of course you can measure that directly on revC2
<awygle>
whitequark: is there an advantage to FX3 over e.g. FT600?
<whitequark>
awygle: yes. FX3 acts as a BMC
<electronic_eel>
so to sum it up: false alert, that part is fine in current revC2
<whitequark>
awygle: specifically it is responsible for board bringup in a way that does not involve FPGA gateware (other than a single "gold" design that basically connects the whateverMII to the FX3)
<whitequark>
my goal is to not have, by design, any sort of a flash with a precious FPGA bitstream that is critical to the board's functioning and would effectively brick it if erased
<whitequark>
whether over Ethernet or over USB
<awygle>
and that's not achievable with the FT600? if you're allowing a "gold" design seems like you'd be able to
<electronic_eel>
you could probably use another microcontroller that has a inbuilt bootloader that can be triggered via the ft600
<whitequark>
awygle: so the thing is that I treat all (user built) FPGA gateware as inherently suspect, and nonfunctional until proven otherwise
<whitequark>
electronic_eel is right, FT600 + different MCU would approach the robustness of the FX3 approach if done well
<whitequark>
but... FX3 isn't really that expensive, it fits the job perfectly, and best of all, it lets us do without drivers
<awygle>
mm, i see
<whitequark>
the idea is that revE is Ethernet-only (E for Ethernet, see? :P)
<whitequark>
so when you plug it in, it enumerates some sort of USB Ethernet encapsulation that works on the host
<whitequark>
it's a bit tricky to do in a cross-platform way, I'm not sure if NCM covers all bases yet. if it does, it'll just be NCM
<awygle>
"not really that expensive" is iffy imo, it's a ~10$ bom hike in low quantity. but i do take your point(s)
<whitequark>
revE isn't designed as an especially cheap device
<whitequark>
mind you, revC and revD are not something that will be made obsolete by revE
<awygle>
mhm, gotcha
<whitequark>
I expect most people will be quite happy with revCD
<electronic_eel>
the ft600 are like 7 bucks in low quantities - and you need another mcu on top of it
<awygle>
context - i was thinking about a design for a sensor platform because i have a bunch of things i want to sense and no good way to sense them, and was thinking about the glasgow reconfigurability as a desireable feature for such a thing
<whitequark>
honestly, I think the $10 BOM hike is more than worth the ability to run without drivers
<electronic_eel>
also ftdi has a tendency for having silicon bugs and not acking or fixing them. the cypress fx2 design on the other hand is old, but really nice
<whitequark>
I also feel like having unbrickability rest on uh... being able to fiddle with FT600 GPIOs to bitbang serial programming of some bog standard MCU, is not a good design
<awygle>
yeah, i getcha
<awygle>
breaking news - engineering design consists of tradeoffs
<awygle>
:p
<whitequark>
last but not least I do not want to give FTDI any design wins because they still basically think that the only downside of punishing customers owning counterfeit FTDI chips is that you might get bad publicity
<awygle>
def. copy there
<whitequark>
they do not deserve design wins. they deserve bankruptcy, or at the very least being cut off from normal windows update release streams
<whitequark>
electronic_eel: that's absolutely true, but everyone i talked to insists that FT600 is very good silicon
<whitequark>
so i think it would not factor into decisions here
<electronic_eel>
ok
<whitequark>
"why not FT600" is basically the first question I get from anyone looking into revE design :p
<hl>
whitequark: re: IOMMUs: do you ever use Asmedia USB host controllers (whether onboard or add-in)?
<whitequark>
hl: not knowingly
<awygle>
setting aside the (valid) moral reasons, you could probably(?) hook the bottom 8 bits of the ft600 FIFO to the "slave parallel interface" config method of the ECP5
<electronic_eel>
we could lower the bom of revE if we decided to just do fast data transfer over ethernet and have just lowish speed and unbrickable config over usb
<hl>
whitequark: could be worth checking. Asmedia USB host controllers are known have bugs which cause them to generate bad DMA requests (if you have no IOMMU, have fun with silent memory corruption)
<whitequark>
awygle: that leaves open the question of reconfiguring the FPGA over GigE
<electronic_eel>
but I'm not sure it is worth it
<awygle>
whitequark: true
<whitequark>
hl: worth checking... why? did i ever complain that my system runs too well? :p
<hl>
whitequark: oh I'm just saying, avoid knowingly putting one in a system with no IOMMU enabled
<whitequark>
oh. oh checking in that sense. yeah
<hl>
(this is Fun(TM) because supposedly Asmedia is the only game in town for USB3.2. \w/)
<whitequark>
electronic_eel: i feel like GigE should have reasonable feature parity with USB here
<awygle>
i think if i was gonna go that way i'd do unbrickable usb2 and 10GbE
<whitequark>
in revE, USB, while it is certainly (and somewhat unfortunately) still 3x or so faster than GigE, is a secondary port that exists basically because (and here comes my response to awygle) laptops are everywhere
<electronic_eel>
I'd prefer a SFP+ cage to fixed 1Gbase-T, so the user can plug in a GigE-module, a 10GbE DAC or fiber module
<whitequark>
480 Mbps both directions is unfortunate, but the general unfortunateness of USB2 is even more unfortunate
<whitequark>
but the worst thing is 10GbE on a laptop
<awygle>
yeah i get why you have it that way as opposed to like, PoE or 10 GbE or whatever
<whitequark>
(a) you need Thunderbolt ($), (b) you need a Thunderbolt PCIe dock ($$), (c) you need a 10GbE card ($$$)
<whitequark>
i still don't have a 10GbE setup because the cards are so goddamn expensive. I don't have $120 or so I can just drop on a card that I don't even have anything to plug in
<whitequark>
or a router that would take it
<hl>
Is there somewhere I can read about the RevE plan?
<awygle>
idk if my laptop (or most laptops) could crunch 5 Gbps or 10 Gbps of data
<whitequark>
hl: it's all verbal (well, in the sense of being discussed on this IRC)
<whitequark>
awygle: IPoTB on XPS13 does in fact deliver 10 Gbps
<electronic_eel>
the nice thing about the sfp+ cage is that the user can easily plug in what fits their setup best
<hl>
ah okay. How is GigE attached to the board, block diagram wise?
<awygle>
whitequark: not talking about the i/o, more the cpu (since it would, uh, melt due to Very Bad Cooling)
<electronic_eel>
sfp modules for 1Gbase-T are cheap
<whitequark>
awygle: depends on what you're doing. like, consider that revC can process 30 MB/s in idiomatic Python, assuming you're not doing anything more complicated with it than "get from one socket, put into another or on disk or whatever"
<whitequark>
if you're streaming LA samples or something i can absolutely see your laptop doing fine, you could probably trigger just fine on that much data with judicious use of SIMD
<awygle>
whitequark: sure but 10GbE is ~50 times more data
<whitequark>
awygle: you can parse 20 Gbps of JSON on commodity Intel hardware
<whitequark>
and i bet most things you would want to do are easier to squish into SIMD than "parsing hierarchical Unicode text"
<awygle>
<3 simdjson. would love to know _which_ skylake
<electronic_eel>
the extended data analysis stuff azonenberg is currently doing with his glscopeclient requires some beefy machine when you want to decode 10 Gbps data
<awygle>
but yeah ok i'm probably underrating the hardware
<awygle>
isn't zonenberg's stuff mostly on the gpu?
<hl>
like, is the GigE PHY connected to the ECP5 via RGMII, or is there some path to the FX3? I'm assuming you can't bootstrap via GigE?
<whitequark>
i mean nothing stops you from triggering on GPU
<electronic_eel>
he is moving more and more into the gpu, but you still need tons of ram and cpu cores
<whitequark>
hl: GigE <-> FPGA <-> FX3. you are correct that there can be no bootstrap via GigE, which seems immaterial
<hl>
whitequark: yep that's fine, just checking
<whitequark>
(the boards would ship bootstrapped anyhow)
<awygle>
sure, zonenberg and "low end" don't go together :p
<hl>
whitequark: I assume there is no power loss persistence of bitstreams? So USB is basically always necessary?
<hl>
whitequark: Or can the FX3 bootstrap without host intervention from its attached nonvolatile stores?
<electronic_eel>
I gues there will be some eeproms or spi flash to keep the golden gateware
<whitequark>
latter, just like FX2 can
<hl>
right, makes sense
<whitequark>
yes, there would be a flash dedicated to FX3 itself and not under any influence of user bitstreams
<awygle>
speaking of power loss, is the usb power delivery gonna be the whole of it?
<electronic_eel>
hmm, we could design in a whole small programmable lab psu if we wanted
<hl>
electronic_eel: and this is how you get scope creep /s
<electronic_eel>
exactly
<whitequark>
hl: awygle: given current trends I believe a type-C only design with PD, plus, assuming there isn't anything I'm seriously overlooking, PoE (probably in the format of a prefab module) fits just fine there
<awygle>
mk. i was just worried on account of laptops being a specifically called out use case. not sure how much power my laptop can supply over usb, even with PD
<whitequark>
I mean, USB 3 microB is an abomination
<hl>
whitequark: Will it be possible to update bitstreams over GigE if you're willing to risk the need for USB recovery? (I guess this would require awkward hairpinning through the ECP5)
<electronic_eel>
hmm, is PoE really necessary? the modules are costly and I'm not sure that PoE is really that much of an advandtage for the usecase of Glasgow. Why not just a dc jack for the ethernet only case?
<whitequark>
awygle: the base board itself should draw so little that any USB port could power it, even an USB 2 port
<awygle>
(and speaking of evil isn't pd Very Evil Intel Nonsense or something as well?)
<whitequark>
FX3 is ~100 mW, ECP5 is ~2 W, if i don't misremember anything
<whitequark>
hm
<d1b2>
<daveshah> will there be any DDR3 or anything?
<d1b2>
<daveshah> otherwise 2W for an ECP5 seems reasonable
<whitequark>
okay, FX3 is more like 400 mW I think
<electronic_eel>
some fast ram would be nice for buffering la samples or emulating memories
<miek>
the PD spec is open and seems fine to me
<whitequark>
I think we just barely fit into the power envelope of USB2 but we very easily fit into the power envelope of USB3 (without PD)
<whitequark>
can draw 4.5 W from USB3
<miek>
old-PD was wild, FSK on the VBUS line or something
<whitequark>
miek: yeah, at 23.2 MHz iirc
<whitequark>
awygle: PD is Evil Intel Nonsense although not in the legal sense, it is just profoundly badly designed
<whitequark>
so... exactly like the rest of USB, which we already take as a hit to sanity to enable people with laptops to use the device
<hl>
...and then we have USB4
<awygle>
arright, I was thinking of thunderbolt then probably
<whitequark>
fortunately since revE would always be a PD sink and it has only a single port, all we'd really have to tolerate is obnoxious/noncompliant host behavior, which isn't really *that* bad
<hl>
Will RevE have to speak PD?
<whitequark>
awygle: Thunderbolt is much more open since USB4 became a thing
<whitequark>
they kind of retroactively opened the spec in the form of a diff from USB4
<awygle>
that's genuinely amusing
<hl>
...are there Thunderbolt docs published now I haven't seen? I've only seen the USB4 spec.
<whitequark>
I *think* it is technically possible now to implement a compliant TBT3 controller using just the public docs
<whitequark>
hl: the latest USB4 spec should have a bunch of sections where they explain how TBT3 differs from it
<hl>
Aah.
<whitequark>
the first release of it did not
<whitequark>
I assume they had to negotiate some patent rights or some crap like that
<whitequark>
whichever was the reason it was so heavily guarded in first place
<whitequark>
I assumed it was so strictly controlled for compliance reasons, since you could only possibly certify designs that match Intel's reference designs exactly (well you can do your own layout, but you have to use even exact same passives... wtf?)
<whitequark>
but... guess not? I don't know, it's baffling
<whitequark>
maybe they just stopped caring whether the usual suspects will flood the market with cheap noncompliant chips
<whitequark>
hl: revE would have to speak PD yes. I think a soft modem could be implemented just fine on FX3
<hl>
whitequark: huh, interesting
<whitequark>
PD2/3 are amazingly obnoxious, they removed the radio modulator from the PHY but they didn't remove the rest of the radio bits
<hl>
whitequark: over USB-C CC1/CC2? How would USB3 Type-A host to USB-C work?
<whitequark>
so it still goes through the scrambler and 4b5b encoder and has a preamble and everything
<whitequark>
it technically sort of *has* to be DC balanced because the *DC level* on the CC pin is actually significant at the same time as the digital PD signaling
<whitequark>
so everything that senses the DC level on the CC pin has to use a special filter that carefully removes all digital comms
<hl>
whitequark: ...why does it always feel like the people designing USB don't really care how good of a job they do
<whitequark>
it's amusing, there is an elaborate TI appnote that explains exactly how you would design such a filter
analprolapse has quit [Read error: Connection reset by peer]
<whitequark>
it is written by the guy who is credited for this part of the specification
analprolapse has joined #glasgow
<whitequark>
it probably went along the lines of "hey, you designed that clusterfuck? now it's your job to explain our customers how they can get it to function"
<TiltMeSenpai>
hl: USB-C spec specifies that in an A to C cable, CC1 should be pulled high via a resistor (56k I think?)
<whitequark>
yeah that's where the DC offset comes from
<whitequark>
what's wild is that the DC offset on the CC pin actually varies depending on the device role
<whitequark>
so it shifts up and down a bit such that sinks and sources have different DC offsets
<whitequark>
this is also why the 300 kbps CC channel has a normative eye diagram specified with 12 points
<TiltMeSenpai>
yikes
<whitequark>
for comparison, 5 GT/s PCIe somehow lives with four.
<TiltMeSenpai>
is there a reason for not just using a stusb4500 or something?
<whitequark>
(well, it lives with four because it was designed by reasonable people and it doesn't use the DC offset for anything meaningful...)
<whitequark>
daveshah: i agree with electronic_eel that some kind of DDR would be very helpful for LA-type applications
<whitequark>
or for flash emulators, or other stuff like that
<whitequark>
i think revE has to have some onboard DDR. LPDDR maybe? not my strong area
<d1b2>
<daveshah> flash emulators are a bit of an icky case because of worst-case latencies
<whitequark>
well yes but you can split the DRAM in half and alternate banks while queueing outstanding writes
<d1b2>
<daveshah> I would probably go DDR3 as it is the most tried-and-tested but decent performance
<d1b2>
<daveshah> yeah
<whitequark>
it would be kind of icky if we had a restriction like "welp you cannot use DDR3 on USB2 upstream ports" but honestly i think it's almost reasonable
<whitequark>
there is a clear cause for it, it won't be a problem for most people, and DDR3 isn't critical to every function of the device
<whitequark>
the board management MCU would have to explicitly manage the power envelope of the board anyway
<whitequark>
or you'd (a) violate the USB spec, (b) brown out every rpi you plug this in
<d1b2>
<daveshah> particularly at lower frequencies with the right termination settings, DDR3 doesn't actually use that much power
<d1b2>
<daveshah> but that might still push the overall board power envelope over 0.5W
<whitequark>
0.5? typo?
<d1b2>
<daveshah> 2.5W
<d1b2>
<daveshah> 0.5A
<d1b2>
<daveshah> oops
<electronic_eel>
the whole power thing is why I suggest to add an extra dc jack where you can plug in a common 12v ac adapter
<whitequark>
it's easier to communicate "no DDR3 on USB2 ports" than "keep DDR3 under this Fmax on USB2 ports"
<d1b2>
<daveshah> true
<whitequark>
(it's not like you can't just disable the safety if you really want)
<whitequark>
electronic_eel: it obviously must have a barrel jack
<electronic_eel>
yes
<whitequark>
having to use a type-C PD charger every time you deploy the board connected via GigE would have been amazingly obnoxious
<electronic_eel>
there are nice ones available where you can plug in 2.1mm and 2.5mm ones, so both common standards are served
<whitequark>
yup. honestly, could also do a screw terminal or something along these lines
<whitequark>
can probably make it take "up to 48V nominal, any polarity, both dc and ac work"
<d1b2>
<daveshah> Just don't forget the reverse polarity protection (and ideally some kind of overvoltage protection too, even if just a crowbar)
<d1b2>
<daveshah> any polarity is even nicer
<whitequark>
i mean it's just a bridge rectifier
<TiltMeSenpai>
I think if you do PoE, you get that for free
<d1b2>
<daveshah> have to be careful with grounds and bridge rectifiers though
<whitequark>
oh, yeah
<whitequark>
could do half-bridge then?
<electronic_eel>
just a protection diode should be enough
<electronic_eel>
the user will figure out that something is wrong and switch polarity
<TiltMeSenpai>
electronic_eel: I think if it's a barrel jack, that doesn't work
<whitequark>
that's not a bad solution, though i would normally push for something nicer
<whitequark>
yeah, there are center negative barrel jacks
<whitequark>
which... would actually cause the grounding issue daveshah is talking about
<whitequark>
if i used a half-bridge
<awygle>
i am increasingly of the opinion that DDR2 is the sweet spot for hobbyist DRAM, personally
<electronic_eel>
TiltMeSenpai: there are a lot of ac adapters available with a selection of common output connectors you can plug in. ususally you can turn them to switch polarity
<whitequark>
i think we can figure this out when time comes for it
<hl>
>As someone who been to USB-IF committee back around 2006
<hl>
>There are some smart people there, unfortunately some are old-timer in large orgs - they were pushed there "to do least harm".
<hl>
>Didn't care less about how bad some of the proposals were, as long as they were according to the required format.
<hl>
>We tried to fight a bit, but it was a lost cause :\
<whitequark>
electronic_eel's suggestion is quite reasonable
<whitequark>
awygle: i have ~zero insight on DRAM so i'll have to rely on other project members to do that i think
<whitequark>
not much of an opinion either besides "we should have a gig of DRAM or so"
<TiltMeSenpai>
with the external dc power, would it be possible to add explicit ground points? maybe like the mounting holes or something
<TiltMeSenpai>
not as a primary mechanism but a "just to be sure" backup
<whitequark>
oh sure, revC has them of course
<TiltMeSenpai>
nice
<awygle>
i was mostly indirectly commenting at daveshah
<whitequark>
tbh i'm *somewhat* partial to "feed whichever input is plugged in to a PoE module, it's fully isolated, it can just do the right thing"
<whitequark>
but... it's true that PoE modules are very expensive
<d1b2>
<daveshah> The only risk with DDR2 is obsolescence as time goes on
<whitequark>
can one do DDR2/DDR3 assembly variants?
<awygle>
that is true, but folks are still using SDRAM which i'd think has the same issue
<awygle>
BOM variants seems tricky unless you have enough pins to fully route both. i'd have to check but i doubt they're footprint compatible.
<d1b2>
<daveshah> No, I don't think they are pin compatible (but I may be wrong, I don't know all the package variants)
<awygle>
you could try to do some shenans with resistors or something but then you risk SI issues
<d1b2>
<daveshah> 1Gbyte or 1Gbit of DDR @whitequark ?
<whitequark>
TiltMeSenpai: STUSB4500 is a bit simplistic; for example it doesn't seem to have a way to detect "up to 100 mA allowed" and "up to 500 mA allowed", which would be quite nice to have
<TiltMeSenpai>
ah, true
<whitequark>
it is also true that implementing all the power routing logic in FX3 ourselves is not easy, or easy to get right
<whitequark>
i also have a particular dislike of USB PD chips that have an MCU hidden inside which the vendor pretends does not exist
<hl>
oh god yes
<whitequark>
not sure if STUSB4500 has one, leaning towards "yes"
<TiltMeSenpai>
I was thinking mostly from the perspective of "nobody actually follows the USB PD spec"
<hl>
pay no attention to the man behind the curtain
<whitequark>
i know TPS65982 does and i've seen that code and it is bad
<TiltMeSenpai>
so by using a dedicated part, there's a better chance that it's been tested with a variety of chargers
<TiltMeSenpai>
in practice, this isn't true but
<TiltMeSenpai>
one can dream
<whitequark>
and the only way to get the CSP for it is to have a volume order with TI (iirc that was the response)
<whitequark>
so you're stuck with some M3 running 100 kB of shoddily written C you can't even read
<hl>
could you write your own firmware for it?
<whitequark>
well yes, it doesn't have anything like signature checking
<awygle>
yakkity yak
<whitequark>
but you don't get the docs without a high volume order with TI
<hl>
fffff
<electronic_eel>
by then you are far better of doing it yourselves on a documented mcu
<whitequark>
fun fact, TI has a configuration tool that it suggests everyone use to configure the MCU. literally no TPS65982/3 i've seen in the wild was provisioned with that tool
<awygle>
brb writing rust pd controller firmware
<hl>
any decent user-programmable MCUs which happen to have PD peripherals?
<whitequark>
every single vendor (Dell, Apple, Sonnet, some random one I forget) has extracted the sources from TI and rebuilt them
<hl>
...hah
<whitequark>
well, s/Dell/Compal/
<electronic_eel>
the stm32g series has pd peripherals
<whitequark>
hl: if at all possible i'd prefer to keep it down to a single MCU
<hl>
whitequark: yeah, deffo
<whitequark>
what do MCUs bring? that is right. they bring very of cheap at the cost of lot of pain
<awygle>
that feels like a reference I didn't get lol
<hl>
MCUs are painful?
<whitequark>
you can kinda bitbang PD but it's awful. you can use a PD controller with an integrated MCU and it's awful. you can use a PD controller based on hard logic (they exist) but, as you'd expect, those are limited...
<whitequark>
awygle: nop, i just felt like phrasing it that way
<whitequark>
hl: well, you have firmware, and you need to ship it, and you need to debug it, and with multiple MCUs you end up having to debug state machines where the state boils down to "every variable and stack slot the thing has"
<hl>
whitequark: ah
<awygle>
software is the most painful thing
<whitequark>
if you have a single MCU you can at least make sure it's the first thing that boots and that nothing on the board happens without its direct control
<whitequark>
if you have two MCUs honestly all bets are off
<whitequark>
will there be race conditions between the FX3 and the PD controller MCU? of course there will. how will you handle them? badly, because you can't predict them or test them without the CSP for the PD controller
<electronic_eel>
I think that part isn't that difficult. but you have to keep 2 toolchains and fiddle with their bugs and limitations
<whitequark>
i mean you could just pick a second ARM chip for that.
<whitequark>
fx3 is ARM9 sadly (i would have much preferred Cortex)
<electronic_eel>
ok, just one toolchain, but still two hardware libraries for their different peripherals
<whitequark>
yeah. and judging by what i found, i'm going to have to write a "libfx3" as well
<awygle>
ouroboros, use the ft600 and you're back to one mcu :-P
<miek>
a few years ago i was working on a product with a TI gas gauge chip and was trying to implement the programming algorithm, to burn in the battery characteristics. unfortunately TI's docs were terrible and any screw-up would brick the chip. i ended up finding better docs in someone's defcon talk about reversing the hidden mcu, and did a bit more reversing to finally get it all working...
<awygle>
(I'll shut up now)
<whitequark>
miek: this sounds suspiciously similar to other TI gas gauge chip experiences i've listened to
<whitequark>
awygle: besides being driverless, the other nice thing about FX3 is that it doesn't need any dedicated Ethernet routing (well besides an alert pin)
<whitequark>
it can just configure the FPGA to connect the ?MII to the FIFO and then it can run smoltcp and grab the new firmware that way
<whitequark>
19:17 < hl> whitequark: Will it be possible to update bitstreams over GigE if you're willing to risk the need for USB recovery? (I guess this would require awkward hairpinning through the ECP5)
<whitequark>
it will be possible and routine to update bitstreams over GigE. normally the firmware should just route every packet it doesn't recognize to the FX3
<hl>
aah
<whitequark>
so everything except for the actual applet TCP streams would be handled on the FX3
<whitequark>
whether with USB or with GigE link
<whitequark>
or both, i mean, you could get 4 Gbps of bandwidth that way. probably.
<whitequark>
the only thing that's actually a problem here is a case where you upload gateware but it doesn't work
<whitequark>
which... shouldn't really be common, but it will certainly happen
<hl>
I mean
<hl>
you could always just attach the glasgow to some SBC and run USB-IP for remote access >:D
<hl>
(i literally did this, though not with a glasgow)
<whitequark>
so in that case what you do is send a magic ping packet to the GigE port, which trips up comparators inside of the PHY
<whitequark>
I was looking at a particular TI PHY which lets you configure a ridiculously long compare string for WoL, *64 bytes* of arbitrary data. DP83867
<hl>
whitequark: .......did you seriously take advantage of WoL functionality in a PHY to wire a 'restore to golden gateware' GPIO to the FX3? because if so, that's inspired
<whitequark>
haha :D thanks and yeah indeed i did
<hl>
2020 and someone actually found a use for all that WoL vendors still meticulously put in their PHYs in a world of server BMCs
<whitequark>
lmao i mean it's there and it's common so i'm not even tied to a single vendor
<hl>
nice
<whitequark>
and since it doesn't have to be an actual WoL packet, i can send it via IP just fine
* kc8apf
uses WoL routinely...
<gruetzkopf>
used 10GE cards got ridiculously cheap
<awygle>
isn't it the explicit goal of your employer to murder the server BMC tho kc8apf
<whitequark>
so as long as the device didn't botch itself so long ago that all of the ARP entries have expired (this seems unlikely)
<gruetzkopf>
i recently paid 21€ for a dualport QLogic one
<whitequark>
you should be able to trip it with an UDP packet (or even a TCP SYN if you'd so like) over the internet
<kc8apf>
awygle: kinda sorta. Doesn't do anything to help with wanting wake my workstation from my laptop on the otgher end of the house
<awygle>
fair nough :p i'm almost to your podcast episode btw
<whitequark>
hl: tbh, i would probably not wire it to a GPIO. unless there's an unforeseen issue with that, i would wire it straight to FX3's reset pin
<hl>
ah interesting
<whitequark>
the FX3 knows that it's been reset via the pin, so it can pick up a few bits of state (like the IP it got and stuff) and start over with anything else
<whitequark>
so maybe the FX3 got stuck in a loop because an I2C bus somewhere on the board fucked itself over. doesn't matter. this just resets the entire board
<whitequark>
hell, you could even upload not-necessarily-known-good FX3 firmware over the net this way if you really wanted, though the reason to do so elides me
<awygle>
think you probably meant eludes?
<whitequark>
awygle: oh. yeah
<whitequark>
(i guess you could update the FX3's firmware in SRAM and then do it in the Flash once you know the new one works?)
<whitequark>
(esoteric but not entirely pointless)
<whitequark>
(troll suggestion: configure WoL interrupt as level and wire it to a FET powering the entire board. there's only one way to be sure, etc)
<whitequark>
anyway. the one tricky part with this plan is that you really don't want just anyone to be able to trip this. beyond the obvious "only consider packets on the same LAN segment" and "tunnel it in something secure" suggestions i can only think of using some sort of replay protected HMAC scheme, which somewhat negates the reliability advantage just gained with all the hardwiring
<whitequark>
but i guess the people who give a revE a publicly routable IP for some reason are probably just fine with that
<d1b2>
<daveshah> Letting users set their own 'key' seems like a reasonable compromise
<whitequark>
the problem is really replay
<whitequark>
hm
<whitequark>
i guess it's the same problem as the control socket
<whitequark>
just noninteractive
<d1b2>
<daveshah> yeah
<whitequark>
so a choice between "no authentication, this is a trusted network, you never lose control" and "HMAC with rollover, you're fine with everyone seeing cleartext but not controlling your equipment, you can lose control if you lose the key or have some sync issue" seems totally reasonable
<whitequark>
hm. no. that's useless. if you can see cleartext and inject packets you can just hijack the TCP stream
<electronic_eel>
I don't think it is reasonable to do all kinds of tls or ssh on glasgow, so only trusted networks
<whitequark>
electronic_eel: hypothetically, you could authenticate but not encrypt the control socket
<electronic_eel>
but then you get the tcp hijack problem
<whitequark>
yeah, so since the control packets are authenticated, you can't inject an arbitrary one, and since they're replay protected, you can't, well, replay
<whitequark>
practically, this means rolling our own extremely weird crypto when we could spend time on literally anything else instead and it'd be more useful
<electronic_eel>
yeah, just put a small firewall in front and you are done. you could hang the glasgow off usb on a raspi and use ssh if you want a small+cheap and secure setup
<whitequark>
yep. a long time ago (when i first came up with the WoL scheme) i thought the HMAC thing will work, but it's obviously completely broken under any realistic threat model, so the only reasonable choice is to punt on it
<electronic_eel>
the phy would need to have a store for several valid WoL magic packets and some logic to remove one once it was used. then you could do rolling code
<electronic_eel>
but in the end there will be too much complexity involved, so the probability of something going wrong would be too high for my liking
<whitequark>
electronic_eel: i mean, you can live with one match
<whitequark>
increment the nonce each time the board reboots. you'd have to flash it somewhere, too
<whitequark>
this is dumb. instead the pattern should just be the device serial with some framing, and anyone exposing the board anywhere has no false hope that it will be secure in any way
<whitequark>
which also matches how USB works
<electronic_eel>
since the software doesn't know how often the board was rebooted (e.g. by power faults or something), it would have to send several. an attacker could block them and read them, so get the next codes and misuse them
<whitequark>
electronic_eel: agh. you're right. so the scheme is even worse than i initially thought!
<electronic_eel>
no hope of securing this without hard crypto
<whitequark>
yup. and that's just not our job.
<electronic_eel>
exactly. securing the transport is something better left to tools that are better at this
<TiltMeSenpai>
god I don't even want to think of what an fpga-driven tls implementation would look like
<whitequark>
TiltMeSenpai: oh just ask azonenberg
<TiltMeSenpai>
wait did he really
<TiltMeSenpai>
*runs*
<whitequark>
i think it is planned
<whitequark>
i'm not sure if it's full TLS. i would hope not
<whitequark>
but... dunno, can't really put that beyond him :p
<electronic_eel>
for what project does he plan it?
<TiltMeSenpai>
if anyone could do it, I have more faith in him than most
<whitequark>
electronic_eel: no idea. i assume something with eye-watering scope and equally eye-watering price
<electronic_eel>
I thought the scopes and logic analyzers he is working on right now are designed to be used on a secure net
<whitequark>
no, i meant, scope as in "project scope"
<electronic_eel>
ah
<electronic_eel>
he plans to put 40gbe into his logic analyzer. the fpgas needed to crypt that kind of traffic would have to be really huge
<whitequark>
it's funny, glasgow was inspired in part by his STARSHIPRAIDER (which i think still doesn't really exist?) and he was basically completely uninterested in it because it's too USB + too slow
<awygle>
afaik you are correct re: SSR
<whitequark>
which is strictly speaking valid criticism on both counts. yet here we are, with it having more popularity than i know how to deal with
<awygle>
oh no whitequark, you're unix :p
<whitequark>
awygle: hrm
<whitequark>
first of all how dare you,
<electronic_eel>
he also prefers to use system verilog, which is only available in closed source toolchains. so the whole "synthezise on the go" thing won't work
<whitequark>
awygle: second, i think that's not the right comparison. *USB* is unix. i'm just like... running on unix, trying to make best of its madness
<awygle>
i was just trollin'. something something worse is better
<whitequark>
yeah, i figured
<whitequark>
i just think it doesn't actually match that pattern
<whitequark>
"worse is better" glasgow would use an USB bootloader on the FPGA, Vio connected directly to FPGA IO banks through some passives for 5V tolerance, and also explicitly support some common cheap devboard which doesn't even feature ESD diodes
<awygle>
mhm
<awygle>
i can't actually imagine you signing up to a worse is better project tbh
<whitequark>
i actually think that device has a right to exist, and it would be far more popular than glasgow can be due to its rock bottom cost and the "you probably already have that devboard sitting uselessly" appeal
<whitequark>
but i would not be the one who makes it :p
<whitequark>
awygle: ironically, this is actually what i was *trying* to make when i first started the project. some $5 thingy with castellated pins you could order in bulk on jlcpcb and then just leave anywhere you need a debug interface
<awygle>
i remember
<awygle>
i was there :p
<electronic_eel>
how would a "worse is better" project handle level shifing? just 3v3 and nothing else? or direction sensing shifters with all their fun?
<whitequark>
then i looked at USB FS and FPGA USB bootloaders (remember, this is before nextpnr, you frequently had to run arachne a few times until it happened to use a lucky seed) and just kinda went "ok screw this"
<whitequark>
electronic_eel: the "worse is better" solution is to use FPGA IO banks directly
<whitequark>
they can be powered from 1.2V to 3.3V
<awygle>
ironically i think revs A and B would have been much more useful if we'd done that lol
<electronic_eel>
ok, no 5v, so just modern stuff
<whitequark>
i'm actually not sure if 5V would kill them or if they just weren't specified at that voltage
<awygle>
auto-direction shfiters - never again
<miek>
it would be neat to have that device as a cheaper embeddable thing to use after developing an applet on a "full" glasgow
<whitequark>
i suspect it's the latter and if you *really* went all in on the principle you could just yolo it with 5v
<TiltMeSenpai>
Lattice devices are pretty durable from what I've heard
<whitequark>
i vaguely remember that ice40 fpgas tolerate 3.3v on *vcore*, which is like 3 times the rated voltage
<whitequark>
actually not vaguely, we swapped vregs on revC0
<awygle>
people keep trying to get me to run lattice devices _wildly_ out of spec
<electronic_eel>
hmm, I haven't played with the ice40s, but for example the stm32 burn at about 4.5
<whitequark>
hrm
<whitequark>
define burn
<awygle>
like "oh don't worry, you can do SGMII with the ECP5 i/o pins, never mind that it's more than 50% over the rated speed"
<electronic_eel>
burn = permanently die
<TiltMeSenpai>
how do you even get pnr to do that
<whitequark>
electronic_eel: i wonder if it's breakdown or electromigration or something else
<TiltMeSenpai>
is there a flag that says "warn but don't fail if this is out of spec"
<awygle>
ignore it when it tells you you've failed timing lol
<whitequark>
TiltMeSenpai: yes
<TiltMeSenpai>
oh, it still outputs a bitstream?
<awygle>
yup
<TiltMeSenpai>
rofl
<whitequark>
in fact this was the default mode of nextpnr until i discovered this fact and insisted that it should be an error by default
<electronic_eel>
I guess you could get away with using it at 4v and adding some resistors. most 5v duts will accept 4v
<whitequark>
electronic_eel: mostly wondering because i want to try 5v vio but i don't have any ice40 devboards i want to kill
<whitequark>
breakdown would probably be noticeable if i limited the current
<whitequark>
on the i/v curve
<whitequark>
miek: you... can basically do this today
<whitequark>
most glasgow applets are controlled solely through a bidirectional byte stream
<whitequark>
it takes almost no effort to build a subtarget outside of the glasgow framework
<whitequark>
and just zero effort to connect an applet interface to a lower that supports .read(), .write(), and .flush()
<whitequark>
i have a friend who did this as her first glasgow-related project *and* first fpga-related project, and i don't recall hearing any questions
<electronic_eel>
I guess having an fx2 on the embedded thing would make it easier
<whitequark>
electronic_eel: would it?
<electronic_eel>
you'd have to figure out another way to do fast usb transfers otherwise
<whitequark>
the only thing it would directly simplify is the stuff that's currently done through I2C, which is handling pull resistors and slow sidebands
<whitequark>
sidebands in every applet that still has them managed via I2C should be refactored so that it happens through the main pipe
<whitequark>
I2C sidebands just... present nothing but problems
<whitequark>
was a stupid idea
<electronic_eel>
sidebands managed via i2c? can you give an example?
<whitequark>
pulls are actually managed by the applet itself, not the subtarget interface, so they actually don't matter
<whitequark>
oh sure
<whitequark>
JTAG TRST#
<whitequark>
er
<whitequark>
i think i already refactored that one
<whitequark>
fine, iCE40 SPI SRAM programming RESET# and CDONE# pins
<electronic_eel>
so how does it work? the gateware begins to do i2c transactions on the internal i2c?
<whitequark>
ha, no
<whitequark>
i just send a control transfer to FX2
<whitequark>
which flips a bit in the FPGA's I2C target
<whitequark>
how is this synchronized with normal USB bulk data? i am glad you asked. it is not
<electronic_eel>
ok, that seems much more sensible than my first thought of multimaster i2c. but timing is obviously a problem
<whitequark>
so e.g. after the FPGA is taken out of reset the applet does this silly dance of flushing the entire buffer stack by basically pinging the gateware. it creates a happens-before relationship
<whitequark>
it is slow, awkward to program, awkward to use, and error prone
<whitequark>
the only reason it is done that way is that when implementing the first sideband in glasgow, i did not use my brain. then everyone just copied it
<whitequark>
what should happen instead is that the SPI has a SET_SIDEBAND and GET_SIDEBAND commands that are basically GPIOs but less flexible (since most of the time you don't actually need configurable direction and stuff)
<whitequark>
*the SPI subtarget
<whitequark>
it *already* has a command that waits a preset number of cycles, since some of the SPI-derived applets (EPD, I think?) are timing-sensitive
<whitequark>
ironically the EPD applet does still use I2C sidebands and it uses even worse timing hacks and it's a small miracle it works at all
<whitequark>
it just uses in-band delays for commands
<whitequark>
miek: right. bottom line: "taking glasgow out of the glasgow applet", basically just grafting the glasgow subtarget to the glasgow uart, is already very practical, which is not surprising because i intentionally designed it that way. in the future, once the nmigen stream abstraction lands, it would be as easy as connecting the nmigen-stdio's UART's rx and tx pipes to the applet's in and out pipes
<whitequark>
but i mean that's just 2 lines instead of 6 :p
<electronic_eel>
but then you'd talk serdes+sideband to the fpga over some uart you have to provide, correct?
<whitequark>
sure. doesn't have to be uart. could be a (gasp) FT232's parallel bus
<miek>
cool, thanks for the explanation. i'll have to try it out
<electronic_eel>
yeah, that is the point where I'd prefer a fx2
<whitequark>
there's nothing *specifically* stopping you from using an FX2 for that, but then you have to write firmware, mess with libusb or cdc-acm, and so on
<whitequark>
if you really need massive bandwidth, i suppose why not
<whitequark>
but... unless you are already very familiar with the FX2 i do not see this as necessarily the easiest option
<whitequark>
besides having to deal with 8051 C (perfectly nice in isolation, *way* better combined!) configuring the FX2 FIFOs is not entirely trivial
<electronic_eel>
hmm, you could take all these parts from glasgow
<miek>
electronic_eel: an example of the kind of use-cases i'm imagining is developing an applet for some obscure sensor, then later installing it permanently with whatever comms suit the situation (esp, some ble micro, a serial port, etc.)
<whitequark>
and there are a bunch of failure modes where you get things like "ZLP packets don't get transmitted" and those are incredibly obnoxious
<whitequark>
it took me a ~year from first data to first reliable data when i was bringing up revA
<electronic_eel>
miek: ok, if you have other existing comms then the fx2 doesn't make sense
<whitequark>
and i needed help from tnt in the end to actually fix it
<whitequark>
now i was pretty inexperienced but still
<whitequark>
electronic_eel: yeah, it is true that you could cut down the glasgow firmware
<whitequark>
if you are a professional embedded developer who does not find using yet another new toolchain much of a speed bump, yes, absolutely
<electronic_eel>
I was more thinking of someone already familiar with glasgow
<whitequark>
glasgow is built around using python for as many things as possible because, while slow and clunky, it's hard to accidentally misuse
<whitequark>
i would not call sdcc C or FX2 hard to accidentally misuse
<whitequark>
like the whole point of making these parts invisible and non-customizable is making sure that no one ever has to debug FX2-related problems
<whitequark>
(which i'm pretty sure i achieved)
<whitequark>
or USB-related problems
<whitequark>
another thing that is easy to accidentally misuse
<electronic_eel>
yeah, these abstraction layers are why I suggested taking the fx2 and parts of the python glasgow sw
<sorear>
last I heard STARSHIPRAIDER was fpga openssh, not fpga tls
<whitequark>
sorear: oh right
<whitequark>
that's still quite some scope but it's much more manageable
<whitequark>
electronic_eel: i'm still ambivalent on it. if there's one thing i *strongly* dislike to support, it is nonstandard variations of glasgow glue logic, schematic, firmware and so on
<whitequark>
i'm pretty open to making the "meat" of applet logic easier to use in foreign contexts because it isn't (or shouldn't) be closely tied to the glue code. if it were, then something like revE would not be practical
<whitequark>
now, it is true that saturating USB isn't that easy, so if you need tons of bandwidth, you have to find some sort of solution
<whitequark>
if any significant number of people does that, what we can do is a fake rev, call it "rev@" or something, with no ADC, DAC, level shifter, LED, secondary EEPROMs, and so on. or even a layout. it would be a piece of schematic that basically says "if you build these specific parts in this specific way, and do whatever you want with the rest, we'll do our best to support this configuration upstream"
<whitequark>
seems like a pretty niche desire though, as opposed to more general wish of more flexibility...
ali_as has quit [Read error: Connection reset by peer]