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.