Reuse Methodology Manual for System-on-a-Chip Designs / Edition 1998 available in Hardcover
- Pub. Date:
- Springer-Verlag New York, LLC
Silicon technology now allows us to build chips consisting of tens of millions of transistors. This technology promises new levels of system integration onto a single chip, but also presents significant challenges to the chip designer. As a result, many ASIC developers and silicon vendors are re-examining their design methodologies, searching for ways to make effective use of the huge numbers of gates now available.
These designers see current design tools and methodologies as inadequate for developing million-gate ASICs from scratch. There is considerable pressure to keep design team size and design schedules constant while design complexities grow. Tools are not providing the productivity gains required to keep pace with the increasing gate counts available from deep submicron technology. Design reuse - the use of pre-designed and pre-verified cores - is the most promising opportunity to bridge the gap between available gate-count and designer productivity.
Reuse Methodology Manual for System-On-A-Chip Designs outlines an effective methodology for creating reusable designs for use in a System-on-a-Chip (SoC) design methodology. Silicon and tool technologies move so quickly that no single methodology can provide a permanent solution to this highly dynamic problem. Instead, this manual is an attempt to capture and incrementally improve on current best practices in the industry, and to give a coherent, integrated view of the design process.
From the Foreword
'Synopsys and Mentor Graphics have joined forces to help make IP reuse a reality. One of the goals of our Design Reuse Partnership is to develop, demonstrate, and document a reuse-based design methodology that works. The Reuse Manual (RMM) is the result of this effort.'
Aart J. de Geus, Synopsys, Inc.
Walden C. Rhines, Mentor Graphics Corporation
|Publisher:||Springer-Verlag New York, LLC|
|Product dimensions:||6.50(w) x 1.50(h) x 9.50(d)|
Read an Excerpt
Chapter 3: System-Level Design Issues: Rules and ToolsThis chapter discusses system-level issues such as layout, clocking, floorplanning, onchip busing, and strategies for synthesis, verification, and testing. These elements must be agreed upon before the components of the chip are selected or designed.
Topics in this chapter include:
- The standard model
- Design for timing closure
- Design for verification
- System interconnect and on-chip buses
- Design for low power
- Design for test
- Prerequisites for reuse
3.1 The Standard Model
As more design teams use IP to do SoC designs, there is a consensus emerging about some of the key aspects of reuse-based design. We call this view the "standard model" for design reuse.
In this standard model, the fundamental proposition is this: well-designed IP is the key to successful SoC design. No matter how good our SoC integration flow, if the blocks we are using are not designed well, the road to tapeout is long and very, very painful. On the other hand, well designed IP can be integrated with virtually any (reasonably capable) SoC flow, and produce good results quickly.
In this chapter, we discuss the design guidelines for producing well-designed IP, as well as how to integrate, well-designed IP into an SoC design. These guidelines are largely driven by the needs of the IP integrator and chip designer. In this sense, they are basically system-level design guidelines.
In the next chapter, we discuss detailed coding guidelines, many of which are intended to implement the design guidelines discussed here.
There are some basic premises underlying all the guidelines in this book:
The authors, and many designers like us, learned these principles while designing large systems, and often learned them the hard way. For example (Mike speaking here), one of my first jobs was designing very large (hundreds of boards, each with hundreds of chips) ECL systems. When I arrived on the job, I was given a "green book" of how to do ECL system design. One of the rules was always to buffer inputs next to the edge connector, and always to buffer outputs next to the connector. This buffering essentially isolated the board, so that the backplane traces could be designed as transmission lines without knowing the details of how the daughter boards would load each signal. Essentially it made both backplane and board design local (and relatively simple) design problems. The global problem, of designing a transmission line backplane with arbitrary stubs on the daughter boards, is totally intractable.
Similarly, on large chip designs, we can make block design into a local problem by carefully designing the interfaces. Good interfaces decouple internal timing and function (as much as possible) from the external behavior of the block, and thus from the timing and functional behavior of the other blocks. Thus, each block can be designed and verified in isolation. If the interfaces are consistent, then the blocks should plug and play; any remaining problems should be real, system-level design problems and not bugs in the block designs themselves.
This concept of locality is also fundamental to object oriented programming. Here, classes are used to isolate internal data structures and functions from the outside world. Again, by carefully designing the interfaces between the class and the rest of the program, design and debug of key functionality can be isolated from the rest of the program. Software engineers have found that this approach greatly facilitates design and debug of huge software systems, and greatly improves the quality of these systems.
There are two problems that dominate the SoC design process: achieving timing closure (that is, getting the physical design to meet timing), and functional verification. Before we discuss design techniques for addressing these issues, we need to address the issue of hard vs. soft IP. This issue can affect how we approach the problems of timing closure and verification.
3.1.1 Soft IP vs. Hard IP
As the industry gets more experience in reuse-based SoC design, the distinction between hard and soft IP is beginning to blur. Until recently, there was a sharp distinction between which IP should be hard and which should be soft. If we look at the canonical design in Figure 3-5, this view held that the processor should be hard and the interface blocks and peripherals should be soft. The memory, of course, is generated and treated essentially as a hard block. Reasonable people would disagree as to whether the data transformation block should be hard or soft.
Today, the processor may well be available in soft form, and many of the other blocks may be available as hard macros. ARM and the DSP Group have both announced soft versions of their traditionally hard processor cores [1,2].
The emerging trend is that all IP starts out as soft IP, and the RTL is considered the golden reference. This approach is essential for rapid migration to new processes. If a piece of IP is taken to GDSII, then this hard representation should be stored in the IP repository along with the soft version. If another design is done in the same technology, and if it can use the same functionality and physical characteristics as the hard version, then the hard version can be used in the chip design.
On the other hand, if the process is new, or if the blockage from a piece of hard IP makes design of the overall chip difficult, then the soft version should be used. Thus, the soft and hard versions of the IP are just different views of the IP, each appropriate for different situations....