Month: July 2017

Now that the the gate level simulations and timing reports were collected, the experiment could now begin. To accomplish this, I used my previously created test vector generator, along with a new script created to that could compare the results calculated in python with the output generated by the verilog simulation of the hardware. I also create a script that allowed me to compile the hardware at a given clock period, thus changing the clock frequency. Combining all of these scripts, I could begin the experiment. Varying the clock frequency, I collected the error rate of the hardware and plotted them on a graph. However, generating these results took days, so I should have most of the data collected by next week.

Over last weekend, I had the computer compile a gate level design for each bit width: 64 bit, 32 bit and 16 bit. When I arrived at the lab on monday, they all had compiled. Once the gate level synthesis was complete, I needed to run timing analysis software on each design. This software would calculate the actual speed of data through each gate. With this information, we will be able to tell if there is any timing errors in the design, as well as simulate the real world response of the hardware. To accomplish this, I utilized some python code from a project of a previous graduate student, and modified it to analyze the gate level designs of each bit level floating point unit. After its completion, I received output files for each piece of hardware. Inside, was a detailed list of every gate, along with the time in nanoseconds it took to process data. While this worked for the 64 bit and 32 bit versions, I could not generate timing information for the 16 bit FPU.

Now that all of the code was migrated over to the remote server, I could now convert the verilog into a gate level representation of the hardware. To accomplish this, I modified some code by previous graduate students, to compile the verilog. Before compiling my modified design, I attempted to synthesize the gate level design of the original verilog code. However, I was greeted with multiple errors. One of the first issues that arose, was that division could not be implemented at all. Secondly, many of the hard coded values that were used in the process of denormalization crashed VCS. Once I fixed the errors in the original design, I had to do the same for my modified version. However, even after implementing the changes of the original, my modified design still did not work. VCS would not allow me to synthesize a design that had varying bit widths. To fix this, all I had to do was change the design from a parameterized version, to a `define macro based version. Once I completed that, I could synthesize a gate level design.

Since the 4th of July was on a Tuesday. I got Monday off. This gave me the opportunity to visit my family at home. When I got back to Northwestern, I began the second phase of the project. Now that we had a parameterized version of the FPU, we could now use a tool called Synopsys Design Compiler to synthesize a gate level design of the code. To accomplish this, I had to migrate all of my code to a school-run server that had the software installed. In my testing, I used Icarus Verilog to compile the design. However, to get a more accurate response of how the module behaves, Synopsys’ VCS compiler needed to be used. VCS is a much stricter compiler, and the same source code that gave me no warnings in Icarus Verilog gave me hundreds of errors in VCS. So most of this week was spent on trying to get the working source code to compile under VCS.

After changing every value in the source code to it’s parameterized form, it was still full of errors. While the 32 bit parameter worked, the 64 bit and 16 bit versions still did not compile. This was do to the fact that original source contained logic that could not be parameterized. In the IEEE floating point standard, when rounding a number, a single bit is used to determine whether the bits following the cut off point is greater than one. In the implementation that we are using, every possible place the one could be is tested in a case statement. To fix this for the 16 bit and 64 bit implementations, I had to create separate code to check the bit precision, and run the necessary code. In addition to these specialized case statements, I had to come up with a formalized way of testing the code. Up until then, my tests were ad hoc, just to make sure that I was getting a proper result. Changing this, I wrote a python script that would generate random IEEE floating point numbers, and run a random operation on them. The result would be calculated by both python and the verilog FPU. From that, I could compare the values obtained, testing the functionality of the FPU. Once the FPU was up and running, we were finally able to move on to the second phase of the project.