Week 5: July 5 - 9

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

This Week's Goals:

  1. Integrate into my modified VPR code a former student's code for keeping selected logic blocks fixed in place during the placing algorithm.

  2. Make it possible for fixed logic blocks to be placed anywhere that is desired, not only in the center of the FPGA.

  3. Make wide channels automatically appear around groups of fixed logic blocks representing hard macros.

  4. Now that VPR's placer is compatible with our hard macros, get its router to be as well. The former student working on this project had started to write some code to do this, but this code is incomplete and sometimes takes too much time to run. Determine whether some of his code or methods are useable in modifying VPR's router.

    1. Approach 1 - Observe how much slower the former student's code is than an unmodified copy of VPR. Then copy pieces of his code into my copy of VPR one piece at a time, testing at each step to discover which step adds the delay.

      1. Run the student's version of VPR on the simplest test circuit that comes with VPR, the e64 circuit and the fastest to route, and see how much longer this code needs to route this circuit than normal VPR does.

      2. If the e64 circuit does not give sufficient data, run several benchmark files, other sample circuits supplied with VPR to see how slow the student's code is.

      3. Copy sections of the student's code into my VPR, one part at a time, looking for what causes a slowdown of the size observed in the steps above. First copy the code that simply identifies which nets connect to the fixed block. Then copy code which routes these special nets first and other nets second, rather than all of the nets together as in the original version of VPR. Finally, copy the code preventing non-special nets being routed through the fixed block's region.

    2. Approach 2 - When using VPR, one can choose between its two routing algorithms. It's timing-driven algorithm, which produces faster routes was the one the former student modified. However, this algorithm is considerably more complicated, and some of its complications may be causing the problems with his code. If working with the timing-driven algorithm seems unnessesarily complicated, use the former student's work as a model to modify the other, breadth-first algorithm. At the moment we are concerned more with routability than speed, and having a usable tool quickly is more useful than the advantages of the timing-driven algorithm.

Progress Toward Goals:

  1. Completed Tuesday - The student had worked on placing and routing, but his routing code was incomplete so I only wanted to copy the placing code into my copy of VPR. This was not difficult since the code that pertained to routing was well labeled.

  2. Completed Tuesday - I discovered that the code already has this functionality, the feature just had to be enabled.

  3. Completed Wednesday (see picture below) - This was a little tricky because indexing convensions are so complicated in the various pieces of code pertinent to the task. I got several off-by-one errors before resolving this. I ended up drawing myself a diagram labelling each item with each index that would apply to it to straighten this out.

  4. In Progress at End of Week:

    1. Abandoned on Friday:

      1. Completed Thursday - The student's code actually runs faster on this circuit than the unmodified version of VPR!

      2. Deemed Impossible on Friday - VPR has two different routing modes, one called detailed and one called global. Detailed routing involves a lot of information about a specific FPGA's structure, whereas global is more general and gives estimates that apply to many similar types of FPGAs. In our study, we are using global routing.

        My mentor and I discovered that the VPR's timing-driven algorithm only works with detailed routing and is incompatible with global routing. We think this may have caused some of the unpredictable behavior we were observing in the former student's code - which uses the timing-driven algorithm. This also means that I could not run the former student's code on the benchmark files and was forced to abandon approach 1.

      3. Not to be Started - Because this approach has been abandoned.

    2. Not Started at End of Week

Below, you can see the results of goals 1, 2 and 3. VPR's GUI displays FPGAs by showing a grey square for each clb, and grey squares subdivided into little rectangles around the FPGA's border to represent io pins. White squares and rectangles are resources (clbs or pins) that are available in the FPGA but not used in the design currently being placed/routed. The fixed clbs are marked in pink rather than grey. You can see from the VPR screen-shot that the channels around the group of fixed clbs are wider than the others.

About My Project | home