A hardware-centric approach to checking HLS code before synthesis

Finding coding problems in C++ or SystemC code before passing it to high-level synthesis has historically been a tricky process. It has arguably slowed HLS adoption. A recent technical paper from Mentor, a Siemens business, describes how it is looking to solve this problem within its Catapult HLS tool family.

Historically, the main issue has been that the linters and other static software analysis tools used to check code were originally designed for general purpose software projects. Understanding hardware intent was not originally seen as a priority.

A second factor has been that creating C++ code for RTL synthesis has its own nuances. There are good and not-so-good ways of slinging it.

These limitations typically cause three types of problem:

1. RTL simulation mismatches (e.g., divide-by-zero issues that have previously required time-consuming manual checks of divisors)
2. Unintended hardware (e.g., incomplete switch or case statements leading to undefined states that make the hardware unpredictable)
3. Optimization problems (e.g., forgetting to specify the size of the variable associated with an accumulator)

Catapult Design Checker for HLS code

Mentor’s Catapult Design Checker sits within the company’s Verification Solution for HLS. It includes a digital copy of a HLS Blue Book with guide lines of RTL-friendly coding and a series of automated processes to address the three problem types, using a hardware-centric combination of static and formal verification techniques.

The flow is illustrated in Figure 1, and comprises the following steps.

1. Optionally, choose which checks to run. By default, all checks run.
2. Run Design Checker on the design.
3. If there no violations, proceed to running Catapult synthesis to generate the RTL.
4. If there are violations:
   • (a) Interactively make code corrections
   • (b) Optionally waive code
   • (c) Optionally run counter-example testbenches that the tool generates to replicate violations
   • (d) Repeat the flow

Figure 1. The Catapult Design Checker flow (Mentor)

The technical article, by Mentor Director of Engineering Gagandeep Singh, describes the flow in more detail and refers to the types of result generated by the Design Checker. It also includes a link to a case study at autonomous driving IC and IP specialist Bosch Visiontec.

‘Finding code problems before high-level synthesis’ is available now.