<marcan>
whitequark: checked the pinout/side arrangement? I can order a bunch and post you some if you want
<marcan>
that's lucky if we can just drop those in
<whitequark>
marcan: looks good to me but double check
<whitequark>
i think we can
<marcan>
fair
<marcan>
thanks for looking into this, will investigate tonight
<marcan>
I still need to wrap my head around why the TCA9517 oscillates, that pisses me off so much
<marcan>
I was convinced it was strictly a matter of transactions not making it back out the fork
<marcan>
(which was irrelevant for us)
<whitequark>
i'm not *totally* sure myself
<whitequark>
but you have a board that will do this, so, yeah
<marcan>
yeah
<marcan>
whitequark: the oscillation happens after addressing, right?
<marcan>
so at the first point the slave pulls low
<marcan>
(sda only?)
<marcan>
or is it as soon as anything goes low?
<whitequark>
marcan: as soon as the tca9534 pulls low when acking the address
<marcan>
so it's on the ack, when the host speaks it's fine
<marcan>
so sda only
<whitequark>
yep
<whitequark>
i think what happens is they don't have hysteresis and there's some feedback
<marcan>
I don't get it. it's supposed to be the other way entirely.
<marcan>
like the A side is supposed to be the saner side
<whitequark>
we're connecting the B side to the main bus
<marcan>
yeah, so then I would expect it to break as soon as anything goes low
<whitequark>
hm
<marcan>
like, the slave pulling low should not be distinguishable from the master pulling low through the shifter in this application
<marcan>
at the slave side
<whitequark>
>The output low level for this internal buffer is approximately 0.5 V,
<whitequark>
but the input voltage must be 70 mV or more below the output low level when the output internally is driven low
<marcan>
well I guess what happens is that feeds back *without* the master pulling low, and that causes the oscillation... but then wouldn't that happen as soon as the master *stops* pulling low during any master-initiated action?
<whitequark>
>When the B-side I/O is driven low internally, the low is not
<whitequark>
recognized as a low by the input.
<whitequark>
so
<whitequark>
if we have 70 mV of noise on the bus
<whitequark>
maybe from digital switching
<marcan>
yeah so it's some overshoot shit
<whitequark>
this noise would bring the SDA on the main bus above/below the threshold
<whitequark>
i think
<marcan>
that would make sense
<whitequark>
or it's overshoot stuff but i don't really see overshoot on the scope
<marcan>
so one side drives low to the master
<whitequark>
so i think it's noise
<marcan>
it tries to drive to 0.5V
<marcan>
but undershoots
<marcan>
that triggers the other side
<marcan>
and now shit has hit the fan
<whitequark>
or that, yeah
<marcan>
and this doesn't happen when the master drives
<marcan>
because the undershoot happens within the master-driven pulse
<whitequark>
yep
<marcan>
and when the master releases stuff gracefully goes above 0.5V
<marcan>
and cleanly releases
<marcan>
sigh
<marcan>
so the 9509 instead has some Different Magical Bullshit on the A side
<marcan>
but hey at least with that one B to B is a supported config
<whitequark>
fun fact
<whitequark>
the 9509
<whitequark>
it's exactly like the FXMA
<marcan>
lol
<whitequark>
i swear there are two autosensing topologies and they are both utterly cursed
<marcan>
the FXMA exploded with i2c for that reason?
<marcan>
(pullups)
<whitequark>
well, it's a modified FXMA
<marcan>
so we need to remove the pullups for the 9509
<whitequark>
instead of bus hold circuits it uses some sort of current source
<whitequark>
same concept though
<whitequark>
and yeah
<whitequark>
but that's not even a board revision
<marcan>
yeah
<marcan>
well obviously those footprints are going away
<marcan>
but they can be DNP for C0s
<whitequark>
one thing i want is EN of level shifter connected to LDO EN
<whitequark>
first, this is just cleaner
<marcan>
yeah that makes sense
<marcan>
for the i2c part you mean
<whitequark>
yes. second, in the absolute worst case, we could quickly turn off the other LDO, reconfigure pulls, then turn LDO back on
<whitequark>
though by that point i feel like a "proper" solution would be an i2c switch
<marcan>
wait we can't configure pulls with the LDOs down
<whitequark>
yes.
<whitequark>
but that's unavoidable.
<marcan>
unless you mean like using residual capacitance
<whitequark>
yes
<marcan>
lol ok
<marcan>
horrible hack but OK
<whitequark>
like it's either an i2c switch
<marcan>
revD is getting an I/O expander on the main bus to drive all this jellybean bullshit I/O we're missing
<whitequark>
or another i2c gpio expander
<whitequark>
yeahhhh
<whitequark>
i mean, not necessarily
<whitequark>
we have barely enough pins
<whitequark>
we have four EN pins on the FX2
<whitequark>
and that exhausts all of its IO
<whitequark>
but if we do end up needing more IO, yeah
<whitequark>
more I2C shit
<marcan>
yeah
<whitequark>
fwiw i added some experimental code in a branch
<marcan>
also if revD can use the next up FPGA package so we don't need to somehow crap 4 banks onto there that would make me happy
<whitequark>
to time out on i2c bus conflicts and stuck slaves
<marcan>
because with the current FPGA it's, uh, dodgy
<marcan>
like juuust plausible but I don't know about that PLL in that case
<marcan>
and the LEDs would have to go away
<whitequark>
we can def go to 256 ball package
<marcan>
good
<whitequark>
don't even need finer design rules iirc
<whitequark>
the CB256 package is 0.8mm
<marcan>
good
<marcan>
I don't see anything wrong with the 9509 btw
<whitequark>
neither do i
<whitequark>
other than absolutely no one over here stocking it
<whitequark>
it even costs less
<whitequark>
marginally, but less
<marcan>
mouser has it
<whitequark>
yeah but that doesnt deliver to RU
<marcan>
ah
<marcan>
I'll ship you some then
<marcan>
how many?
<whitequark>
i have one revC0 and whoever makes me more boards can use the right part
<whitequark>
so, three? two plus one spare if i fuck up
<marcan>
so six, because why the fuck not
<whitequark>
sure
<whitequark>
might use it for something else then
<marcan>
do you need them in a rush? AIUI this is not blocking any development, right? since we can work, just no pulls on one (either) port
<whitequark>
soooort of blocking
<whitequark>
well not really blocking
<whitequark>
i'd have to change the board identification code to export the board revision in full
<whitequark>
to distinguish C0 boards and not try to use both pulls at once on those
<marcan>
oh, I think we can tell people to suck it and replace the chip
<marcan>
like this is a temporary hack only
<whitequark>
i suspect we'll need it in the future again for something
<marcan>
possible
<marcan>
but what I'm trying to say is, is it worth me fedexing this to you or can I just drop it in an envelope?
<marcan>
(also considering your last experience with EMS I assume you're not a fan of that either)
<whitequark>
that's like 3 days vs 1 week?
<whitequark>
ems is fine, actually
<whitequark>
i figured out how to yell at them in the right way
<marcan>
something like that? I think ems took longer than expected last time?
<marcan>
I don't have a good benchmark for this
<whitequark>
their couriers are still awful but they're reliably awful
<whitequark>
yes
<whitequark>
they lie
<whitequark>
they say they'd deliver it two days earlier than reality
<whitequark>
but it's always two days
<whitequark>
nfc why
<marcan>
heh
<whitequark>
non-ems requires me to go to post office
<whitequark>
which in my current state is hard
<marcan>
ah
<marcan>
they don't just leave it in your postbox?
<whitequark>
no, they can't do that for registered mail
<marcan>
I mean I could send it unregistered :p
<whitequark>
and unregistered mail has no real guarantees of delivery or means of retribution
<whitequark>
they are free to lose it with no consequence, or delay it for a month
<marcan>
I guess the question is how much you trust your mail service :p
<marcan>
(around here unregistered is Usually Just Fine)
<whitequark>
if it was some junk i drunk bought on ebay i would not care
<whitequark>
if it's for something i need, always registered
<marcan>
EMS it is then
<whitequark>
yep
<marcan>
totally going to be 80% shipping 20% contents though. maybe I should send you something else as a gift to make it worthwhile :p
<whitequark>
sure. i have no real ideas though
<marcan>
EMS is 10x the cost of regular registered lol
<marcan>
(like $20 for EMS)
<marcan>
meh, I'll figure something to pad it with :p
<marcan>
actually if you need any other parts from mouser just let me know
<marcan>
because if I pad *that* I get free shipping on that order
<whitequark>
marcan: wait
<whitequark>
> For the level translating application, the following should be true: VCCA ≤ (VCCB – 1 V)
<marcan>
wait, shit
<marcan>
I saw that later but I thought it was about chaining only
<marcan>
what, why
<whitequark>
exactly
<whitequark>
can you like... try it on yours?
<whitequark>
to be clear
<whitequark>
fig 6 and fig 7
<whitequark>
oh i see
<whitequark>
when you go through the graph from A to B you always arrive at a higher voltage...
<whitequark>
ughhh
<marcan>
butwhyyyyy
<whitequark>
no idea!
<whitequark>
let's test them?
<whitequark>
we can do that in parallel to adding a switch to the board
<marcan>
"let's ignore the datasheet, that worked great last time"
<marcan>
:D
<whitequark>
thats called experience
<whitequark>
:P
<marcan>
if we're playing this game I want to order like 7 or 8 different shifters/switches at once
<marcan>
and then we can figure out what the fuck works
<whitequark>
i don't think ti has any more shifters we can use
<whitequark>
yeah
<whitequark>
i fucked up
<whitequark>
tca9517 is the *only* one without vcca<=vccb-1 restriction
<marcan>
TCA9617B looks like a TCA9517 with the same problem, but I'm trying to figure out what's the difference
<marcan>
I wonder if we can just fix it by adding capacitance to the master side or something?
<marcan>
I'll try some stuff
<whitequark>
ok, we can't use tca9544
<whitequark>
well not alone
<whitequark>
oh hm maybe we can
<marcan>
at this point for revC doesn't it make more sense to use 4x of the regular I/O shifters we already have (they fit), and use one remaining FX2 pin for each as DIR for SDA?
<marcan>
like fuck all this autosensing bullshit
<whitequark>
that wouldn't work for revD...
<marcan>
yeah but at least revD will have more space
<marcan>
I guess that still gives bus contention on SDA on the way back
<marcan>
unless we add a series resistor
<whitequark>
marcan: ok so take a look at tca9544
<whitequark>
if we run that chip at 1.8V
<whitequark>
i think it will work
<whitequark>
>. In order for the TCA9544A to act as a
<whitequark>
voltage translator, the Vpass voltage must be equal to or lower than the lowest bus voltage. For example, if the
<whitequark>
main bus is running at 5 V and the downstream buses are 3.3 V and 2.7 V, Vpass must be equal to or below 2.7 V
<whitequark>
to effectively clamp the downstream bus voltages. As shown in Figure 16, Vpass(max) is 2.7 V when the TCA9544A
<whitequark>
supply voltage is 4 V or lower, so the TCA9544A supply voltage could be set to 3.3 V. Pull-up resistors then can
<whitequark>
be used to bring the bus voltages to their appropriate levels (see Figure 15).
<whitequark>
marcan: so BOTH sides of TCA9544 can be above its Vcc
<whitequark>
of course, we don't have 1.8V, we only have 1.2V, which is below the spec
<ylamarre>
whitequark: Are there plans for an FX3 version eventually? Just curious.
<whitequark>
ylamarre: yes
<whitequark>
there's no point for FX3 with ice40 for the most part
<whitequark>
the fabric isn't fast enough
<ylamarre>
Obviously
<ylamarre>
Artix7?
<whitequark>
no, ecp5
<ylamarre>
Hm, yeah much cheaper too...
<ylamarre>
But those LUT4 :-/
<whitequark>
i'm far more interested in OSS tooling and speed of PNR
<whitequark>
than some theoretical density advantage
<ylamarre>
Looking forward to it.
<ylamarre>
whitequark: Understood and agreed.
<marcan>
whitequark: so here's a dumb idea. the TCVA9534 is *very* vague about requiring the I²C bus to be < Vcc. It's under recommended, and it says "The SCL and SDA pins shall not be at a higher potential than the supply voltage VCC in the application, or an increase in leakage
<marcan>
current, II
<marcan>
, results."
<marcan>
what if we just... don't shift?
<marcan>
what *happens*?
<ylamarre>
Thanks for the answer!
<whitequark>
marcan: hrm
<marcan>
3.3 / 0.7 = 4.71 which is under spec but *barely*
<whitequark>
marcan: i understand that htey have protection diodes there
<marcan>
like for all I know this might just *work*
<marcan>
have we checked?
<whitequark>
which is what the leakage current refers to
<marcan>
that usually means *clamp* current
<marcan>
not *leakage* current
<marcan>
which is why I'm confused
<marcan>
gotta go, bbiab
<marcan>
whitequark: per spec I think the TCA9544 could work but we'd need to power it at 2V or something like that, which is not a voltage we have lying around
<whitequark>
yep, we'd need another LDO just for it
<whitequark>
well... maybe not even an LDO
<whitequark>
marcan: it consumes under 100 microamps
<whitequark>
i think that's a resistive divider alright
<marcan>
heh
<marcan>
could work, yeah
<whitequark>
i mean we could put an LDO there i guess
<whitequark>
dunno
<whitequark>
marcan: ok, please look at... a few things, i guess
<whitequark>
you're the person with mouser
<whitequark>
i'll make sure we can apply workarounds to Cx subrevisions
<marcan>
I'm going to mess with the one I have first
<marcan>
see if magic caps in the right place, or resistors, does anything
<whitequark>
sure
<marcan>
looking at the layout, fitting a TSSOP-20 in here is going to be a massive pain
<whitequark>
we can shift the other tssops to the right
<marcan>
*maybe* just about doable, though I don't know what will happen to the silkscreen around the right edge
<whitequark>
yep
<marcan>
anyway, gotta go
<whitequark>
marcan: shittier workaround: one i2c gpio expander
<whitequark>
hopefully smaller than tca9544
<whitequark>
but... this is barely better
<marcan>
and bitbang the slaves?
<whitequark>
no
<whitequark>
EN inputs of TCA9517s
<marcan>
oh
<marcan>
sure but at that point just use the extra fx2 pins?
<marcan>
and worry about that for revD
<marcan>
I kind of feel that's the least-effort fix right now
<whitequark>
i don't feel very good about kicking this can down the road
<marcan>
what I mean is use the extra pins for revC
<marcan>
and an expander for revD
<whitequark>
yes, i understand
<whitequark>
but i'm still not very happy
<marcan>
I mean if this works that will work
<marcan>
well, actually, no it won't :D
<whitequark>
oh?
<marcan>
enabling/disabling the TCAs in the middle of an i2c transaction... to the expander itself...
<marcan>
bad idea
<marcan>
anyway, I really gotta go
<whitequark>
marcan: so i looked at a tca954*3*
<whitequark>
it's actually smaller than tca9534s we have
<whitequark>
tssop14
<whitequark>
i think we can fit it instead of the current shifters
<whitequark>
ttyl
wenna has joined #glasgow
<marcan>
whitequark: yeah, a priori I think I can fit that in without touching the pulls and the whole right hand side
<marcan>
gotta move all the resistors and gunk from the left of the pulls to somewhere else
<marcan>
decoupling might have to go on the rear, but that should be fine
<davidc__>
bgamari: a couple of local (small) board houses and PCB assy houses
<davidc__>
bgamari: note that I didn't actually go out and get quotes; I was just estimating by component count and prior experience
<davidc__>
bgamari: also, thats at ~QTY 50 or so
<bgamari>
ahh
<bgamari>
yes, at qty 50 that makes more sense
<bgamari>
my projects thusfar have generally been qty 5
<bgamari>
which makes a huge difference
<bgamari>
the bulk of the cost ends up being setup
<bgamari>
which would amortize out nicely at larger scale
<davidc__>
Yup. of that rough estimate, ~half was NREs
<davidc__>
Then there was the usual per-run setup that they hide inside the quantity pricing
<davidc__>
I had a local assy house that trusted me to give them good clean pick-and-place setup data for which I got better NREs, but they aren't around any more :(
<whitequark>
marcan: yeah, that's what i did too
_whitelogger_ has joined #glasgow
_whitelogger has quit [*.net *.split]
_whitenotifier-9 has quit [*.net *.split]
yorick has quit [*.net *.split]
zkms has quit [*.net *.split]
<whitequark>
heads up: I changed the revision numbering scheme in firmware/software
<whitequark>
it was revX, now it is revXN
<whitequark>
everything should transparently and automatically migrate