This week I started to integrate everything together starting from the generation of the C++ code by the user up to the creation of the final bit stream. It’s the time to get every part of the project work side by side with each other.
Verilog top module and EMACS:
To begin with, I’ll first talk about the changes I made on my way of creating the Verilog top level module from the C++ code. If you still remember we rely heavily on EMACS (Editor) and specially its Verilog mode in order to ease our work by using the Auto Template feature. Although I really hate using it and prefer to write my code or any other kind of document in other editor due to the inconvenience it causes specially when it comes to using the keyboard shortcuts for Copy and Paste (it has its own ones), I had to admit that when it comes to writing Verilog modules it becomes my favorite :D.
This week I encountered the rest of its AUTO features such as AUTARG, AUTOWIRE, and AUTOINPUT…etc. Using them makes the creation of the Verilog top module a way easier. You only need to get the sub-modules instantiated, write the correct AUTO Template for each module based on your desired connection and then attach the /AUTOWIRE/ to your top module and BINGO the EMACS will create all the wiring you want automatically.
Other features were as helpful as AUTOWIRE. For more details please visit the following page: Verilog-mode
One problem I encountered regarding running the emacs Verilog mode from the terminal (batch mode) was that the top module file that comes to be elaborated usually has no .v extension on it so the emacs kept giving me an error. The problem was that EMACS was unable to recognize the type of the file so it refused to run the Verilog-mode. At first, I simply overcame the problem by changing the name of the file to a name that has .v extension but later I felt that definitely there’s a shortcut solution. Eventually by googling that, I came across this topic that described the different ways the EMACS used to recognize the file. My solution for this problem was simply: just adding this command option (-f Verilog-mode) to the command: emacs --batch fileName.v (Verilog file) -f verilog-batch-auto
The two machines communicate together:
So after the creation of the top module automatedly from the user C++ code and getting the UCF file from the schematic editor based on the user connections. Those two files were sent to another machine in order to create the final bitsream. The process of the synthesis went smoothly except at the end when I failed to get the final output of the bits stream back in the response of the request. I kept getting this error:
Wt::Http::ResponseContinuation : write Error
Since the second machine was already been tested, I only suspected my client side . The Problem was that I inadvertently forget to change the timeout waiting for I/O operation using the setTimeout() function. The timeout was a way less than the time needed from the other machine to process the files and then return the response. Another parameter I had to modify was also the MaximumResponseSize by using the Client function:
void setMaximumResponseSize( std::size_t byte).
Playing around:
Since we have already built some modules weeks ago with their respective schematic objects, I was quite interested to play with them and also to make sure the algorithms I make works quite well with different modules that have different number of parameters . The simplest one was a component that has master I2C. By instantiating this module in UI, then doing the connection in the schematic editor and then finally synthesizing the top module without any errors I got relived since everything seems to be working the way it’s supposed to regardless what kind of modules the user instantiate.
Got to admit that, by starting integrating the project this week the full picture of it becomes clearer and clearer.
That is all for this week , and till next week stay SAFE 😀
0 Comments