Redefining Design with ESL
By Rami Rachamim
Mentor Graphics Corp.
Many companies today are trying to determine exactly what is Electronic System Level (ESL) design, the value it may bring, the vision behind it and how it can impact their current “way of life”. Why? Because ESL has the potential to greatly transform and improve the current design process, redrawing the traditional boundaries of the EDA industry. Consequently, designers are paying greater attention to it as a growing number of consumer and mobile companies are adopting ESL methodologies.
There are several perspectives needed to fully understand ESL, some of which we will try to cover. In the most general form ESL is the design paradigm above RTL, the current foundation for the development process. But this is the most simplistic view. From a flow perspective, ESL aims to automate the path from concept to implementation. From a business perspective, ESL will lead to reducing cost through higher productivity, reducing engineering costs as well as variable (silicon) costs, and reducing development time. ESL will also help drive better business requirements and constrains into the design process.
From an engineering point of view ESL brings a leap in abstraction with all the associate benefits. Similar to how the adoption of RTL led to tremendous design creativity, the adoption of ESL could take the electronics industry to a whole new level of productivity. The ability to control, differentiate and scale electronic products could dramatically change due to ESL methodologies, making it extremely important to management, promising to produce better products with the same or less design effort.
The Abstraction Leap
The move from Gate Level to the RTL flow was relatively smooth transition since both are encapsulated within the same implementation domain. Moving from implementation (RTL) to higher design phase (ESL), however, is a much larger leap that re-defines the boundaries of any specific hardware, software or architecture. This move dramatically empowers the flow, but also demands more sophisticated and automated processes (e.g. high-level synthesis).
Changing abstraction on the hardware side implies the abstraction of data types, communication and computation. Even more fundamental, is the abstraction of implementation details from the hardware description. This is similar to the software world, where software applications can be developed on a generic platform and can be targeted into different processors and architectures. As a result, software development is independent of the target platform.
The elimination of hardware implementation affects all the modeling layers and requires a new way of describing system behavior—such as in the emergence of TLM (Transaction Level Modeling) – to support the ESL methodology. TLM describes communication in a generic form, such as read and write transactions. The focus is on what is being communicated rather than how it is being communicated. TLM modeling is independent of any specific protocol being used to transfer data or the bus used to transform it. Such abstraction is well aligned with the software communication layer.
Similarly, when describing computation logic in ESL at a higher level of abstraction, only the high-level functions and algorithms used to process data are captured initially, not the hardware that is used to perform those functions. The elimination of implementation details creates a model that is hardware and architecture independent allowing it to be mapped into different implementations while keeping functionality intact. The absence of implementation details also means it can run and simulate much faster and can execute real time software.
Design Modeling Crucial to ESL
The core of such an ESL methodology needs to build on a well defined modeling semantic and structure, allowing teams to define and execute their strategies in a deterministic way. As opposed to RTL, the model at the ESL phase serves different domains with potentially conflicting requirements, such as hardware analysis and software validation.
Often times the model needs to transform from an un-timed sequential description to a timed concurrent one because functionality may be sequential while implementation is concurrent by nature. Such a transformation is similar to the challenge of mapping single threaded software onto multi-core architecture with concurrent processing engines. This can be solved by keeping functionality and implementation (mainly timing and power) separated and independent as possible. Timing in this regard reflects the micro-architecture (pipeline, for example) of a given implementation.
Virtual Prototyping Enabled
The benefit of keeping these two phases independent can be shown in this simple example. Let’s assume there is a set of functions (e.g. C/C++) that define the required hardware behavior. Those functions, that perhaps represent processing/communication algorithms or control functions, are wrapped into TLM hardware models that can process and transfer large blocks of data at zero time. Such models usually contain Registers View (also known as PV – Programmable View) to allow interaction with software.
At this point how data is processed or transferred is not important, only the data itself and where it is stored (memory allocation) matters. Simulation at this virtual prototype phase is extremely fast since there are no timing events and calculation that usually requires much larger CPU resources than functional processing. It is extremely useful for validating system-wide behavior and can be distributed as a virtual platform for software development at this early stage of the development cycle.
Once the un-timed virtual prototype is validated the design team can start looking at implementation strategies and how to get the required performance from the system. Implementation of the hardware blocks will add the processing delays (latency) with the effect of any pipeline and parallelisms that may be used. Annotating such timing and power attributes that can reflect a given implementation to the un-timed functional description, without changing it, would enable such a flow.
Also, the bus architecture and memory hierarchies will be defined. Consequently, transactions that are executed instantly at the virtual prototype level will now expand in time, taking longer to simulate.
Faster Architectural Exploration
The distribution of data transfers and interrupt latencies over time and across the system will determine the performance of the system and the dynamic power that is consumed during operation. While still retaining control over the system variability, the design team is now able to explore different configurations and test those configurations at high simulation speeds using actual system software and various use cases. If accurate power behavior is available at this level, the design team can explore the entire solution space and achieve an optimal architecture.
When both hardware and software functions are derived from C/C++ functions, users can better practice hardware/software tradeoff cycles.
Hence, the design team can go through such exploration process deterministically before starting any actual implementation, and while keeping functionality intact, they can arrive at a system with dramatically reduced power with higher performance and that is optimal for the application it should serve. Moreover, they have now the knowledge to scale the system and balance it differently to quickly react to market and competitive dynamics.
High Level Synthesis Becomes a Reality
A key technology needed for ESL and design automation is a high-level synthesis. In the ESL design phase, designer should be able to synthesize un-timed algorithms into RTL resources under set of performance constraints. Today there are powerful high-level synthesis tools that automatically generate RTL from higher level descriptions in languages such as ANSI C++. Automating this step can save literally weeks, if not months, of engineering time.
Since the generated RTL is correct by construction and preserves the system designer’s original algorithm intent, it is much easier to verify. Formal equivalence checking is used throughout the process to keep code refinements in sync with the original C++ model, and to comprehensively verify that the RTL functionality matches the C++ code. The testbench created in C++ can be directly re-used for verifying the RTL, eliminating the time-consuming creation of an HDL testbench. Software can also serve as a real-time test mechanism.
ESL Ready Today
ESL holds great promise, offering a new design paradigm that can fundamentally change hardware and software development and can substantially augment the current RTL paradigm. ESL will allow efficient mapping of the concept into hardware and software, resulting with shorter development cycles and more optimal electronic devices and systems.
There are many companies who have already adopted ESL, implementing one or two of the capabilities described above: virtual prototyping, architecture exploration, and/or high-level synthesis. However, very few have fully adopted the entire ESL methodology. That will require more investment, additional technologies and modeling infrastructure, but will also substantially increase the value and scope of ESL within those organizations. So look to see ESL becoming more pervasive and standard in design groups around the globe.
A Holistic View of the Development Process
ESL requires an expanded view of the design process, so let us take a few moments to look at the larger design flow. Basically, the development process can be divided into three phases: Concept, ESL design, and RTL implementation. Each phase is derived from the previous one and feeds the next one.
Concept (Vision): At the concept phase a system designer creates a conceptual description of the system without explicit software/hardware definitions or boundaries concept. The phase starts with a spec and a set of requirements that are mapped into algorithms and functions that can be validated. There are several languages that can serve this domain including UML and C/C++.
ESL Design (Strategy): At the ESL design phase the designer needs to drive its strategies and map the conceptual description into hardware (RTL) and software (C/C++) representations. This is where the ability to impact (variability) is the greatest, and iteration cycles are shorter. The design phase should define the hardware and software domains (partitioning) that can carry the concept and drive parallel hardware and software implementation flows. It should allow exploration and optimization when allocating and configuring hardware and software resources while making sure they interface appropriately.
The ESL design phase is where the designer creates and finds the best possible hardware and software system configuration that is functionally correct and can support the original system concept. The output of the design process should be a well-defined hardware structure at the RTL level (most likely VHDL or Verilog description) and some of the software layers. It is important to optimize systems against real software since the application greatly impacts the performance and power behavior of the system, and is reflected at the user experience level.
RTL Implementation (Tactics): At the implementation phase the designer actually executes upon the ESL guidelines and maps the hardware (RTL) into silicon. Automating the ESL design phase would not only make the RTL implementation task more efficient, it would also result in shorter verification cycles, since the integration of the main hardware and software blocks is already validated. RTL Verification would then focus solely on implementation related aspects, rather then system-level aspects (e.g. hardware/software interaction, protocol mismatches and data integrity) that are much harder to detect at RTL.
October 10th, 2008 at 12:44 pm
Rami -
Very nice article. I have one question/comment: You seem to only briefly touch on the Quality of Results issue … in the section “High Level Synthesis Becomes a Reality” you gloss over the specifics and state “Today there are powerful high-level synthesis tools that automatically generate RTL from higher level descriptions in languages such as ANSI C++. Automating this step can save literally weeks, if not months, of engineering time.” which I believe is true … except it doesn’t say anything about the QoR produced by HLS tools!
These high-level synthesis tools have yet to demonstrate they can produce gate-level implementations BETTER than an RTL flow. In fact, Cadence states on their C-to-Silicon tool datasheet that users should expect gate-level implementations to be only 90% as good as an RTL flow.
So – are you saying IC designers will be motivated to move to a higher-level design flow even though the gate-level implementation is INFERIOR to an RTL design flow? That is saying that shoppers today will pay for a new consumer device or network processor that is slower, more expensive, and consumes more power? When you look for a laptop, are you willing to purchase one slower with less memory and costs more than the one you bought last year?
QoR for most IC designers is the MOST important criteria … they simply cannot move to a design flow that makes their job complete faster (as you say, productivity is improved) IF the result is a less competitive gate-level implementation.
In my opinion, this is the achilles heel of ESL flows. Until they can deliver BETTER QoR than an RTL flow, all the benefits you point out will be largely ignored. History shows this – else Forte, CoWare, AccelChip, et al would all have become major EDA players by now. Where are they today??? Not major players :^)
ESL does hold great promise – but until the gate-level designs are BETTER than an RTL flow, it’s not ready as you claim.
If you go back and study the rise of the RTL design methodology in the early ’90′s, you’ll see the same was true then. History does repeat itself. RTL was adopted because it produced better gate-level implementations … period.
Just ask all the Synopsys FAEs who performed thousands and thousands of customer evaluations in the early 90′s …. they had to prove the QoR before anyone would move from their existing design flows.
Same is true today!!
Dan
October 24th, 2008 at 3:45 pm
Interesting article. ESL has been promoted for quite some time now, and the benefits are clear, so why is it taking so long to adopt? Dan’s reply above gives us a clue: the focus is on beating the current RTL designers at their own game. This reminds me a lot of the compiler wars of the 80s: compilers were not to be trusted as they produced code that was slower and bigger than hand-coded assembler. Fortunately this argument was eventually lost for all but the most demanding performance applications. The consequent increase in market size for compilers brought investment and improvement allow us all to move forward. Engineers need to start seeing the bigger picture here. ‘Better’ implementations can be slower and use more gates if they bring improved functionality to the market earlier. So what if you have the most efficient design out there if it is 6 months late to market?
October 31st, 2008 at 11:18 am
Good article. And as it always happened in the past adoption of new technology has resistance from the older one. But most importantly, ESL provides the essential step of increasing the abstraction level, without which making larger designs of the future is not feasible. Of course, one stumbling block for hardware designers is that they should become also good software designers. C++ is a very powerful and flexible language, easily spanning both hardware and software design needs, but it also comes with a cost of time and efforts learning to use it efficiently. We found in producing our own software, that providing hardware designers with a sort of schematic editor, which automatically generates C++ code for simulation library makes the whole process much easier. Automatic C++ code generation prevents errors, due to inexperience, make the process go faster, it’s also easier to reason about a diagram than about hundreds of lines of code it represents, and importantly, it teaches a hardware designer to use C++ language and simulation library while working on hardware design, so even a person with very rudimentary knowledge of C++ can quickly create working ESL applications.
November 21st, 2008 at 12:13 am
While Dan points to some of the challenges in getting the tool across engineering community, Mark has a perfect answer comparing it to the Compilers evolution. I think any tool be it in HW or SW or across the two boundaries (ESL) will have to prove its utility to change/get accepted in an existing design flow. As the designs get complex and system design takes center stage, HW and SW need to be addressed by a set of common tools. The current EDA and SW tools are still focused on their vertical domains. Moving up abstraction levels is a must in order to address system level requirements.
February 25th, 2009 at 8:26 am
> so why is it taking so long to adopt?
I think there is a gap between RTL designer and system designer. RTL designer is creating a part of system. System designer think how to migrate the parts. For example, system designer needs to think how to establish the arbitration of 2 masters which drive a bus to use slaves. And it should be defined before coding RTL.
In 1990′s, some skillfull designers have their own style/library to simulate such behavior in C/C++ for simulating synchronous system. other designers used Simulink/SPW/COSSAP. SystemC was given for such testing and designing. But still the role of designers have some gap from the capability of the extension.
It is too high abstract for RTL designers who does not care how important an interrupt from Timer for system, and too detail for dataflow designers who does not care about conflict of bus masters.
Many guys know C/C++ is not useful for System validation and designing by its blocking behavior, and many guys are still dreaming.
July 23rd, 2009 at 8:28 am
I think the QoR discussion is missing a major benefit that comes with ESL synthesis adoption. If we were just to compare one design point, then yes I expect that an RTL designer could produce a better design today. Maybe not so with all designers, but the best are the best for a reason. Even then, they will not be that much better and as other people have pointed out, over time that benefit will disappear.
But using ESL allows for architectural exploration, which is not possible at the RTL level. In my latest book, which is just being handed over to the publisher, I have an actual example where a company thought they knew the best solution to a problem. If they had gone ahead and coded it in RTL, they would never have found out that they were wrong. There was a better architecture that they quickly found using the architectural exploration features of high-level synthesis. At the end of the day they saved time, and got a design that was faster and 30% smaller than what would have been obtained with the other architecture. With that kind of gain – who cares if the tool missed 5%!
If you keep the same paradigm, then you will not see the gains. It is only with a shift in methodology and attitude that the gains from ESL start to be seen. It is the inertia associated with the change of thinking that is slowing the adoption of ESL. But those who make the change are seeing the gains.
August 14th, 2009 at 2:28 pm
Brian,
First let me wholeheartedly agree with the general point about HLS enabling architectural exploration, compared to RTL. As I’ve said elsewhere, just as algorithms trump everything else for quality in SW design, similarly architecture trumps everything in HW design. Consequently, one should prefer tools that enable you to converge to better architectures.
One the other hand, let me caution against an expectation that C-based HLS tools enable serious architectural exploration. In our experience they provide extremely weak knobs to control architecture because the tools are stuck with certain templates about architectures (generic datapaths and control engines which are then tweaked for a particular design). As a result, the architectural exploration turns out to be rather “local hill-climbing”. It’s hardest to get such tools to optimize for true system-level considerations such as the memory system (customized prefetching, cacheing, bursting, etc.) These tools may get you quickly to initial RTL, but there’s often a very long tail trying to squeeze it down to acceptable area, precisely because of lack of architectural transparency and control.
Just like the result you cite in your book, a customer evaluation of the Bluespec tool produced a 30% better area compared to a certain commercial C-based HLS tool. The customer hadn’t been aware that such an improvement was possible, even though the earlier C-based synthesis team had tried much harder (2 people for 24 weeks, compared with 1 person for 7 weeks for the BSV design). In this case, HLS was not by itself the magic bullet–it was HLS along with control and transparency over architecture.
And this was not an isolated result–we’ve seen this rempeated in many other instances.
August 18th, 2009 at 4:14 am
I was at DAC this year and was trying to find out how much the users are leaving on the table by adopting high level synthesis. I see Brian mentioning 5% but I am not sure if that is the “average” % the tool missed. Does anybody have any pointers on representative average numbers from the industry?
The other key point to note is how one arrives at the reference area target; more often than not, this is guesstimates and can cause a misleading impression.