From 8311b1ae021472c0bbe565daffc39e7c7603bd86 Mon Sep 17 00:00:00 2001 From: nozidoali Date: Tue, 1 Aug 2023 19:27:41 +0200 Subject: [PATCH] update the read me for the experiments --- Experiments/delay_characterization/README.md | 12 ++++++++++++ Experiments/runtime-exp/README.md | 8 ++++++++ 2 files changed, 20 insertions(+) create mode 100644 Experiments/delay_characterization/README.md create mode 100644 Experiments/runtime-exp/README.md diff --git a/Experiments/delay_characterization/README.md b/Experiments/delay_characterization/README.md new file mode 100644 index 0000000..117a17c --- /dev/null +++ b/Experiments/delay_characterization/README.md @@ -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. \ No newline at end of file diff --git a/Experiments/runtime-exp/README.md b/Experiments/runtime-exp/README.md new file mode 100644 index 0000000..979462f --- /dev/null +++ b/Experiments/runtime-exp/README.md @@ -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.