Give the people what they want: HLS for RTL verification

As the manual RTL design flow stumbles under the burden of titanic designs, an excessive burden is placed on RTL verification teams to meet expectations for design cycle time and quality of results (QoR) in the hardware design flow. If not lifted, this truly Sisyphean endeavor will eventually sap the drive of the electronic design industry because verification is the bottleneck of modern design flows.

Instead of prolonging the painful process of finding numerous bugs in manually produced RTL code, EDA tool flows should provide relief by creating bug-free RTL designs through high-level synthesis (HLS) tools. This is not simply an exercise in utopian logic; an increasing number of RTL engineers demand it. A recent blind, worldwide survey found that verification is the primary reason for using high-level synthesis, because HLS makes it faster for engineers to verify their designs when compared to a more error-prone manual RTL implementation process.

Figure 1. Top reasons for using HLS. (total ~200 percent because two answers allowed)

Source: 3^rd party HLS survey, Jan. 2010

However, to ease the load on RTL verification, the high-level source files must be verified exhaustively, the synthesized RTL must be correct-by-construction, and it must be easy to prove that the RTL matches the specification. Only these conditions will make the RTL verification task much easier and reduce the time to verified RTL. Suddenly, RTL designers are relieved of the relentless verification burden.

Keeping it simple

To fully impact the time to verified RTL, it is critical to ensure that the high-level code itself is exhaustively verified with as little effort as possible. Verification at the C level is simpler and faster because it is more abstract than the RTL. There are fewer things to verify, fewer lines of code to debug, higher simulation performance, and quicker fixes. This makes it possible to attain higher coverage and code quality much more quickly than at the RTL.

Less detail in the source code enables faster simulation and quicker modifications. Improving simulation performance even more, C/C++ models execute directly on the host workstation, so they do not inflict the performance hit of an event-based simulator or simulation kernel. Faster simulation applies more test vectors for greater coverage of the design.

Verification engineers still need to know when they have fully covered their design. Any truly worthwhile HLS solution must include built-in static and runtime C/C++ checks, and it must tightly integrate with the best C/C++/SystemC analysis tools that collect and measure code coverage metrics. These coverage tools build confidence by making sure the C code is thoroughly and properly tested and they save time by eliminating extraneous tests—by enabling engineers to know exactly when enough is enough.

Another way that high-level models speed the time to verified RTL has to do with the fact that these purely functional models do not include implementation details; such as timing and concurrency. This means that the synthesis tool can build different design scenarios, implementing different concurrency schemes from the same source code, without modifying the source code. This delivers the enormous advantage of not having to re-verify the source code with every change. Thus, the information about concurrency should be controlled during the synthesis process, as HLS is designed to do. The outcome is the creation of what is in essence high-level IP, which is extremely versatile and can be reused for many types of implementations.