ISBN-10:
0792381750
ISBN-13:
9780792381754
Pub. Date:
10/01/1998
Publisher:
Springer-Verlag New York, LLC
Reuse Methodology Manual for System-on-a-Chip Designs / Edition 1998

Reuse Methodology Manual for System-on-a-Chip Designs / Edition 1998

by Michael Keating, Pierre Bricaud

Hardcover

Current price is , Original price is $125.5. You
Select a Purchase Option
  • purchase options

Product Details

ISBN-13: 9780792381754
Publisher: Springer-Verlag New York, LLC
Publication date: 10/01/1998
Pages: 240
Product dimensions: 6.50(w) x 1.50(h) x 9.50(d)

Read an Excerpt


Chapter 3: System-Level Design Issues: Rules and Tools

This 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....

Customer Reviews

Most Helpful Customer Reviews

See All Customer Reviews