Source code error detection in high level synthesis functional verification

Source Code Error Detection in High-Level Synthesis
Functional Verification
Abstract:
A dynamic functional verification method that compares untimed simulations versus timed
simulations for synthesizable [high-level synthesis (HLS)] behavioral descriptions (ANSI-C) is
presented in this paper. This paper proposes a method that automatically inserts a set of probes
into the untimed behavioral description. These probes record the status of internal signals of the
behavioral description during an initial untimed simulation. These simulation results are
subsequently used as golden outputs for the verification of the internal signals during a timed
simulation once the behavioral description has been synthesized using HLS. Our proposed
method reports any simulation mismatches and accurately pinpoints any discrepancies between
the functional Software (SW) simulation and the timed simulation at the original behavioral
description (source code). Our method does not only determine where to place the probes, but is
also able to insert different type of probes based on the specified HLS synthesis options in order
not to interfere with the HLS process, minimizing the total number of probes and the size of the
data to be stored in the trace file in order to minimize the running time. Results show that our
proposed method is very effective and extremely simple to use as it is fully automated using
Xilinx 14.2.
Enhancement of the project:
Existing System:
RAISING the level of abstraction in VLSI design has some distinct advantages over traditional
register-transfer level (RTL) design methods. First, most of the designs start with a high-level
model in order to validate the application to be implemented. High-level synthesis (HLS)
provides a direct path between these models and RTL. It has been shown [1] that one line of C-
code translates into 7–10× more gates than RTL. This further implies that behavioral descriptions
are easier to maintain and debug, and that fewer bugs will be introduced by designers. Second, in
many cases, the design specifications are unstable and any changes in them can lead to major
architectural changes (e.g., the use of on-die memory or external memory). At the RTL, this
requires major redesigns, while at the behavioral level; these changes can be tackled easier.
Third, raising the level of abstraction allows software and hardware designers to speak the same
language. Applications to be implemented in custom hardware are getting extremely complex
and are based on complex mathematical models that in many cases are difficult to understand by
the hardware designer. Using the same behavioral description language allows both hardware
and software designers to communicate at the same level of abstraction using the same language.

Some examples of complex applications include dedicated hardware security engines based on
complex encryption and decryption algorithms.
Disadvantages:
 Performance is low
Proposed System:
Our proposed verification method takes as inputs a behavioral description in ANSI-C and the
untimed test vectors used for the SW verification. Fig. 1 shows an overview of the complete
flow. It comprises of four main steps. An alternative initial preprocessing step is also part of the
flow. This preprocessing step parses the given behavioral description and performs typical
compiler optimizations (e.g., dead code elimination and constant propagations). The output of
this preprocessing step is the optimized behavioral description called ANSI-C optimized (ANSI-
CO). The advantages of executing this initial step are obvious. Our method cannot automatically,
e.g., detect dead code, which means that it would insert probes to visualize parts of the code,
which are not needed. The drawback of executing this preprocessing step is that the optimized C
code is automatically generated by the HLS tool parser and is, therefore, not as readable as the
original C code written by the designer. Moreover, the errors detected by our method will
consequently point to the ANSI-CO code and not to the original code (ANSI-C).
Fig. 1. Proposed verification flowchart.

Probe Insertion
One of the main contributions of this paper is to determine how and where to insert the probes
shown in Fig. 2 and also the type of probe. A naïve method inserts a probe whenever an internal
signal is being written to. This approach guarantees that the EDL is minimized at the expense of
having to record and compare a very large number or probes. The number of probes inserted is
important in order to exactly locate where the mismatch between the original behavioral
description’s behavior and the synthesized descriptions happen. In order to determine the quality
of the error detection mechanism, we define the term SCED.
Fig. 2. Probes insertion overview
Observations
At this point, some observations should be made. First, most HLS tools perform automatic
bitwidth optimization. This means that the final bitwidth of the internal signals is not known
when the probes are inserted and hence the probes’ bitwidth will be larger or equal to the internal
signals’ bitwidth after HLS. Two cases should be considered.
1) The HLS tool also adjusts the output port bitwidth automatically and hence there is
nothing to be done.
2) Our method checks if the internal signal is signed or unsigned and inserts a type cast at
the assignment, e.g., probe = (signed) internal_signal or probe = (unsigned)
internal_signal.

FIR filter:
HLS tools can very easily create these signals because they know in which particular state the
inputs are read and in which states the outputs are generated. Fig. 3 shows an example of valid
signals. Fig. 3(a) shows the block diagram of a finite-impulse response (FIR) filter with its data
and coefficient ports and the data out port. Fig. 3(b) shows the valid signals generated
automatically by the HLS tool in order to assert when an input signal is needed and when a valid
output is generated. This simple, but extremely effective method combined with testbenches,
which monitor these signals to apply and to compare test vectors, allows a very effective way to
reuse untimed input and output test vectors for timing verification. The last step in the HLS
verification flow is the verification of the final RTL generated by the HLS. For this purpose, an
RTL testbench generator that can again reuse the untimed original input test patterns and
compare the generated outputs with the original untimed golden outputs is normally provided in
commercial HLS flows. These different models generators combined with the RTL testbench
generator allow designs to be effectively verified at different HLS design stages.
Fig. 3. (a) Regular FIR filter. (b) FIR filter with valid signals for DEC.
Fig. 3 shows an example of this effect. The figure shows a FIR filter described in ANSI-C and a
probe inserted after the sum-of-products (SoPs) computation. In this case, the SoP result is
written to the output port SoP_out in order to make this internal signal visible to the outside. Fig.
4(a) and (b) shows two of the most common ways to synthesize the FIR. Fig. 4(a) shows part of
the synthesis result if the loop is fully unrolled, whereas Fig. 4(b) shows the result if the loop is
not unrolled.

Fig. 4. Motivational FIR example. Synthesis scheduling results. (a) Loop fully unrolled. (b) Loop
not unrolled.
Advantages:
 Performance is high
Software implementation:
 Modelsim
 Xilinx ISE

Source code error detection in high level synthesis functional verification

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (14)

More from Nexgen Technology

More from Nexgen Technology (20)

Recently uploaded

Recently uploaded (20)

Source code error detection in high level synthesis functional verification