Prototyping Results

In prototyping our design, we chose to focuse on a single aspect from each of the major design subsystems. For the Data I/O subsystem, we prototyped the on-board acceleromoter and the on-board light sensor as data inputs, and we used the on-board LEDs as data outputs. For the processor subsystem, we prototyped the hardware interrupts within simulation, and prototyped the base MSP430 HDL design on the FPGA. Details and results on each of these prototypes is listed below.



Data I/O Sensor and LED Prototype

The quickest and most direct path forward for this subsystem is to simply use the onboard sensors provided by the chosen FPGA evaluation kit. These sensors will be most easily accessed and do not require purchasing, implementing or debugging any additional external hardware. The variety and resolution of the sensors available on the board are sufficient to our needs in proving our solution.

The FPGA we decided on as a team was the Arrow DECA MAX 10 Evaluation Kit by Altera because it has a robust hardware design platform. MAX10 devices are the ideal solution for system management, I/O expansion, and communication controlling. It equips high-speed DDR3 memory, Ethernet networking, and many onboard sensors. Here are some pictures of it.

BoardPic1
BoardPic2
BoardPic3

One of the onboard sensor, Accelerometer, has been chosen for our prototype input source. Considering that the LED could be an output form, we sent the data into an LED driver, which classifies these data into different classes. The sensor uses SPI to communicate with the board. We use SPI to write the data into the sensor and fetch data from it. The data we can obtain from the sensor are loaded in three 16-bit buses, which represent the X axis, Y axis, and Z axis. We send the data from X axis into LED driver, to present how we manipulate these data by the LEDs.

The following two videos test the accelerometer and the light sensor. As shown in the first video, the LEDs are showing the X-axis value from the sensor. When there is an inclination in X-axis, the LEDs move to the corresponding direction based on the degree of inclination. The second video uses the light sensor to test the distance between this sensor and any other objects. In the video, when the light sensor is getting close to the desk, more LEDs are becoming lit.

Accelerometer Testing
Light Sensor Testing


Processor Interrupt and Hardware Prototype

Due to a previous NAU independent research program, SystemVerilog HDL for the MSP430 processor design was available to us. Our chosen job for prototyping this part of the design included two parts. First, we wanted to test the HDL design on the FPGAs. We wanted to find any issues with the design and correct them, and get to the point where we could verify that the design was indeed running on the physical hardware, not just in simultion. Our second task was to expand the design to accept hardware interrupts. The HDL as we recieved it was essentially a closed system, due to the lack of interrupt support. We needed to expand the hardware to allow external signals to change the instruction cycle and run interrupt service routines (ISR).

Interrupt Simulation Results

We were able to successfully expand the SystemVerilog HDL with the addition of an interrupt controller that decodes different interrupt request signals and interrupts the processor with the proper ISR address. Our MSP430 block diagram shows the added module and signals. Within the controller, if an interrupt signal is detected, it will complete the current instruction, then move to the ISR at the address provided. A waveform of the processor sucessfully interrupting is provided below. We programmed three ISRs to load the decimal values 17, 19, and 23 into registers R13, R14, and R15 respectively. As can be seen, these three values are successfully loaded. Both the second and third interrupt signal go high at the same time to test the priority of the interrupts, which successfully loads the higher priority interrupt first, then immediatly begins the lower priority interrupt. The processor is programmed with a running program during the interrupt test and it continues on to complete successfully after the end of the screenshot.

Interruptsimulation results