-
Power Considerations
08/20/2018 at 00:12 • 0 commentsThe primary power input for the board will be +5V from the USB connector. This will need to be regulated down to +3.3V for all the circuitry on the board. In the case where the flash memory is populated on this board and it is connected to provide the image to the target FPGA, it should not be necessary to connect the USB cable and the board will draw power from the target board through the PMOD or UEXT connector. To enable two different power sources, a diode is placed in-line with the USB power input and a Pch MOSFET is connected in-line with the PMOD/UEXT power pins. The gate of the MOSFET is connected to a voltage divider from the USB power input so that the MOSFET is off when USB power is present, and enabled when only the PMOD/UEXT power is present. The gate is also tied to PA28 on the MCU so that the controller can detect when USB power is present, and so that it can also override the signal to deliver power from USB to the PMOD or UEXT connectors for additional flexibility.
-
Connection Details
08/20/2018 at 00:03 • 0 commentsHere are details on the connector pinouts:
Micro USB
1 VBUS +5V 2 PA24 D+ 3 PA25 D- 4 nc ID 5 GND GND PMOD
SSEL PA09 1 1 PA19 RX MOSI PA08 2 2
PA18TX MISO PA10 3 3 PA17 SCL SCK PA11 4 4 PA16 SDA GND GND 5 5 GND GND +3.3V VTGT 6 6 VTGT +3.3V UEXT
+3.3V VTGT 1 2 GND GND TXD PA18 3 4 PA19 RXD CDONE PA17 5 6 PA16 CRESET SDI PA10 7 8 PA08 SDO SCK PA11 9 10 PA09 SS_B Qwiic
1 GND GND 2 VCC +3.3V 3 PA22 SDA 4 PA23 SCL MAXDAP
+3.3V VTGT 1 2 PA31 SWD GND GND 3 4 PA30 SWC GND GND 5 6 PA14 DBG-TX nc nc 7 8 PA15 DBG-RX ID nc 9 10 RESET# Reset GPIO
1 VCC +3.3V 2 GND GND 3 PA02 AIN0/AOUT 4 PA03 AIN1/VREF 5 PA04 AIN4/VREF 6 PA05 AIN5 7 PA06 AIN6 8 PA07 AIN7 -
Board Strategy
08/19/2018 at 23:28 • 0 commentsWith a framework in mind and the host controller family selected, the next step is determining what all needs to be connected to the controller. Let's start by listing the features:
- USB connector
- Target Interface (SPI, I2C, UART)
- Analog/GPIO
- RGB LED
- Reset button
- In-circuit debug connector
The target interface consists of multiple interfaces and deserves some additional consideration.
The SPI interface will be connected to a serial flash device in parallel with the target FPGA. We can hold the FPGA in configuration reset and load code into the flash device on the target board, or we can load code into a flash device mounted on this board with the target board in configuration reset or disconnected. The SPI programming bus is located at two headers on the iCE40UP breakout board, one pinned out for an Ardvark connector which does not have any power, and one at a dual row PMOD header with power and 4 additional I/O. We will target the PMOD header so we have access to power and the additiona I/O. The Olimex boards connect the programming signals to a UEXT connector. In addition to the SPI signals, the UEXT connector also includes CRESET, CDONE and two I/O in the UART locations. The I2C signals in the UEXT connector are used for CRESET and CDONE, so we will need another connector to get I2C to the Olimex boards. To keep the board area down, I will add a Qwiic connector for the extra I2C port.
Since much of the code will be coming from Adafruit projects, I will use the same RGB LED connections found on the Tricket M0 and ItsyBitsy boards.
The debug connector will primarily be used for development so I will use a small SMT connector on the back side of the board that can be left off in production. There is a standard 50mil pitch 10pin header that is common with ARM MCU's and there is even room for a debug console UART if you follow the MAXDAP pinout from the MAX32625PICO board.
For the extra analog/GPIO signals, I'll include another single row header with an extra power and ground signal.
-
Where to begin
08/19/2018 at 22:54 • 0 commentsThe goal of this project is to make FPGA development much easier and more accessible, similar to the recent advances in embedded firmware development. We will need to address many of the same issues, like how to conveniently load code into hardware, and how to communicate with a computer, and how to support development on more than one operating system. Fortunately, many of the advancements in embedded firmware development are directly applicable so we can learn from them and apply the best practices.
The most operating system agnostic implementation that I have seen is the cloud based ARM mbed environment. While a cloud based development environment has limitations, the use of USB mass-storage class drag-n-drop for programming is a great idea that is spreading. There is a great summary of the genesis of the UF2 file format at the makecode blog which pretty much covers all the reasons why I have chosen to use this for the programming interface in this project.
The UF2 bootloader was originally implemented on the SAMD21 which is very popular at Adafruit. In addition to the bootloader code, there are many other open source programs available for this MCU (like seesaw and CircuitPython). In order to keep the scope of this project manageable, I will use the SAMD21 so that I can spend less time porting to a new platform, and more time on the critical features.