There's no compelling need to move beyond RTL

By Ramesh Narayanaswamy

System-level design languages are being touted as the next step beyond the register-transfer level. But it is clear that SLD won't solve the tough problems we face. We would be best served by improving the efficiency of RTL and verification languages we have.

Before signing on for the move to SLD, we have to ask two questions: Are we ready to shift to it as the central design abstraction for hardware design? And, are the perceived benefits of SLD real?

Let's examine the conditions under which design abstraction shifted in the past, when we moved from transistors, to gates, to RTL. In that case, each abstraction was extremely well-understood by the design community because abstractions were the basis of courses all of us took in circuit design, digital design, computer arithmetic and computer architecture.

Additionally, the abstraction shift was preceded by significant advances in synthesis algorithms that created efficient implementations. Timing analysis and simulation algorithms provided adequate accuracy at the abstract level.

Design Compiler dictates

Notice that the RTL in use today is defined by what the Synopsys Design Compiler can efficiently synthesize. The Verilog hardware description language (HDL) did not define RTL, Design Compiler did. Meanwhile, cell-level timing simulation with the standard delay format (SDF) provided accurate enough results so that only cells had to be simulated in Spice.

As we moved to RTL, silicon process capabilities and analysis capabilities were well matched. As a result, the silicon we got back behaved the way the simulations predicted it would. Silicon processing was advancing fast enough so that the few percent synthesis inefficiencies in area and speed were covered by better silicon.

How does the RTL-to-SLD shift measure up? We do not have a universally well- understood design abstraction beyond RTL.

For example, there are domain-specific abstractions in DSP, or there are general programming languages like C++. We do not have algorithm advances in synthesis or analysis that are shaping SLD. Silicon is not under control; we are required to do more bottom-up design to achieve timing convergence and reliability. SLD synthesis is several orders of magnitude less efficient than RTL-level design and synthesis and we do not have that much silicon to waste.

Given all that, it is clear that we as EDA tool vendors and designers are not ready for this shift.

Let's examine the benefits that were expected from a shift to SLD:

• A higher level of abstraction reduces design time.
• Abstraction and Encapsulation will lead to reuse, which will result in more gates in less time.
• A higher level of abstraction means faster verification.
• A common language for hardware design and software design will promote hardware/software codesign.

In truth, a higher level of abstraction will not reduce design time if you spend time rewriting the code and tweaking tools to get acceptable quality of results.

While abstraction and encapsulation enable reuse, these are not sufficient to promote reuse. It takes considerable reflection and refinement to develop reusable abstractions; typical design schedules don't allow the time to develop them. Only well-understood objects are reused.

A considerable investment in education is required to propagate reusable objects. It is no coincidence that all of the widely used and available intellectual property is for objects out of textbooks such as adders, multipliers and CPUs. Widespread adoption of C++ has not led to a significant increase in reuse in the software industry. We would be better served by focusing on finding good, reusable abstractions and perhaps making some incremental changes to RTL to address encapsulation.

Abstraction lets us manage complexity but it does not allow us to escape it; although we can create terse test benches they still have to cover all the design corners. With the current state of high-level verification languages we are able to create terse test benches, but they are slow and are starting to dominate the verification time. We should focus on improving the performance of test benches by better compilation and by acceleration of test benches.

Since higher level abstraction in the hardware description is not adequately supported by synthesis, we should focus on improving simulation performance of RTL. Simulation accelerators with fast compile times and high performance are the best solutions to this problem.

Design teams have practiced hardware/software codesign without benefit of a common language for many years. Most nontrivial hardware projects I can think of have had a C model that evolves into an RTL model that the software team targets to fine tune the system partitioning and performance. All projects in which I have been involved in the last dozen or so years have involved concurrent hardware/software design. The description language has never been the concern — the real one has been simulation performance of the model.

Ramesh Narayanaswamy is Vice President of Engineering at Tharas Systems Inc., (Santa Clara, Calif.).

Back to TechTrends