<sorear>
so if you take a revC board and snap it in half, the entire right hand side is level shifters and pulls :x
<whitequark>
lol
<whitequark>
autosensing for I2C is not *quite* as bad
<whitequark>
we no longer use it anyway
<cr1901_modern>
So the answer is multivoltage i2c is unsupported?
<sorear>
i2c is an implementation detail
<whitequark>
yeah
<cr1901_modern>
But you can still make your own i2c bus on the I/O pins. I was just asking while I still have bandwidth left for a coherent thought.
<whitequark>
we'll add a switch later
<whitequark>
oh
<whitequark>
no, that's different
<whitequark>
it's different because the I/O pins don't *bridge* I2C
<whitequark>
they allow you to implement a master or a slave or something.
<cr1901_modern>
oh so basically, "you're on your own" (for want of a better term) if you're implementing an i2c applet?
<cr1901_modern>
not applet, sorry
<cr1901_modern>
implementing an i2c bus*
<cr1901_modern>
Provide your own pullups, only master or slave (no multimaster/bidir stuff)
<whitequark>
hrm
<whitequark>
no, glasgow has onboard pullups
<whitequark>
and of course multimaster works just fine
<whitequark>
the only problem you'd get if you say... tried to put a "wire" between one SCL/SDA pair and another SCL/SDA pair
<cr1901_modern>
How is that possible if each level shifter has its own dir enable?
<whitequark>
exactly, it isn't
<whitequark>
you need pass transistors for that
<cr1901_modern>
Ahh whoops, let me retry. In general, how does glasgow revc multimaster work if the level shifters that connect to the I/O were changed (_AIUI_) from autosense to have an explicit direction pin?
<cr1901_modern>
the FPGA has to be conscious of the direction pin, so I don't see how it could react correctly to a bus that changes direction at any time
<tnt>
cr1901_modern: when you output 0 the fpga is sender, when you output 1 you're a passive listener. And if what you sense is a 0 then you have a collision.
<tnt>
bus doesn't "change direction".
<sorear>
FPGAs always have explicit direction, internally
<sorear>
revC just externalizes that
<sorear>
the direction signal to the level shifter is the same direction signal that used to go to the FPGA-internal tristate buffer
<whitequark>
^
<cr1901_modern>
Okay, that explanation makes sense, thanks
<sorear>
or to put it differently, the idle state of an i2c bus is that *everyone* is reading
<sorear>
when you want to put something on the bus, you switch briefly to writing, but that's a *local* decision
<sorear>
your level shifter doesn't have to care what anyone else is doing
<cr1901_modern>
It stopped making sense to me temporarily, I don't know what else to say :P
<sorear>
luckily most protocols don't try to transmit and receive simultaneously on the same wires
<whitequark>
so i'm wondering
<whitequark>
can you make a stateful i2c switch?
<cr1901_modern>
>we'll add a switch later <-- What's this refer to, btw?
<sorear>
I'm not sure I understand the question. If «switch» has the same meaning it does in Ethernet (transactions are not visible off-path), then you have to have at least one bit of state to remember which direction you're passing a transaction to after the ID has already passed
<whitequark>
yes
<cr1901_modern>
Is that what "switch" also means in the context of "we'll add a switch later (for the internal i2c bus"?
<whitequark>
no
<whitequark>
that's a completely different switch
<cr1901_modern>
Well I'm wondering what you meant, since it's distinct from my original question re: using the I/O for i2c :P
<whitequark>
that was not related to your question