Forte CynCity

For nearly a decade Forte Design Systems has been working with customers to design and implement high-level synthesis (HLS) strategies and methodologies. These customers ask a lot of questions as they try to determine if HLS is right for them. But there’s one question they almost never ask: “What should I expect from high-level synthesis?”

They don’t ask it because it seems too obvious, or they already think they know what to expect. But the answer is not so obvious. Pose the question to yourself right now before reading on… what was your answer?

If you chose “productivity benefits” or some form of “faster time-to-RTL,” you’d be right–well, sort of.  There are several values and we’ll discuss five of them here.

Productivity
Certainly HLS promises and delivers great productivity improvements over RTL. Raising the abstraction level of hardware design means that the functional intent of the design can be expressed in fewer lines of code. Fewer lines of code should, in theory, take less time to write. The HLS tool then does a lot of the work in transforming the high-level code into RTL, creating the control FSM and the datapath. Oftentimes our customers see productivity improvements for real designs of 2-10X over RTL. Roughly speaking, that’s a gate count somewhere between 300,000 and 1,000,000 gates per engineer-year. Not bad!!!

Predictable Timing Closure
It’s usually unexpected, but during the RTL creation process users find that HLS has great value in timing closure. State-of-the-art HLS tools extract information from the user’s technology library (.lib), and, along with the target clock frequency, can characterize the performance and cost of each part. Based on user constraints, it can choose which ones to use when building the FSM and datapath. Different tools do this differently, of course, with varied levels of accuracy. Forte’s Cynthesizer uses an internal synthesis engine to estimate the area, speed, and power of each part at the gate-level, and then efficiently packs the operators and control into each clock cycle. The result is an RTL architecture that gets through logic synthesis and place-and-route smoothly, because Cynthesizer scheduled it with the target technology and process in mind. Timing closure problems are virtually eliminated, saving months of time and effort.

Less Time In Verification
As many a marketing person has stated, “verification is greater than two-thirds of the RTL design process.” Sure, that’s probably true, but the reason is because of the RTL design process itself. Think about it. RTL designs have thousands of lines of code, are insanely complex, and the code doesn’t get to the verification team until the end of the design schedule, leaving little time to verify the design. And with incredibly slow RTL simulation times, it’s no surprise RTL verification would take so long.

What if the verification team had a super-fast, accurate model of the design months earlier in the design process, a model where the functionality, architecture, and even the interfaces are fully specified and “simulatable”?  A SystemC HLS model can provide just that–an early, accurate, fast, executable specification. Cynthesizer can then compile this model and produce a unique RTL architecture for each set of user directives (more on that later). More importantly, the RTL design can be automatically validated using the same SystemC testbench, significantly reducing the verification effort. There are even formal tools that can check equivalency between the high-level SystemC and the RTL. The result? An improved design and verification flow that lets you start verification much earlier in the process and reduces the overall design time.

True Design Reuse
Everybody reuses RTL, but the same comments about reuse come up every time: old RTL designs are difficult to modify, they have limited shelf life when changing clock speeds, and a lot of area is wasted when changing geometries because of inefficient silicon use. HLS provides true design reuse by eliminating the majority of implementation details from the model. A SystemC HLS model doesn’t include any technology-specific details of the design. It is focused on the functional aspects and relies on the HLS tool to add the implementation details. Because of this, many of the issues mentioned above in reusing RTL are never encountered:

• Modification of designs is only necessary if the function changes, and with fewer lines of code, the functional intent is much more clear.
• The shelf life of the IP is longer because it is not tied to a specific process and speed. The HLS tool can easily retarget the design for different technologies (even FPGA!) simply by changing the directives.

Quality of Results
Of course, no amount of productivity and verification improvements will really help if you can’t meet your performance, power and silicon area targets.  Designers looking to HLS for high-volume production designs are naturally skeptical that they can get better results with an HLS tool than by hand coding RTL. This is not unreasonable, and some of the other HLS tools are pretty good on productivity but force users to sacrifice QoR. This is simply not true for Cynthesizer. You can expect to achieve just as good a result using Cynthesizer as you would if you wrote RTL by hand. This is not done by waving a magic wand. The user has to apply engineering skill to organize the design and drive the tool to get the best results, but it’s been proven on numerous production chips that Cynthesizer lets users take HLS all the way to the finish line.

So, there you have it.  If you are looking to adopt HLS design, you now know what you can, and should, expect.