New silicon-process-technology nodes are coming out every 18 months. Each process node brings a doubling of chip gate capacity. On top of that, the new 90-nm technology with 7.2-ps gate delays and 10 layers of interconnect offers the capacity to integrate more than 100 million logic gates. This technology has far reaching implications on design methodology.
Traditionally, the divide and conquer method has been used in complexity management. But after more than a decade of dividing, the shear volume of pieces is creating its own complexity crisis. Two strategies address this issue: working with bigger pieces or using more abstraction to simplify the problem.
The first option requires a new generation of register-transfer-level (RTL) synthesis tools based on a completely new approach to the synthesis problem. Incremental fixes and patches being applied to the incumbent solutions haven't kept up with silicon technology.
One of the more serious methodology issues relates to using synthesis tools whose capacity and runtime-associated limitations haven't kept pace with process technology. Most designers using old synthesis technology create more than the necessary number of subblocks for designs. If we look at the design process for a high-performance, 50-Mgate design employing old synthesis tools, we could expect that the design would be subdivided into approximately 500 modules of 50 to 100 kgates (Fig. 1).
Of course, it takes time and engineering effort to create these 500 chip partitions. Worse yet, the price of this added partitioning continues to mount throughout the design process. Indeed, the expense of the additional complexity to manage too many blocks recurs throughout the design process and in the reuse of the design data. These costs include:
- The designer must write longer synthesis scripts than are needed to compile the design. For a design of just a few million gates, scripts of more than 3000 lines aren't uncommon. When compile scripts are more complicated than the RTL code, it's time to rethink design strategies and tools.
- Once written, the script must be debugged. Obviously, debugging thousands of lines of script is more complicated than debugging a script that's tens of lines. Design errors and project delays often result from such complications. This arcane scripting language is far from self-documenting.
- These scripts must be maintained throughout the project's life, as well as during the design data's useful life. Out-of-date and overly complex compilation scripts impede design and script re-use. This has been a great benefit for those in the cottage industry of tool jockeys who specialize in synthesis scripting.
- Junior engineers face a steep learning curve to become proficient in the arcane tool knowledge required to make the hyperpartitioned design strategies work. This means that the attention of the most-experienced engineers will become tool-centric, instead of design-centric. This defocus is subtle, but obviously a huge potential issue.
The second option to combat escalating complexity—add abstraction—has some perceived barriers and risks. These must be addressed before it really is considered a viable option.
False Starts And Bad Karma: A few years ago, a great deal of hoopla surrounded the second coming—behavioral synthesis. It was going to revolutionize the way that the electronics world would design. While adding more abstraction to the design process is fundamentally a sound idea, the actual implementation tarnished the entire idea for a generation of designers. A high-level synthesis tool detached from the ability to make accurate performance calculations just wasn't what the market was looking for.
Further, it was assumed that this bad tool was representative of high-level synthesis in general. Soon, it became fashionable to lambaste anyone foolish enough to touch the stuff.
But the compelling complexity crunch has motivated designers to again consider the value of abstraction beyond RTL. Luckily, there are also new generations of high-level synthesis tools to turn to. However, the macro-economic climate doesn't always cooperate with needs generated by new technology. Most corporations have cut their exploratory methodology projects, choosing instead to milk everything they can out of their existing tools and remaining designers.
There never seems to be a good time to change design methodologies. But if teams don't evolve, they will perish. Evolution is the key. To reduce training and ramp-up time, along with the risk of making a change, evolution—not revolution—is necessary.
A high-level summary of the differences between RTL-based and architectural-based design is shown in the table. Note that architectural synthesis yields automation three steps up the design-implementation chain. This automation comes from combining the more abstract starting point of the pins-out-cycle-accurate (POCA) coding style and the automated, optimized implementation provided by architectural synthesis—fine tuned for technology process and constraints.
Reprints
