<electronic_eel>
sorry for the noise, I broke my irc daemon and it didn't show that anything was posted
<electronic_eel>
back to the selftest - Do I understand the selftest code correctly:
<electronic_eel>
the pins-ext test first enables all output enables of the level shifters via reset_pins()
<electronic_eel>
then check_pins() enables the output enables only for the bits that are set to output 1
<electronic_eel>
the other level shifters now stay floating in high-zthe other level shifters now stay floating in high-z
<electronic_eel>
there are no pullups/pulldowns enabled unless in the pins-pull test
<electronic_eel>
I don't think this is gonna work reliably: floating cmos inputs are influenced by random stuff, they can demodulate rf signals, they get influenced by leakage currents in the picoamp range,...
<electronic_eel>
Even clearing the charges by shortly setting output enalbe in reset_pins doesn't really solve this
<electronic_eel>
To fix this I think the pulldowns should also be enabled in the pins-ext test. After enabling the pulls, there should be a short synchronized wait to allow the i2c transmission to finish, the pulldown really be activate and any stray capacitance be discharged through the pulldown.
<electronic_eel>
for pins-int we should use the internal pullups of the ice40 and set the bit-to-test to 0 instead of 1
<whitequark>
electronic_eel: you're absolutely correct that selftest is broken
<whitequark>
re floating cmos inputs: on revAB they weren't floating because of the bus hold circuits
<whitequark>
really, selftest makes much more sense if you consider it was written for revAB
<electronic_eel>
I haven't looked at revAB schematics, just know about revC
<electronic_eel>
maybe we should split it for revAB and revC?
<whitequark>
maybe! i haven't thought about this in depth yet
<whitequark>
internal pullups, hrm
<whitequark>
this won't work
<whitequark>
well, it can be hacked into omigen code but not nmigen code at the moment
<whitequark>
not without bringing back explicit SB_IO instantiation which is meh
<electronic_eel>
do you have a better idea to get the pins-int test to work reliably?
<electronic_eel>
I mean to get reliable voltage levels to the inputs
<whitequark>
fix nmigen, probably
<whitequark>
it's going to take a little while with my current workload
<electronic_eel>
sorry, I won't be able to help you there, nmigen is not my area of expertise
<electronic_eel>
but I can take a look at selftest when I received my Glasgow from Greg
<electronic_eel>
the pins-int can wait until you provide some primitives for internal pullups
<whitequark>
not asking you to as this is an API design question mostly
<_whitenotifier-3>
[Glasgow] electroniceel opened issue #151: False positive results in selftest - https://git.io/fjF6l
<_whitenotifier-3>
[Glasgow] whitequark commented on issue #151: False positive results in selftest - https://git.io/fjF6z
<_whitenotifier-3>
[Glasgow] electroniceel commented on issue #151: False positive results in selftest - https://git.io/fjF6V
<_whitenotifier-3>
[Glasgow] electroniceel opened issue #152: Add selftest for sync and aux pins - https://git.io/fjF6M
<_whitenotifier-3>
[Glasgow] whitequark commented on issue #152: Add selftest for sync and aux pins - https://git.io/fjF6H
<_whitenotifier-3>
[Glasgow] electroniceel commented on issue #152: Add selftest for sync and aux pins - https://git.io/fjF6x
<_whitenotifier-3>
[Glasgow] whitequark commented on issue #152: Add selftest for sync and aux pins - https://git.io/fjFie
<whitequark>
i wonder if it has only full speed on the usb 2 part
<electronic_eel>
don't know. but I guess I'll order one and take it apart
<electronic_eel>
want to have galvanic isolation for glasgow without loss of througput
<whitequark>
yes, this is a common request
<whitequark>
there's like 1 chip that can do it
<electronic_eel>
this hub is not exactly cheap, but a special isolation addon with all bells and whistles the regular Glasgow outputs have won't be cheap either
<whitequark>
a number of people have been talking about an isolated glasgow derivative
<electronic_eel>
the datasheet of this hub claims that it uses a Genesys chipset. I haven't heard of that one, thought only usb 2 @480 was available on the market
<electronic_eel>
yeah, a derivative would probably better than an addon, as you'd have to duplicate a lot of stuff with an addon
<whitequark>
on the USB side that is
<whitequark>
I kinda wonder if isolating I2C and FX2 bus is the easier way out...
<electronic_eel>
isolating i2c without help of the fx2 isn't easy, but I think there is some ic in the ADUM-line that can do it
<whitequark>
ADuM1251
<electronic_eel>
given the economies of scale I think it is cheaper to use regular glasgow with such a hub than a special isolated glasgow with very low production volume
<electronic_eel>
and such a hub can be reused with revD and E
<electronic_eel>
and some other usb gear too of course
<whitequark>
this is true, but making an isolated usb hub is very hard
<whitequark>
USB 2 to USB 3 transaction translators
<electronic_eel>
ah, ok, thanks. are they integrated into hub ics, like the ones for ls/fs?
<whitequark>
nope
<whitequark>
the spec doesn't allow it
<whitequark>
it's a hack made solely for 4K VR over USB C
<electronic_eel>
is that in the spec? or just something seen in the wild?
<whitequark>
it's not in the USB specs
<whitequark>
but you have to use it for VirtualLink
<electronic_eel>
hmm, couldn't one do something like usb phy - fpga - serdes - isolate - serdes - fpga - usb phy?
<whitequark>
obviously, that's a solution
<whitequark>
it's very expensive and very challenging because your latency budget is super low
<davidc__>
electronic_eel: IIRC that doesn't work due to some USB latency requirements
<whitequark>
when using ULPI
<whitequark>
no, it works
<whitequark>
it's just hard
<davidc__>
it might work in practice, but not to spec
<whitequark>
you can meet the spec
<whitequark>
I looked into it
<whitequark>
you have to do two source synchronous interfaces
<whitequark>
so, one FPGA, two ULPI transceivers, and the far end (isolated) one is clocked by your FPGA via an isolator and that clock is then returned through a different isolator
<whitequark>
this means your design can be fully synchronous and you don't need additional buffers
<whitequark>
i.e. your latency is essentially 1 ULPI clock
<whitequark>
you need a *lot* of isolated pins though.
<davidc__>
probably easier just to optically isolate PCIE + stick a USB host controller at the end of the cable
<whitequark>
then you need a PCIe host...
<whitequark>
so it won't work unmodified with any other device