Unit II

DESIGN METHODOLOGY
FOR LOGIC CORES
• To maintain productivity
• ever-increasing design complexity,
• design-for-reuse
• In cores and SoC designs, design-for-reuse also helps
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
test benches that are complete and can be simulated
independently
• Difficulty in reuse of cores
• Inadequate description of the core,
• Poor or even nonexistent documentation
• In the case of hard cores, a detailed description is
required of the design environment
• 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 daunting task
with a high probability of incomplete or erroneous
functionality.
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.
• Reason
• during the design phase of a core, all of its possible uses
cannot be conceived
• A pure top-down design is suitable when core is known
• Because of the dependency on the core design, the SoC
is designed by the combination of bottom-up and top-
down models (hardware-software co-development).
SoC Design Flow…….

• This design is considerably different than the traditional

ASIC design
• Tasks are done in sequential order.
• 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.
Fig. Interlaced horizontal/vertical co-development design methodology
• The first part in this design process consists of
recursive development and verification of a set of
specifications.
• The specifications should be independent of the
implementation method.
• There are two possible ways to develop
specifications:
• Formal specifications and
• Simulatable specifications.
• Formal specifications can be used to compare the
implementation at various levels to determine the
correctness from one abstraction level to another.
• A few formal specification languages such as VSPEC have
been developed to help in specifying functional behavior,
timing, power consumption, switching characteristics, area
constraints, and other parameters.
• However, these languages are still in their infancy and
robust commercial tools for formal specifications are not
yet available.
• Today, simulatable specifications are most widely used.
• Simulatable specifications describe the functional behavior
of the design in an abstract form and do not provide a
direct link from high level specs to the RT level.
• Simulatable specifications are basically executable
software models written in C, C++, or SDL(Specification
and Description Language), while the hardware is
specified in Verilog or VHDL.
General Guidelines for Design
Reuse
• A number of precautions must be taken at various
design steps to ensure design reusability
• Synchronous Design
• Memory and Mixed-Signal Design
• On-Chip Buses
• Clock Distribution
• Clear/Set/Reset Signals
• Physical Design
• Deliverable Models
1. Synchronous Design
• Synchronous design style is extremely useful for core-
based SoC design.
• In synchronous design, data changes based on clock
edges only, 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 2.2 is very useful in managing core-to-core
interaction.
• Such registration essentially creates a wrapper around a
core.
• Synchronization at the core boundary provides
portability and application of manufacturing test.
• Latch-based designs on the other hand are not easy to
manage because the data capture is not based on a clock
edge; instead, it requires a longer period of an active
signal.
• It is thus useful to avoid latches in random logic and use
them only in blocks such as FIFOs, memories, and stacks.
• In general, asynchronous loops and internal pulse
generator circuits should be avoided in the core design.
• Multi-cycle paths and direct combinational paths from
block inputs to outputs should be avoided.
• If there are any asynchronous clear and set signals, then
their deactivation should be resynchronized.
• The memory boundaries at which read, write, and enable
signals are applied should be synchronous and register-
based.
2. Memory and Mixed-Signal Design
• The majority of embedded memories in SoC are designed
using memory compilers.
• In large memories, the parasitics at the boundary cell are
substantially different than the parasitics of a cell in the
middle of an array.
• To minimize this disparity, it is extremely useful to include
rows and columns of dummy cells at the periphery of large
memories as shown in Figure 2.3(a).
• 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.
• BISR allows a bad memory cell to be replaced and also
improves the manufacturing yield.
• While the large memories are generally placed along the
side or corner of the chip, small memories are scattered
all over the place.
• If not carefully planned, these small memories create a
tremendous hurdle in chip-level routing.
• Hence, when implementing these small memories, it is
extremely useful for the metal layers to be kept to one or
two metals less than the technology allowable layers.
• Subsequently, these metals can be used to route chip-
level wires over the memories.
• In present-day SoC design, in general, more than 60% of
the chip is memories; mixed-signal circuits make up
hardly 5% of the chip area
• The most commonly used analog/mixed-signal circuits used
in SoC are PLLs, digital-to-analog converters (DACs),
analog-to-digital converters (ADCs), and temperature
sensors.
• These circuits provide specialized functionality such as on-
chip clock generation, synchronization, RGB output for color
video display, and communication with the outside world.
• Analog/mixed-signal circuits are extremely sensitive to noise
and technology parameters.
• It is useful to place these circuits at the corners as shown in
Figure 2.3(b).
• This also suggests that placing the I/Os of the analog circuit
on only two sides is somewhat useful in simplifying their
placement at the SoC level.
• Further, the use of guard-bands and dummy cells around
these circuits is useful to minimize noise sensitivity.
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
to connect various cores.
• The design of on-chip buses and the data transaction
protocol must be considered prior to the core
selection process.
• On-chip bus design after the selection and
development of cores leads to conflicting data
transfer mechanisms.
• Subsequently, it causes complications at SoC-level
integration and results in additional hardware as well
as lower performance.
• Parameterized interfaces should be used in the core
design.
• FIFO based interfaces are reasonably flexible and
versatile in their ability to handle varying data rates
between cores and the system buses.
• A number of companies and organizations are actively
working to develop an acceptable on-chip bus and
core interface standard/specifications that support
multiple masters, separate identity 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.
• Clock 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.
• It is better to isolate each clock in an independent
domain and use buffers at the clock boundary.
• If two asynchronous clock domains interact, the
interaction should be limited to a single, small sub-
module in the design hierarchy.
• The interface between the clock domains should avoid
metastability and the synchronization method should be
used at the clock boundaries.
• A simple resynchronization method consists of clock
buffering and dual stage flip-flops or FIFOs at the clock
boundary.
• When cores contain local PLLs, a low-frequency chip-
level synchronization clock should be distributed with
on-chip buses.
• Each core’s local PLL should lock to this chip-level
synchronization clock and generate required frequency
for the core.
• Control on clock skew avoids data mismatch as well
as the use of data lock-up latches.
• A simple method to minimize clock skew is to edge-
synchronize master and derived clocks.
• The general practice has been to use a balanced clock
tree that distributes a single clock throughout the chip
to minimize the clock skew.
• The basic principle is to use a balanced clock tree and
clock buffer at the beginning of the clock tree so that
any skew at the upper level can be adjusted by
adjusting the buffer delay.
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,
• 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.
6. Physical Design
• A number of physical design issues are extremely
important from the reuse point of view.
• 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.
• Floor Plan
• Synthesis
• Timing
• Inputs/Outputs
Deliverable Models
• The reuse of design is pretty much dependent on the
quality of deliverable models.
• These models include
• a behavioral or instruction set architecture (ISA) model,
• a bus functional model for system-level verification,
• a fully functional model for timing and cycle-based logic
simulation/emulation, and
• physical design models consisting of floor planning,
timing, and area.
Design Process for Soft and Firm
Cores
• Design Flow
• Development Process for Soft/Firm Cores
• Top-Level Design Specifications
• Sub-Block Specifications
• Integration of Sub-Blocks
• RTL Guidelines
• Soft/Firm Cores Productization
• Soft, firm, or hard cores requires design guidelines
which 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.
I.Design Flow
• Soft and firm cores should be designed with a conventional
EDA RTL synthesis flow.
• Figure 2.5 shows such a flow.
• 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.
• Based on these partitioned sub-blocks, RTL code is
developed together with synthesis scripts.
• Timing analysis, area, and power estimations are revised
and test-benches are developed to verify RTL.
• During integration of sub-blocks into core-level design, a
top-level netlist is created and used to perform functional
test and synthesis.
• Because of the reusability 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.
• Synthesis script of firm cores provides a netlist with a
target performance and area.
• 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 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.
II. 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 is to refine the functional specs so that they can
be partitioned into self-contained sub-blocks.
• Each sub-block to be designed without
interference/dependency of other blocks, verified by a single
designer and clear interface details.
• In many cases, a behavioral model is used in the testbench
development; for firm cores it is a key simulation model.
• A behavioral model is essential for a core that has a high
algorithmic content.
• For a state machine-dominated core or for a core with little
algorithmic content, an RTL model can provide the equivalent
abstraction description and simulation performance.
• In addition to behavioral/RTL simulation models, a testbench
with self-checking for output responses is also required at the
top level to describe the bus-functional models for
surrounding subsystems.
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.
• Along with RTL coding, testbenches are developed to verify the
basic functionality of the blocks.
• At this stage, low-effort first-pass synthesis is done to determine if
timing, area, and power constraints can be met.
• As timing, area, and power are optimized, a synthesis script is
developed that is used for sub-block synthesis during integration.
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 subblocks 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 insertion such as scan.
• Also, a robust power analysis must be done on various
configurations of the core.
III. 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.
• RTL code should be simple, easy to understand,
structured, uses simple constructs and consistent naming
conventions, and is easy to verify and synthesize.
IV. 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.
 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.
• 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 Cores
• Clock and Reset
• Porosity, Pin Placement, and Aspect Ratio
• Custom Circuits
• Test

• Development Process for Hard Cores

Unique Design Issues in Hard Cores:
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.
• As a rule of thumb, all bus signals including external enable
are connected to adjacent pin locations; input clock and reset
signals are also made available as outputs.
• In general, large logic cores are placed on one corner of the
SoC.
• 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.
• Inside the core, common Vdd/Gnd wires should be shorted as
rings to minimize voltage spikes and to stabilize internal
power/ground.
• Another item that can have a serious impact on SoC floor plan
and routing is the aspect ratio of the hard core.
• 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.
• These circuits cannot done through RTL synthesis-based flow,
these circuits require schematic entry into the physical design
database as well as an RTL model.
• 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 of soft and firm cores
should be followed.
• 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.
• The gate-level netlist 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. A
simplified version of such flow is shown in Figure 2.6.
• At the present time, the common situation is that the silicon vendor
of the SoC chip is also the provider of hard cores.
• For certified cores, the silicon vendor licenses a hard core, develops
various models, and validates the core design and its models
including 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 includes footprint (pin placement),
size of the core in specific technology, detailed timing data sheets,
routing and porosity restrictions, Vdd/Gnd and interconnect rules,
clock and reset distribution rules, and timing specs.
Sign-Off Checklist and Deliverables
• sign-off checklist ensures that certain checks were
made during design, simulation, and verification so
that the final files meet certain criteria.
• Another objective of the checklist is to ensure that
all necessary design, simulation, and verification
files have been created and that installation scripts
and required documentation have been developed.
• These files, scripts, and documentation form the
deliverables.
1. Sign-Off Checklist
• The sign-off checklist should include procedures for design
checks as well as procedures for database integrity.
• For design, a check for the following rules is recommended
(this list is suitable for hard cores; soft cores will require a
subset of this list):
• Completely synchronous design; • Synchronized write/read at memory
• No latches in random logic; boundary;
• No multicycle paths; • Memory design and placement rule
• No direct combinational paths checks;
from inputs to outputs; • Analog/mixed-signal circuits
• Resynchronization at clock design and placement rule checks;
boundary; • Guard bands for memory and
• Resynchronization of all analog/mixed-signal circuits;
asynchronous set/reset/clear • Synchronization and protocol
signals; verifications for on-chip buses;
• Load balancing in clock tree;
• Isolated clock domains;
• Buffered clocks at the block
boundary;
• Clock skew within specified
margin;
• Registered block inputs/
outputs;
• No combinational feedback
loops;
• No internal tri-states;
• No reconvergent logic;
• Static timing analysis done;
• Electromigration rules check;
• No DRC violations;
• LVS and DRC checks for
custom circuits;
• RTL and structural simulation
match;
• RTL code coverage;
• Gate-level simulation done;
• Fault grading and simulation
done;
• Fault coverage;
• SDF (standard delay format)
back-annotated timing;
• Functional simulation done;
• DFT rules (such as scan rules)
check is done;
• Timing, synthesis, test, design
shell files generated.
2 Soft Core Deliverables
• Soft core deliverables are significantly less stringent
than hard core deliverables and include the following
• Synthesizable Verilog/VHDL; • Testbenches with sample
• Example synthesis script; verification tests;
• RTL compiled module; • Cycle-based simulation or
• Structural compiled module; emulation models;
• Design, timing, and synthesis • Bus functional models;
shells; • Application note that describes
• Functional simulation signal slew rate at the inputs,
testbench; clock
• Installation script; • skew tolerance, output-loading
• Bus functional models and range, and test methodology.
monitors used in testbenches;
3 Hard Core Deliverables
• The deliverables for hard cores consist primarily of the models
and documentation for the core integrator to design and verify
the core in SoC environment.
• Installation scripts; • Testbenches with verification
• ISA or behavioral model of tests;
the core; • Manufacturing tests;
• Bus functional and fully • GDSII with technology file
functional models for the core; (Dracula deck);
• Cycle-based emulation model • Installation script;
(on request); • Application note that describes
• Floor planning, timing, and timing at I/Os, signal slew rate,
synthesis models; • clock distribution and skew
• Functional simulation tolerance, power, timing data
testbench; sheet,
• Bus functional models and • area, floor plan, porosity and
monitors used in testbenches; footprint, and technology
specifications.
System Integration
• The key issues in integrating the core into final SoC
include logical design, synthesis, physical design,
and chip-level verification.
• Designing With Hard Cores
• Designing With Soft Cores
• System Verification
Designing With Hard Cores
• Developing a chip using hard cores from external sources
such as IP vendors carries certain issues such as from which
source to acquire, design and verification of interfaces
between the cores and the rest of the chip, functional and
timing verification of the chip, and physical design of the
chip.
• The most difficult tasks are related to verification.
• The verification of different aspects such as application-
based verification, gate-level verification, and so on
requires significant effort.
• The most important task of SoC design is to verify
functionality and timing (performance) at the system level.
• Normally, the SoC-level validation effort is about 60% to
75% of the total design effort.
• Various items need to be considered in core selection.
• These include the quality of the documentation,
robustness/completeness of the validation environment that
comes with the core, completeness and support for the design
environment, and so on.
• Hard cores generally require that the design be silicon proven
with predictable parameters and that the physical design
limitations such as routing blockage and porosity of the core
are clearly identified.
• From the physical design point of view, distribution of clock,
Vdd/Gnd, and signal routing is important for hard cores.
• The delays in the core must be compatible with the clock
timing and clock skew of the rest of the chip since the hard
core has its own internal clock tree.
• Because a hard core would limit or prevent the routing of
signals, the placement of the core in the chip can be critical in
achieving routability and timing of the chip.
• The requirements of the power and ground signals and
switching characteristics must also be met because they could
affect the placement and route.
Designing With Soft Cores
• Design issues of soft cores in SoC include the quality of the
documentation and robustness/completeness of the
verification environment that comes with the core.
• The core and related files including the complete design
verification environment should be installed in the design
environment that looks like the core development
environment.
• Many soft cores are configurable using parameters and the
user can set them to generate complete RTL. After RTL
generation, the core can be instantiated at the top-level
design.
• The main issue in this process is the correctness of
interfaces between the core and the rest of the system.
• Finally, even if the core provider has verified that the core
meets the timing on multiple cell libraries and
configurations, the SoC designer should still verify it using
target technology library.
System Verification
• Along with the SoC specification development, SoC-
level behavioral models are developed so that the
designer can create testbenches for the verification of
the system without waiting for the silicon or a hardware
prototype.
• Therefore, a good set of test suites and test cases are
needed, preferably with actual software applications by
the time RTL and functional models for the entire chip
are assembled.
• Efficient system-level verification depends on the
quality of test and verification plans, quality and
completeness of testbenches and the abstraction level of
various models, EDA tools and environment, and the
robustness of the core.
System Verification……..
• The system-level verification strategy is based on the
design hierarchy. First the leaf-level blocks (at core
level) are checked for correctness in a stand-alone
manner.
• Then the interfaces between the cores are verified in
terms of transaction types and data contents.
• After verification of bus functional models, actual
software application or an equivalent testbench should
be run on the fully assembled chip.
• This is generally a hardware-software co-simulation.
• This could be followed by a hardware prototype either
in ASIC form or a rapid prototype using FPGAs.