Week 4: June 28 - July 2

<-- Prev Week ||||||||| Next Week -->

Note- starting this week, I'll be using a slightly different format for my updates, organizing my tasks into a grid with goals on the left and progress toward those goals on the right.

Within each task description, there is a concise statement of the task's focus in bold.

This Week's Goals:

  1. My first step is to get VPR to operate on FPGAs in which some channels are wider than others.

    1. Approach 1 - VPR requires an input file with the extension .arch that describes the structure of the FPGA being used. I will see if FPGAs with varrying channel sizes can be described by modifying a .arch file rather than VPR's code.

    2. Approach 2 - When VPR reads the .arch file, it stores information about the FPGA being used in a data structure called a routing resource graph. I will find the part of the code where the routing resource graph is built and modify the fields describing channel width.

    3. Approach 3 - I will trace through the code to find out where the currently implemented options for unusual channel structures are converted into actual channel widths, and modify channel widths in this location.

  2. We want VPR to choose several logic blocks from the netlist being placed and routed and place them together to represent a hard macro. The blocks comprising the hard macro should not be particularly related to eachother or to other blocks near the hard macro so that there will be a lot of connections between the hard macro and the rest of the FPGA (as would occur with a real hard macro).

    VPR's placer works by originally placing all logic blocks randomly, and then gradually moving the blocks into positions where adjacent blocks are very related and have as few connections as possible to far away blocks. To create our hard macro, in the part of the FPGA where the hard macro will be, we want the original random logic blocks to remain and not be replaced by the placing algorithm by blocks that are more related to eachother. I need to modify VPR so that the placer will not move logic blocks that will be part of a hard macro.

Progress Toward Goals:

  1. Completed Friday:

    1. Abandoned Last Week - This method is not sufficient because it can only widen multiple channels if they are adjacent. There is no .arch file that could describe an FPGA with two non-adjacent wide channels with normal sized channels between them.

    2. Abandoned Wednesday - Unfortunately, this approach does not work. VPR's routing algorithm experiments to find the smallest possible width each channel could have and uses this value in its final output. During this experimentation, it overwrites the value originally stored in "capacity" for each channel. Thus, modifying the graph as it is built does not effect the final contents of the graph (at least not as desired).

      VPR can run in a mode where this experimentation is disabled and specific channel widths are specified as inputs. If only this mode of operation were desired, this method might have been successful. However we do not want to disable this experimentation.

    3. Completed Friday - By tracing where the information from the .arch file goes within the VPR code, I located the method that is repeatedly called during the routing algorithm to set channel sizes. I modified this function so that now the width of arbitrary channels can be chosen as desired.

      VPR has two routing algorithms. The channel width modification causes problems with the one algorithm, but not the other, so now it is necessary to use the second algorithm. We may try to make this modification compatible with the first algorithm as well, if time permits.

  2. In Progress at End of Week - A former student working with my mentor already wrote code performing either this task or a very similar task in VPR. My mentor is finding me this code so I can either use it directly or use it as a model in making this modification.

About My Project | home