μgrind: A framework for dynamically instrumenting and verifying HLS-generated RTL

High-level synthesis (HLS) compilers enable the rapid creation of custom accelerator circuits. However, HLS-generated RTL (H-RTL) is inconsistent in terms of quality, too verbose to be comprehensible, and may even have functional errors [Lahti-2019, Herklotz-2021]. We propose a framework that helps designers inspect, instrument, and profile H-RTL. State-of-the-art tools such as [Goeders-2014, Yang-2016] have predominantly focused on tracing. Unfortunately, tracing requires a massive amount of memory, limits the H-RTL size, allows for faults to propagate to other modules, and expects the user to manually identify the signals. Further, the tools can only run post-execution which limits the types of analysis the designer can perform. μgrind (name inspired by binary instrumentation tool Valgrind), is a Dynamic instrumentation framework that enables computer architects to observe, and modify signals during the execution of the accelerator prototype. The key technique is guards, additional circuits that we automatically attach to the H-RTL (without requiring human intervention for insertion or removal). Guards perform two activities: i) Run analysis functions on the values fed from the H-RTL signal. ii) Inject values into registers, wires, and memory entries of the H-RTL and patch the execution. During prototyping guards get mapped onto the FPGA along with the H-RTL; μgrind removes the guards once the H-RTL is finalized. We use guards to develop a verifier tool that instruments the H-RTL iteratively and locates a faulty module. Compared to state-of-the-art [Yang-2016] μgrind requires 2---10x less on-chip SRAM, supports 5x larger H-RTL circuits, and verifies complete accelerator in less than 24 hours. Two additional tools are also introduced: i) H-RTL Faulty, which uses guards to inject faulty values and observe the propagation of erroneous values in the circuit, and ii)H-RTL profiler, a lightweight guard for profiling the data values, hardware signals, and addresses. We require around 200-35000X less DRAM traffic than off-chip profilers