Hardware emulation
It is a process where a design is implemented on a specialized hardware platform (an emulator) that can mimic
the behavior of the designed system. It's used primarily for the functional verification of hardware, including the
validation of firmware and software that runs on the hardware.
Emulation involves mapping a circuit design onto the programmable logic of an emulator, which consists of
custom silicon chips designed to be configurable to mimic various logic functions. This allows the emulator to act
as a real version of the design, executing its behavior in real-time or near real-time.
Key points about hardware emulation include:
Execution Speed: While slower than actual hardware, hardware emulators can run much faster than software
simulators, allowing more extensive testing in a shorter time.
Software/Hardware Co-Verification: Emulation enables testing the hardware design with actual software,
firmware, and even operating systems. This co-verification process can uncover issues that may not be visible
when hardware and software are tested separately.
In-Circuit Emulation (ICE): In this mode, the emulator is connected to a system under test, just as the real chip
would be. This allows real-world stimuli to be applied to the design.
Virtual Emulation: In this mode, the emulator is connected to a simulation testbench or a software test
environment. This can allow more control and visibility into the design, but it may not capture all the interactions
with real-world physical systems.
Complex Debugging: Emulators often provide powerful debugging capabilities, including full visibility into the
design's internal nodes and the ability to start and stop execution, set breakpoints, and step through the execution.
An example of using hardware emulation could be verifying a design for a system-on-chip (SoC) that includes a
processor, memory, and various peripherals. The design could be loaded onto an emulator, and the actual firmware
and software that will run on the SoC can be executed on the emulator. This can include booting up the operating
system, running application software, and interfacing with external devices or systems. The emulator can provide
visibility into the internal workings of the SoC, allow control over its execution, and check for functional
correctness, performance, and timing issues.
Fault models in RAM:
Testing memory components like RAMs (Random Access Memories) in an integrated circuit is an important
aspect of ensuring reliable operation. Given the large number of storage elements in a memory (millions to
billions), an exhaustive testing of all possible conditions is practically infeasible. Therefore, to simplify the process
of testing, fault models are used.
Fault models represent probable defects that might occur during the manufacturing process. By focusing on a
limited number of representative faults, it becomes possible to develop efficient testing procedures. Below are
some common fault models used in the testing of RAM:
1. Stuck-at Faults: This is the simplest type of fault model where a memory cell is assumed to be stuck at a logic
'0' (stuck-at-0) or a logic '1' (stuck-at-1) regardless of the write operation to the cell. This type of fault can result
from manufacturing defects like a short-circuit to power or ground.
2. Transition Faults: This type of fault models a memory cell that cannot change its state, i.e., a cell that cannot
transition from '0' to '1' (stuck-at-rise) or '1' to '0' (stuck-at-fall). This might happen due to issues like insufficient
charge or discharge time because of process variations or defects.
3. Coupling Faults: These faults model the condition where the state of one cell (the aggressor) influences the
state of another cell (the victim). Two primary types of coupling faults are Inversion Coupling Fault (ICF), where
the victim cell's state is inverted when the aggressor cell changes state, and State Coupling Fault (SCF), where the
victim cell's state is forced to the state of the aggressor cell when the aggressor changes state.
4. Address Decoder Faults: These faults occur when there's a problem with the memory's address decoder. For
instance, a single address could map to multiple cells (multiple-cell upsets), or a single cell could be mapped by
multiple addresses.
5. Read/Write Faults: These faults occur when the read or write operations themselves are faulty. For example, a
write disturb fault happens when writing to one cell accidentally alters the data in another cell.
These fault models are used to design memory test algorithms, which generate test patterns to effectively detect
the presence of these faults. These patterns are applied to the memory, and the responses are analyzed to determine
the presence of faults. Such algorithms aim to achieve high fault coverage with a minimum number of test patterns
to keep testing time and costs low.
Test algorithms for RAMs:
1. March Tests: These are a class of algorithms that are most commonly used to test RAMs. They are named
"march tests" because they involve 'marching' through the memory from the lowest to the highest address (and
vice versa), performing a series of read and write operations at each address.
A march test consists of a sequence of 'march elements', where each march element comprises a set of operations
(read, write) that are performed on each memory cell in an address sequence. Different march tests are identified
by the specific operations and their order within the march elements. For example, March C- is a commonly used
march test that can detect all static faults including stuck-at, transition, and coupling faults. It involves the
following sequence:
(a) Write '0' to all cells while moving upward.
(b) Read '0' and write '1' to all cells while moving upward.
(c) Read '1' and write '0' to all cells while moving upward.
(d) Read '0' to all cells while moving downward.
The direction of the march (upward from lower to higher addresses or downward from higher to lower addresses)
and the read/write operations are both crucial to the detection of different types of faults.
2. Galpat (Galway Pattern) Tests: Galpat is a type of test that was developed to catch stuck-at faults and coupling
faults. The basic idea of Galpat tests is to write a pattern to all cells, read and verify the pattern, invert the pattern
(write the complement), and then verify the inversion.
For example, in the case of the Galpat '0' test, the algorithm first writes '0' to all cells, then reads and verifies
that all cells are '0'. This is followed by writing '1' to all cells and verifying that all cells are '1'. The Galpat '1' test
is similar but starts with writing and verifying '1' before moving to '0'. The pattern written to all cells helps detect
stuck-at faults, while the inversion operation can help reveal coupling faults.
3. Walking 1 and Walking 0 Tests: These tests are especially designed to identify stuck-at faults and some types
of coupling faults.
In a Walking 1 test, a pattern of all zeroes except for a single one is written and then moved or 'walked' through
the memory. The test works by moving the '1' through different memory locations while keeping all other locations
at '0'. This can reveal whether a cell is stuck-at '0' (since it will not be able to hold the '1') or whether it has a
coupling fault with an adjacent cell (since the '1' may inadvertently flip a '0' to a '1').
The Walking 0 test is similar but uses a pattern of all ones with a single zero that is walked through the memory.
This helps identify cells that are stuck-at '1' or have coupling faults.
4. Checkerboard / Word / Bit-Oriented Tests: These tests are designed to catch gross faults, such as shorts between
word or bit lines.
The checkerboard test involves writing and reading back a checkerboard pattern of '0's and '1's. The word-
oriented test involves writing all '0's or all '1's to each word line and then reading back to verify the data. The bit-
oriented test is similar but involves writing to each bit line instead. If there is a short between word or bit lines,
these tests can detect the incorrect data due to the short.