HLS Tools Coming into Limelight!

For about a decade I am looking forward to seeing more of system level design and verification including high level synthesis (HLS), virtual prototyping, and system modeling etc. to come in the main stream of SoC design. Although the progress has been slow, I see it accelerating as more and more tools address the typical pain points in designing and verifying at the system level. Naturally, if you can’t confidently verify a design done in certain way, you wouldn’t design it in that way. So, the message is clear – close the gap between what a designer wants to do and what the tools provide; closer the gap, faster the adoption.

I was particularly happy seeing the sixth annual HLS survey reportconducted by Calyptoamong SoC, IC and FPGA design engineers and managers. I couldn’t imagine only 4% of engineers among 750 who responded to the survey do not use HLS. That means majority of the respondents were active users of HLS and they knew about the actual problems they face while using HLS. What if these problems are solved to delight them? Let’s see what these pain points are –

It’s clear, proving C and RTL equivalence is a major challenge; RTL structure depends on the constraints put in the synthesis tool and hence can significantly vary in its sequential behavior depending upon those constraints. So, the C-to-RTL formal verification tools must take into account the design intent. The other major challenge in tracking the mismatches between C and RTL models and lack of test coverage for the generated RTL signifies that there is acute need to generate equivalent RTL testbench also along with the RTL model.

Which C source code errors were hardest to identify during HLS? As usual, detection and removal of dead code in any software is a major pain point. The point important to HLS is the fact that such errors (e.g. uninitialized memory read, ABR etc.) in C source code can show their effect differently in different contexts, thus affecting consistency in results and re-usability of code. These errors must be removed early in the design process to keep the code quality high and re-usable which can be synthesized consistently.

The question on power reduction was interesting; we are already seeing major power reduction at RTL through various RTL level tools in the market. The power reduction at system level and then at C++/SystemC/HLS is a step well perceived for best way to start the design at system level. HLS tools can optimize micro-architecture to minimize power and also utilize RTL power optimization tools to produce power optimized RTL in one go.

What are the hardware types being designed using HLS? Clearly major concentration is towards wireless, video, imaging, graphics etc. However it is interesting to see the other 25%, that means the advantages of using HLS in more designs is being recognized by the design community.

Look at the HLS reportat Calypto website to find more details. I like this process of Calypto; gathering inputs from design community and then incorporating those into their tools, that’s a great way to accelerate closing the gaps between design and tool-to-design. So what’s Calypto doing to address the key points in their HLS tool Catapultand Sequential Logical Equivalence Checking (SLEC) tool? We need to watch out on that. Stay tuned to hear more on specific HLS improvements from Calypto to provide a superior experience to designers.

More Articles by PawanFangaria…..