Abstract
High-Level Synthesis (HLS) tools provide facilities for the development of specialized hardware accelerators (HWacc). However, the verification stage is still the longest phase in the development life-cycle. Unlike in the software industry, HLS tools lack testing frameworks that could cover the whole design flow, especially the on-board verification stage of the generated RTL. This work introduces a framework for on-board verification of HLS-based modules by using reconfigurable systems and Docker containers with the aim to automate the verification process and preserve a clean testing environment, making the testbed reusable across different stages of the design flow. Moreover, our solution features a mechanism to check timing requirements of the HWacc. We have applied our solution to the C-kernels of the CHStone Benchmark on a Zedboard, in which the on-board verification process has been accelerated up to four times.
Highlights
Today’s advanced embedded system designs pose a challenge for teams that have to deal with tight deadlines
When it comes to High-Level Synthesis (HLS)-based design, designers only deal with a specification of the hardware accelerators (HWacc) in a High-Level Language (HLL), such as C or C++, which is tuned and optimized until the design meets the requirements
Designers must describe test cases to validate the HWacc and, analyse the reports produced by the HLS tool to decide the optimizations that will be applied in the iteration
Summary
Today’s advanced embedded system designs pose a challenge for teams that have to deal with tight deadlines. A productive methodology for designing specialized hardware accelerators (HWacc) is that where more time is spent at higher levels of abstraction, verification time is minimized and productivity is maximized. After going through the place & route process, the synthesized RTL may be mapped on a reconfigurable fabric to be verified again (on-board verification) [1]. These three verification stages are considered pre-silicon activities [2], whose objective differs from post-silicon activities, which creates a gap between both; the first is driven by models, whilst the second ensures that the silicon works properly under actual conditions. These devices have a similar complexity to post-silicon activities and make control, observation and debugging difficult to accomplish [1]
Sign-in/Register to view highlights & summary Sign-in/Register to access full text options 
Free) 
Talk to us
Join us for a 30 min session where you can share your feedback and ask us any queries you have
Schedule a call
