Final day, final post, I will explain the things I managed to finalize this week as well as the thing that I couldn’t get to finish.

I created a Flippable Master SPI. This master SPI can flip it’s MOSI and MISO pins depending on the value of it’s configuration register. The device has 4 output ports, SCLK, SS, datA and datB. When the configuration register at address zero is NOT SET datA is an input representing MISO and datB is an output carrying MOSI and vice versa when the configuration register is set. By default the Configuration register is not set. This Flippable Master SPI is to be used by the system to communicate with the SD card and the PIC.

In addition, to increase the portability of our synthesis software we needed to be able to specify the location of the Xilinx license files based on our preference. Normally Xilinx License Manager (XLCM) searches by default in $home/.xilinx for the license file.  There is two variables that can specify locations that the software scan for license. The variables are called XILINXD_LICENSE_FILE and LM_LICENSE_FILE. I couldn’t find any difference between the two variables so I ended up using the first one. This is an environment variable that need to be initialized before running the Xilinx software. I added it to my synthesizer and data2mem classes.

As for UART, I rechecked the code and finalized it. The device has been tested successfully by simulation and by FPGA implementation where it communicated with Minicom. The UART device can operate with various setups. To choose the baud rate, the user need to set two parameters one is the actual clock frequency running the UART and the other is the desired baud rate. The device will set it’s own clock divider values to achieve this baud rate. Moreover, the device can support different sizes of the data byte from 5 to 8 bits per transfer. The device can send either one or two stop signals. Finally the device has the ability to generate and check for different kinds of parity.

The transmitter and receiver use the same settings. However, both of them have separate clock dividers, Bit counters and Parity checks. This way they are completely independent. Moreover, if the designer wishes to operate the transmitter and receiver at different settings they only need to edit the parameters and create separate sets for each one.

As for the accelerators, the SHA1 is fully working and has been tested via simulation and on FPGA with the SOC. The RC4 slow and fast versions has been tested successfully by simulation and on FPGA. However, the two devices has a bug where the system performs as expected once the bit stream is written to the FPGA. However, once the reset button for the SOC is pressed the system stops responding. This bug remains hidden waiting to be solved. Nonetheless, when I tested the two versions of RC4 with the latest version of SOC on FPGA they both didn’t function properly. Chances are I made a mistake in connecting them to the SOC.

As for ECDSA, it successfully passed simulation tests with the processor but failed when it comes to FPGA implementation.

The current SOC uses only 32 K of block RAMs. In order to use the full 64 K of LX9 RAM the BMM file and UCF file need to be altered to include the extra 32 K of RAM. The current BMM and UCF file should be more than enough as an example to create the new files. I used the Plan Ahead floor planning feature to obtain the locations of block RAMs.

 The UCF file for the SOC has been used in many simulations successfully without adding the specifications for the pins. I didn’t have time to add all the proper pin specifications to the file.

Categories: Experiential


Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.