Commentary
The future is High-Level Synthesis
Sean Dart
2/4/2011 10:53 AM EST
The future is high-level synthesis (HLS). As a developer of HLS software, Forte’s vision for this methodology is far reaching and all inclusive, and one we’ve considered for some time. We share a common belief with other HLS developers that it will replace the register transfer level (RTL) as the predominant front-end design methodology and will be used to do everything logic synthesis can do today.
The semiconductor industry is not there yet, and getting to that point will clearly take time, both in terms of extending the capabilities of the technology and driving adoption by the design community, but the trend is clear. The transition from gate-level design to RTL set a clear precedent. The industry saw the adoption of new tools, development of designs and intellectual property (IP) and, eventually, the bulk of designs and IP exist in the form of RTL code.
A number of key drivers and requirements enable such a methodology transition, beginning with productivity. Productivity is increased through the delivery of a more abstract design language. Back in the day, when hardware designers transitioned from assembly code to high-level languages for software development, they saw a huge increase in productivity, delivered by abstraction. Coders could add significantly more functionality with less lines of code; debugging was easier; maintenance was easier; code was more understandable; and reuse was increased.
These same designers experienced the same kind of change when hardware design transitioned from gate level to RTL. And, it will happen again as design teams transition to C++ from Verilog and VHDL.
However, abstraction on its own is not enough for hardware design. Designing a chip with complex behavior is a huge undertaking with many engineers assigned to various aspects of the project. A hardware design language must support the partitioning of the design into smaller chunks to provide manageable pieces for tools and scalability, to divide work among separate engineers or teams and chip functionality into sensibly reusable pieces. Key additions to a language to support such partitioning are modules, hierarchy and interfaces, something found in C++.
It is also critical to consider not only the final state of HLS deployment, but how design teams transition to that state. This will be a gradual transition, and during that time, blocks designed using HLS must coexist with blocks designed with RTL languages. They must interface cleanly and consistently, simulate together and merge well during implementation.
And, that’s the task set in front of developers of HLS technology: to deliver a methodology that increases productivity through abstraction and also deals with the practical issues of partitioning and integration with existing design blocks. These issues need to be carefully considered and solved to get all the way to the end.
That’s why many of us have chosen SystemC as the design language for HLS. Plain old C++ may seem logical when first considering a move to HLS, and it can be a useful utility for block-level experimentation. But when design teams look more closely at the problem, they will recognize that they will never be able to replace their entire RTL design flow without the extensions that SystemC delivers.
The transition from RTL to HLS as the predominant front-end methodology is under way. As the design community will soon discover, SystemC will be a ready enabler for this move.
About the author:
Sean Dart is president and CEO of Forte Design Systems Inc. (San Jose, Calif.)
Dart joined Forte Design Systems Inc. in 1997 and has over 20 years of software design experience, with 14 of those years in EDA. Prior to joining Forte, he was the CTO of Speed Electronics S.A., a company specializing in front-end design tools for logic synthesis flows. Prior to Speed, Dart held a number of software management and development positions in the fields of telecommunications and operating systems development. Dart graduated from the University of N.S.W. in Sydney, Australia.
The semiconductor industry is not there yet, and getting to that point will clearly take time, both in terms of extending the capabilities of the technology and driving adoption by the design community, but the trend is clear. The transition from gate-level design to RTL set a clear precedent. The industry saw the adoption of new tools, development of designs and intellectual property (IP) and, eventually, the bulk of designs and IP exist in the form of RTL code.
A number of key drivers and requirements enable such a methodology transition, beginning with productivity. Productivity is increased through the delivery of a more abstract design language. Back in the day, when hardware designers transitioned from assembly code to high-level languages for software development, they saw a huge increase in productivity, delivered by abstraction. Coders could add significantly more functionality with less lines of code; debugging was easier; maintenance was easier; code was more understandable; and reuse was increased.
These same designers experienced the same kind of change when hardware design transitioned from gate level to RTL. And, it will happen again as design teams transition to C++ from Verilog and VHDL.
However, abstraction on its own is not enough for hardware design. Designing a chip with complex behavior is a huge undertaking with many engineers assigned to various aspects of the project. A hardware design language must support the partitioning of the design into smaller chunks to provide manageable pieces for tools and scalability, to divide work among separate engineers or teams and chip functionality into sensibly reusable pieces. Key additions to a language to support such partitioning are modules, hierarchy and interfaces, something found in C++.
It is also critical to consider not only the final state of HLS deployment, but how design teams transition to that state. This will be a gradual transition, and during that time, blocks designed using HLS must coexist with blocks designed with RTL languages. They must interface cleanly and consistently, simulate together and merge well during implementation.
And, that’s the task set in front of developers of HLS technology: to deliver a methodology that increases productivity through abstraction and also deals with the practical issues of partitioning and integration with existing design blocks. These issues need to be carefully considered and solved to get all the way to the end.
That’s why many of us have chosen SystemC as the design language for HLS. Plain old C++ may seem logical when first considering a move to HLS, and it can be a useful utility for block-level experimentation. But when design teams look more closely at the problem, they will recognize that they will never be able to replace their entire RTL design flow without the extensions that SystemC delivers.
The transition from RTL to HLS as the predominant front-end methodology is under way. As the design community will soon discover, SystemC will be a ready enabler for this move.
About the author:
Sean Dart is president and CEO of Forte Design Systems Inc. (San Jose, Calif.) Dart joined Forte Design Systems Inc. in 1997 and has over 20 years of software design experience, with 14 of those years in EDA. Prior to joining Forte, he was the CTO of Speed Electronics S.A., a company specializing in front-end design tools for logic synthesis flows. Prior to Speed, Dart held a number of software management and development positions in the fields of telecommunications and operating systems development. Dart graduated from the University of N.S.W. in Sydney, Australia.
Navigate to related information


Jack.Erickson
2/4/2011 2:24 PM EST
Well-said, Sean. SystemC provides pre-defined constructs for defining the hardware items that you describe as necessary. This not only makes it easier for hardware designers to adopt, but it also provides an agreed-upon set of constructs so that we as an EDA industry can build an ecosystem of tools and IP so that this methodology can become mainstream.
Sign in to Reply
Frank Eory
2/4/2011 3:02 PM EST
Maybe this time around the block, HLS will finally succeed.
Sign in to Reply
Amit.Hermony
2/6/2011 11:04 AM EST
Its important to understand there is still a wide gap between the promises and the actual capabilities.
Today HLS is a niche aimed at data path and still lacking on ability to describe the control and build an efficient pipe.
Its also important to remember that the promise is that you can write high level code – not RTL style systemC. This means that weird coding style that hint the tool how implementation should be done – may be practical but are not putting this approach on the right track.
Sign in to Reply
Jack.Erickson
2/7/2011 2:59 PM EST
Hi Amit - you should check out the more modern offerings from Cadence and Forte. Both of these synthesize datapath and control logic together, and both synthesize untimed or loosely-timed SystemC. The technology to use HLS for production design is finally here, and companies are doing just that!
Sign in to Reply
KB3001
2/13/2011 5:33 AM EST
We have been hearing this for years Jack. I would like to see benchmarks and results from independent sources.
Sign in to Reply
eewiz
2/13/2011 10:40 AM EST
Totally agree with KB3001. From atleast ~2004, I am hearing the same thing too. Still most companies are using just RTL based synthesis.
Sign in to Reply
Rishiyur.Nikhil
2/7/2011 3:22 PM EST
"Plain old C++ may seem logical when first considering a move to HLS ..." What's logical about using a language, optimized for sequential computing, for HW design, where there is abundant, fine-grain, heterogeneous parallelism? Or about using a language for a fixed architecture (von Neumann), when HW design is all about finding good architectures for each app? SystemC hardly addresses or improves on these misplaced assumptions! No wonder Amit.Hermony talks about "weird coding style"! Perhaps it's time to re-examine all these misplaced assumptions and look for languages and computational models for HLS that are more tailored for HW design?
Sign in to Reply
KB3001
2/13/2011 5:35 AM EST
An objected oriented tool is good for modelling and for design space exploration. I am not sure about its use for synthesis though.
Sign in to Reply
Frank Eory
2/7/2011 3:35 PM EST
The best "language" for HLS isn't a language at all, it's a graphical block diagram -- something a system engineer can use to see the datapaths and to wrap his or her mind around the signal processing that needs to be done. Think of tools like Simulink or SPW.
For those who are solving problems that are mostly control-oriented and not datapath-oriented, then the best language for HLS is none at all -- HLS isn't the right technology for those designs. Square peg, round hole.
Sign in to Reply
KarlS
2/8/2011 10:19 AM EST
Hi Frank -- Well said, I did have to make a concession on one point: Using text for design input has logistical advantages such as running a diff program for managing changes.
All this ESL is so "programmers" can design hardware that has inherent parallelism that a good design will exploit. Just after the programmers find out how to really program multi-core I may become interested in that idea.
For many years there has been a way to run procedural code to solve procedural problems. It is called a COMPUTER!
Sign in to Reply
KB3001
2/13/2011 5:37 AM EST
There is a lot to be said about visual programming indeed. That said, this is just a front-end issue. You can still have HLS below that.
Sign in to Reply
shorie
2/13/2011 3:55 AM EST
Hi, would anyone please guide me, whether should i learn system-verilog via verilog or should go for c and system C
Sign in to Reply
MHK_#1
3/2/2011 12:58 AM EST
Shorie, You are not trying to create a holy war on SV(SystemVerilog) vs. SC(SystemC), aren't you? IMO, I don't think there is any big different at the end. Only thing I could tell you is that where was your home base, is that in hardware side or software side. If you are thinking the concept of the final product in either hardware or software, you can start your small bit in SV or SC, respectively. That is my 2 cents.
Sign in to Reply