SPECC: Specification Language and Methodology / Edition 1 available in Hardcover, Paperback
SPECC: Specification Language and Methodology / Edition 1
- ISBN-10:
- 1461370361
- ISBN-13:
- 9781461370369
- Pub. Date:
- 11/05/2012
- Publisher:
- Springer US
- ISBN-10:
- 1461370361
- ISBN-13:
- 9781461370369
- Pub. Date:
- 11/05/2012
- Publisher:
- Springer US
SPECC: Specification Language and Methodology / Edition 1
Buy New
$169.99Buy Used
$119.60-
-
SHIP THIS ITEM
Temporarily Out of Stock Online
Please check back later for updated availability.
-
Overview
Product Details
ISBN-13: | 9781461370369 |
---|---|
Publisher: | Springer US |
Publication date: | 11/05/2012 |
Edition description: | Softcover reprint of the original 1st ed. 2000 |
Pages: | 313 |
Product dimensions: | 6.10(w) x 9.25(h) x 0.03(d) |
Read an Excerpt
Chapter 1: Introduction
1.1 System Level Design Challenge
Ever since the Semiconductor Industry Association (SIA) roadmap forecast a productivity gap in the design of system-on-a-chip (SOC), the design and CAD community have been working hard on closing that gap. This gap has been created by a continuous increase in chip complexity that has not been accompanied by a similar increase in design productivity. In particular, chip complexity, measured by the number of transistors on a silicon chip, has increased at a rate of 58% per year over the last twenty years, while designer productivity, measured by the number of transistors per designer per day, has increased at a rate of only 21 % over the same period. This disparity between chip complexity and design productivity indicates that the semiconductor industry will be able to manufacture complex chips beyond our ability to design those chips in any reasonable time to market.
The most obvious solution for closing the productivity gap is to raise the level of abstraction in design in order to reduce the number of objects with which a designer has to contend and effectively increase the designer's productivity. However, raising the level of abstraction means raising the level of abstraction in specification, architecture, communication, components, tools, methods, methodologies, education and so on. In other words, the higher abstraction level has to be achieved throughout the design infrastructure and design community. This is not a simple challenge and requires a true paradigm shift.
The next obvious solution is to reuse the parts of a design developed for past process technologies or last year's products. However, migrating a legacy design to a new technology while adding new features and optimizing the design for a new product is not a simple challenge either. It requires a new focus which has not been attempted before on design for reuse.
To meet these challenges the semiconductor industry has three choices that differ in cost, effort, flexibility and quality. These three choices are: platform approach, IP assembly, and system synthesis.
1.1.1 Platform Approach
In a platform the architecture, that is, the set of components and communication channels (buses) is fixed. An example of a platform, in which an architecture consisting of a main core processor, a set of smaller I/O controllers, DSP processors and memories, is shown in Figure 1.1; the types of the processors and busses are predetermined. Each component in a platform can be included or excluded in the final implementation for better efficiency. The main programmability is in the software assigned to each processor. The only optimization for a particular application is in the selection of processors and buses for platform definition, or in other words in creating a platform for a specific set of applications.
The platform methodology consists of several steps. First, we have to develop a product specification, partition it according to the given constraints, and map partitions into different components of the platform. Then, we have to develop a platform model that reflects the partitioned specification and platform constraints. Next, we have to verify that this model implements the specification. Finally, we have to compile the code assigned to each processor and generate an RTOS kernel to support the partitioned specification in the platform architecture. The major challenge in platform technology is the development of a specification language, a well-defined implementation model, and techniques for verifying equivalence of specification and implementation.
The new tools needed for platform-implemented SOCs are: a specification language, a specification compiler and simulator, a specification partitioner with estimators, verifiers and retargetable compilers for the evolution of platform processing components, and a retargetable RTOS to accommodate different subsets of platform components.
1.1.2 IP Assembly
SOC implementations using different intellectual properties (IPs) or virtual components (VCs) offer more flexibility in the selection of components and architectures than a platform approach does. However, they require a well developed IP database from which we can select different components and assemble them in different ways to achieve a good fit for the given application domain. Flexibility is not only in software but also in the architecture. However, this approach requires sophisticated techniques in IP assembly, particularly in interfacing of different IN with possibly different protocols.
The IP methodology is similar to the platform methodology with the additional tasks of selecting components and constructing proper architectures. First, we have to develop a product specification, partition it, and map the partitions into the different components selected from the IP database. The partitioning is performed concurrently with the selection of components and the evaluation of possible architectures. These concurrent tasks of architecture exploration make the IP approach to SOC implementation more difficult but also more attuned to product specification. Otherwise, the methodology remains the same as in the platform approach.
The main challenge in EP assembly, as in the platform approach, is the development of a specification language, architecture models, and verification techniques. However, an additional challenge for IP assembly is the development of an IP database and architecture exploration and integration techniques.
The new tools needed for IP assembly in addition to the tools needed for the platform solution are: an IP selector and evaluator, an architecture explorer, and a protocol/interface synthesizer. We should also mention that the complexity of the tools for IP assembly is much greater than that of the tools needed for the platform approach. For example, the verification tools must be able to take into account different imported IPs, while in a platform architecture the component models are known. Similarly, partitioner, selector, explorer and synthesis tools must deal with a larger and more diverse set of components. Also, if IPs come from different suppliers outside the company, standard IP trade and business models must be established...