-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
update the read me for the experiments
- Loading branch information
Showing
2 changed files
with
20 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,12 @@ | ||
Delay characterization | ||
====================== | ||
|
||
We determine the LUT level delay and carry chain delay by characterizing all the delays in the critical path's timing report. | ||
|
||
The code can be found in ``Experiments/delay_characterization/raw/retrieve_timing.py``. | ||
|
||
The figure below show the delay distribution measured in our flow for the following constructs: (i) inside a single LUT, (ii) on the wire between two LUTs, (iii) the effective LUT level delay (i.e., the sum of the single LUT delay and the surrounding wiring), and (iv) an arithmetic unit (including the wire delays to and from the arithmetic units). | ||
|
||
![](../../Figures/delay_decomp_v6.png) | ||
|
||
For example, if the target clock period is 4.2 ns, then we derive that the maximum number of LUT levels is 6, and the DSPs take 4 LUT levels. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,8 @@ | ||
CPU-time analysis | ||
================= | ||
|
||
MapBuf combines buffer insertion and technology mapping into a MILP formulation which is, naturally, more complex than approaches that handle these optimizations separately. We here investigate the runtime of MapBuf and its ability to achieve near-optimal results within an acceptable time frame. | ||
|
||
![](../../Figures/runtime_v9.png) | ||
|
||
plots the evolution of the objective function value of the four techniques with CPU runtime. A higher value indicates a circuit with better performance. We can identify which term is updated by the slope of the line since throughput improvements increase the objective function more significantly than reducing buffers. We use dashed lines to indicate the last update of throughput and, thus, the CPU time required to acquire the final performance (without accounting for possible improvements in the area). We observe the following from the figure: (1) M-B and B-M quickly converge to the same objective function value, which does not further improve with time. (2) MapBuf-Exhaustive takes 21% longer to converge than the B-M method, but then achieves a higher objective function value than M-B and B-M, which demonstrates the superior performance of MapBuf. (3) MapBuf-Lite converges faster than MapBuf-Exhaustive and even 49% faster than B-M, with only a minor decrease in objective function value; this indicates the ability of our heuristic to effectively reduce MILP runtime without significant performance degradation. All of these point to MapBuf's ability to achieve high-performance design points that prior techniques were not able to discover, as well as its scalability and broad applicability. |