Whatever Happened To HLS?

Experts at the table, part 3: Targeting FPGA resources, OpenCL, tackling safety and security issues, addressing IoT needs.


A few years ago, (HLS) was probably the most talked about emerging technology that was to be the heart of a new Electronic System Level (ESL) flow. Today, we hear much less about the progress being made in this area. Semiconductor Engineering sat down to discuss this with Bryan Bowyer, director of engineering for high-level design and verification at Mentor, a Siemens Business; Dave Kelf, vice president of marketing for OneSpin Solutions; and Dave Pursley, product manager for HLS at Cadence. Part one can be found here; part two is here. What follows are excerpts from the conversation.

SE: Is there demand for HLS in FPGA?

Bowyer: All over the place. A lot of usage is for prototyping. Here is my big ASIC and I want to do early production using an FPGA and it will eventually go into the ASIC. There is a growing group of people looking to target FPGAs as an endpoint and not have to learn RTL. Xilinx and Altera have dreamed about this for a long time. Can we get to the people who are used to writing customer software for DSPs, for GPUs and get that into an FPGA? That is starting to happen. We see Amazon having FPGAs in the cloud. The idea is that you use HLS to target these things.

Kelf: They dream of this market where there is a guy writing C or C++ and putting it into FPGAs. OpenCL is another language being used for this. The issue is that by skipping the RTL step, and trying to go from system level to an FPGA matrix is a big leap and the verification is being stressed at that point. We need to add in equivalency checking at the RTL level and add sequential equivalence checking because the registers have moved around and tie that in with consistency checking between the C and RT level to get the whole flow working. This is a big issue.

Bowyer: Yes, this is one place where you do see HLS in the news. Migrating software into hardware.

SE: Does OpenCL become the new language?

Bowyer: For hardware design, OpenCL does not really fit, but for software there may need to be some language like that. The jury is still out on OpenCL, but something like it will be needed. This is not just for FPGAs, you need it for parallel processing, GPUs etc.

Kelf: Altera is pushing OpenCL hard for exactly those reasons. They want to have a portable design representation from the DSPs and GPUs straight into FPGAs. It is more of a use model thing rather than a language discussion. FPGAs have also opened up new applications for HLS way beyond the graphics area. One automotive company was trying to work out how to go from small microcontroller designs into FPGAs.

Pursley: OpenCL targets a certain class of applications really well so maybe there isn’t one language, maybe there are ten languages. Right now SystemC is what we have that can handle the control and can handle the parallelism, but for certain applications, where you want to accelerate your algorithm on the FPGA, it makes perfect sense.

Bowyer: Good point. We cannot assume the next language will be one language. There may be domain specific languages that grow out of everything.

SE: What about embedded FPGAs? This is slightly different than targeting a commercial FPGA chip.

Bowyer: Yes, and not just that, but the ability to reprogram those internal resources in the field. That is where it gets exciting. Today the reality is that you program it once and ship it, but there is a lot of interest in having a chip able to morph into something else in the field. Once you put the FPGA on the chip you solve one of the biggest problems of FPGAs, which was that you had a very narrow pipe to go between them. With a wide pipe between the CPU, FPGA and DRAM, it really changes the value of FPGAs.

Kelf: Another application is base stations for mobile. They have been users of the large FPGAs for some time, and that enables them to reprogram the base stations and upgrade them. But someone has to go there and do that. When they get access to embedded FPGAs, they can configure things in the field. The base station has many algorithms embedded into it, such as different modulation algorithms or going into different markets with different standards, or different terrain. So they would be able to do it with one device that can be reprogrammed for local needs. There are many applications that have this kind of problem. You have the notion of semi-flexible chips. HLS is perfect for this type of application. You start with the system modeled in SystemC and test the whole thing together and you want to verify all of the various modulation algorithms at the high level.

Pursley: We have seen a much simpler application than that, and that is basically turning the power/performance knob. This is so easy to do with HLS.

SE: Optimization choices may change when you have more bandwidth and more memory.

Bowyer: It is interesting because it is not something that people have done before. You are opening up a world of design architecture and research. They could not have been conceived in the past. And right – a good application for HLS. The microarchitecture is tunable in the synthesis process so you can make the tradeoffs in real time as you are designing the algorithm, and when doing the verification you can find and fix these things and improve them.

Pursley: And quantify them.

Bowyer: At the end of the day, you have working hardware that is running at speed and you can try it in an FPGA. Most ASIC designers would love to have that speed. FPGAs will be much more competitive to ASICs in that space because most ASICs are IO limited.

SE: Design and verification have transitioned from just being about functionality and today they are multi-faceted. Power was the first orthogonal issue. Now we are adding safety and security. Does that put additional strains on HLS?

Pursley: There are some methodology changes especially when you are talking with the defense department. You partition things into multiple domains and ASICs, but most of that is in the higher level methodology and putting in place a solid verification methodology.

Kelf: Safety and security issues require new verification techniques, such as fault injection. We are seeing quite a lot of the at RT level and have started seeing some at the SystemC level where users need to inject faults at the high level and obtain a high level diagnostic number that they can meet for various standards such as ISO 26262. That is hard at the SystemC level, and the standard says you have to do it at the gate level. But at least you can do some of the work at the higher levels and know that when it is synthesized, that you will be able to meet the coverage required by the standard. With security, there is the case of can you read the encrypted word or get at some protected region of the device, we are seeing that a lot in the SystemC space and people are talking about how to build the necessary protection in there and verify that. Formal is good for this type of thing. Another interesting area is Trojan horses. In the past three or four months, especially from defense contractors, there has been a lot of interest in Trojan horse analysis. Has the design changed in ways which we are unaware of?

Bowyer: Formal benefits from abstraction even more than simulation. There are formal properties that you could never attempt to verify at RTL but are quite straight forward with some procedural C code or SystemC. Moving up in abstraction brings in a lot of benefit for formal because it is simpler. All of the things you see today at RTL formal, you will eventually see in C and SystemC.

SE: Safety is tackled primarily using redundancy today. Can HLS do better if you know about the safety requirements?

Kelf: Yes you can do that today. For aeronautical designs, they use a lot of redundancy and they have lots of space for it. With ISO 26262 it is entirely different. They have space and power constraints and they are doing error correcting codes, locks step analysis, watchdogs: but they are pulling away from that. At the abstract level you are able to do a lot of the basic testing to ensure that hardware mechanisms do the right thing. With ISO 26262 you have to do most of the testing at the RTL or the gate level. That is what they mandate and the standard has to catch up. But we can do much of the analysis at the higher level and just do the final fault coverage at the gate level.

Bowyer: HLS does have the opportunity to do things such as Triple Modular Redundancy (TMR) and duplicate registers or encode parity bits into the state machine. Once you get beyond the generic capabilities, it is hard to make things automatic. The growth will be more in terms of people designing this type of capability in rather that trusting a tool to design it in. But for the simple things, we can do that.

SE: The IoT market has different requirements. What demands does this place on HLS?

Pursley: With most of the larger semiconductor companies, it is different divisions doing it and they are adopting similar methodologies, so it doesn’t really create any new demands. But for a lot of the smaller companies, they may just be creating one specific chip, they may not have a large design team but they still need to get to hardware and it may well be a big A little D chip. HLS gives them a way to avoid having a large digital hardware team. With HLS you can get hardware without needing to be an expert RTL designer. But high-end graphics, wireless or that kind of thing, you do need experienced hardware designers.

Bowyer: We see interest with things such as battery charge controllers or mirror controllers, where a lot of the simulation is done up front in C or abstract languages. That means they can do verification at a much higher rate. But it is little D, a tiny piece of hardware and the only thing they worry about is power consumption. It may be on an old process.

Kelf: You need to see an application with a significant new requirement and with IoT, there may be a power issue, but with safety, there is a huge new requirement and that will bring in new methodology.

Pursley: It is really just a new type of user.

Related Stories
Whatever Happened To High-Level Synthesis? Part 1
What progress has been made in High Level Synthesis and what can we expect in the near future?
Whatever Happened To High-Level Synthesis? Part 2
Playing in an IP integration world, defining verification flows and compatibility with a virtual prototype.
Embedded FPGAs Come Of Age
These devices are gaining in popularity for more critical functions as chip and system designs become more heterogeneous.
Embedded FPGAs Going Mainstream?
Programmable devices are being adopted in more market segments, but they still haven’t been included in major SoCs. That could change.


Kev says:

Time to get beyond RTL, OpenCL won’t cut it – you need something like CSP as a methodology –


Extended C++ – http://parallel.cc
GoLang – https://golang.org/doc/faq#csp

Leave a Reply

(Note: This name will be displayed publicly)