Some system-level advocates suggest limiting ESL to the next step above hardware. Others suggest it encompasses a variety of techniques, which only have in common the fact that they are applied prior to the register transfer level (RTL), which has been for at least the last 10 years and still is the pre-dominant entry point from which chip implementations are derived.
Driven by my German genes, my impulse is to help to put pre-RTL technologies into buckets with nice labels on them like ESL. Yet I will resist doing that and focus on what I think matters to developers, who really don’t care about the names given to technologies they are using.
On The Job
The developers I talk to during my day job care about being as productive as possible. They have ideas and need to get them to implementation as quickly as possible to meet specific market windows. Depending on which application domains their ideas target, different requirements will drive their implementation decisions. Some care more about power, others about performance, and everybody seems to care about cost.
Complexity is the key issue making developers’ lives complicated. The number of issues they have to wrap their heads around has grown tremendously. In less than 25 years, chip complexities have grown about 12,846-fold from 134,000 transistors in 1982 for an Intel x286 to 1.72 billion transistors in 2005 for a dual-core Itanium. And, the complexity of software running on embedded processors in those chips has exploded as well.
Given the growth in complexity, developers depend on technologies to improve their productivity. Enabled by tools, the design entry level moved up from transistor layout to logic gates to RTL. A chip with a billion transistors can be expressed in about 100M logic gates and about 10M lines of RTL. In every step up, a new design entry technology was introduced. These entries were about 10 times less complex than their predecessors. Also, the next level down could be automatically derived from the new arrivals (see the figure).
Abstraction allows representation of the design intent at a new design entry level with about 10 times less complexity. Synthesis permits the automatic implementation driven by the higher level of abstraction. Once automation of implementation exists, verification can be performed at the higher level of abstraction, and formal verification can prove the equivalence of both representations.
So where does that leave us with system-level design? The discussion about ESL is missing a clear definition of the “S” in ESL, i.e., what a system really is. It is all a question of perspective. One developer’s system becomes a component for the next developer. Let’s use the design entry at RTL as starting point. For Example…
My last chip was an MPEG-2 transport/video/audio decoder. Main design entry level was RTL. The focus was on the design of blocks, how to reuse them, and how to assemble them. At the time, my team and I actually thought of it as a system, a system-on-a-chip (SoC) to be precise, because it had at least 30 blocks, all connected though busses, sharing memory, and so on.
We had to perform architecture analysis, decide which function gets which memory bandwidth, and complete other tasks. However, our chip was only one portion of a set-top box, which was the next level of “system,” integrating various chips and software. And then the set-top box was itself part of an even bigger system, the cable and satellite networks.
That was about 10 years ago. Even today that chip likely would not be represented and automatically synthesized from a higher level of abstraction. Conceivably, the individual blocks all could be automatically synthesized, but the assembly would likely be done in a hierarchical fashion. Our chip at the time was hardware only. Today it probably would have one or more processors with software on it.
This adds a whole new dimension to the task of architecture analysis, as now hardware/software tradeoffs are an option. In addition, a single, universal new level of design entry above hardware and software is even more difficult to find, especially one from which implementation can be automated.
To me, the quest for the next design entry level, the next level of abstraction, is still on. The industry is talking about transaction-level models (TLMs) as a candidate. They work well for use cases like creating virtual platforms for early software development. The SystemC TLM-2.0 standardization has opened new opportunities here. But are TLMs the panacea for system-level design? Are they the next level of design entry?
We have heard claims that a chip with 10M lines of RTL can be represented in thousands or even hundreds of lines of TLMs. This would be a totally unprecedented jump in abstraction compared to the past progression from layout to gates to RTL, which all lowered the complexity of the design entry about tenfold.
Just like in the definition of a system, the next level of abstraction may actually turn out to be a matter of the developer’s perspective. There is room for different design entry levels, depending on whether they include software or not and what application segments they target. As long as the tools supporting them increase productivity for developers, nobody will care about naming them and whether they are part of ESL or not.
Future Columns
This series will center around four topics. First, it will address the issues involved in system-level design and modeling independent of implementation. Second, it will deal with the system aspects of hardware implementation, more generally, how to get in a predictable fashion from a high level model to RTL.
It additionally will cover software implementation, specifically how software components are developed and how their implementation can be automated. Finally, it will tackle hardware/software integration at various levels of abstraction—before hardware and software partitioning has been decided on at the transaction-level and at the signal level.