In this week I was given reading permission to the firmware of the board. Starting to look into the project, I get a better picture of what it is all about.
My first task is to get the mechanism of Spartan-6 FPGA programming work. This involves a few steps. First, download the code sent by user through the Cross-Origin Resource Sharing (CORS) communication protocol. What CORS does is basically identify the permission of resource sharing via a sequence of HTTP request to make sure only the requests come from our end get proceeded and block the others. For example, in our case PUT request allow writing to the FPGA, but before this a sequence of OPTIONS->DELETE->OPTIONS requests must take place otherwise the PUT request will be rejected, this is done by a state machine that surveillance the HTTP request. Second, get the FPGA into programming state by toggling the PROGRAM_B pin of FPGA and wait for INIT_B pin to react as specified in UG380. Afterward, the FPGA is ready to be programmed.
Third, read the content of the PUT request, which contains the code to be program into the FPGA, via Harmony Network Presentation Layer framework into a buffer, then write from buffer directly into the FPGA until the DONE bit of the FPGA goes high which indicates the programming is done. Usually, the writing to FPGA is done through SPI communication, but the SPI pin for FPGA programming was misconnected on the PCB board and unfortunately other SPI data and clock pair are not available. But there is always a way and nothing could ever stop these elite engineers, they have decided to simulate the SPI communication with usual GPIO PIN before the next printout of the board (the fabrication of a prototype is never going to be inexpensive). At this point, we “blind fed” all the content in PUT request into FPGA, including the header which is not part of the code to be programmed, as the FPGA can recognize the pattern of its code and ignore the others. This is not the best solution but we will surely improve it after the basic mechanism is settled.
In fact, these have all been done before but as the firmware of the board keeps on developing and new features being merged into it, this function has not been tested for quite a while until recent which somehow is not working anymore. After some testing on the code, I found that the program gets stuck on waiting for the INIT_B pin to react. Turns out the problem is just the GPIO connected to INIT_B is accidentally set to output mode in Harmony configuration. Just some minor tweak of the code then the FPGA works as it should.
Afterward, I am to collect some statistic of the speed of FPGA programming and its reaction to the change of TCP receiver buffer size and system task delay as for now the programming took quite a while to finish, we need to find the optimum condition for the FPGA programming to run effectively. In order to collect reliable statistic, we need quite a few samples for each condition, which is very time-consuming. And so I need to use Bash Script to automate the repetitive step of data collection such as sending requests to the board and record the time it takes. Bash Script is basically the script that runs commands, but I have not touched this before, so, study time again. Well, when will the learning come to an end? Guess it would not.
0 Comments