Weekly Report: Week5 & Week6

Week 5 was mostly focussed on completing the midterm task. I had been so preoccupied with completing midterm tasks, coupled with a network outage during the crucial Thursday night during the midterm week, I was unable to present a weekly report last week. I continued with completing the midterm tasks till Monday this week. Feeling unwell since a few days since then. (maybe due to severe lack of sleep chasing midterm deadlines). Slight delay in adding this report as I was waiting to get it reviewed by my mentor.

Heartbeat Module: link

I had been dealing with glitchy output in the heartbeat module last week (Video). After incorporating suggestions from _florent_’s comments and some more independent bug fixing I was able to get a stable glitch free output on the screen. Here is a link to the pull request which contains marginal updates with each new commit.

One change I made was to modify the way framebuffer was allotted its base address, instead of copying it from input side (hdmi_in0_fi_base), I read the updated address from each of three designated outputs, (for eg hdmi_out0_fi_base). This still didn’t correct the glitch. But gave me the idea that my heartbeat glitch can be corrected by calling the hb_fill() at a much faster rate to match the HDMI input frame rate. I made some changes in the timing part of the code, with some other changes the heartbeat module works perfectly. The next step is to get it tested on someone else’s hardware and merge it with the main repository.

Float16 CSC conversion: code

Building up on my previous week’s work on float16 conversion, I was basically building up upon the existing pipelined structure designed for YCbCr color space conversion. While going through the code I realized how easy it was for me to understand and the elaborate test modules built to test the color space conversion using a lena.png image. My conversion modules for rgb2rgb16 and reverse were built up upon these.

The pipeline latency is two for both the conversions. I have basically described a single module for one conversion and reused it as submodule for complete rgb to rgb16 space conversion. The modules are designed specifically keeping in mind that input pixel is a 8 bit number and won’t necessarily work for a general integer. The input int8 numbers in the range 0 to 255 are mapped to 0-1 in their corresponding float conversion for added precision in that range in case of float. The design is implemented as described in the float16 design document.

For testing, there is already described test setup which uses streamer and logger to send and receive packed RGB data. To test the working of our hardware model, we need a standard model in described in software, this serves two purposes, one of comparing the hardware design with software model and other of converting the float data back to RGB pixel data to be later saved as an image.

Float16 Design document: link

Added FPGA mapping to design document which was missing until last time. This was added for the basic arithmetic operations and currently, covers multiplication. I have currently described a five stage pipeline for float16 multiplication and identified the components which are likely to use higher hardware resources. These are pretty simple components like 6 bit adders or 11 bit multipliers, I wrote simple Verilog codes for them, and took a look at the Xilinx XST synthesis report. I included both the hardware resource usage and the combinational delay of that element so that pipeline can be optimized for highest throughput.

Float16 Arithmetic: code

Since I had already worked with designing hardware in migen and completely described the pipelined hardware, this was pretty easy to describe. It is important to take care of edge cases here as they are described IEEE standard document. For example subnormal numbers or the description of NaN or Inf in float16 format.

The already existing test module based on images wouldn’t have been sufficient for the task here, as it will not necessarily cover all the edge cases. It is important to note the format in which bits are streamed for to the design under test hardware module. The streamer accepts integer data type, and corresponding 16 bit representation of that integer data type should correspond to the float16 value we are intending to send, and hence it became really difficult to debug things with this system. Hence I described two functions which convert to and from, float data type to int16 data type which is actually streamed and logged.

RLE Encoding and Decoding: code

After several code reviews, I finally have an object orientated implementation for generating an object of Repeat class. This class also defines generate() methods to return a list of repeated elements. Also defined is a Pixel class which is used to represent individual pixels, and returns a list of that pixel value, when the gen() function is called. Also added required documentation and python doc tests, to test the class methods and other functions.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s