High Level Synthesis Grows Up

When Semiconductor Engineering proposed this Experts At The Table discussion, which was held at the recently concluded DVCon, Cadence had yet to express its intention to purchase Forte. Little did we know that the stakes in the high-level synthesis (HLS) arena were being raised so high. Is this an indication of a maturing product, or that things are ready to be taken to the next level?

Semiconductor Engineering sat down with Mike Meredith, vice president of technical marketing at Cadence/Forte Design Systems; Mark Warren, Solutions Group director at Cadence; Thomas Bollaert, vice president of application engineering at Calypto; and Devadas Varma, senior director at Xilinx. What follows are excerpts of that discussion.

SE: HLS attracted a lot of attention in the early days when languages were being decided upon, then there were public discussions about block interfaces, then HLS went quite. What happened?

Warren: The industry has chosen the language. Sure we could have done behavioral coding in SystemVerilog, but talking to customers, most specs that drive toward hardware come from the C world. So C-based languages are better suited to this level of abstraction. Then in the C world it was C versus SystemC and people well understand the pros and cons of this. If you stay in untimed C, things will simulate faster, but SystemC takes the beautifulness of the C++ world and allows hierarchy and organization of your functional verification. Overwhelmingly, our customers see the extra value of this.

Meredith: Another reason for the quieting is that we became too busy. We had customers with real production deadlines and we needed to ensure their success.

Varma: We look at HLS a little differently, given that we come from an FPGA world. HLS is a building block of system-level design. We deliver system-on-chip heterogeneous platforms and our customers have to worry about not just the hardware but how we interface to the software world. Is it going to be one or two people writing this code? Language is not an issue – it is the programming model. We can take any language and make it work. We also support OpenCL. The users will select the right language for the right job.

Bollaert: The selection of the language is not always certain. For example, you can hurt yourself by not using SystemC correctly, especially from a verification standpoint. You can write SystemC that is verifiable and synthesizable, but there are SystemC models that cannot truly be verified.

SE: Semiconductor Engineering recently published an article about Virtual Prototypes (VP) and many contributors to that article said that a flow was not possible between VP and HLS because there was difficulty taking a VP model and using it as input for HLS.

Warren: This is because they have mutually exclusive requirements. For a virtual prototype, your number one requirement is that it runs fast so that you can run software and do testing. If your priority is to generate hardware that is efficient, you need to give the tool enough information so that the tool can find the optimal architecture and configuration. The VP does not care about this information. We are trying to see if there is a middle ground – a coding style that is fast enough for the VP but still provides a good base that can be refined for HLS. The industry is working on this.

Bollaert: This is in part a problem created by the EDA industry because the two tools have been created independently. They do have different requirements and often are created by different teams. Yes, there is a desire to try this out, and we are trying to help by providing synthesizable TLM interfaces that can hook up to VP. We do need to find that middle ground, but the customer motivation is still not clear, and has actually slowed down in recent years. This is because of technical and organizational issues.

Varma: We are seeing a lot of interest in things like OpenCL that take the virtual out of the platform. This does not allow you to investigate performance things or bottlenecks in your system, but people are working on how to introduce that. When people got introduced to OpenCL we saw a significant boost in interest for HLS because there was a clear way to go from a prototype into a hardware platform.

Meredith: There is a natural desire to pull them together because you often have to produce both a loosely timed and an approximately timed model, which are two separate activities. If the implementation model is a completely separate modeling activity, then it is natural to want to reduce the modeling activity. But to take the VP loosely timed model and have that be the input to HLS is not realistic. They cheat in every way they can, such as putting everything in global memory and pass pointers around to achieve speed. A more modest goal is to end up with a VP model and HLS model that share source code even if they use ifdefs, typedefs and conditional compilation tricks.

Varma: People used to ask me to synthesize from a TLM 2.0 model, but today I see more demand for a fast model for the purpose of verification after synthesis is complete. They see more value in this.

SE: Has the typical customer for HLS changed?

Warren: It has been interesting with the merger between Cadence and Forte. We have two independent teams that can now share notes, and our experiences have been completely consistent. When you engage with a new company that wants to quickly design some hardware, they start by saying our software guys write C programs and your input language is C, so we will let these be the tools drivers and I don’t need to hire an RTL designer. But it is much easier to take RTL guys who don’t know C and teach them C than it is to take a software guy and teach them hardware. People now understand the skill sets necessary to use HLS.

Meredith: The desire to take a software guy and have them write hardware is what I call g++ -o99. They have been writing code and running it through g++ at the optimization level of -o3, but with o99 they expect to get parallel hardware. We need to help them learn which things they still need to decide and which things the tool will do automatically. For an RTL designer that distinction is unclear. They need to learn where to let go and have the tool do it for them.

Bollaert: The idea of wanting software engineers to drive HLS was there five years ago, but today they understand it is a tool for hardware designers. Today the question is one of abstraction. What does the SystemC model have to look like, what kind of details does the designer need to put in? The refinement process has to be done by people with hardware knowledge. We have also crossed the chasm in that it is no longer just early adopters, but pragmatists, who are looking for complete solutions and not just point tools. They want a methodology that includes verification.

Varma: I agree that it is about abstraction because abstraction is a good solution for complexity. We used to compete with RTL but not anymore. There are three types of abstraction: sequence, data and interface abstraction. If they are complex and subject to change we recommend that they use HLS. It is easy to change from floating point to fixed point, or to go from a parallel to a serial interface, or add pipelining. These changes are difficult to make at RTL. We have made this accessible at very low cost to all of our users. We have not had to explain to any user within the last year why they should use HLS. But I disagree that it is only for hardware designers. In the beginning we did struggle selling HLS to software engineers, but now we sell HLS in two different packages. One is block design for hardware engineers, the other is for software engineers. This is built as acceleration of the OpenCL or CUDA kernels. The technology is a great fit. If you look at definitions of these languages, the synthesizable subset is almost identical to that of SystemC, although things such as memories are abstracted out. The expectations are different. Hardware engineers want the maximum performance out of the tool. But software engineers are facing a different problem. Performance has flattened out and the only way forward is with parallelism and that is what HLS can do.

In part two of this roundtable, the panel looks at verification and innovation within the sector.