The FPGA daughterboard embedds an Igloo AGLN250 chip in a VQ100 package, driven by a 10 MHz clock.
The board is powered either through an USB-C connector (+5V, providing a JTAG access along an USB-UART converter) or through the motherboard via an external +5V rail.
It will automatically resolve the path if both supplies are wired simultaneously, choosing the motherboard +5V rail in priority.
Internally, it will create a +3.3V rail used by both the FPGA and the motherboard, plus another +1.5V rail for the FPGA core supply.
The board can be programmed through its USB-C connector with the help of OpenOCD and some custom scripts.
But for now, a Microsemi FlashPro 4 can be plugged into the 10 pins and used with the Libero IDE.
Both the USB and the FlashPro can be plugged at the same time. The FlashPro gains priority over the USB JTAG signals.
If the daughterboard is not plugged into a powered motherboard, it is necessary to plug both the USB-C and the FlashPro to be able to program the card. Else, the FPGA will have no power.
If extra JTAG chips are present on the motherboard, the latter enables an extra signal which will re-root the JTAG lines through the motherboard. It is not the case in the Kart project for now.
Connection with the mobo
The board is linked to the motherboard through an SODIMM-200 connector (the 200 gold fingers on the FPGA board). By design, it cannot be inserted the wrong way.
The connector pining is shown here.
A button is found on the board to reset the FPGA. Be careful when pushing it while it is inserted in a motherboard (do not force on the SODIMM connector).
A LED indicates that the board is powered (top right of the board), while a second (found near the USB connector) shows in and out transaction over UART.
Red, yellow and green LEDs are found under the power indicator and can be freely controlled by the user.
The board also embeds a Power on Reset circuitry that will detect low FPGA voltage and reset it (discharged batteries, too high current consumption ...).
It is possible to emulate the BLE module to test the system without the Android application through a custom utility.
In addition to the dedicated modules testers, the overall behavior can be tested through the Kart_test -> kartController_tb block.
This simulation differs a bit, since the internal tester layout is the following:
The tester will read the commands given in $SIMULATION_DIR/Kart/UVM/uvmCommandsStudent.txt, and create different logs under $SIMULATION_DIR/Kart/UVM/outXXX.txt. The file can be modified without the circuit being recompiled.
The corresponding simulation layout file for Modelsim is available under $SIMULATION_DIR/Kart/kartStudent.do. It will automatically run the simulation if it has not been modified.
All the student-designed blocks are tested (read both target and info signals).
Contrary to the other testers, there is no direct error logging. One must check the functionality "by hand" (by correlating signals with the info from the transcript window or the log files).
Another tester, checking the whole system (including Rx/Tx frames, registers managers ...) can be loaded through the Kart_test -> kartController_full_tb block and the $SIMULATION_DIR/Kart/kartStudent.do file.