Reloading FPGA bitstream causes all outputs whose Vio is enabled to strongly drive high

[whitequark]

This unfortunately happens because the reset state for the FPGA is pull-high, which translates to DIR=H (B=A), where A is FPGA-side and B is DUT-side.

Solutions:

1. Turn off Vio during FPGA reconfiguration and wait for the output cap to discharge before proceeding.
   • Pros: costs nothing.
   • Cons: slow, turns off DUT power which is undesirable, makes Vsense alert even less useful.
2. Add pulldowns on Dxn nets.
   • Pros: preserves existing design as much as feasible.
   • Cons: another BOM line, @esden has 4000 revC3 PCBs.
3. Switch to 74AXP1T45 and swap A/B.
   • Pros: improves performance of the device, doesn't add a BOM line.
   • Cons: @esden has ~2000-3000 boards worth of SN74LVC1T.
4. Power gate the FPGA bank or the IO drivers
   • Pros: zero new BOM lines, one added part
   • Cons: really awkward solution, may have unintended consequences

Swapping A/B on SN74LVC1T isn't feasible since this level shifter is asymmetric.

We have to implement (1) anyway to handle the existing devices; we must implement (2) or (3) for revD. What is not clear is whether or when revC4 will be designed, tested, and put into production.

[smunaut]

You can also power gate the VCCIO of the FPGA bank. Either using a power switch or having two 3v3 rail ( fed by another TLV75533PDRVR with a different EN line). Not saying it's a great option, but it's a fourth option.

Or shutdown the 3v3 to the IO drivers actually, that will also make them hi-z.

Either way, it's a bit similar to (2) since you can keep most of the design, but adds at least 1 part (albeit an already used one) but you can't keep the PCBs.

[whitequark]

Thanks, added.

[nekrondev]

Many thanks for building and maintaining glasgow... I've got a question regarding this issue ... how practically does this affect using the current device revision (C3)? I'm new into this and can't reason about it if it's only an issue when there is some edge case hacking where you need to power the DUT or does it interfere using glasgow with some common setup? As this hasn't been detected during the different PCB version integration tests I guess it should be a minor concern, right?

[whitequark]

@nekrondev We'll deploy a firmware based fix that only has trivial effect on usability of device (slight delay added to firmware reload).

[whitequark]

Apparently we did notice this... back in 2019: https://github.com/GlasgowEmbedded/glasgow/issues/96

[whitequark]

While working on this (testing it with the UART applet) I discovered another buggy behavior in transients:

Because the FIFO interface was turned off before the FPGA was reset, and because turning it off meant that several active-low flags would go permanently low, applets would receive an endless stream of phantom zero bytes. This could potentially cause very undesired operation.