The stream of code bugs and necessary modifications continued running this week as well. I had to do some code modification, complete some features and solve some bugs here and there. This really took longer than I thought it would! Hopefully it will finish soon.
Customizable BRAM size.
I had already mentioned this issue in one of my past blog entries but since I was not done with it yet at that time, I didn’t talk in much details about it. This week I managed to complete this feature finally and to integrate it with our back-end.
The FPGA has a limited BRAMS resources (72 kbyte in our case ) and since in the project the we are carrying out the user need for memory can vary based on the C++ code he/she writes (instructions and data), here comes the need for having customizable memory size.
Based on the User C++ code size all the necessary files (SOC, UCF, and BMM file) will be modified (updated) every time to only meet the need of the user requirement of memory resources.
However, the current implementation is not 100% customizable and has some drawbacks since both memories (instruction and data) are limited to those values. 2k, 4k, 8k, 16k, and 32k byte. Meaning that if the user code instruction require 18kbyte the system will infer the 32kbyte model. Moreover, both memories (instructions and data) will have the same size each time although that might be a way more than the requirement for one of them (This is due to way the current memory module infer the BRAMs). That of course leaves some enhancement doors open in this area.
Top module syntax check:
Previously, the user top module used to be saved in the user directory (in the approot) directly after it gets generated and only gets processed when the user press the synthesis button where all the processes take place in on go but with our recent modification the journey of it has changed. The first two processes will take place independently form the latest. This step will report any syntax errors in the design and will feed these information back to front end server .If the design passes this step it will be saved to the user directory and will be waiting to be synthesized . This step is really necessary to capture any syntax errors in the design earlier.
Inconsistent error:
My bug for this week was in my code inconsistency of showing the errors. To be clearer I meant by the errors here both the syntax error and the error of giving the objects same Id number and by the inconsistency that each error is displayed to the user in different way. (popup and the other showing some hint icons on the error line in the editor)
So my task was to modify the code that the repeated Id error messages will be shown in the same manner of the syntax errors. Although that sounds easy at the first glance , the true challenge is that the last is not a real error. It’s only recognized as error in our application. And in the syntax errors the compiler feeds me with line number so the error is directly shown in the exact position but for the repeated Id and since I only get the information of the user defined templates from the object file I don’t have the line numbers info. which making showing the message icon in the same line of the object that has repeated id quite hard. I still have not worked around this bug. But for now if the user gives the same ID to two or more objects the message will be shown in similar way like the syntax errors but in fixed position in the editor (line 0 for now) which makes it .. hmm less inconsistent :\ .
This is it for this week !
Keep me in your prayers 😀 cheers!
0 Comments