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:
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
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: