4 hours ago, Wavicle said:
The SPI flash is also used to configure the FPGA during reset, a sequence which is driven by either a hardware state machine or embedded microcontroller. If the CS pin for SPI flash goes low, that component must start responding or the FPGA will fail to configure itself properly. You could use an SR latch connected to the SD's CS (set) and reset (reset) to drive a multiplexer select, but that's adding even more external hardware.
A hardware state machine or embedded microcontroller inside the FPGA, or outside? Below, I am presuming inside, since if outside, it would go through an AND with the CS_flash line from the FPGA and there would be no change.
With the external decode, if the the FPGA puts out %01 on those pins, then the CS pin for the SPI flash WILL go low.
If the build is logic resource bound, that is more logic to have the FPGA reset state machine drive CS_flash low AND CS_SD high, independent of the simulated register state (or, during FPGA reconfiguration, existence!) versus the status quo where it only drives CS_flash low and that is nothing but an AND.
It's also less logic to have it not decode the state of CS_flash and CS_SD from the two setting bits in the register.
But the logic is likely not in the same place.
So ... well, if it builds, it builds, if it doesn't, back to the drawing board.
Then there is the mystery pin. If it is available (at least when none of the three are decoded) and CS2, CS1 and CS_flash=CS0 are taken out, then you can have three external selects with a single three to eight decoder: CS_SD=%001, CS_EXT1=%011, CS_EXT2=%101, CS_EXT3=111. With CS_flash directly to the flash and decoded %xx0 not connected, the CS_flash select effectively over-rides the SD and External selects, with no FPGA logic required. That's a single glue logic, pull up resisters and a pin block header. And the pin block header is smaller, to boot ... +3.3V, GND, SCLK, MOSI, MISO, CS_EXT1, CS_EXT2, CS_EXT3 ... 1x8 long/wide.
On the debug serial port, how usable is the debug serial port as-is, if operated from the X8?
If it's an I2C bus master, and the I2C bus being mishandled is why you need to debug, I don't know enough about I2C and what would likely be already built into the fpga dedicated serial module to know if that is problematic. If that works, heck, just add that to the block pin header and make it 10 long. I2C_1, I2C_2, +3.3V ... or for a more stable base for a hat, a four block pin header with I2C and power, and a six block pin header with just SPI, on parallel edges.
I don't know enough about I2C to know if this is what you were proposing or it it's feasible, but if for debugging purposes, the UART/I2C bridge is connecting with the X8 acting as an I2C peripheral, that's a really appealing change, since then doing the same thing without the UART means the X8 can be plugged straight into the X16 I2C bus.