After a bit of break during week 6, as I was unwell, I am back to my standard GSoC schedule now. There were a lot of things left to be reviewed from last two weeks so most of the time this week went in getting code reviewed and making the required changes.
Float16 Arithmetic: code
This work is continued from last week. I had defined a multiplier which worked for normal values, but gave incorrect results when the output is in the subnormal range of float16 variable. This was fixed by adding some extra conditions in the code. To test and debug the code efficiently added functions to convert unsigned int16 data type (the format in which data is streamed) to standard float and binary representation. This also helped to effectively verify the code for various test cases. This was code was tested to work fine on simulation, to test this on hardware, few more things were added to gateware and firmware to test the working.
In gateware, first added CSR storage and status registers. CSR is added as a part of bus support in migen and designed for accessing configuration and status registers of cores from software. Figured out a way to correctly initialize the FloatMult module in opsis_base, and checked the added functions in csr.h file for accessing operands and results of float multiplier. These functions for writing to multiplier operands and reading from multiplier outputs were added to ci.c file in lm32 firmware.
While testing this I figured out that, when output is held to a constant value in gateware code, it shows up correctly in firmware output. But when a previous stage’s output is held to constant value output remains as zero, which is the reset value. I suspect that in some part of initialization of CSR registers, something or other is inferred as an wire and not holding its value. I assume this is a trivial mistake in initializing something in migen.
I had also started writing code for adders likewise. Still a work in progress, hoping to get back to this once all the existing things get reviewed.
Heartbeat Module: code
This pull request is in review since a lot of time now, hopefully in the final stages now. Apart from many other things I got to learn about usage of volatile data type in C. I had based my heartbeat code upon variables defined by pattern.c file, which used a volatile integer for framebuffer variable. Defining a variable volatile is required when we want the memory access to be sequential in the manner defined in code. But this was not the case here, not in pattern file as well, logged a github issue for this, which describe this issue in detail.
This week’s work on heartbeat involved cleaning up parts of code and adding documentation. After incorporating _florent_’s suggestions I no longer needed to make those changes hdmi_in and pattern c files. Thus, I won’t be needing to change those in this pull request which is a good practice to track changes. Also added documentation for setting desired heartbeat frequency. Link
Design Document on Float16: code
Continuing with the review going on, made small changes here and there to improve the overall feel of the document and make it more easier for beginners in the field to understand. Added a whole bunch of links and added a github link to codes for generating the synthesis report results. This documentation currently explains in detail the FPGA mapping of a float16 multiplier, also adding a similar description for FPGA mapping of a float adder.
Float16 CSC Conversion:
Ported this design to litex for merging with _florent_’s litevideo repository. Code review underway at this pull request. After _florent_’s suggestion I might add a look up table for this conversion instead of doing this using pipelined hardware and other things. I had earlier considered this but wasn’t sure about the available memory space and bandwidth. The size of look up table for uint8 to float16 will be a lookup table of size (16bits)*(256 locations) and (8bits)*(65536 locations), this can be further reduced if we cleverly consider the range of float16 number. The former is still okay, but latter seems a bit expensive.
Run Length Encoding:
After several weeks of reviews and comments on my work, my mentor, mithro added most of the code required for the run length encoding. I spent most of the time of a day trying to understand the code. Both the python and the C code used a lot of things here and there and I couldn’t imagine myself writing a code like that. I was supposed to work further on the code to add documentation and adding functions for image transformation. Still a work in progress. Will be adding the pull request soon.