BRAM Size before Synthesis
This week continues with the issue that I had opened previously, which is on the issue that some file is not updated before the synthesis starts. This was a mistake made by the previous intern, that the ramSize (BRAM size) that is needed for synthesis is never been specified correctly on the most updated design.
Update the Ram Size for Synthesis
Despite knowing the problem, solving it is a big headache, because it involve the alteration on the synthesis flow. The main problem is due to the ELF file is not generated before the HDL file generation as previously discussed in my blog.
So I came up with several attempt to solve this problem, but to generate the ELF file, it requires the WResource to run a function on another WContainerWidget. Where I also found that the usage of
static function could actually be used to call the function from another class. But this is not a good solution for it because static function would also require static variable in it.
The final thought is to create an additional handle request function to handle the ELF file generation. This way is much more organized because the code flow can be terminated on any stage if it fails to generate the ELF file. This function will also generate the ioMap.h before the ELF file request is sent.
Found Bug in the Progress
As I work on the generation of ELF file towards the generation of Ram Size file, I also fixed some bug on the file usage that had been created by the previous intern. That also makes me wonder how does those code actually worked previously.
But then I found that my concept on my usage of WFileResource is actually incorrect. Where previously I try to respond back an error respond if the synthesis process is killed, by redirecting the file output with an invalid path using the code
this->setFileName("/invalidPath"). This is completely wrong because the resource actually set the latest output file path to the invalidPath, which will result in an error even when the new synthesis process is completed.
Draw out the GPIO module
Besides, I drew out the GPIO module that had been inferred from, to monitor the real address that the processor should be written to. This time, I found that I could understand the GPIO module better compared to the first time I was learning it.
Next week, I will fix the data and control register address that the processor should be written to in the ELF file.