ATtiny roles in Rev3

[josuah]

Here is a discussion to start anticipating the role an ATtiny could have on such a module, for inclusion in Rev3 instead of the GPIO expander.

[josuah]

GPIO expander:

• Toggle the clock enable pins
• Toggle the LDO enable pins
• Toggle the FPGA PROGN pins
• Toggle the FPGA image selection pins
• Toggle the external GPIO pins
• Toggle the JTAG EN pin
• Toggle an interrupt PIN towards the FPGA upon certain condition (i.e. undervoltage, over-temperature)
• Provide extra SPI select lines integrated into Zephyr.
• Control the Devkit LEDs (i.e. blink pattern to indicate error)
• Control extra Devkit switches

[josuah]

ADC sensor

• Probe the VCC voltage rail to detect over/under voltage
• Use the NRESET pin hooked to a pull-up resistor as a probe for a different voltage rail
• Probe the internal temperature sensor
• Use extra signal lines as sensor for extra voltage line (i.e. I2C)
• Use the spare GPIO pins as possible extra input from outside the board

[josuah]

Signal generator

• Use the clock input from the on-board clock as an optional clock source (increases stubs and clock jitter?)
• Use the clock output as extra, scaled-down clock input for the FPGA
• Use timers to provide PWM-style signals
• Integrate several external GPIO pins as interrupt sources and merge them into a single interrupt pin, requiring to probe the source over I2C.
• Expose out the analog comparator, with the output signal towards the FPGA.
• Use the internal LUT to expand the I/O capability of the FPGA.

[josuah]

Extra digital interface

• Expose the UART/SPI over I2C for more interfaces,
• Bit-bang extra UART/I2C/SPI buses using timers,
• Use the logic gates as a MUX for multiple data interfaces into a single FPGA pin to allow the FPGA communicate at relatively fast speed to more devices

[josuah]

Storage and management interface

• Provide a board serial number into a FUSE region accessible over I2C
• Encode the board revision and variant into the serial number.
• Provide a fail back mechanism and extra logic for when the FPGA does not boot (i.e. blink and LED)
• Provide self diagnostic algorithm with error codes
• Add a shell over UART as a debug interface to do i.e. an I2C scan or dump the error messages.
• Export the real-time clock to the FPGA for counting the time the FPGA did stay sleeping: absolute uptime of the board.
• Perform I/O with the flash to compute a checksum before booting an FPGA image.
• Turn off all voltage rails with a "wake-up reason" configured inside the MCU, eventually processing data to take decision about when to wake-up.

[josuah]

No Attiny :) This is a choice for the client, not needed on-board.