<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
<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>
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?
<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
<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…]