whitequark changed the topic of #glasgow to: glasgow debug tool · code https://github.com/GlasgowEmbedded/Glasgow · logs https://freenode.irclog.whitequark.org/glasgow
Dark-Star has joined #glasgow
modrobert has quit [Ping timeout: 245 seconds]
gsuberland has quit [Read error: Connection reset by peer]
gsuberland has joined #glasgow
gsuberland has left #glasgow [#glasgow]
gsuberland has joined #glasgow
modrobert has joined #glasgow
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
futarisIRCcloud has joined #glasgow
<whitequark> tnt: you were the one who got me an openvizsla, right?
<whitequark> i got it to work, thanks!
<whitequark> it's a bit awkward because it's almost a direct competitor to glasgow. i might be able to share some of the code though
<sorear> xilinx and ftdi. the anti-glasgow
<whitequark> lol
<whitequark> well yes
<whitequark> it'd be quite hard to make glasgow *exactly* equivalent to openvizsla
<whitequark> OV has a 256 Mbit SDRAM on it
<whitequark> the largest SPI PSRAM i can find is 4 Mbit
<whitequark> that you can buy
<sorear> can you read and write that at HS line rate?
<sorear> well I guess you only need to write at line rate
<whitequark> good question. no, not remotely
<whitequark> ULPI is 4-bit DDR at 60 MHz
<whitequark> that SPI PSRAM is 4-bit SDR at 45 MHz max
<whitequark> so you'd need like an auxiliary FPGA
<whitequark> at which point you're better off just using openvizsla
<whitequark> i mean, you could do a cheaper-and-inferior version of openvizsla that's a simple glasgow plugin with no psram
<whitequark> that explicitly cannot do HS line rate
<whitequark> so yeah, you're right, it's not a direct competitor at all
<sorear> https://github.com/openvizsla/ov_ftdi/wiki/limitations says the SDRAM isn't actually used
<whitequark> wtf
<sorear> I have been looking at this for all of five minutes and if there are inconsistencies or inaccuracies I don't know about them yet
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<sorear> but revE will be 3/4 of openvisla, just needs an addon board with the USB signal probe and PHY
<sorear> (3/4 counting "big chips" but as much time as y'all have burned debugging bizarre level shifter and voltage regulator problems I think that may be a bad metric)
<ktemkin> given how temporally-sparse a lot of interesting USB communications tend to be, I expect there's still a lot that can be done with something like current-glasgow + a ULPI phy
<ktemkin> [also, hi]
<sorear> the ice40 HX8K used on revC has 128 kbit of on-chip memory, if that helps
<ktemkin> (I'm currently testing how much high-speed USB you can readily capture with a ULPI phy stuck to a LPC18xx/43xx the results might wind up being interesting)
<ktemkin> [plus a semicolon after 43xx]
<ktemkin> I'm of the opinion that there's a lack of very-inexpensive USB analyzers that can analyze high-speed USB; and I think even options that can't keep up with a well-utilized USB bus are valuable
<marcan> sorear, whitequark: the wiki is made of fail, SDRAM is used.
<marcan> and yes revE will easily supersede OV, but I expect at a higher price?
<marcan> like the goal of OV was to make a USB analyzer and oh btw you can also use it as an FPGA dev platform, but it doesn't have any fancy configurable I/O, just some spare pins
<marcan> glasgow revC/revD definitely suffer from lack of memory for some purposes (and externally adding it isn't terribly easy), but I think it's a fine tradeoff given the design
<marcan> I think glasgow revC should be able to sniff LS/HS USB, possibly even with zero additional hardware. Those are slow enough you can get away without differential IO and such I think.
<marcan> er, LS/FS
<marcan> OV was explicitly designed to do HS properly, that was the whole point
<marcan> ktemkin: €120 isn't exactly expensive, considering commercial USB analyzers that *do the same thing* and are *literally equivalent hardware* cost $1400.
<ktemkin> I don't think OV is super expensive; I just think it's more than I can e.g. hand out during a USB training or workshop
<sorear> isn't our cost already past that
<marcan> glasgow revC? possibly, but all that fancy I/O isn't free
<ktemkin> I'm not saying glasgow is, either
<marcan> if you look at OV3 it's really a trivial design
<marcan> FTDI+FPGA+PHY+SDRAM
<marcan> those aren't exactly expensive chips
<marcan> and there's only minimal stuff around that
<marcan> you could certainly cost-optimize it by just getting rid of the SDRAM and hoping the BRAM is enough (hey it worked for OV3 until we got the SDRAM controller done)
<ktemkin> by the way, I'm hoping to integrate an OV backend into the (GUI) USB analyzer software I've started planning out
<ktemkin> which should hopefully address one of the major usability gaps between OV and commercial analyzers
<tnt> whitequark: glad to hear you got it. :)
<marcan> whitequark: also yeah I think you should look over the OV codebase, I think there are some good ideas there you might be able to steal for glasgow
<tnt> whitequark: as far as competition go well .. it has the USB phy HW/connector and the sdram and none of the io circuit :p That's quite a bit of difference.
<marcan> the whole USB pipe <-> user streams, configuration stuff, etc architecture is basically the same exact problem glasgow is trying to solve
<marcan> gateware and software-wise
<marcan> tnt: when I wrote up the design doc that I eventually realized was just glasgow revE, I had "USB sniffing frontend" as an explicit use case, with the idea that it could supersede OV, but obviously at a higher cost (and also being a lot more flexible)
<marcan> (this was when I started working on glasgow, because I realized whitequark had had the same idea as I and had already started working on it :p)
<marcan> ktemkin: that would be really neat; OV currently suffers from rather barebones software
<marcan> dumping USB packets to the terminal is fine for teaching people how to read the USB spec in a stream, but it's not exactly efficient :p
<tnt> marcan: sure. I mean OV is also a rather old device, but it has the benefit of existing, being available at a reasonable price and doing very useful stuff today :p
<marcan> yeah
<marcan> like if you need a USB analyzer today it's the obvious choice
<ktemkin> marcan: yeah; I agree -- right now, I'm at the point where I _really_ want to be able to drop the use of usbmon / software analyzers from my trainings; and software's half the barrier there
<marcan> and it was also extremely late (it might even hold the record for "most delayed kickstarted project that *actually* fulfilled all the rewards")
<marcan> (don't get me started on *that* story)
<whitequark> ktemkin: hihi!!
<sorear> i assume, the most painfully cost-optimized way to do this is "add J2 and J3 to tinyfpga"
<marcan> you need a USB PHY to do HS
<marcan> well, either that or a custom frontend that would just be a lot more expensive than a USB PHY
<ktemkin> marcan: though for trainings I'm pretty tempted to put together some boards with just an LPC{18,43}xx + ULPI PHY [+ optional sdram?] for simple analysis
<ktemkin> my most recent USB stack for the LPCs peaks at a reliable 40Mbps on good hosts; and the LPC's SGPIO peripheral can grab ULPI+ data at full rate and do some limited filtering/triggering with its pattern match hardware
<marcan> I'm curious as to how well that would work
<ktemkin> *MBps
<ktemkin> (what's an order of magnitude between friends, anyways?~)
<marcan> FWIW bulk data rates for both OV3 and Glasgow are in the 42MB/s range
<ktemkin> whitequark: hi!
<marcan> I think we hit 45 on Glasgow even
<sorear> how much ram do you get on a LPC?
<whitequark> so the point of having an ULPI addon for Glasgow would be that if you already have Glasgow the cost of the addon is extremely low
<whitequark> it's literally just USB3340 or whatever and two connectors
<marcan> yeah
<whitequark> but it's definitely worse than OV3
<whitequark> so, at the very least, both have a right to exist
<marcan> of course
<marcan> either way, OV3 is a mature project
<marcan> and shares enough software-wise with glasgow that deduplicating USB-related bits is entirely feasible
<marcan> so I don't see any conflict here
<ktemkin> sorear: there's 264Kb built in; and then its external memory controller can address up to a gig of SDRAM
<marcan> revE will get USB add-on support and when the time comes we can figure out how to share some code with the OV3 software and that's about it
<marcan> whitequark: fwiw there's a lot of intent crossover here, historically
<marcan> after the spectacular OV1 and OV2 failures, OV3 was basically a twlfpga with a USB PHY glued in front
<whitequark> what caused OV1/OV2 to fail?
<marcan> a twlfpga replacement is what I wanted to design, and then I accidentally came up with revE
<marcan> whitequark: a certain person who shall remain unnamed.
<marcan> also xmos.
<whitequark> hrm
<whitequark> (whispers) lennart poettering?
<ktemkin> out of curiosity, is revE going to have SS data transport?
<marcan> no
<whitequark> SS?
<ktemkin> USB superspeed
<marcan> SuperSpeed
<whitequark> um, ys
<marcan> upstream, yes
<whitequark> *yes
<marcan> let's just say a certain individual both pushed for an entirely braindead design and stole half of tne kickstarter money and vanished.
<whitequark> ah, it was the answer to that
<whitequark> gotcha
<marcan> and then bushing and a few of us were left to pick up the pieces, and bushing put a bunch of his personal money in to be able to fulfill the KS goals
<sorear> USB SS and GbE have been discussed as transports for revE
<marcan> that's the TL;DR version of the OpenVizsla clusterfuck.
<marcan> but hey, at least it exists now.
<ktemkin> I assume you've seen the Daisho and its gateware SS stack?
<whitequark> ktemkin: i am aware of it
<whitequark> i have specifically avoided gateware USB stacks
<whitequark> the reason is simple
<sorear> unfortunately > 1G ethernet doesn't have readily available PHYs
<whitequark> `glasgow run uart` currently takes under 5 seconds
<ktemkin> I'd avoid using one for the host-side transport, too
<whitequark> there's no way you can make that happen with a gateware USB stack in an FPGA without partial reconfig
<whitequark> which is true for ECP5 and iCE40 alike
<ktemkin> but I'd *love* seeing it used as a target side
<whitequark> sure, why not
<marcan> whitequark: fwiw, as fast as synthesis currently is, I want to add a bitstream cache to glasgow.
<whitequark> marcan: that was my very first plan
<whitequark> and then i opted not to because i never figured how to clear this cache
<whitequark> well, in which conditions
<marcan> I'll have to figure something out
<whitequark> well, it was different back then
<tnt> wouldn't just hashing the verilog file do ?
<whitequark> tnt: nope
<whitequark> first, that doesn't take into account the constraint fil
<whitequark> *file
<whitequark> which was an actual bug
<whitequark> i fixed that by adding the constraint as a verilog attribute as well, quite hacky
<whitequark> second, not all nextpnr runs are created equal
<sorear> theoretically one could implement some kind of hard macro thing in nextpnr instead of partial reconfig, but that's a huge project
<whitequark> third, you can upgrade yosys and nextpnr
<whitequark> sorear: indeed
<whitequark> also, it still consumes valuable resources
<whitequark> ice40 is miniscule, ecp5 is just tiny
<marcan> I mean, you can add a bunch of those identifiers to the hash key
<marcan> and also have a fallback "expire everything older than 24h" or whatever
<whitequark> marcan: well yes
<marcan> and have an explicit cache clear command
<whitequark> but i'm not sure if it's worth the hassle
<whitequark> i haven't actually *wanted* the cache for a long time
<marcan> I'll do it when I get bored/annoyed enough if you don't :p
<whitequark> it might be useful for something underpowered like an rpi, yes
<marcan> I have, already, when just flipping between applets for testing stuff
<whitequark> are you using HeAP?
<marcan> HeAP?
<whitequark> it needs a migen patch right now, i have that fixed locally
<whitequark> --placer heap
<whitequark> analytical placer
<whitequark> works *way* faster than annealing
<marcan> probably not, how do I use that?
<sorear> is that still not the default?
<whitequark> --- a/migen/build/lattice/icestorm.py
<whitequark> +++ b/migen/build/lattice/icestorm.py
<whitequark> - "nextpnr-ice40 {pnr_pkg_opts} --pcf {build_name}.pcf --json {build_name}.json --asc {build_name}.txt --pre-pack {build_name}_pre_pack.py",
<whitequark> @@ -118 +118 @@ class LatticeIceStormToolchain:
<whitequark> + "nextpnr-ice40 -q {pnr_pkg_opts} --pcf {build_name}.pcf --json {build_name}.json --asc {build_name}.txt --pre-pack {build_name}_pre_pack.py --placer heap",
<whitequark> sorear: nope
<whitequark> it really should be
<ktemkin> re: a couple of lines back: I'd love to have a board that'd be both able to do some open-source USB-SS analysis and do FaceDancer-ish things at SS; which an ECP5 connected to something like an FX3 should be quite capable of
<whitequark> yep, that's the idea for revE
<marcan> unrecognised option '--placer'
<whitequark> marcan: well you need nextpnr master, yes
<whitequark> at least ~1 month old?
<whitequark> it got merged on 03-25
<whitequark> ktemkin: we're going to do revD first though
<whitequark> so revE is probably... a year away? year and a half, possibly?
<whitequark> that's all fairly optimistic
<marcan> why the hell does nextpnr-ice40 link against Qt5Widgets, lol
<whitequark> it has a GUI
<marcan> oh it has a gui
<whitequark> speaking of revD
<whitequark> marcan: do you have any idea what kind of form factor would that even be
<marcan> board layout? not really
<whitequark> because i have no idea how to route 4 banks in the same width
<marcan> yeah obviously it needs to be larger
<marcan> connector layout is important
<whitequark> we might be able to put the FPGA in the middle and generously space the banks, maybe?
<whitequark> they don't have to be super tight
<ktemkin> whitequark: I'm not super in a hurry; a ECP5 board like that is just something I've been tempted to make recently -- and I figured I'd be better off seeing how much overlap there was with future glasgow plans so I could avoid duplication of effort
<marcan> yeah, it might work to just "blow up" the current layout a bit
<marcan> and have 4 banks along the 2 edges
<sorear> would the banks be paired with revC-compatible spacing?
<whitequark> well the idea is that they would be
<whitequark> but i have no idea how to lay it out
<marcan> I think that's a pretty hard constraint
<marcan> not impossible, but tricky
<marcan> maybe we can just take revC and rotationally duplicate it along the center of the FX2, approximately? keep the width, just make it longer?
<marcan> would make for a bit of a long board though
<marcan> and then the USB port goes where the LVDS currently is, for example
<whitequark> something like that is an option
<whitequark> i am more thinking about making it wider but having the connectors spaced the same
<whitequark> then we can push the programmable pulls outside
<marcan> ah, adding padding to the other side of the connectors?
<marcan> yeah that would work
<whitequark> yes
<whitequark> i like that quite a bit more, really
<whitequark> most addons would be fine and worst case you need a spacer
<marcan> though the routing would still have to wind back, due to the ESD protection, if we want to do it right
<marcan> but that's not a huge issue
<whitequark> yeah
<whitequark> we could also add a second ESD protector after the pulls
<marcan> after the resistors? yeah that would work
<whitequark> its capacitance will be insignificant if it's behind a resistor
<marcan> yeah
<marcan> if we add enough width to fit the pulls, I think that also fits the Vio logic
<whitequark> exactly
<whitequark> and then the FPGA can go between the 4 connectors
<marcan> yeah
<marcan> the whole glasgow would still have to be a bit wider than it currently is
<whitequark> and we can even add an LVDS bank to the small distant side
<marcan> if we have the pins, which I'm not sure still
<whitequark> (if we can fit it into the ballout)
<marcan> but yeah
<whitequark> oh and the aux power for the connectors can go on the *outside* of the connector too
<marcan> ah, yes
<whitequark> because there's not many other places where it wouldn't mechanically interfere with revC
<marcan> actually at that point it might make sense to leave the Vio stuff where it is
<marcan> and use that space for the aux power, only moving the pulls outside
<whitequark> that seems like a nightmare to route
<marcan> how so?
<whitequark> it takes almost all board space in between of the connectors
<marcan> ? the vio stuff is basically *outside* the connectors already, towards the far edge
<marcan> it's the pulls eating up all the space inside
<whitequark> yes but if we add another pair of connectors
<whitequark> the larger FPGA ought to be placed where the Vio stuff currently is
<marcan> wait you mean making the board a lot longer?
<whitequark> uh, yeah
<whitequark> like by a third
<whitequark> and *also* wider
<marcan> uh let me open up inkscape
<sorear> i'm fairly certain all of the I/O chips for revD can't be fit in the current board area even if you punt on routing
<whitequark> you couldn't even fit the connectors, yes
<marcan> it has to be larger, I think we're just disagreeing about the exact way
<marcan> whitequark: very crude mockup: https://mrcn.st/t/Screenshot_20190510_145158.png
<marcan> red is revC1
<marcan> might need to add some more width to fit SYNC and the vregs in a better place, but something like that generally comes to mind
<whitequark> hmmm
<whitequark> that's definitely one option
<marcan> sidenote: we probably should use the 1.5A protection for revD
<whitequark> i was thinking about a board that's... about as wide but longer
<sorear> do you need PD for that?
<whitequark> not exactly
<marcan> sorear: officially yes, but we're not going there
<whitequark> iirc it is legal to be a high speed only USB 3 device
<marcan> yes, though that is 900mA, not 1.5A
<whitequark> so that you can take advantage of the 3A limit
<whitequark> oh, 900mA, right
<marcan> 3A is for typec
<whitequark> bleh
<marcan> but 1.5A is the USB charger spec limit
<marcan> I just plugged my phone into a decidedly USB2 hub
<marcan> and it's pulling 1.3A
<marcan> with data
<marcan> so basically, nobody gives a flying fuck any more about the spec
<marcan> we can eat 1.5A and if you brown out your host, get a powered hub
<marcan> (or don't try to power that much via vio)
<sorear> is "aux power" a firm thing yet?
<whitequark> exactly
<whitequark> it's not like glasgow itself can consume even 500 mA
<marcan> yeah
<whitequark> sorear: i'm fairly confident we do need it
<marcan> power and data, right
<sorear> observation: revD will pull the full 1500mA for ~1 ms while the 330µF charges, regardless of what's connected to it
<marcan> and we also need i2c switches, I was wondering what to do with the space right of the LEDs; that answers that.
<whitequark> sorear: nope
<whitequark> we have an inrush limiter
<sorear> i thought the inrush limiter was what we were discussing replacing right now
<marcan> also whitequark: if we concede to putting more passives on the bottom (which I tried to avoid for revC), we can probably be a bit denser still
<whitequark> oh, right
<whitequark> marcan: yeah
<marcan> or even actives, heck
<whitequark> the most problematic part is well
<whitequark> hm i guess since we DNP the PTH connectors for pull replacements
<whitequark> it doesn't need wave soldering keepout
<marcan> I can try to work with the keepouts anyway
<marcan> also, we can put the shifters on the bottom, and here's some merit to it
<marcan> if you fuck a shifter up, you might need to hot air it off
<whitequark> i agree
<marcan> and hot airing the top side sucks because you need to shield the connectors to avoid melting them
<whitequark> hot airing the top side is a nightmare
<whitequark> i'm fairly good at it and i wouldn't want to o it
<marcan> I've done it a few times for my C0 patches
<marcan> each time it's a gamble
<whitequark> i mean the shifters specifically
<marcan> ah
<whitequark> the closest ones to the shrouds
<marcan> yeah
<whitequark> i could probably do something with a really narrow nozzle and a lot of foil
<whitequark> it would be Bad
<whitequark> i mean, the connector would stay usable, sure
<whitequark> but it would get warped a bit p sure
<marcan> I did mine with a huge nozzle and no air speed control, because my hotair station is busted, lol
<marcan> but I used kapton tape to shield them
<whitequark> Al foil is reflective
<whitequark> so that's one thing going for it
<marcan> I did the pulls and the regulator that way
<whitequark> and it usually comes with an insulating layer of air
<marcan> yeah, but it's also very conductive
<marcan> so if it *does* touch the connectors it'll melt them
<marcan> I used kapton tape because that's more insulating
<whitequark> i wrap the connectors in Al foil all the time
<marcan> worked well enough, and I bent it such that there was a layer of air
<whitequark> i'm not sure exactly what the physics is
<marcan> heh
<whitequark> what you said sounds sensible
<whitequark> but also, i don't melt the connectors that way
<marcan> well, whatever works
<whitequark> so there are more things at work
<marcan> might do some experiments some day
<marcan> either way, we agree that reworking the top side is a PITA
<whitequark> yes
<whitequark> shifters on the bottom seem OK
<whitequark> but... then we have their decoupling on top?
<marcan> possibly, or it might still fit on the bottom
<whitequark> true
<marcan> obviously I need to sit down with kicad and sketch this at some point
<whitequark> yeah either way it's basically a complete relayout
<marcan> also, the ESD protection would go on the bottom too then, or else we take some trips through vias
<marcan> yeah
<whitequark> indeed
<whitequark> and ESD protection is also something you could kill
<marcan> yeah
<whitequark> i do wonder at what voltage the shifters will die and how
<marcan> I don't think it's worth going much deeper than this without kicad
<whitequark> agree
<marcan> just wanted a general feel for the layout
<marcan> re: shifter death, I was thinking I want to try that
<marcan> patch-wire the ESD protection in and hook it up to my bench PSU
<marcan> and crank up the voltage and see what happens
m4ssi has joined #glasgow
<electronic_eel> marcan: re revD layout mockup - wouldn't it be better to leave some space horizontally, so that revE has a chance to fit in?
<electronic_eel> or will revE break connector compatibility?
<marcan> I think revE will definitely break connector compatibility, at least the relative position
<marcan> it's going to end up being a much larger board
<marcan> and I'm not entirely happy with the pinout for revC/D going into revE
<marcan> revE is going to be a very different beast
<electronic_eel> hmm. don't know if it is a good idea to plan for t
<electronic_eel> t
<electronic_eel> this break of compatibility
<electronic_eel> (sorry, still learning my new keyboardio)
<marcan> I mean I think revE will at least have some compatible connectors, though I'm not sure if *all* the I/O on revE will end up as compatible banks
<marcan> but I'm not sure it's worth keeping the relative position fixed as we are from revC into revD
<whitequark> revE will use a connector that's electrically SYZYGY
<whitequark> you could grab an adapter
<marcan> SYZYGY?
<electronic_eel> will a one-port-addon fit on revE?
<marcan> oh TIL
<whitequark> they use some really weird stuff, an attiny44 instead of an EEPROM and an I2C mux
<electronic_eel> SYZYGY uses a samtec connector, no direct plugin of pin headers
<whitequark> yes
<whitequark> revE is a different class of device
<marcan> it makes sense to ship revE with adapters for pin headers
<marcan> but not to use them outright
<whitequark> the bare revE board will not have level shifters either
<marcan> oh that's how we're doing this? fair
<electronic_eel> ok, really different beast then
<marcan> (I had the same idea)
<marcan> (I mean for iceface)
<whitequark> it's for multiple reasons
<whitequark> it's to extend the viable range
<whitequark> i.e. we no longer have to be bound by 5V as an absolute requirement
<whitequark> it's also to extend usefulness. SYZYGY has I2C and Vaux baked in
<whitequark> so it only makes sense that revE IO boards will often feature things like ADCs
<marcan> yeah
<marcan> at that point you'd have a revC-IO board for revE
<whitequark> correct, that would be the first IO board
<marcan> wastes a bunch of pins though but oh well
<marcan> (16 single ended signals + 12, the 12 would be wasted)
<whitequark> nope
<whitequark> that's why i said "electrically"
<marcan> oh?
<whitequark> i will reuse the 4 clock signals for IO/OE
<marcan> ah
<marcan> yeah, that adds up to 32
<marcan> good
<whitequark> well, at least as an option, iirc on ECP5 there are clock capable io pins
<marcan> so one expansion provides two revCD ports
<electronic_eel> the io addon board could keep connector position compatibility with revD then
<whitequark> exactly
<marcan> yeah
<whitequark> electronic_eel: yep.
<whitequark> it's not yet clear to me how it works out mechanically
<electronic_eel> plug it on top?
<whitequark> a board that mounts *over* the revE PCB is a bit bad but a board that *protrudes* far from revE PCB is also bad
<whitequark> one makes cases harder to make
<whitequark> and leaves revE mainboard accessible
<whitequark> another adds an enormous lever on the samtec connector
<electronic_eel> ah, ok, yeah, the case problem
<whitequark> it might make sense to populate the revE from the bottom (in terms of normal operation
<marcan> looks like the the intent of the SYZYGY spec is for ports to be at the board edge
<whitequark> so that the only thing really exposed is a bunch of LEDs
<whitequark> well yes
<marcan> OTOH the spec does include screw holes
<whitequark> yes.
<whitequark> that's why i want to be able to deviate from it.
<whitequark> it will be compatible electrically because well
<whitequark> for one, SYZYGY is fairly popular
<whitequark> digilent will ship first SYZYGY peripherals soon
<whitequark> that means they've kind of taken this specific samtec connector
<whitequark> we will also absolutely need an I2C mux because unlike SYZYGY, which only uses I2C for 1 device with a geographically defined address, we can hang many I2C devices off that bus
<whitequark> like eight DACs or whatever
<marcan> yeah
<whitequark> so there's no point in following their stupid plan with the attiny44 which isn't even in circuit programmable for the first time
<whitequark> it should be a good old EEPROM
<marcan> and i2c is the only sideband we have, so we're going to have to funnel everything through that
<whitequark> of course, we could *accept* SYZYGY peripherals
<marcan> yeah[
<marcan> we're going to need micros for addon boards pretty often anyway, I think
<marcan> but it definitely shouldn't be *required*
<whitequark> anyway, so normal SYZYGY peripherals protrude outside the board
<whitequark> we could define our own IO boards that protrude *into* the revE
<whitequark> this way you could mount them with like 4 screws
<whitequark> semi-permanently
<whitequark> that gives you a lot of mechanical stability and i think it's very important to have that
<marcan> ah, so put them on the edge but make a proprietary form factor that goes inwards
<electronic_eel> yes, wiggling on t
<marcan> so we can have it both ways
<whitequark> yes.
<marcan> I think that makes some sense
<whitequark> i imagine revE could be 2x as wide as revD from the start and it would have uhm
<marcan> I want 128 pins, so 4x32 :p
<whitequark> i'm not sure if i want 4x32 or 128x32
<whitequark> er
<marcan> 128x32 lol
<whitequark> 4x32 or 8x32
<marcan> depends on the FPGA IO at that point, I think
<whitequark> i think i want 8x32 so you get 128 usable pins with level shifter
<marcan> could be 6x really
<marcan> like 4 on one edge and 2 on a side
<marcan> yeah that's nice too
<marcan> though I think the use cases for 128 pins with level shifters are semi limited
<marcan> I can see lots of use cases for 64 bidirectional pins with level shifters, and 128 input-only pins for logic analyzer only mode
<marcan> or a combination of both (the system is modular for a reason)
<whitequark> LFE5UM-85 has 365 user I/Os
<marcan> so we could have input-only modules that give you 2x the IOs
<whitequark> and that's the largest we can get
<whitequark> hmmm
<marcan> anyway, this will all start to come together when we start putting things into eeschema :p
<marcan> but I have a gut feeling that 6 ports is where we'll end up
<whitequark> we're going to use every single ball on the LFE5UM-85 aren't we
<whitequark> there are also transceiver modules
<marcan> it also depends on what we do for the USB/ethernet/whatever upstream
<marcan> and everything else
<whitequark> and the FX3
<marcan> yeah
<marcan> and ideally I don't want to be scrounging for the last few balls either
<marcan> like we did for revC
<whitequark> right, so 6 ports and 2 transceiver ports
<whitequark> 8 in total
<whitequark> that seems reasonable
<marcan> like, if we can fit in 8 connectors using *every* *single* *ball*... I'm not sure I want to do that
<marcan> yeah, something like that
<whitequark> that's going to be a 6L board if not worse
<marcan> for sure
<marcan> but hey, it's revE
<marcan> looking forward to laying that out
<whitequark> heheh
<whitequark> yeah
<marcan> do we have a BOM cost target?
<whitequark> iirc it was something like revC was $50 and revE was $200 or $250
<whitequark> we definitely blew the revC BOM target but that's okay
<whitequark> we'll blow the revE BOM target and that's also okay
<marcan> yeah
<marcan> I'm mentally preparing myself for $300-$400 depending on what ends up happening
<marcan> though ideally not, but hey
<marcan> if it's for good reasons, worth it
jevinskie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<marcan> revE should be a seriously powerful tool
<whitequark> that's closing in to STARSHIPRAIDER in cost :D
<marcan> yeah :D
<whitequark> well SSR is more like $1000 BOM target
<marcan> well, we'll see, just pulling numbers out of my ass right now
<whitequark> and it doesn't retail
<whitequark> so it's not quite comparable
<marcan> yeah
jevinskie has joined #glasgow
<whitequark> speaking of revD
<whitequark> i'm thinking about the layout of the AUX connector
<whitequark> i think it should be a dual row pin header with a layout like
<whitequark> 3 I 5
<whitequark> G I G
<whitequark> where I are the I2C signals
<whitequark> this means that no matter which two adjacent pins you short together there is no damage
<whitequark> since the I2C mux uses pass transistors and is powered at 3V3
<whitequark> alternatively, it could be a pin *socket*
<whitequark> (honestly, with the same layout and for the same reasons)
<whitequark> actually yes it should be a socket for sure
<whitequark> having always active power without an inherent limit on a header sucks
<electronic_eel> yes, socket is a good idea
<whitequark> speaking of that, on revE unused samtec sockets should not have any power turned on either
<whitequark> i mean, that's just basic principles of hotplug
<whitequark> SYZYGY isn't designed for hotplug at all
<electronic_eel> you should turn on some power for autodetection to work
<whitequark> but revE has to be
<whitequark> yes. but it would turn on only when you are actively detecting something.
<whitequark> actually, hang on, i have a better idea
<electronic_eel> ok
<electronic_eel> maybe some pullups in the addon turn it on?
<marcan> whitequark: it could be another shrouded IDC connector
<marcan> definitely not a bare header
<marcan> socket is fine too though
<electronic_eel> socket is smaller than shrouds
<whitequark> ^
<marcan> yeah
<whitequark> shrouds are huge
<marcan> well, we need ~the width of a shrouded socket for the pull IC anyway
<marcan> I don't think it's much of a waste
<whitequark> mmm
<marcan> I just realized that SYZYGY has no GNDs, lol. it's one of those things where there is a big fat GND shield built into the connector, right?
<whitequark> not a shield
<whitequark> it's a huge knife at the center
<marcan> the inside thing I mean
<marcan> yeah
<whitequark> honestly a rather good ground
<marcan> yeah
<whitequark> i have no idea how to detect hotplug of SYZYGY peripherals :S
<whitequark> yes they all have a pullup on R_GA
<marcan> I was thinking the RSVD pins for ours
<whitequark> a 10k one
<marcan> but yeah the R_GA pull is the only way for official peripherals
<marcan> dammit get out of my head whitequark
<whitequark> lol
<marcan> I was already thinking about this
<marcan> :p
<whitequark> i was thinking about RSVD pins too
<whitequark> but we could get out of sync with them then
<whitequark> here's a stupid idea
<whitequark> by default, put a 100k (1M, you get the idea) pullup on 3V3
<marcan> if we use the RSVD pins it should be for something "benign" of course, like a resistor-based hotplug detect
<marcan> nothing that's going to horribly clash with any sane use case they come up with
<whitequark> yeah but think about this
<marcan> kk
<whitequark> someone tries to make a SYZYGY-compatible peripheral and ends up ne... hm
<whitequark> actually you're right
<whitequark> we can use RSVD pins as "soft straps"
<whitequark> i.e. 100k pullup on our mainboard, 100k pulldown on our IO board
<marcan> yeah
<whitequark> none of this will interfere with any normal operation of RSVD
<marcan> well our add-ons are not SYZYGY compatible anyway
<whitequark> someone might want to make a hybrid Glasgow-and-SYZYGY addon
<marcan> so we can have like a 4k7 pulldown on our IO board
<marcan> and a 100k pullup on the mainboard
<whitequark> and be able to use RSVD pins on that
<marcan> true
<marcan> but I mean if we do 1:1 then we need some funky comparator thing to measure it
<whitequark> one of those breadcrumb I2C ADCs
<marcan> if we're doing that just put them on R_GA and measure that
<whitequark> but you can't do it without power
<whitequark> this actually brings me to my other idea, which is *evil*
<whitequark> put a 100k pullup on the *3V3* line
<marcan> lol the spec doesn't even say what *rail* R_GA is a pullup to
<marcan> idiots
<whitequark> it does
<whitequark> that's where it says it
<marcan> oh that spec
<whitequark> it's a pullup to 3V3
<whitequark> on revE we'd probably do something like put a 2k00 pulldown on every R_GA pin
<marcan> ok, so you're saying you want proper power switches on 5V/3V3 for hotplug
<whitequark> yes
<whitequark> and we'll also need ESD protection on the mainboard
<whitequark> for similar reasons
futarisIRCcloud has joined #glasgow
<marcan> of course
<marcan> but that's fine
<whitequark> anyway the evil idea
<whitequark> 09:24 <@whitequark> put a 100k pullup on the *3V3* line
<whitequark> if we have a 2k R_GA then this will pull down the 3V3 line itself below Vil
<marcan> I don't think we can guarantee anything about static draw on the 3V3 bus?
<whitequark> we can.
<whitequark> the R_GA plus R_PU on the IO board are a 12k pulldown
<whitequark> so there is at least that much load on 3V3
<marcan> oh I see what you mean
<marcan> lolol
<whitequark> isn't it elegant?
<marcan> for fuck's sake
<marcan> well... I mean... this is the kind of shit the USB specs would do.
<whitequark> can you tell me any reason it's bad
<marcan> no, no, I get it
<whitequark> i don't disagree with the last point btw
<marcan> it's just *cringe*, I'm not saying we shouldn't do it
<marcan> so the only problem with this is there is no sane hot-*un*plug
<marcan> mind you, that's always the case with non-hotplug connectors like these
<marcan> and even hotplug is dodgy
<whitequark> put a button next to it
<marcan> like we need a delay and hope the connector is in all the way
<marcan> heh, sure
<whitequark> i mean not really
<marcan> oh wait
<marcan> lol
<whitequark> the way the syzygy mechanical spec works it doesn't leave any space for that
<whitequark> in case of dual wide modules
<marcan> R_GA and +3V3 are on opposite ends
<marcan> ahahahaha
<whitequark> oh you mean the connector being tilted?
<marcan> yeah
<whitequark> lmao
<whitequark> that's... brilliant actually
<marcan> we need to measure both though
<marcan> because 3V3 alone might be pulled down without R_GA
<marcan> this complicates things
<whitequark> oh btw
<whitequark> by "hotplug" i didn't mean like plug&play like usb
<whitequark> i meant only that you don't need to power off the mainboard each time you change a module
<marcan> oh sure
<marcan> but then you don't need detection at all
<whitequark> how so?
<marcan> you just ask the user :p
<whitequark> huh? noo
<marcan> you could also just probe
<marcan> send power, enumerate i2c, power down if no peripheral found
<whitequark> that's kind of gross
<marcan> I mean it's reasonable to expect people not to hotplug modules *while* they're interacting with the software
<whitequark> powering up 8 switchers each time you run a CLI command...
<marcan> oh you want dedicated switchers?
<marcan> not just some fets?
<whitequark> how much current do we want to provide on that 3V3 rail
<whitequark> revE will have a dedicated PD controller
<marcan> spec says 2A per port max, but the board doesn't have to actually have nports * 2A available
<marcan> I'm not sure it makes sense to have per-port PSUs
<whitequark> by which i mean i will curse the entire world and write an open-source PD baseband and run it on the FX3
<marcan> much eaiser to have one big fat PSU and just switch ports
<marcan> *easier
<whitequark> because while i *could* use a Cypress EZ-PD device it's honestly ehhhh
<whitequark> i guess i might still use it
<whitequark> but it's some fucking WLCSP
<whitequark> and it's full of USB shit
<whitequark> btw
<marcan> this is going to use typeC, right? not that horrible shit over typeAB
<whitequark> yes
<marcan> wasn't the PD spec marginally saner on typeC?
<whitequark> no
<gruetzkopf> marginally
<whitequark> it has a baseband with an eye diagram specified by 12 points
<marcan> lol
<whitequark> TWELVE POINTS FOR 200 KBPS
<marcan> amazing
<whitequark> it spends literally dozens of pages describing the PD PHY
<whitequark> it's completely insane
<gruetzkopf> own wire instead of FSK on vbus
<whitequark> the common mode level depends on whether you're sourcing or sinking
<marcan> can we just make this use USB4?
* marcan hides
<whitequark> by like 100 mV each way
<whitequark> who the *fuck* wrote that *shit*
<whitequark> fucking *PCIe Gen2* is specified on 4 points
<whitequark> everyone involved needs to be flogged and not in a hot way either
<whitequark> this crap is designed for being epoxied into cable plug
<marcan> lol
<whitequark> because someone thought that's a good idea
<whitequark> oh
<whitequark> oh it has a QFN
<whitequark> ok nevermind then
<electronic_eel> add an optional 12v socket for cases when usb pd doesn't work as expected & specced
<marcan> electronic_eel: yeah definitely
<whitequark> IIRC the firmware isn't actually open source
<whitequark> you're supposed to configure the EZ-PD with some piece of shit windows tool
<whitequark> marcan: oh have i mentioned the 200 kbps baseband uses 4b5b
<marcan> lolol
<whitequark> and IIRC has an equalizer?
<whitequark> and the packet format is hairraisingly complicated
<whitequark> it is so complicated in fact that they had to define a "fast role swap" thing
<whitequark> for a case where like
<whitequark> you power your external display from a type-C charger, and laptop from display, and nintendo switch from laptop
<whitequark> then you unplug the charger from the display
<whitequark> and the entire rest of the chain is supposed to get powered by the switch
<whitequark> but their normal baseband is far too slow to pull that off before the capacitors discharge
<whitequark> so there's a hack that bypasses it
<whitequark> it feels like some kind of parody protocol stack
<whitequark> fresh university graduate wishes he could have designed USB 1.1 by the book but could not
<whitequark> so he designed USB PD 2 instead
<whitequark> and everyone else just nodded approvingly
<whitequark> christ. i hate this so much
<whitequark> on so many levels
<whitequark> oh god they're up to the 4th revision of EZ-USB
<whitequark> doesn't seem so EZ now
<whitequark> also does everyone here know how the USB PD devices determine which one is the charger and which one gets charged?
<whitequark> i usually put it as "the same way hermaphroditic snails mate" because it's a perfect analogy
<whitequark> but not a very good user interface
<whitequark> (dual-role devices, that is)
<marcan> I'll fall back to what my switch does with my old Anker battery pack
<marcan> that is: if you power on the Anker first, it charges the switch
<marcan> until the switch is charged, then it reverses and the switch starts charging the anker
<marcan> hilarity ensues
<marcan> I think this wasn't even PD?
<whitequark> incredible
<electronic_eel> if this pd stuff gets wider use, we'll end up with all sorts of hacky cables with switches and stuff to control it
<electronic_eel> don't think it will make it easier for the users
<electronic_eel> it's just nice for marketing papers where they say "everything over just one cable"
<electronic_eel> but in the end users will hate it because it has all kinds of weird hiccuos
<electronic_eel> hiccups
<marcan> oh god
<marcan> this means unidirectional Type C cables will *actually make sense*
<whitequark> >Solid conductors prevent strand interaction, a major source of cable distortion.
<whitequark> isn't that........ normal... ethernet cable
<ar> it is
<ar> except for the price tag
Yggdrasil has joined #glasgow
Yggdrasil has quit [Client Quit]
spacekookie has quit [Quit: No Ping reply in 60 seconds.]
spacekookie has joined #glasgow
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
pie_ has quit [Remote host closed the connection]
pie_ has joined #glasgow
Sellerie has quit [Quit: The Lounge - https://thelounge.github.io]
Sellerie has joined #glasgow
<ktemkin> I mean, I could actually imagine a bunch of hacky solutions leading to spec additions for things like "e-marked cable that instructs the device on its yellow end never to source current"
m4ssi has quit [Remote host closed the connection]
mehar has joined #glasgow
jevinskie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
jevinskie has joined #glasgow
jevinskie has quit [Client Quit]
jevinskie has joined #glasgow
jevinskie has quit [Client Quit]
jevinskie has joined #glasgow
jevinskie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
bgamari has quit [Ping timeout: 252 seconds]
bgamari has joined #glasgow
carl0s has joined #glasgow
bgamari has quit [Ping timeout: 248 seconds]
bgamari has joined #glasgow
futarisIRCcloud has joined #glasgow
carl0s has quit [Quit: Page closed]
_whitelogger has joined #glasgow
Jasjar has quit [Ping timeout: 246 seconds]
Jasjar has joined #glasgow
Jasjar_ has joined #glasgow
Jasjar has quit [Ping timeout: 252 seconds]