Search for System Bugs
This week, I continued with my previous week task, to find the way on how SPI C code actually work with the Verilog module. I stared on the same circuit for hours, but then I still could not find the way to integrate them together. And finally I decide to search in the Internet, finding as many clue as I can.
However, then I realized that the SPI module that the previous intern written has only two address that control the data and status of SPI, which only affect the data output of the SPI module. The next approach on this problem would be trying the testbench codes. The previous intern has did a good job in generating the VCD file to be examined with GTKWave analyzer. However, I found there is a lack of documentation in the code, where it is hard to understand how the things actually work, unless the circuit is drew and compared with.
There is a C++ simulation code that had been done by other intern as well, where it seems to be written for the Verilog module. Thus, I try to integrate the C++ code in a way similar to the existing GPIO module, and tested the compilation as well.
I try to break the whole system, where I use Jeunn Hao’s application as well. Sometimes, the project may crash, but I still could not determined what is the cause of it. However, as I try it more often, I found bug that the synthesis process that would still continue running synthesis even the browser/tab had been closed. This create wasteful of resource to process it because the bitstream file has already been sent back to the user cloud storage before the updated bitstream file actually been synthesized.
Thus, I implement a terminate function for synthesis, where it is triggered by using jQuery
Hopefully by next week I would be able to find more bugs on the system, especially on Jeunn Hao’s work, and complete some documentation.