revD minispec

[whitequark]

Summarizing the broad design points regarding revD in one place:

1. Four I/O banks (ABCD) instead of two (AB)
2. 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.
3. No LVDS bank.
4. 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.
5. 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.
6. 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.
7. Placement/layout sketch: https://marcan.st/transf/Screenshot_20190510_145158.png
8. 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.
9. 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.
10. 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.
11. 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.
12. Proposal: expose Vref DAC output on extension connector from (4) to accomodate @electroniceel's advanced IO protection board.

[electroniceel]

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.

[whitequark]

Huh? Why use an adapter if we can just not have one?

[electroniceel]

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.

[whitequark]

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.

[electroniceel]

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.

[whitequark]

We are not going to change any GND pins on the connectors to non-GND.

[whitequark]

Oh sorry, you meant one new GND pin. That could work.

[whitequark]

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).

[electroniceel]

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.

[whitequark]

That makes sense. I think they should somehow be keyed, too.

[whitequark]

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?

[electroniceel]

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.

[whitequark]

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.

[electroniceel]

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

[whitequark]

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.

[electroniceel]

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.

[whitequark]

I am a bit worried about making VDAC a part of our "public API". What happens with revABCD compatible sockets on revE?

[electroniceel]

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.

[whitequark]

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.

[electroniceel]

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.

[whitequark]

OK. No objection to DAC out on accessory connector.

[electroniceel]

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.

[whitequark]

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.

[whitequark]

Actually, not PCA9544A, since it does not have a reset. PCA9545A seems fine tho.

[whitequark]

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).

[electroniceel]

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.

[whitequark]

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.

[electroniceel]

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.

[whitequark]

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.

[whitequark]

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.

[whitequark]

To add to this, the 1:8 mux allows us to strap every ADC/DAC to the same addresses, which is very nice and reduces errors as well as simplifies firmware.

[electroniceel]

As per discussion on IRC, remove the ATECC digital signature IC. Not enough benefit for the work of implementing the software for it.

[electroniceel]

as per discussion on IRC, the interface to the addon boards should have one pin for swizzling i2c addresses for stacking up to 2 addon boards. This pin is GND on Glasgow. An addon that is designed for stacking will set it to 3V3 on it's output connector.

Addon boards are expected to connect one address pin of their ID-EEPROM to this pin. If they have more i2c devices than the ID-EEPROM, they are expected to have an I2C switch, which address is also connected to the swizzle-pin.

[whitequark]

If they have more i2c devices than the ID-EEPROM, they are expected to have an I2C switch, which address is also connected to the swizzle-pin.

To expand on this, the reason is to avoid address collisions between one device on a bottom addon strapped to A=0 potentially having a conflict with a completely different device on a top addon strapped to A=1, e.g. if they have different address bits adjustable with address straps.

[DurandA]

Will you keep the ATECC508A/608A footprint or completely get rid of it?

[electroniceel]

Will you keep the ATECC508A/608A footprint or completely get rid of it?

I'd say there is no reason to waste space for it. That is unless there is actual interest in using the ATECC on Glasgow, with someone contributing code to make use of it (creating a CA, creating certificates, signing, checking,...)

revD will expose the internal I2C over the new addon interface, so you could also put a ATECC on an addon board, without any specific provisions necessary on the side of Glasgow revD.

[hardkrash]

Would changing the USB connection to Type-C legacy UFP Sink be acceptable? It involves a type-c connector and 2 resistors, no additional logic.

Could upgrade to have usb super speed streaming, but that's just icing on the cake.

[whitequark]

Would changing the USB connection to Type-C legacy UFP Sink be acceptable?

@esden was worried about assembly of these.

Could upgrade to have usb super speed streaming, but that's just icing on the cake.

Nope. Would need to change almost the entire design to have SS; that'll be revE.

[sslupsky]

Add a couple Pmod interfaces?

[whitequark]

@sslupsky Glasgow isn't intended to be a general purpose FPGA development board, so I would say Pmod interfaces are out of scope.

[sslupsky]

I was think along the lines of possibly using Glasgow with sigrok as a logic analyzer?

[electroniceel]

Add a couple Pmod interfaces?

You could design an addon board for Glasgow with a Pmod on top.

[sslupsky]

I think so. When do you think will the Glasgow be available for sale?

[whitequark]

I was think along the lines of possibly using Glasgow with sigrok as a logic analyzer?

Do you need Pmods for that?

[hardkrash]

I would leave specialty I/O for addons to attach.

In your instance a pmod snooping addon might be the best bet.

I would rarely use PMOD for my applications, and probably resort to jumper wires in that application as the -.1" connectors are easy to come by.

[hardkrash]

Would changing the USB connection to Type-C legacy UFP Sink be acceptable?

@esden was worried about assembly of these.

There are USB 2.0 only Type-C connectors that are pretty simple, no hidden pins and the like of a super speed version. I understand the desire to keep it simple.

Could upgrade to have usb super speed streaming, but that's just icing on the cake.

Nope. Would need to change almost the entire design to have SS; that'll be revE.

Makes sense.