Continuous feedback yields design-by-refinement

It's common to see the term "top-down design" in articles and white papers in the context of digital IC and system-on-chip designs.

"Top-down" means different things to different people. To some, it implies a steady, measured progression from some starting point--say, the original specification--to the final implementation.

One way to visualize this is that we commence with a single block representing the entire design. We then partition this into sub-blocks, each of which represents some portion of the design. These sub-blocks may themselves be partitioned into smaller units, and so forth. Eventually, we fill in the details by creating RTL representations of the contents of the lowest-level blocks. This is obviously a gross simplification, but it serves our purposes here.

In the real world, of course, things are never quite this simple. In addition to being incomplete or incorrect, specifications tend to evolve over time. Also, when the design process begins, the optimal implementation may not be clearly understood. Thus, a more appropriate methodology for today's large, complex and sophisticated designs is that of "design-by-refinement," in which engineers commence with an initial high-level executable representation of the design that is incrementally refined into the final realization.

The problem is that traditional RTL design languages and tools are not conducive to a design-by-refinement methodology, so a new approach is required.

Traditional 'two-step' process
The traditional flow may be largely regarded as a two-step process: first, creating the textual specification, then hand-translating it into the implementation.

The process begins with a set of informal requirements, which are often confusing, contradictory and incomplete. These requirements are then studied by a team of senior system architects and engineers, who--following a great deal of work using state-of-the-art tools such as whiteboards and spreadsheets--produce a big, fat, unwieldy text document called the specification.

By definition, specifications are high-level and leave a lot of detail to be determined later. Having said this, it is human nature to describe in detail anything that is considered clearly understood.

The result is that, despite its grand name, the specification is almost invariably an ad hoc mixture of different levels of detail. Some portions of the design may be underspecified to the extent that they may not actually be feasible--a fact the implementers may not discover until late in the process. By comparison, other portions may be overspecified, with prematurely early commitment to specific microarchitectures that may or may not be appropriate in the context of the rest of the system.

Textual specs can be ambiguous and subject to misinterpretation. The situation is further complicated because the specification and the design are subject to change. Frequently, market requirements--and hence the specification--may change during development.

In other cases, the spec itself may simply be incomplete or incorrect, because it is difficult to think everything through in the specification stage without implementing the design. This typically requires changes to the design. In some cases, the specification is modified to reflect the design.

Armed with the specification, the design engineers create RTL representations of the various blocks forming the design. The design engineers begin their portion of the development process by defining the microarchitecture of the design, including detailed control structures, bus structures and primary data path elements. This microarchitecture also covers which operations are to be performed sequentially or in parallel, which portions will be pipelined and the number of pipeline stages, and which resources (such as adders and multipliers) are to be shared between multiple op- erations.

That the design engineers have complete control over every aspect of the design might lead one to expect that the resulting implementation will be optimal in terms of using the smallest amount of silicon, providing the highest performance, consuming the smallest amount of power, and so forth. Unfortunately, creating and verifying these traditional RTL representations is time-consuming. Further- more, modifying and reverifying the RTL to perform a series of what-if evaluations of alternative microarchitecture implementations is prone to error.