This week a new millstone for the project release has been created. So we were working on closing our outstanding issues and completing the rest of the left features.
Changing the Object-List File Format:
Have you experienced the feeling that usually comes to a little kid who likes playing by his “building blocks” and making his own building structure.. and during one of his design he suddenly decides “out of nowhere” to take one of the block out … and then .. ALL the building falls down!?!? Well I got to experience this feeling last week. As some minor changes I did in the code lead to massive changes and deletion of considerable part of the code. This can be seen in the following paragraph. 😀
This week I was working on changing the format of the Object list file that contains all the necessary information to create the Verilog top module and used also by the schematic editor to both make the objects appear in the editor and to create the UCF file. The information previously was written in the file with format that we agreed on. All the information of any object is written in one line and in certain order. And in order to parse the file a long function was needed to extract the information from the file which made Dr. Shawn to ask us to change the format of the file to one of known format such as JSON and XML. We decided to change the format to JSON, therefore, I had to re-write my function that creates the file of Object list in such a way that the output is JSON file. The object list format is now changed but the work is not done yet as ALL the functions that use this file have to be modified as well. In the generation of the SOC the file has to be parsed in order to extract the necessary information and here comes the need for witty JSON parser.
It was my first time to deal with the Witty JSON parser. It was really weird to work with JSON format using C++ classes, as I usually used to deal with it in JavaScript. Any way the parsing of JSON file was completed successfully but the task involved massive changes and modifications to the code.
Editor Bug
If you have read my previous blog, you would probably remember this bug. It was regarding the inconsistency of showing the errors to the user. The problem was partly solved except that the message of the error of repeated IDs doesn’t show up in the line where this error takes place. This happens because I don’t have the exact lines where the object ID gets re-used. So this week I was investigating some possible ways to get the line number or make the compiler sees this as an error using some pre-processing magic as stated by Dr. Shawn. Since all I want is just the line number of where the object of that class is defined I tried to explore if I can get this information from the ELF file itself using the Debugging information. But this way tended to fail as the line number information that can be read from the elf file doesn’t actually refer to the line where the object is declared (The constructor is called) but to where the constructor is actually defined. Hmm.. Then I moved to see what magic I can actually do with the C++ pre-processor. Exploring them has really enlightened me with their true capability. The first thing I thought I can use was the “LINE” preprocessor, this standard C++ preprocessor will return the line number in the source code at which the preprocessor is used. So if we can make this preprocessor as a parameter for all the templates classes we have. .. This will definitely work as the line information can be extracted now yet, it will be really troublesome for the user to enter another macro (Plus the ID) to the class template…hmm.. Well it seems like I’ll be still looking for a solution for this bug next week.
That is it for this week, Please Please keep me in your prayers as I need them strongly this week.
0 Comments