In a recent whitepaper Gagandeep Singh, Director of Engineering at Mentor, a Siemens Business outlines a flow using Catapult Design Checker that helps in early detection of coding errors as many companies are turning to High-Level Synthesis (HLS) methodology. This requires that high -level C++ models are correct, that ambiguities in the language be detected and addressed during simulation and that sub-optimal coding generates unintended hardware after synthesis. Deficiencies there lead to simulation mismatches between HSL and RTL or even worse failure to detect design problems.
Some of the defects in a C++ model can be pointed out by static software analysis tools but these tools are meant for general purpose software and do not understand the hardware intent of the model. Software checking tools, like linters, on C++ source code, do not understand hardware.
Some hardware-aware issues for software checking tools include the fact that checkers:
- Only work for C++ code and do not support SystemC
- Do not understand bit-accurate data types
- Only employ static analysis that can generate many false positives
- Do not understand that some code can produce sub-optimal or incorrect hardware
- Do not produce counter-example test-benches
What design and verification teams really need is a tool to quickly and easily check for coding bugs and suboptimal code before synthesizing to RTL. Teams also need to avoid simulation mismatches between C++ and RTL simulation. Checks need to be performed on C++ or SystemC source code before downstream tools are used.
The Catapult® HLS Platform provides a complete C++ verification solution that interfaces with Questa® for RTL verification as shown in the diagram.
The Catapult verification solution includes:
- The C++ (or SystemC) source code with Assert and Cover statements is input into the Catapult Design Checker (CDesign Checker) which uses formal analysis and lint techniques to find language and coding bugs.
- Catapult Code Coverage (CCOV) provides hardware-aware coverage analysis of the C++ code.
- Catapult synthesizes the source into power-optimized RTL that is verification ready.
- The flow generates test infrastructure using Catapult SCVerify for RTL simulation using Questa.
- As a final step, the sequential logic equivalence checking tool SLEC-HLS formally verifies that the C++ exactly matches the generated RTL.
While a design might simulate at the C++ level with no apparent issues, ambiguities in the C++ description can lead to simulation mismatches during RTL simulation. These issues are often hard to debug and can be time-consuming to fix. Design Checker employs both static and state of the art formal verification techniques to find problems, like uninitialized memory reads, before RTL simulation. The tool can check the source code without any simulation framework, such as test-benches, to provide designers with information about coding issues that might cause problems after synthesis and during RTL simulation. The Figure below shows the steps for using Design Checker.
The design checking flow consists of:
1. Optionally, choose which checks to run. By default, all checks run.
2. Run Design Checker on the design.
3. If there are no violations, proceed to run Catapult synthesis to generate the RTL.
4. If there are violations:
- Interactively make code corrections
- Optionally waive code
- Optionally run counter-example test-benches that the tool generates to replicate violations
- Repeat the flow
Waivers allow designers to alter checking results for specific areas of code. Using a separate file, designers can specify the file and line numbers to filter specific check violations out of the violation report. Design Checker can generate counter-example test-benches that contain stimulus sequences that trigger the violation. The team can use these to independently show that a violation does occur due to the associated issues in the source code.
The whitepaper discusses examples of design checking errors with solutions addressing them.
Two examples are listed below:
1. An incomplete switch or case statement is an error that can create unintended logic during high-level synthesis. This check looks at all possible values in the conditional code within switch and case statements and reports an error if all the values are not covered. These violations typically lead to the design entering an undefined state. During synthesis, the tool uses the specified case/switches as the only legal conditions, meaning that if the missing condition occurs in the design, the results are unpredictable.
2. It is possible to write C++ that does not synthesize to optimal hardware. To prevent this, the designer must understand the ramifications of writing code in a particular way in order to get the expected RTL results. To help with this, Mike Fingeroff at Mentor created the “High-Level Synthesis Blue Book” that explains how to code for hardware. An electronic copy of this book and all its examples are available in the install directories for the tool. Design Checker incorporates checks that support optimized coding, like those found in the book.
Catapult Design Checker is a unique tool within the Catapult High-Level Synthesis Platform that combines state of the art static analysis with patented formal analysis to find coding errors, code that can create unintended hardware, and code that creates sub-optimal hardware during synthesis. Design Checker is part of the complete high-level synthesis platform of tools that provides an ecosystem that enables C++/SystemC level verification signoff.
To learn more about the Catapult verification solution, view this website.
Share this post via:
Comments
There are no comments yet.
You must register or log in to view/post comments.