[content] => 
    [params] => Array
            [0] => /forum/index.php?threads/dac-hls-panel-who-drives-whom-high-level-synthesis-or-ip-reuse.4273/

    [addOns] => Array
            [DL6/MLTP] => 13
            [Hampel/TimeZoneDebug] => 1000070
            [SV/ChangePostDate] => 2010200
            [SemiWiki/Newsletter] => 1000010
            [SemiWiki/WPMenu] => 1000010
            [SemiWiki/XPressExtend] => 1000010
            [ThemeHouse/XLink] => 1000970
            [ThemeHouse/XPress] => 1010570
            [XF] => 2021270
            [XFI] => 1050270

    [wordpress] => /var/www/html

@DAC HLS Panel: Who Drives Whom: High Level Synthesis or IP Reuse?

John Swan

New member
I would ask: Is anyone actually using HLS yet for highly reusable IP? This is beginning to happen and I will say more but first let's look at some positions taken on the panel.

The panel was moderated by Warren Savage if IPextreme. Anyone in IP for long knows of Warren as he has been active in IP for a long while. It's guys like him that help make the commercial IP market succeed. The panelists were Oliver Gunasekara, of NGCodec, Shishpal Rawat of Intel, and David Garrett of Broadcom. I first met Oliver at the GSA IP Summit in 2008 and know that he has been involved in design with a concern for internally and externally developed IP. NGCodec does video compression. I think he understands IP from a design ecosystem perspective. Shishpal has been involved for several years with IEEE ESL standards related activities and is the current Chair of Accellera. He brings to the panel a good overall ESL perspective. David is known as an HLS expert within Broadcom.

One question from the audience was: What should someone not use HLS for? David responded that extremely high speed microarchitectures where the designers understand well how to tweak the design in ways that HLS tools may not be able to do. HLS, he notes, takes a generalized approach to area/speed tradeoff. Shishpal answered that you shouldn't expect to use HLS in mixed-signal design.

Another question from the audience (I asked) was regarding the cultural change involved in adopting HLS. The team admitted to this being an important hurdle to overcome. There was a cultural change in design methodology when we moved from gates to HDL. But at least the RTL had the same timing as the gates. the ESL code feeding into HLS is untimed, therefore a greater 'distance' from the output. Additionally the HLS input is sequential code vs. the concurrent constructs the HW designer is used to in the HDL's. Again, the input code to the HLS is a greater 'distance' from the output vs. that 'distance' compared to the HDL to gate synthesis flow.

Main take-always from each of the panelists:

  • David - You have to get to know the strengths and weaknesses of the HLS tool(s) you use. They are different for each tool and in order to get a good design result, knowing this is a must. Just start using the tool, and start getting to gates quickly to confirm it's doing what you want.
  • Shishpal - Having an adoption strategy is key. You need internal champions that act as internal AE's from the CAD group that partner with the design teams for adoption. They help the team ensure success on the first uses, until the design teams are proficient in using HLS. This is because of the significant cultural change in the design flow.
  • Oliver - Noted that HLS provides a good opportunity for taking early vertical slices of the design down the flow to support exploration and validation of performance and power.

There was a common theme was among the panelists. The way I would explain it is a concern for how to keep the ESL code the golden code. If and when needed changes to a design are found at the RTL or gates, can designers change the ESL code and get the results they want? If not, they make the required changes at RTL or gates, and now the ESL code is no longer the golden model. This is a problem. Cadence's C2S supports ECO, but there needs to be wider support for this.

HLS first came to the market with at least 4 commercial providers in 1997. Adoption has been slow and it's a chicken-and-egg situation. Design teams are slow to adopt because they feel the HLS tools can't do as good a job of creating quality RTL in a wider range of designs. But wider adoption of HLS would drive development of improved tool capability as well as the ESL/HLS ecosystem. I know of two startup companies developing IP with HLS: Adapt IP and Auviz Systems. Additionally CircuitSutra presented an HLS IP core for AMBA AXI4 at the North American SystemC User Group (NASCUG) on Monday. See my blog on NASCUG here. Do you know of others? NGCodec?

View attachment 11310

Last edited:


New member
Actually HLS tool may have more usage than converting a HW design written in C/ C++/ SystemC to RTL. Sometimes the RTL generated from HLS tool may not be of as good as hand written RTL. But HLS tool can provide a good insight on the advantages and disadvantages of a particular architecture used for C to RTL conversion. A design in high level language can have several RTL implementation and each implementation has its own pros and cons w.r.t. area, latency, frequency etc. HLS tool can provide a designer quick overview of those pros and cons and after that the designer may write the RTL himself for the architecture best suitable for his purpose


John Swan

New member
Barun - you are absolutely correct. HLS can produce worse results than hand coded RTL, and it can also product better results than hand coded RTL. Depending on the situation.

The process you are referring, of using HLS to explore architectures, can also be called taking 'vertical slices' of the design. I documented that one of the panelists, Oliver, agreed with you about this. However, consider the following.

Regarding "better" or "worse" HLS synthesis results: it can relate to any combination of
  • Performance
  • Area, and
  • Power
  • plus I am adding design cycle time: time to write & verify the design.
Quality of results (QoR) also depends on the
  • The function being synthesized
  • The strength of the synthesis engine being used for that particular algorithm
  • How the function was coded, and
  • The constraints used for HLS synthesis
By varying the constraints, and even how the functional code is written, you can vary the QoR around the performance, area, and power space. And get several results to choose from within minutes or hours.

So while you have the option to hand code the function in RTL, you now have the option of selecting among several micro architectures and related trade-offs.
Last edited:


New member
So while you have the option to hand code the function in RTL, you now have the option of selecting among several micro architectures and related trade-offs.

Yes, you are right. But I think this is one area none of the HLS companies are promoting till now. All HLS companies highlight the benefits of writing code in C which results in shorter design cycle due to much smaller code size, much less verification effort. HLS very seldom has been projected as a tool to architecture analysis and selection of right architecture

John Swan

New member
Actually I have seen the message by commercial HLS suppliers about using their tool for architectural exploration. Admittedly, it gets lost in list of other benefits of HLS. One example of this exploration capability is NEC's CyberWorkBench, which has an automated 'System Exploration' module. It varies user-selected constraints and plots results of only the improved architectures. It can produce several architectures in minutes.