GlasgowEmbedded
revD minispec
Summarizing the broad design points regarding revD in one place:
- Four I/O banks (ABCD) instead of two (AB)
- Placement of AB and CD so that addons developed for revC work on revD side by side (at least if width allows). That means relative position of AB and CD is the same as AB on revA-C.
- No LVDS bank.
- Goal: we should provide I2C and power to ports. Proposal#1: put I2C on NC pins in the 20-pin connector, put GND/3V3/GND/5V on a pin header next to 20-pin connector. Proposal#2: put SDA/SCL/GND/3V3/GND/5V on a pin header next to 20-pin connector, leave NC pins as NC.
- Goal: I2C on ports should not impact reliability due to faults such as stuck bus. Proposal: use 1:4 I2C level translating passthrough switch such as PCA9545A with dedicated reset pin.
- Problem: we run out of I2C addresses (definitely on PCA6408, possibly on DAC081 without change of package). ~Proposal#1: change PCA6408 part and DAC081 package. Proposal#2: expand passthrough switch from (5) to 1:8, use identical parts to revC (simplifies production!).~ Proposal#3: Change only DAC081 package to allow four addresses.
- Placement/layout sketch: https://marcan.st/transf/Screenshot_20190510_145158.png
- Proposal: replace ADC with INA233 to allow for precise current and voltage limiting (#165). Existing 0.68 ohm resistor BOM line could be used for the shunt. Vsense range is also expanded to 0-36 V.
- Proposal addendum to (8): Connect INA233 ALERT pin directly to LDO EN pin, adding a resistor between FX2 GPIO and LDO EN. This way, any voltage or current fault condition will lead to immediate port shutdown, significantly improving safety.
- Consideration: if there is free board space, some sort of low pin count RAM would help with streaming workloads. Only a "nice to have" and should be dropped if troublesome at all. The RAM chip should be PSRAM, either QSPI or HyperRAM.
- Consideration: if there is still free board space left after (10), perhaps on underside, add a DNP footprint for SPI Flash connected in parallel to RAM.
- Proposal: expose Vref DAC output on extension connector from (4) to accomodate @electroniceel's advanced IO protection board.
Placement of AB and CD so that addons developed for revC work on revD side by side (at least if
width allows). That means relative position of AB and CD is the same as AB on revA-C.
This could be solved by an adapter board which can be plugged into revD and which provides connectors with the same width as revC.
For this to work revD has to be wider and the position of the new connectors must not intersect the position of the revC ones.
It might make layout easier if we want/need to use a different layout than what marcan proposed. Such an adapter board would be dirt cheap and I don't think many users with revC addons would mind.
But it needs to be produced, packaged, sold, assembled, etc. And then you have to not lose or forget it.
The only thing better than solving a problem cheaply is to not have it in the first place.
Another point: my I/O protection board will work easier and better if it has access to the IO voltage DAC output. I suggest to put that on the addon pins too. We could replace one of the GNDs proposed above, there are enough GND pins on the port header already.
The reason I suggested using this many GND pins on the extension connectors is to make shorts between adjacent pins a little less destructive (short to GND generally stresses the LDO, short from 5V to 3V3 will stress all logic on 3V3 too).
yes, the new header. Not change the existing 20 pin header. I suggest using female connectors for the new header. It is harder to short these.
Another point: my I/O protection board will work easier and better if it has access to the IO voltage DAC output.
I'm confused. Isn't that just Vio already?
What is the use case for this keying? If you plug in single wires, a keying won't matter. If you plug in full addon boards, these won't fit into the 20 pin header the wrong way, so the other connector fits too.
I think of regular female pin header, something like this: https://lcsc.com/product-detail/Pin-Header-Female-Header_HOAUC-2685Y-106CNG1SNA01_C350307.html Getting keyed ones might be more expensive.
I guess it's fine. If it's not centered wrt 20 pin header, then plugging it the wrong way wouldn't result in electrical contact even if you try to plug in the board one pin off and it skews.
Another point: my I/O protection board will work easier and better if it has access to the IO voltage DAC output.
I'm confused. Isn't that just Vio already?
I explained it somewhere, but don't find it now. Probably on IRC. Overvoltage will be current limited, but the current still has to go somewhere. Vio might rise above the programmed voltage if there is not enough other load on it. So there will be an opamp and transistor to drain it. But the opamp needs some reference value to compare the current Vio against. The DAC output voltage is this reference value.
More details here: https://github.com/electroniceel/io-protection-notes/tree/master/vio-discharge-sim
The DAC output voltage is this reference value.
Makes sense. One problem is that it's not actually the same as Vio, there is a more complex function between the DAC out and the Vio voltage.
Makes sense. One problem is that it's not actually the same as Vio, there is a more complex function between the DAC out and the Vio voltage.
That is already accounted for, see the U3 opamp in my simulation schematic.
revC1 has VDAC test points on the back for exactly this use case. The voltage scaling would be the same for revD, just on a regular connector which doesn't require the user to solder bodge wires.
I am a bit worried about making VDAC a part of our "public API". What happens with revABCD compatible sockets on revE?
Will revE not be only SYZYGY and you need a SYZYGY-to-regular-glasgow-port addon? If so, the addon can have a similar dac-to-ldo configuration.
Will revE not be only SYZYGY and you need a SYZYGY-to-regular-glasgow-port addon?
I was thinking about including one or two legacy ports somewhere, since it's so convenient to do some wirewrapping to them.
ok, but why should we develop some new DAC/LDO scheme for these regular ports? I think it works quite well as it is now.
If we ever have to change it, we could either add an opamp to Glasgow to keep compatibility or respin the protection board with a jumper to select the correct ratio. Or a more automatic way with autodetection and a mux.
If there is enough board space left: add a DNP SO-8 footprint for a SPI-flash connected to the FPGA to load/store user data from in a setup without host.
We can use PCA9544A as the I2C mux, connecting all of our level translating GPIO expanders behind it. It has four interrupt inputs and one interrupt output. We can connect the INA233 alert output to PCA9544A interrupt input, and PCA9544A interrupt output to the FX2 interrupt input (which is also shared with FPGA alert pin). This way, a PCA9544A reset followed by a register read should give us the exact faulting channel, which seems reliable enough to me. Also, in this scheme, we do not need any diodes and can connect INA233 alert output directly to LDO EN input.
Note that while PCA9545A is a voltage translating I2C switch, I think we should run all of its subordinate buses at 3V3 as well. First, the ~INTn inputs are referenced to the bus pull-up voltage. Second, I think the connected extension board should not be forced to interoperate with Vio level I2C but 3V3 level I2C. So we would keep the voltage translating PCA6408 IO expander (and use it for translating) even as we use a voltage translating I2C mux (and do not use it for translating).
How do we deal with the too few I2C addresses for the PCA6408? Is the PCA6408 for pullup/-down of a port connected to the same I2C sub-bus as the addon board on this port?
The list of available I2C addresses becomes part of the addon interface guarantee, right? We already use up a lot of address space for common stuff (like EEPROMs, DAC, an addon might also want to use the tried and tested PCA6408 to switch something onto the pins of the port,...).
So I'm more leaning towards splitting the I2C bus into smaller bits by using a 8-way switch like the TCA9548A. Just the fx2 eeprom would be directly on the bus as the fx2 wouldn't start without, and the TCA9548A. We'd then have 4 sub-busses for internal stuff, including the PCA6408 for pullup/-down per port. The addon connectors each get their own sub-bus, so that just the address for the TCA9548A and the fx2 eeprom is blocked from usage on the addon board. Also a broken addon can't interfere with the glasgow controlling it's pullups/-downs.
I think all the I2C busses, including the ones on addon boards, should just run on 3V3. This makes it easier and prevents unexpected trouble like oscillating i2c-level-shifters and the like.
The list of available I2C addresses becomes part of the addon interface guarantee, right? We already use up a lot of address space for common stuff (like EEPROMs, DAC, an addon might also want to use the tried and tested PCA6408 to switch something onto the pins of the port,...).
This is a good point. I did not realize that the addresses used by Glasgow-internal I2C devices become "holes" in our I2C addressing scheme. I think your suggestion makes a lot of sense.
The 8-way I2C switches don't have integrated IRQ handling, so we have to use something else. Here is a quick sketch of what I propose:
In response to "<whitequark> that seems kinda like the worst of both worlds":
This adds a 74HC4066 analog mux to the diode logic I proposed earlier in #165. This analog mux allows the user to select between each INA233-Alert only shutting off it's own port and each Alert shutting off all ports simultaneously in hardware. While you could think of use cases where you for example just want port A and B shut off together, I think offering either global or local shutoff will allow a reasonable behaviour for most cases.
But we can now handle both cases fully in hardware, with quick response and no software handling necessary in the FX2.
The Reset for the TCA9548A I2C switch and the 74HC4066 global/local shutoff will need 2 more GPIOs on the FX2 which aren't free.
- The reset for the TCA9548A could be wired together with the FX2-LED. The FX2-LED will be on as soon as code is loaded into the FX2, the TCA9548A will need to be high most of the time. Only in case we really assert a reset the pin will be pulled low, resulting in a short, but probably not noticeable flicker of the LED.
- The ICE-LED could be rewired directly to the ICE40. It only lights up if gateware is loaded and could be hard-wired high by default in gateware. Then we get one GPIO on the FX2 to control the 74HC4066 global/local shutoff.
I'm really unhappy about the increase in complexity. I think neither the hardware global shutoff feature nor the reduction in reserved addresses is really justifies adding all this.
After discussion on IRC and careful consideration I changed my mind. Let's prototype this. Instead of rewriring ICE-LED to iCE40 we should rewire it to CDONE, I am not sure why it's not already done that way.