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.
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.
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.
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!
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.
"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?
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!
David Patterson, known for his pioneering research that led to RAID, clusters and more, is part of a team at UC Berkeley that recently made its RISC-V processor architecture an open source hardware offering. We talk with Patterson and one of his colleagues behind the effort about the opportunities they see, what new kinds of designs they hope to enable and what it means for today’s commercial processor giants such as Intel, ARM and Imagination Technologies.