UNIT-II

Design Methodological For Logic Cores

SoC Design Flow
On-chip buses
Design process for hard cores ,Soft and firm cores
Core and SoC design examples.
Why SOC Design?
• Time and design effort required to integrate different types of
components on a chip : a bottleneck for SOC evolution
• Design reuse to reduce time to market
• Use of parts from previous designs
• Making use of parts designed by third parties
• Hardware and Software component model!
• All for PROVEN and tested solutions, avoiding re-design and re-
verification of real-time hardware and real-time software

 Advanced technologies enabling more integration on a chip Reduced

Product Cost.
 Physical size of products shrinking Minimize number of parts on a board.
 Consumer electronics requiring low cost products  More integration.
 Minimize number of silicon vendors for a product  Reduced Business
Cost.
Needs for SoC design Methodology:
 Time-to-Market extremely important for business.
 Easy integration of Intellectual Properties (IPs) Cores from
multiple sources.
 Resource management
• Minimize number of resources required to complete a
design.
• Efficiently manage resources across projects.
• Share domain expertise across multi-site design teams.
• Make effective use of design automation.

 Advancement in technology : Handle Increased Complexity of

Integration.
 Maximize Performance.
 Manage Feature Creep and Engineering Changes quickly.

SOC LOGIC CORES available in three forms:

 Soft
 Firm
 Hard
3
SoC design available in:
IP based,
platform based and
microcontroller based

IP based Design SoC’s:

• Intellectual Property Cores
• Parameterized components with standard interfaces facilitating high level
synthesis
• Cores available in three forms
• Hard
• Black box in optimized layout form and encrypted simulation model. Example:
microprocessors
• Firm
• Synthesized netlist which can be simulated and changed if needed
• Soft
• Register transfer level HDLs; user is responsible for synthesis and layout
Platforms based SOC’s
• Embedded Applications built using
• common architectural blocks and
• customized application specific components
• Common architectures
• Processor, memory, peripherals, bus structures
• Common architectures and supporting technologies (IP libraries and tools) are called
Platforms and platform based designs
• Platform based SOC’s are systems that contain
• IP blocks like embedded CPU, embedded memory,
• Real world interfaces (e.g., PCI, USB),
• Mixed signal blocks and
• Software components
• device drivers, real-time operating systems and application code
Design Methodological For Logic Cores
 To maintain productivity levels when dealing with ever-increasing design complexity, design-for-reuse is an absolute necessity.
In cores and SoC designs, design-for-reuse helps to keep the design time within reasonable bounds.
 Design-for-reuse requires good functional documentation, good coding practices, carefully designed verification environments,
thorough test suites, and robust and versatile EDA tool scripts. Hard cores also require an effective porting mechanism across
various technology libraries.
 A core and its verification test bench targeted for a single HDL language and a single simulator are generally not portable across
the technologies and design environments. A reusable core implies availability of verifiably different simulation models and test
suites in several major HDLs, such as Verilog and VHDL. Reusable cores must have stand-alone verification testbenches that
are complete and can be simulated independently.
 Much of the difficulty surrounding the reuse of cores is also due to inadequate description of the core, poor or even nonexistent
documentation. Particularly in the case of hard cores, a detailed description is required of the design environment in which the
core was developed as well as a description of the simulation models. Because a core provider cannot develop simulation
models for all imaginable uses, many times SoC designers are required to develop their own simulation models of the core.
Without proper documentation, this is a difficult task with a high probability of incomplete or erroneous functionality.
Design for Reuse
• Design reuse is the inclusion of previously designed components (e.g., intellectual property (IP) in software and hardware.
Reusing designs makes it quicker, easier, and less expensive to design and build a new product. That's because existing
components amuch more re reliable and well-tested than new components.
 Design reuse can expedite system-on-chip (SoC) and IC design and development.
---But managing the increasingly large number of digital assets is difficult. It creates a need for stronger collaboration between
internal and external resources
 IP-Reuse may be as simple as using standard cell libraries developed internally or externally, meant for general ASIC designs or
specifically designed for high performance designs. Other flavors of IP-reuse involve some common design entities like
memories, PLL etc or application specific complex modules. It’s this last category of IP-Reuse that is the most interesting and
challenging in terms of reuse methodology.
General Guidelines for Design Reuse:
A number of precautions must be taken at various design steps to ensure design reusability. Some of these precautions are
basic common sense while others are specific architectural or physical design guidelines.
1.Synchronous Design Synchronous design style is extremely useful for core-based SoC design:
In synchronous design, data changes based on clock edges only (and, hence, instructions and data) are easily manageable. Use of
registers in random logic as well as registration at the inputs and outputs of every core as shown in Figure .. is very useful in
managing core-to-core interaction. Such registration essentially creates a wrapper around a core. Besides providing
synchronization at the core boundary, it also has other benefits such as portability and application of manufacturing test.
● Use registers for synchronization in core logic and its inputs and outputs to manage
core
● Creates a wrapper around a core.
❖ portability

❖ manufacturing test application

● Avoid latches in random logic

Use them only in blocks such as FIFOs, memories, and stacks
• Avoid asynchronous loops.
2. Memory and Mixed-Signal Design :
The majority of embedded memories in SoC are designed using memory compilers. This topic is discussed in detail in Chapter 3. While
the memory design itself is technology dependent, some basic rules are very useful in SoC-level integration.
● Large memories: different parasitics at boundary cells and a cell in the middle of an array.
 Include rows and columns of dummy cells at the periphery of large memories.
 Make these rows and columns part of the built‐in self repair (BISR) mechanism, to minimize area overhead.
● most commonly used analog/mixed‐ signal circuits used in SoC, ADCs/DACs, and temperature sensors.
 extremely sensitive to noise and technology parameters place them at the corners.
To minimize the area overhead penalty because of these dummy cells, these rows and columns should be made part of the
built-in self-repair (BISR) mechanism.
3. On-Chip Buses:
● On-chip buses play an extremely important role in SoC design. Bus-based designs are easy to manage primarily because
on-chip buses provide a common interface by which various cores can be connected. Thus, the design of on-chip buses
and the data transaction protocol must be considered prior to the core selection process. On‐chip buses and data transaction
protocol must be designed prior to the core selection process.
● Parameterized interfaces should be used in core design.
❖ FIFO‐based interfaces are flexible and versatile in handling varying data rates between cores and the system buses.
❖ support multiple masters, separate entity for data and control signals, fully synchronous and multiple cycle transactions, bus request‐and‐grant
protocol.
4.Clock Distribution : Clock distribution rules are one of the most important rules for cores as well as SoC designs. Any
mismatch in clocking rules can impact the performance of an entire SoC design.
It may even cause timing failures throughout the design. Therefore, establishing robust clock rules is necessary in SoC design.
These rules should include clock domain analysis, style of clock tree, clock buffering, clock skew analysis, and external timing
parameters such as setup/hold times, output pin timing waveforms, and so on.
The majority of SoCs consist of multiple clock domains; it is always better to use the smallest number of clock domains.
● Isolate each clock in an independent domain.
● Use buffers at the clock boundary.
● Use synchronization method at the clock boundaries.
E.g., clock buffering and dual stage FIFOs at the clock boundary.
● Distribute a low‐frequency chip‐level synchronization.
5.Clear/Set/Reset Signals :It is essential to document all reset schemes in detail for the entire design. The documentation should
state whether resets are synchronous, asynchronous, or internal/external power-on-resets, how many resets are used, any
software reset schemes used, whether any functional block has its locally generated resets, whether resets are synchronized with
local clocks, and so on. Whenever possible, synchronous reset should be used because it avoids race conditions on reset. Static
timing analysis becomes difficult with asynchronous resets, and the designer has to carefully evaluate the reset pulse width at
every flip-flop to make sure it becomes inactive synchronously to clocks. Hence, whenever reset/clear is asynchronous, their
deactivation should be resynchronized.
6Physical Design: . In the development of hard cores, physical design is a key item for the success of the core. Although soft and
firm cores are not delivered in layout form, consideration of their physical design issues is still necessary
i. FLOOPLAN: Floor planning should start early in the design cycle. It helps in estimating the size and in determining if area,
timing, performance, and cost goals can be satisfied. The initial floor plan also helps in determining the functional interfaces
among different cores as well as clock distribution at the chip level. When a SoC combines hard and soft cores, the fixed-
aspect ratio of the hard core can impose placement and routing constraints on the rest of the design. Therefore, a low-effort
SoC-level floor planning should be done in the early design process.
ii. Synthesis The overall synthesis process should also be planned early in the design phase and should include specific goals for
area, timing, and power. Present-day synthesis tools do not handle very large design all at once; hence, hierarchically
incremental synthesis should be done.
iii. Timing: Static timing analysis should be done before layout on floor-planned blocks. The final timing verification should be
done on postlayout blocks. During timing analysis careful attention should be paid to black boxing, setup/hold time checks,
false path elimination, glitch/hazard detection, loop removal, margin analysis, min/max analysis, multipath analysis.
iv. Inputs/Outputs The definition of core I/Os is extremely important for design reuse. The configuration of each core I/O,
whether it is a clock input or a test I/O, should be clearly specified.
v. Validation and testing
SoC Design FLOW:
 SoC designs require an unconventional design methodology because pure top-down or bottom-up design methodologies
are not suitable for cores as well as SoC.
 The primary reason is that during the design phase of a core, all of its possible uses cannot be conceived.
 A pure top-down design methodology is suitable when the environment in which the core will be used is known a priori
and that knowledge is used in developing the functional specifications.
 Because of the dependency on the core design, the SoC design methodology is a combination of bottom-up and top-down
philosophies that look like an interlaced model based on hardware software co-development while simultaneously
considering physical design and performance.
 This design methodology is considerably different than the traditional ASIC design philosophy in which design tasks are
done in sequential order. Such design flow is described in a horizontal/vertical model as shown in Figure 2.1. In such a
design flow, although the architectural design is based on hardware software co-development, the VLSI design requires
simultaneous analysis and optimization of area, performance, power, noise, test, technology constraints, interconnect,
wire loading, electro migration, and packaging constraints.
 Because SoC may also contain embedded software, the design methodology also requires that the both hardware and
software be developed concurrently to ensure correct functionality.
 SOC DESIGN FLOW
A SOC consists of both the hardware, and the software that controls the microcontroller, microprocessor or DSP cores, peripherals and interfaces. The
design flow for a SOC aims to develop this hardware and software in parallel. Most SOC’s are developed from pre-qualified hardware blocks for the
hardware elements described above, together with the software drivers that control their operation. Of particular importance are the protocol stacks that
drive industry-standard interfaces like USB. The hardware blocks are put together using CAD tools; the software modules are integrated using a software-
development environment.

Often, one step in the verification flow is emulation: The hardware is mapped onto an emulation platform based on a field-programmable gate array
(FPGA) that mimics the behavior of the SOC, and the software modules are loaded into the memory of the emulation platform. Once programmed, the
emulation platform enables the hardware and software of the SOC to be tested and debugged at close to its full operational speed. Emulation is generally
preceded by extensive software simulation. In fact, sometimes the FPGAs are used primarily to speed up some parts of the simulation work. After
emulation the hardware of the SOC follows the place-and-route phase of the design of an integrated circuit before it is fabricated.

DESIGN FLOW:

1.The SOC design starts with the specification model, which is a purely functional model free of any implementation details. It focuses on capturing the
algorithmic behavior and allows a functional validation of the description.

2.Once the specification model is finished it will serve as a “golden model”, Architecture information is added during the Architecture refinement. During
this step processing elements are inserted into the system and functional behaviors are mapped to them. The processing elements can be standard
components such as generic processor cores or DSPs, as well as specific hardware. Parameters, such as clock frequency, of the inserted elements can be
adjusted to the application needs. Based on internal statistics, first estimations about the runtime performance can be made, which gives the designer the
first feedback about the design decisions.

3.Then communication model well be decided and framed to integrate both Hardware and software to provide intercommunication between them. The
hardware blocks are put together using CAD tools; the software modules are integrated using a software-development environment. Horizontal/vertical so
design is carried out.

4.Then Real time synthesis is carried out for development of specific product.
SOC DESIGN FLOW
On-Chip buses
Heterogeneous Today’s SoC

CPU DSP MEM

Interconnection network (BUS)

Embedded Dedicated
I/O
FPGA IP

Different processors with their configurations with interconnection bus

Homogeneous SoC (MP-SoC)

CPU CPU CPU CPU

MEM MEM MEM MEM

Interconnection network (BUS, XBAR)

CPU CPU CPU CPU

MEM MEM MEM MEM

multiple processors with same configurations with interconnection bus

 Communication :
Buses and Network-on-Chip
(NOC)
Bus based On-Chip Communication Architectures
 Buses are the simplest and most widely used SoC in-
terconnection networks
 Bus:
◦ a collection of signals (wires) to which one or more IP components
(which need to communicate data with each other) are connected
 Only one IP component can transfer data on the
shared bus at any given time

Digital Input/
Micro-
Signal Output Memory
controller
Processor Device

Bus
Bus Properties
• Serialization: Only one component can send a
message at any given time

Broadcast: A module can send a message to several other components without

an extra cost
Bus Terminology
 Master (or Initiator)
◦ IP component that initiates a read or write data transfer
 Slave (or Target)
◦ IP component that does not initiate transfers and only responds to in-
coming transfer requests
 Arbiter
◦ Controls access to the shared bus
◦ Uses arbitration scheme to select master to grant access to bus
 Decoder
◦ Determines which component a transfer is intended for
 Bridge
◦ Connects two busses
◦ Acts as slave on one side and master on the other
Types of Bus Topologies
• Shared bus
Types of Bus Topologies
• Hierarchical shared bus

 Improves system throughput

 Multiple ongoing transfers on
different buses
Types of Bus Topologies
• Full crossbar/matrix bus (point to point)
Types of Bus Topologies
• Partial crossbar/matrix bus
Types of Bus Topologies
• Ring bus
 Why bus Standards?
• Interface standards define a specific data transfer protocol
• decide number and functionality of pins at IP interfaces
• make it easy to connect diverse IPs quickly
• Two categories of standards for SoC communication:
• Standard bus architectures
• define interface between IPs and bus architecture
• define (at least some) specifics of bus architecture that implements
data transfer protocol
• Socket based bus interface standards
• define interface between IPs and bus architecture
• freedom w.r.t choice and implementation of bus architecture

• Ideally, designers want one standard to interconnect all IP’s and bus
• In reality, several competing standards have emerged
Standard Bus Architectures
• AMBA advanced microcontroller bus archietecture (ARM)
• CoreConnect (IBM)
widely used
• Sonics Smart Interconnect (Sonics)
• STBus (STMicroelectronics)
• Wishbone (Opencores)
• Avalon (Altera)
• PI Bus (OMI)
• MARBLE (Univ. of Manchester)
• CoreFrame (PalmChip)
• …
Example:AMBA 2.0
Bus advantages and Disadvantages:
•ADVANTAGES:
•It is the easiest network topology for connecting peripherals or computers in a linear fashion.
•It works very efficiently well when there is a small network.
•The length of cable required is less than a star topology.
•It is easy to connect or remove devices in this network without affecting any other device.
•Very cost-effective as compared to other network topology i.e. mesh and star
•It is easy to understand topology.
•Easy to expand by joining the two cables together

•Disadvantages:
Bus topology is not great for large networks.
Identification of problems becomes difficult if the whole network goes down.
Troubleshooting individual device issues is very hard.
Additional devices slow the network down.
If the main cable is damaged, the whole network fails or splits into two.
Packet loss is high.
Bus pros () and cons ()

 The silicon cost of a bus is small.

 Any bus is almost directly compatible with most available IPs, including software running on CPUs.
 The concepts are simple and well understood.

 Every unit attached adds parasitic capacitance, therefore electrical performance degrades with growth.
 Bus timing is difficult in a deep submicron process.
 Bus arbiter delay grows with the number of masters. The arbiter is also instance-specific.
 Bandwidth is limited and shared by all units attached.
What are NoC’s?
“Network-on-a-chip (NoC) is a new paradigm for System-on-Chip (SoC)
design. NoC based-systems accommodate multiple asynchronous
clocking that many of today's complex SoC designs use. The NoC
solution brings a networking method to on-chip communications and
claims performance increase over conventional bus systems.”
On-Chip Communication

Bus-based architectures Irregular architectures Regular Architectures

 Networks on Chip
• Bus based interconnect
 Layered Approach
• Low cost  Buses replaced with Networked architectures
• Easier to Implement  Better electrical properties
• Flexible  Higher bandwidth
 Energy efficiency
 Scalable
 the NoC uses a point-to-
point,communication, while the bus is syn-
chronous and multipoint
NoC exemple
Processor Processor Processor
Master Master Master

Routing Global
Routing Routing Memory
Node Node Node Slave

Processor Processor Processor

Master Master Master
Global I/O
Slave

Routing Routing Routing

Node Node Node
Global I/O
Slave

Processor Processor Processor

Master Master Master

Routing Routing Routing

Node Node Node
Evolution of on-chip Communication
Traditional SoC Nightmare
• Variety of dedicated interfaces
• Design and verification complexity
• Unpredictable performance
• Many underutilized wires

DMA CPU DSP

Control
signals
CPU Bus
A
Bridge
B Peripheral Bus
IO IO IO
C

3
Network on Chip: A paradigm Shift
in VLSI
From: Dedicated signal wires To: Shared network

s s s

Module

s s s
Module
Module

s s s

Point-Computing
Network
To-point
Module switch
Link
Network on Chip: A paradigm Shift
in VLSI
Network interface

NI DMA
CPU NI
Coproc NI NI DSP

switch switch NI Ethnt

I/O NI
switch
switch
NoC switch
NI DMA

switch
NI MPEG
DRAM NI

DRAM NI NI Ethnt
Accel NI
NoC Essential

• Communication by packets
s s s
of bits
Module • Routing of packets through
several hops, via switches
s s s • Efficient sharing of wires
Module
Module • Parallelism

s s s
Design process for hard cores ,Soft and firm cores
Design flow of soft and firm cores:
Design guidelines are necessary because cores are designed for reuse. The soft and firm
cores are productized in RTL form and, hence, they are flexible and easy to reuse. However,
because the physical design is not fixed, their area, power, and performance are not
optimized.

Design Flow Soft and firm cores should be designed with a conventional EDA RTL
synthesis flow. As shown in Figure 2.
In the initial phase, while the core specs are defined, core functionality is continuously
modified and partitioned into sub-blocks for which functional specs are developed.
● Design with a conventional EDA RTL
synthesis flow.
● Reusability requirement

Fig 2. Design flow of soft and firm cores

Because of the reusability (requires new specification, methodology and tools) requirement, multiple
configuration tests should be developed and run. These configuration tests vary significantly depending on
whether a soft or firm core is being tested.

In general, the synthesis script of firm cores provides a netlist with a target performance and area. Because the
netlist of firm cores under this synthesis script is fixed, the testbench for gate-level simulation, the timing
model, and the power analysis model can be developed.

In the majority of cases, design-for-test methodology (scan, BIST, Iddq) is also considered in the development
of firm cores, and fault-grading analysis is done on gate-level netlists.

For firm cores, the physical design requirements are considered as the sub-blocks are developed. These
requirements consist of interconnects, testbench, overall timing, and cell library constraints
Development Process for Soft/Firm Cores:
At every design step in the core development process, design specifications are needed.
General design specifications include the following:
1. Functional requirements to specify the purpose and operation of the core.
2. Physical requirements to specify packaging, die area, power, technology libraries, and so
on.
3. Design requirements to specify the architecture and block diagrams with data flow.
4. Interface requirements to specify signal names and functions, timing diagrams, and DC/AC
parameters.
5. Test and debug requirements to specify manufacturing testing, design-for-test methodology,
test vector generation method, fault grading, and so on.
6. Software requirements to specify software drivers and models for hardware blocks that are
visible to software such as general purpose registers of a microprocessor.
1.Top-Level Design Specifications: The first step in a core design process is to refine the functional specs so
that they can be partitioned into self-contained sub-blocks. The general objective is for each sub-block to be
able to be designed without interference/dependency of other blocks, as well as coded and verified by a single
designer. Subblock interfaces should be very clearly defined so that assembly of sub-blocks can be conflict
free.
2. Sub-Block Specifications: Sub-block specification starts with the partitioning of the top-level functional
model. Creating detailed specifications for sub-blocks allows for efficient RTL coding. EDA tools (memory
compilers and module compilers) can be used to generate RTL code if the sub-block consists of structured
components such as RAMs, ROMs, FIFOs, and so on. Before RTL coding begins, timing constraints, and
power and area specifications are also required. These constraints at block level should be derived from the
core-level functional specs.
3.Integration of Sub-Blocks: Once the design for the sub-blocks is completed, they are integrated into one
design and tested as part of the core. During the initial phase of integration, some mismatches may occur at the
interfaces of the sub-blocks. These mismatches can be checked by the core-level RTL model that instantiates
sub blocks and connects them. Functional tests should be developed using a sufficiently large number of
configurations of the core. This ensures the robustness of the final design. When the parameterized core is
finalized, it is helpful to provide a set of scripts for different configurations and constraints of the core. Some
provisions must be made in timing constraints to account for design-for-test insertions such as scan. Also, a
robust power analysis must be done on various configurations of the core.
4.RTL Guidelines :
Good RTL coding is a key to the success of soft/firm cores. Both portability and reusability of the core are
determined by the RTL coding style. It also determines the area and performance of the core after synthesis.
Therefore, RTL coding guidelines should be developed and strictly enforced in the development of soft/firm cores.
The basic principle behind these guidelines should be to develop RTL code that is simple, easy to understand,
structured, uses simple constructs and consistent naming convention.
5.Soft/Firm Cores Productization:
Productization means the creation and collection of all deliverable items in one package. In general for soft and firm
cores, deliverables include RTL code of the core, functional testbenches and test vector files, installation and
synthesis scripts, and documentation describing core functionality, characteristics, and simulation results. (Firm cores
also required gate-level netlist, description of the technology library, timing model, area, and power estimates.)
Because many of the documents created during various development phases are not suitable for customer release, a
user manual and data book are also required. This data book (document) should contain core characteristics with
sufficient description of design and simulation environments. As a general rule, prototype silicon should be
developed for firm cores and should be made available to the user.
Design Process for Hard Cores :
 The design process for hard cores is quite different from that of soft cores.
 One major difference is that physical design is required for hard cores and both area and
timing are optimized for target technology.
• Also, hard cores are delivered in a layout-level database (GDSII) and, hence,
Productization of hard cores is also significantly difficult compared to that of soft cores.
• In some sense, the design process for hard cores is the same as that for a traditional
ASIC design process. Hence, many issues of the traditional ASIC design process are
applicable to hard cores.
 Unique Design Issues in Hard Core:
In addition to the general design issues discussed such as Synchronization, memory and mixed signal, clock
distribution etc..some unique issues are related to the development of hard cores. Most of these issues are related to
physical design.

1. Clock and Reset : Hard cores require implementation of clock and reset. This implementation should be
independent of SoC clock and reset because SoC-level information is not available at the time of core design.
Therefore, to make it self-sufficient, clock and reset in hard cores require buffering and minimum wire loading. Also,
a buffered and correctly aligned hard core clock is required to be available on an output pin of the core; this is used
for synchronization with other SoC-level on-chip clocks.

2.Porosity, Pin Placement, and Aspect Ratio: During SoC-level integration, it is often desirable to route over a core or
through a core. To permit such routing, a hard core should have some porosity, that is, some routing channels through
the core should be made available. Another possibility is to limit the number of metal layers in the core to one or two
less than the maximum allowable by the process. The deliverables for the core should include a blockage map to
identify the areas where SoC-level routing may cause errors due to crosstalk or other forms of interaction.
Similar to porosity, pin placement and pin ordering of a core can have a substantial impact on the SoC-level floor
plan and routing. Thus, Vdd/Gnd pins should be placed on one or, at most, two sides rather than distributing them
along all four sides. This rule is tricky for signal pins. However, the signals that will remain primary I/Os at the SoC
level, such as USB and PCI bus, should be placed on one side. Another item that can have a serious impact on SoC
floor plan and routing is the aspect ratio…. As much as possible, the aspect ratios should be kept close to 1:1 or 1:2.
These aspect ratios are commonly accepted and have minimal impact on SoC-level floor plan.
3. Custom Circuits :
Sometimes hard cores contain custom circuit blocks because of performance and area requirements. Because
implementation of these circuits is not done through RTL synthesis-based flow, these circuits require schematic
entry into the physical design database as well as an RTL mode. These circuits are generally simulated at
transistor level using Spice; hence, an additional timing model is also required for integration into the core-level
timing model. In most cases, the characteristics of these circuits are highly sensitive to technology parameters;
therefore, good documentation is required to describe the functionality and implementation of these circuits. The
documentation with core release should also list these circuits with descriptions of their high-level functionality.

4.Test:
Design-for-test (DFT) and debug test structures are mandatory for hard cores but not for soft and firm cores.
Thus, core-level DFT implementation requires that it create minimal constraints during SoC integration.
 Development Process for Hard Cores
:
A hard core may contain some custom circuits and some synthesized blocks. For synthesized blocks, a design flow such as
that given in Figure should be followed, while a custom circuit can be simulated at the transistor level, and the design
database should have full schematics.

Using the RTL model of custom circuits and RTL of synthesized blocks, an RTL model of the full core should be developed.
This model should go through an iterative synthesis flow to obtain area, power, and timing within an agreed-upon range (this
range can be 10% to 20% of target goals). During this iteration full design validation should be done for synthesized blocks as
well as for custom circuits. The gate-level net list with area, power, and timing within 10% to 20% of target should be used
for physical design. The final timing should be optimized using extracted RC values from the layout-level database. The
layout database should be LVS (layout versus schematic) and DRC (design rule checker) clean for a particular technology
deck. Finally, various models (functional, bus-model, simulation, floor plan, timing, area, power, and test) should be
generated for release In the design flow before including it in the core library. In the majority of cases, this validation also
includes the silicon prototype.

Thus, the SoC designer gets the GDSII file along with the timing, power, area, and test models of the hard core. Hard cores
also require much stringent documentation compared to soft cores. This additional documentation (relative to soft cores)
includes footprint (pin placement), size of the core in specific technology etc.
Development process of hard cores
 Core and SoC design examples
Cores in SoC include microprocessor cores, memory cores of various kinds and sizes,
application specific cores such as DSP, bus controllers, and interface cores. The design style
and complexity of these cores vary widely.

Microprocessor cores are one good example of high-value cores because

microprocessor/microcontroller design is nontrivial and it is one of the key components of an
SoC because microprocessor/microcontroller design is nontrivial and it is one of the key
components of an SoC. A large number of microprocessor cores are available for embedded
applications.

The design of a microprocessor core can be optimized to the specific technology and may thus
be available from different companies. In such a case, parameters such as performance, area,
and power will change for the base design. To fulfill the needs of SoC designers, large ASIC
companies generally provide multiple versions of microprocessor cores in their library.
lists of some characteristic parameters for a few selected microprocessors cores
SOC DESIGN EXAMPLES:
Examples of SoC In this section, two examples are given. The first example is of an SoC architectural design and the
second is of SoC test methodology and testability.

MEDIA PROCESSORS:

One good example of a present-day SoC is that of graphics accelerators and multimedia processors. An example of a
multimedia processor (Philips).
Many of these processors perform MPEG-2 decoding for video. This decoding and playback of the compressed bit stream
starts with variable-length decoding (VLD), followed by the inverse quantization (IQ) to retrieve discrete cosine transform
(DCT) coefficients from the compressed bit stream, then an inverse DCT (IDCT) operation that produces the error
prediction signal.
This signal retrieves the decoded frame with the addition of a motion prediction signal. The motion prediction signal is
calculated by pixel interpolation using one or two previously decoded frames. The decoded frame is transformed into a
display format and transferred to the video RAM
 TESTABILITY

1. Veterbi decoder core: Consists of about 100K gates and 10 memories. For memories, the
memory BIST controller was used inside the core. Original RAMs were replaced by RAMs
with wrappers. Logic was analyzed for scan test points, and scan chains were inserted. A
wrapper was used for the whole core and internal scan chains were controlled by logic BIST
controller.
2. GPIO core: This is a legacy core for which functional patterns were available. A wrapper was
generated and integrated; and functional vectors were verified through this wrapper.
3. MIU block: This consists of about 40K gates and 10 memories. Again, a memory BIST
controller was used inside the block to test memories. Original memories were replaced by
memories with wrappers. Scan chains and test points were inserted to test the logic.
4. At the chip level, a memory BIST controller was integrated. A logic BIST controller, boundary
scan, and TAP controller were also integrated.
Internal architecture