Streaming Scan Network (SSN)

Motivation to Use SSN:-

 before we begin to describe the streaming scan network and how to implement it for your design,
let’s look at some of the problems in the scan test that the SSN solves, and these solutions will be
discussed later.

Problems Addressed by SSN

1. we will explore having a limited number of scan channels available for test.

 2. Routing and timing closure issues.

3. the impact of test time and scan data volume.

 4. how do you plan and implement the chosen solution in a tool flow?

5. what about diagnosis and debug?

1. Many test strategies implement a hierarchical block test approach with wrapper chains driven
by TestKompress EDT logic. With lots of blocks in a design, this leads to the need for many scan
channels. Each block needs dedicated channel outputs for tile-based designs or those with
many identical blocks.
2. Routing and timing can challenge issues:- configuring which block patterns to retarget and test
together with different modes can be difficult. If top-level scan channel connections are shared,
that might require many MUXs and wires. The SSN architecture eases routing and timing
closure and is fully compatible with tile-based design with abutment.
3. If a scan failure diagnosis is needed, that can also be problematic. With many retarget modes,
pattern sets, and flat models. Keeping track of all the correct pieces and bringing them together
can take time and effort. Doing diagnosis on several blocks in parallel dramatically increases the
complexity. Failures captured on the tester are reverse-mapped to block-level failures. After the
reverse mapping, layout – aware diagnosis is performed with no limitations.

4. The test planning and implementation flow are very challenging for large designs as many
factors need to be considered concurrently. For example , how many channels are allotted per
block? Are pipelines required for timing? How can we reduce the impact on routing? The SSN
implementation flow is present in Tessent shell. It is fully integrated with all other tessent DFT,
such as memoryBist, if present in the design. You perform a bottom-up DFT insertion for each
 physical block, followed by DFT insertion at the parent level. SSN is inserted into the design
during the second DFT insertion pass along with EDT compression circuitry, OCC and the
connections between these blocks.
5. As for test time and data volume, if the different block patterns are synchronized for their
capture cycles, if often leads to wasted bandwidth on the tester, as some blocks with shorter
scan chains get padded cycles added. Creating test pattern groups with various retargeted block
patterns can also waste bandwidth. The traditional retargeting methods pad the blocks with
fewer patterns such that there is a better use of data and test time.

SSN Architecture Overview:-

 Describe the SSN architecture
 discuss some SSN terms and definitions
 Define the SSN multiplexer and pipeline nodes.

 SSN is a bus-based scan data distribution architecture. The following figure shows a four-core
design with a high-level SSN description. Each core typically contains one Streaming Scan Host
(SSH) node; the SSH node drives local scan resources to load and unblock scan chains or channel
with data delivered on the SSN bus. The SSN datapath is a term used to describe the network of
SSH nodes. It is a synchronous N-bit wide bus used to stream scan test data.
 As you can see, the primary access to the SSN datapath is through the SSN_bus_in and
SSN_bus_out, with bus_clock as the synchronous clock source.
 The scan data is streamed through the SSN datapath, where the SSH nodes transfer data
between the datapath and the TestKompress EDT or scan chains. With this architecture, you
can see that the SSN datapath traverses the whole design hierarchy, delivering scan data to and
from any number of active SSH nodes.
 The data bus by default, runs at a frequency of 400MHZ with a 100MHz shift frequency to EDT
or scan chains. These values are controlled by the user. The SSN bus and SSH nodes can be
inserted at the RTL or gate level. They can be integrated into your design manually, or you can
have the tessent tool do all the insertion and integration automatically. As this is a simplified
design example, we can see only one single SSN datapath, but there can be multiple
independent SSN buses per design.
 You may be wondering if we can modify this datapath while testing to exclude some cores of the
design. Let’s explore other elements in this SSN architecture and how they would allow us to
control the datapath.

 Given the following figure, you can still see that we have the main four cores or blocks, but with
the addition of multiplexers, we can now control the inclusion and exclusion of a section of a
datapath.
 This can be performed by inserting the SSN Multiplexer nodes, which are optionally inserted to
modify the SSN datapath. By default, these multiplexers have a built-in retiming register, but
you can build these multiplexers without this retiming stage.
 As you can see this figure, these MUX nodes can either provide a debug return path from the
SSN_bus_in to SSN_bus_out or exclude cores or blocks from the active datapath. The main
reason to allow bypassing sections of the datapath is if you have massive failures in one core
and still want to test the other cores because you do core harvesting and can still use a chip
with some defective cores. Using this MUX nodes, you may also want to exclude some cores on
a different power domain.
 In this example, you can see that the pipeline registers were added at the inputs of blk_a and
blk_b; they can also be used to register the datapath out of the blocks and on long nets. More
on these nodes and their usage within the SSN architecture are covered in subsequent lessons
of this chapter.

 One of the main components of the SSN network is the SSH or streaming scan host node.
The SSH node represents a primary interface to the scan circuit. It can drive multiple EDTs,
non-compressed scan chains, or both.
 To better understand how the SSH operates, let’s first discuss how it gets initialized. Using
IJTAG is one of the requirements for the SSN network; as you can see, the entire network
gets initialized through the IJTAG, and the red path shown from TDI to TDO represents the
IJTAG path that is required to program each SSH node to operate correctly, this initialization
is static per pattern set.
 When creating the SSH nodes. If we set the property bus_register_reset to “on”, which is
the default value, it will enable all nodes to reset the bus register during the iReset.
 The SSH nodes get programmed as part of the SSN_setup, and the SSN_setup procedure is
executed after the custom test_setup procedure. This SSN_setup is automatically created
by the tool, so you don’t have to worry about initializing the SSN_nodes.
 Once the setup is complete, all nodes will be programmed and ready to run. When you
insert the SSN nodes, if you want to reset this setup, you must do a hardware reset for the
IJTAG network.
How this helps in real silicon testing

On ATE:

1. Run SSN loopback patterns first

2. If PASS → SSN infrastructure is healthy
3. Then run:
o Core ATPG
o EDT patterns
o Parallel core testing

This avoids wasting time debugging cores when the infrastructure itself is faulty.

✅ 1. What is SSN (Streaming Scan Network)?

Streaming Scan Network (SSN) is a bus-based scan test methodology used to

deliver scan test data in packets to internal scan chains and EDT blocks instead of
using traditional flat scan wiring.

In simple words:

SSN is a scan test architecture where scan data is streamed over a bus to
different cores/tiles, rather than being driven directly through global scan
chains.

Key characteristics:

 Scan data is sent as packets

 Uses a shared bus (datapath) for test data
 No scan data crosses hierarchy boundaries except through the SSN bus
 Controlled and configured using IJTAG
 Supports hierarchical and tile-based designs
 Scalable bus width (even 1-bit bus possible)
✅ 2. Why do we need SSN?

SSN is needed because traditional scan and EDT do not scale well for modern
large SoCs, tile-based designs, and 2.5D/3D ICs.

Main reasons:

🔹 1. Decouples core-level and chip-level DFT

 Core teams can optimize scan independently

 Chip-level DFT does not need to rebalance or re-time core scan chains

👉 This greatly simplifies integration.

what is “bandwidth” in scan testing?

In scan context, bandwidth = how much scan data can be delivered per unit
time.

Example:

 ATE can deliver 32 bits per cycle

 That is the total available bandwidth

What is Bandwidth Sharing in SSN?

Bandwidth sharing in SSN means:

The available scan test data bandwidth from the ATE is dynamically and
automatically shared among multiple cores/tiles connected to the SSN bus,
based on their individual test needs.

🔹 2. Handles arbitrary clock skew between cores

 In traditional scan, clock skew between cores forces:

 o Slower shift speed
o Global clock balancing
 SSN allows each core to generate local DFT clocks

👉 No need to globally balance scan clocks.

🔹 3. Scales for large and tile-based designs

 Ideal for tile-based SoCs

 Tiles are abutted blocks with no chip-level logic
 All scan chains terminate inside the tile

👉 SSN automatically manages bandwidth per tile.

🔹 4. Improves test time and power profiling

 Multiple cores can be tested in parallel

 SSN automatically distributes available bandwidth
 Better control of power by selective activation of cores

🔹 5. Supports advanced packaging (2.5D / 3D ICs)

 Works with IEEE 1838

 Supports:
o Primary TAP (PTAP)
o Secondary TAP (STAP)
o Flexible Parallel Port (FPP)

👉 SSN acts as the FPP, enabling die-to-die test access.

✅ 3. Difference between SSN and Traditional Scan

 Aspect Traditional Scan SSN

Architecture Flat / centralized Bus-based / network

Data delivery Bit-by-bit shift Packet-based streaming

Hierarchy awareness Poor Excellent

Clock handling Global scan clock Local clocks per core

Clock skew handling Difficult Easy

Scalability Limited Highly scalable

Best for Small/medium SoCs Large, tile-based, 2.5D/3D SoCs

Integration effort High Low

Bandwidth usage Fixed Dynamically balanced

One-line difference:

Traditional scan pushes data through global chains, while SSN streams scan data
over a bus to selected cores in a hierarchical and scalable way.

✅ 4. Pros and Cons of Scan vs SSN

✅ Traditional Scan

✅ Pros:

 Simple architecture
 Well understood
 Easy ATPG support
 Low initial complexity
❌ Cons:

 Poor scalability
 Global clock skew issues
 Heavy routing congestion
 Difficult SoC integration
 Limited parallelism
 Not suitable for tiles or 3D ICs

✅ Streaming Scan Network (SSN)

✅ Pros:

 Highly scalable
 Excellent for hierarchical designs
 Supports tile-based SoCs
 Handles clock skew naturally
 Enables parallel core testing
 Automatic bandwidth balancing
 Works well with IJTAG
 Ideal for 2.5D / 3D ICs
 Supports on-chip compare (OCComp) for identical cores

❌ Cons:

 More complex architecture

 Higher DFT planning effort
 Requires IJTAG infrastructure
 More learning curve for teams
 Slight area overhead for routers/controllers

✅ Final Interview-Ready Summary

SSN is a bus-based scan test architecture that streams scan data as packets to
internal scan chains and EDT blocks, enabling scalable, hierarchical, and
clock-independent testing of large SoCs. Unlike traditional scan, SSN decouples
core and chip-level DFT, supports parallel testing, handles clock skew naturally,
and is ideal for tile-based and 2.5D/3D designs.

✅ 1. What is traditional flat scan wiring?

Traditional flat scan = direct, global scan connectivity

In a normal scan / EDT design without SSN, the connectivity looks like this:

ATE pins
|
v
Scan_In → Scan FF → Scan FF → Scan FF → ... → Scan_Out

or with EDT:

ATE pins
|
v
EDT Decompressor → hundreds of scan chains (global)
EDT Compactor ← hundreds of scan chains

Key characteristics of flat scan wiring

 Scan chains are globally wired

 Long scan wires run across the entire chip
 All scan chains are driven from one central place
 Clock skew between far-away blocks is a big problem
 Routing congestion is high
 Core-level and chip-level DFT are tightly coupled
👉 This is called flat because:

All scan data is pushed directly into scan chains through flat, chip-wide wiring.

✅ 2. In traditional EDT flow, who generates patterns?

You are 100% correct here:

✅ ATE + ATPG generate deterministic patterns

 ATPG generates patterns

 ATE sends compressed seeds
 EDT decompressor expands them
 Scan chains get deterministic values

✅ LFSR generates pseudo-random patterns

 Used in LBIST
 Not used for deterministic ATPG coverage

So in traditional EDT:

 ATE sends data

 LFSR expands
 Scan chains receive data directly

✅ 3. Then what changes in SSN?

This is the key misunderstanding:

❌ SSN does NOT replace ATPG, EDT, or LFSR

✅ SSN replaces HOW scan data is transported

SSN changes the delivery mechanism, not the source of patterns.

✅ 4. What does “SSN delivers scan data in packets” actually mean?

In SSN, scan data is not wired directly to scan chains.

Instead, scan data flows like network packets:

ATE
|
v
IJTAG / TAP
|
v
SSN Bus ========> Core A
========> Core B
========> Core C

Important points:-

 Scan data moves as packets over a bus

 Bus width can be 1-bit, 8-bit, 32-bit, etc.
 Data is addressed to a specific core
 No scan data crosses hierarchy except through the bus

This is why it’s called a Streaming Scan Network.

✅ 5. How does EDT fit inside SSN?

Now let’s answer your exact confusion:

“ATE generates patterns for EDT scan chains and LFSR generates random patterns,
but you say SSN delivers scan data to EDT blocks and scan chains — how?”

✅ Correct understanding:

 ATPG still generates deterministic patterns

 EDT still decompresses patterns
 LFSR still generates random patterns (LBIST)
👉 SSN only changes the path between ATE and these blocks

Traditional EDT (flat wiring)

ATE → EDT → Scan Chains

SSN-based EDT

ATE → IJTAG → SSN Bus → Core Router → EDT → Scan Chains

So:

 SSN delivers packets to the EDT block

 EDT still does decompression
 Scan chains still shift data

SSN does not replace EDT or ATPG.

✅ 6. Why is packet-based delivery useful?

Because now:

✅ Each core can be tested independently

 Core A can receive data

 Core B can wait
 Core C can be bypassed

✅ Clock skew is no longer a problem

 Each core generates local scan clocks

 No need to globally balance scan clocks

✅ Better scalability

 100s of cores
 1000s of scan chains
  No flat wiring explosion

✅ 7. What about LFSR / random patterns in SSN?

Same story:

Traditional LBIST

LFSR → Scan Chains

SSN-based LBIST

LFSR → Local EDT / Scan Controller → Scan Chains

↑
SSN config enables it

SSN only:

 Configures which cores are active

 Routes control and data
 Does not generate randomness itself

✅ 8. Simple analogy (very important)

Traditional scan:

Like watering all plants using one long pipe running across the field.

SSN:

Like water distribution network with pipes going only where needed.

The water (patterns) is the same.

The delivery system is smarter.
✅ 9. Final clear summary (answer you can give confidently)

✅ What is traditional flat scan wiring?

Traditional flat scan wiring directly connects ATE or EDT outputs to all scan chains
using global, chip-wide wiring, causing routing congestion, clock skew, and poor
scalability.

✅ How does SSN change this?

SSN replaces flat wiring with a bus-based, packet-driven scan network that
streams scan data to specific cores or EDT blocks without global scan connectivity.

✅ Does SSN replace ATPG, EDT, or LFSR?

No. ATPG still generates patterns, EDT still decompresses them, and LFSR still
generates random patterns. SSN only changes how scan data is transported.

✅ One-line interview answer

SSN does not change how patterns are generated; it changes how scan data is
delivered. Instead of flat global scan wiring, SSN streams ATPG or EDT data as
packets over a bus to local cores, improving scalability, clock handling, and
integration.

✅ What is a Tile-Based Design?

A tile-based design is an SoC architecture where the chip is built by repeating

identical or near-identical blocks (tiles) that are placed next to each other
(abutment) to form the full chip.

Think of tiles like LEGO blocks: the same block is reused many times to build a
larger system.
🔹 What exactly is a tile?
A tile is a self-contained physical block that usually includes:

 Core logic (CPU/DSP/accelerator/peripheral)

 Local scan chains
 Local clocks/resets
 Local DFT (EDT, LBIST, wrappers)
 Fixed physical footprint (same size/shape)

Each tile can be designed, verified, and tested independently.

✅ Why are Tile-Based Designs Used?

Modern SoCs are too large and complex to design as one monolithic block. Tiles solve
this.

✅ 1. Scalability

 Need more performance? → Add more tiles

 Need a smaller chip? → Use fewer tiles

No redesign required.

✅ 2. Design Reuse

 Same tile reused across:

o Different products
o Different SKUs
 Saves time and cost

✅ 3. Faster Development

 Tile is designed and verified once

 Integration is simple abutment
 Parallel development by multiple teams
✅ 4. Predictable Physical Design

 Fixed footprint tiles

 Easy floorplanning
 Reduced timing surprises

✅ 5. Perfect for Advanced Packaging

 2.5D / 3D ICs
 Chiplets
 Die stacking

Tiles map naturally to dies or chiplets.

✅ How Tile-Based Designs Are Used (Real Flow)

🔹 Step 1: Design a Single Tile

 Create RTL for the tile
 Insert scan, EDT, LBIST
 Verify functionality
 Do block-level ATPG
 Finalize physical layout

✅ Tile is now a hardened block

🔹 Step 2: Replicate Tiles at Chip Level

 Place multiple copies of the same tile
 Connect tiles via NoC / interconnect
 No internal logic added at top level

+-----+-----+-----+
| T1 | T2 | T3 |
+-----+-----+-----+
| T4 | T5 | T6 |
+-----+-----+-----+

🔹 Step 3: Test the Tiles (DFT Perspective)

Here’s where SSN fits perfectly.

Without SSN (problematic):

 Each tile needs global scan wiring

 Global clock balancing required
 Massive routing congestion

With SSN (ideal):

ATE
|
SSN Bus
| | |
Tile1 Tile2 Tile3

 All scan data goes through SSN bus

 No scan data crosses tile boundary except via bus
 Each tile uses local clocks
 Tiles tested independently or in parallel

✅ Tile-Based Designs + SSN (Why They Go Together)

SSN is ideal for tile-based designs because:

✅ No Global Scan Wiring

 Each tile is isolated

 SSN bus is the only test interface

✅ Automatic Bandwidth Sharing

  Tiles may have different scan sizes
 SSN dynamically allocates bandwidth

✅ Parallel Testing

 Multiple identical tiles tested together

 With On-Chip Compare (OCComp), same pattern applied to all tiles

✅ Clock Skew is Not a Problem

 Each tile has local clocks

 No need to balance scan clock across entire chip

✅ Example of Tile-Based Design in Industry

 Many-core CPUs
 AI accelerators
 GPU shader cores
 Network packet processors
 Automotive SoCs
 Chiplet-based designs

Example:

A 64-core processor = 64 identical CPU tiles

✅ Tile-Based vs Monolithic Design (Quick Compare)

Aspect Monolithic Design Tile-Based Design

Reuse Low High

Scalability Poor Excellent

DFT complexity High Lower with SSN

Physical planning Hard Easy

Test integration Complex Clean & modular

✅ Simple Explanation for Juniors

Tile-based design means building a chip using many copies of the same block.
Each block is complete by itself. SSN is used to test these blocks efficiently
without global scan wiring.

✅ One-Line Interview Answer

A tile-based design is an SoC architecture built by repeating identical

self-contained blocks with fixed physical footprints, enabling scalability,
reuse, and efficient test access—especially when combined with SSN.

Good question — SSH is often mentioned together with SSN, and the names are
confusing if you haven’t seen the full architecture.

I’ll explain this clearly, step-by-step, and then show the exact relationship
between SSN and SSH.

✅ What is SSH?

SSH = Streaming Scan Hub

(sometimes also referred to as Streaming Scan Host in some documents, but Hub is
the most commonly used term in Tessent SSN context).

Simple definition:

SSH is the central control and aggregation block of the Streaming Scan
Network (SSN).
It is the entry/exit point for scan data inside the chip.

✅ What does SSH do?

Think of SSH as the “gateway/router” between:

 External test access (ATE / IJTAG / TAP)

 Internal SSN datapath
 Multiple cores / tiles / EDT blocks

Main responsibilities of SSH:

1. Receives scan data packets

o From ATE via JTAG / IJTAG / test pins

2. Injects data into the SSN bus

o Streams packets into the SSN datapath

3. Collects response packets

o Gathers scan-out data coming back from cores

4. Controls routing and scheduling

o Decides which core gets data
o Manages bandwidth sharing

5. Acts as the SSN “master”

o SSN routers and endpoints work under SSH control

✅ Where does SSH sit in the architecture?

Here is the correct placement:

ATE / Tester
|
IJTAG / TAP / FPP
|
v
+------------------+
| SSH (Hub) |
+------------------+
|
v
====================== ← SSN Datapath (Bus)
| | |
Core A Core B Core C
(EDT) (EDT) (EDT)

✅ SSH is part of SSN, not separate from it.

✅ What is SSN then?

SSN = Streaming Scan Network

SSN includes:

 SSH (hub)
 SSN datapath (bus)
 Routers / endpoints
 Core-level scan interfaces
 Optional OCComp logic

So:

SSH is a component inside SSN.

✅ Relation between SSN and SSH

Correct relationship:

 SSN is the entire scan streaming architecture

 SSH is the central control and aggregation block of SSN

One-line relationship:

SSN is the network; SSH is the hub that manages and feeds the network.
✅ Why SSH is needed in SSN?

Without SSH:

 No centralized control
 No packet scheduling
 No bandwidth management
 No clean interface to IJTAG / ATE

SSH enables:

✅ Packet-based delivery
✅ Bandwidth sharing
✅ Parallel core testing
✅ Clean hierarchy separation
✅ Scalable integration

✅ SSH vs Traditional Scan Controller

Aspect Traditional Scan Ctrl SSH

Scope Flat scan chains Streaming network

Data type Bit-level Packet-level

Hierarchy awareness Poor Excellent

Bandwidth control Fixed Dynamic

Scalability Limited High

✅ How SSH works with EDT

Important clarification (ties to your earlier doubt):

 SSH does NOT generate patterns

 SSH does NOT replace EDT
  SSH only transports data

Flow with EDT:

ATE → SSH → SSN → Core EDT → Scan Chains

 ATPG generates patterns

 ATE sends compressed data
 SSH streams packets
 EDT decompresses locally
 Scan chains shift

✅ Simple explanation for juniors

SSN is like a road network.

SSH is the main traffic junction that controls where the vehicles go.
The vehicles (scan data) are the same — only the transport system is smarter.

✅ Interview-ready final answer

SSH (Streaming Scan Hub) is the central control block of the Streaming Scan
Network. It interfaces with external test access such as IJTAG and manages
packetized scan data delivery and response collection over the SSN bus. SSN
is the overall network architecture, and SSH is the hub that controls routing,
bandwidth sharing, and access to multiple cores or EDT blocks.

If you want next, I can: ✅ Draw SSN + SSH block diagram

✅ Explain SSH vs SSN Router vs Endpoint
✅ Explain SSH + OCComp
✅ Explain SSH role in retargeting

Just tell me 👍
 Lets focus more on what happens inside the SSH node. On the left side
of the figure, you can see the inputs coming into the SSH node, namely
the SSN_bus_in and the bus_clock.
 The SSH node receives the scan data through the SSN_bus_in. once
received, it gets registered in the bus_register. Then, it is passed into the
first cloud of logic, heading into another register before reaching the
EDT through the to_scan_in path.
 In SSN, the scan test data is delivered to the SSH over the SSN_bus_in
bundles called packets. A packet can hold more than one SSH’s scan
data; an SSH will receive many packets through the scan pattern. The
data of each SSH is always in the exact location of the packet, so each
SSH retrives its scan_in data, leaving other SSH scan_in data untouched
from each streaming scan packet as they are synchronously driven
through the SSN network.
 The scan_out data is then shifted from the EDT or scan chains to the
SSH, and the SSH places the data back into a packet, overwriting the
scan_in data. The SSH transfers the packet back onto the SSN bus
through the SSN_bus_out, and it is synchronously driven to the output
of the network, where it is compared against the expected data.
 On the upper left of the figure, you can see the clock Generator
component; this is driven by the bus_clock and used to generate the
scan_enable, edt_update, edt_clock, and shift_capture_clock.
 These locally generated signals are used to transition the circuit
between shift and capture independently from the other SSH node
network.
 This allows you to close timing at a higher shift rate as these signals are
not traversing the whole hierarchy; this way, you can build your core,
verify it, and put it on the shelf, waiting for other cores to be finished.
 This is a very efficient way to complete your block-based design.
Clocking of SSN is covered in more detail in other lessons.
 Another feature of SSN is the loopback verification. That is supported
with this MUX inserted here so that the data on the “to_scan_in” is
looped back into the MUX and brought back to the SSH using this
loopback MUX; you can test your SSH internal logic without any
interaction or interference from EDT or scan chains, this is useful for
verifying the delivery mechanism or packetization of data without
including the EDT, allowing you to make sure that all bits are delivered
in the correct order, nothing is out of sequence and that the SSH is
operating correctly.
 If, for any reason, you need to bypass this SSH node and exclude it from
your SSN network, there is another path here starting with the
SSN_bus_in register, bypassing the two logic clouds going through the
MUX to the SSN_bus_out. This mode is used if the EDT is not active;
therefore, this SSH is not active and would act like a two-stage pipeline
register to help retime the data and send it out through the
SSN_bus_out.
 Remember that we consider the SSH nodes as an active node; if the core
instance of the EDT is active, in this case, the SSH will be part of the scan
path. If the core instance of the EDT is not active, then the SSH will
behave as a two-stage pipeline, only passing the data through.
Below is a clear, row-by-row explanation of the flow shown in your table,
explaining what each feature means, how it works in the traditional
hierarchical flow, and what changes when SSN is used. I’ll also add why SSN
marks some items as Required / Highly Recommended so the intent is very clear.

✅ What this table is showing (Big Picture)

The table compares:

 Traditional hierarchical DFT flow

vs
 SSN-based DFT flow

for key DFT features/capabilities.

The main message of the table is:

SSN is not just an add-on; it changes the assumptions of the hierarchical DFT
flow.
Some things that were “optional or recommended” become “mandatory”
when SSN is used.
✅ Row-by-Row Explanation

🔹 1. IJTAG
Traditional hierarchical flow

 IJTAG is optional but useful

 When used for test_setup, it enables:
o Plug-and-play integration of ICL modules
o Easier hierarchical connectivity
 But scan and EDT can still work without IJTAG

SSN flow

 IJTAG is REQUIRED
 SSN cannot operate without IJTAG
 IJTAG is used to:
o Initialize SSH
o Program SSN time slots
o Configure routing and bandwidth
 SSN and IJTAG share the same control network and ICL extraction

👉 Why required in SSN?

Because SSN is packet-based and configurable, and IJTAG is the only standardized
way to configure and control it.

🔹 2. Full OCC
Traditional hierarchical flow

 Full OCC is recommended

 Mainly used to:
o Control at-speed clocks
o Support wrapped cores
 Some designs may partially work without full OCC

SSN flow

 Full OCC is REQUIRED

  OCC is needed to:
o Control SSN shift clocks
o Control SSN capture clocks
o Support independent core-level clocking

👉 Why required in SSN?

SSN removes global scan clocks, so local clock control via OCC becomes
mandatory.

🔹 3. TSDB Automation
Traditional hierarchical flow

 TSDB (Test System DataBase) automation:

o Helps manage data for many cores
o Especially useful for large hierarchical designs
 Helpful but not always mandatory

SSN flow

 Highly Recommended
 SSN involves:
o Many cores
o Many packets
o Many retargeting configurations
 TSDB automation keeps:
o Pattern data
o Core mappings
o Retargeting information consistent

👉 Why important in SSN?

Because SSN scales to many cores, manual data handling becomes error-prone.

🔹 4. DFT Signals
Traditional hierarchical flow

 DFT signals (testmode, scan_enable, etc.) help:

o Automate the flow
 o Simplify test setup
 Can still work with ad-hoc handling

SSN flow

 Highly Recommended
 SSN requires:
o Clean, well-defined DFT signals
o Predictable control for SSH, EDT, OCC

👉 Why more important in SSN?

Because SSN relies on local autonomous behavior, DFT signals must be clean and
standardized.

🔹 5. DftSpecification
Traditional hierarchical flow

 Used to:
o Automate flow
o Define usage of DFT signals
 Mostly descriptive

SSN flow

 Highly Recommended
 DftSpecification:
o Drives creation of SSN hardware
o Drives insertion of EDT and/or OCC
o Acts as the blueprint for SSN architecture

👉 Why critical in SSN?

SSN is an architecture, not just wiring—tools need a formal spec to build it correctly.

🔹 6. EDT Dual Configuration

Traditional hierarchical flow

 EDT dual configuration:

 o Reduces chip-level EDT resource usage
o Optional optimization

SSN flow

 Recommended
 In SSN:
o EDT improves bandwidth efficiency
o Fewer SSN packets are needed
o Better sharing across cores

👉 Why recommended in SSN?

Because SSN + EDT together give maximum bandwidth utilization.

🔹 7. EDT for Wrapper Chains

Traditional hierarchical flow

 Keeps:
o EDT
o Shift clock implementation
o Timing local to wrapped core
 Useful but not mandatory

SSN flow

 Highly Recommended
 SSN philosophy:
o Everything stays local to the core
o Wrapper + EDT + clocking handled inside the core

👉 Why strongly recommended?

This matches SSN’s goal of complete core-level isolation.

🔹 8. Non-Overlapping EDT / Shift Clocks

Traditional hierarchical flow

 Non-overlapping clocks:
 o Avoid retiming flops
o Improve safety
 But come at the cost of:
o Slower shift rates

SSN flow

 Not supported by SSH

 SSH does not generate non-overlapping EDT/shift clocks
 SSN relies on:
o Packet scheduling
o Time-slot separation
o Local control instead of clock non-overlap

👉 Why not supported?

Because SSN manages timing through packet alignment and local FSM control, not
clock phasing tricks.

✅ Key Takeaway from This Flow

Traditional hierarchical DFT:

 Flexible
 Some features optional
 Works well for medium designs

SSN-based DFT:

 More structured
 Some features become mandatory
 Designed for large, scalable, tile-based SoCs

SSN shifts complexity from wiring and clocks into architecture and control—
hence the stronger requirements.
✅ One-Line Summary (Perfect for PPT)

This flow comparison shows that SSN requires tighter integration of IJTAG, OCC, and DFT
specifications to enable scalable, clock-independent, packet-based scan testing, unlike
traditional hierarchical scan flows where many of these elements are optional.

If you want, I can:

 ✅ Convert this explanation into speaker notes

 ✅ Add real design examples per row
 ✅ Create interview questions from this table
 ✅ Draw flow diagrams for traditional vs SSN

Just tell me 👍

Yes — this image is explaining how test bandwidth is used over time and why
SSN (with iterative optimization) is better than traditional linear/core-by-core
testing.
I’ll explain it from the image itself, step-by-step, and then connect it to SSN
behavior.
🔍 What the image shows (first, read the
picture correctly)
The image has two horizontal bars, both plotted against Test Time (x-axis).

Top bar:

“Bandwidth / Core – Linear Bottom-up”

Bottom bar:

“Bandwidth / Core – Iterative Optimizations (Best Test Time)”

On the right side:

 Top bar shows “Bandwidth Wasted”

 Bottom bar shows “Test Time Saved”

So the picture is comparing two test strategies.

✅ Case-1: Linear Bottom-Up Testing

(Traditional Scan / EDT)
What “Linear Bottom-Up” means

 Cores are tested one after another

 Or bandwidth is statically allocated
 Each core gets a fixed slice of bandwidth
 Other bandwidth stays unused

What happens in the top bar

 Blue region = actual useful test

 Light blue region = bandwidth wasted
 Green region = idle time / waiting

📌 Key problem shown

Even though bandwidth is available, it is NOT fully utilized.

Why bandwidth is wasted here

1. Each core has different scan needs

o Some cores finish early
o Some cores need more data
2. Fixed allocation means:
o Finished cores leave bandwidth unused
o Other cores cannot borrow it
3. Testing happens sequentially, not in parallel

👉 Result:

 Longer test time

 Poor ATE utilization
 Higher test cost

✅ Case-2: Iterative Optimization (SSN-Style

Testing)
What “Iterative Optimization” means

 Cores are tested in parallel

 Bandwidth is shared dynamically
 Allocation changes during the test
 SSH/SSN reallocates bandwidth continuously

What happens in the bottom bar

 Most of the bar is useful work

 Very little wasted bandwidth
 Test finishes earlier

📌 Key benefit shown

Same total bandwidth, but much less test time.

✅ Why SSN enables the bottom case
(IMPORTANT)
This bottom case is not possible with traditional scan.

SSN enables this because:

 All cores connect to a shared SSN bus

 Bandwidth is not fixed per core
 SSH schedules packets dynamically
 Idle cores release bandwidth automatically

Example:

 Core-A finishes early → bandwidth freed

 Core-B and Core-C immediately get more bandwidth
 No waiting, no idle time

✅ How this relates to SSN architecture

Traditional scan / EDT

ATE → Fixed wires → Core A

ATE → Fixed wires → Core B

 Bandwidth is hard-wired
 No sharing

SSN

ATE → SSN Bus → Core A

→ Core B
→ Core C

 Bandwidth is packet-scheduled
 SSH manages who gets how much, when
✅ Why this matters in real SoCs
In large SoCs:

 Hundreds of cores
 Different scan sizes
 Different test modes
 Power limits

If you use linear testing:

 Test time explodes

 ATE cost increases

With SSN:

 Test time minimized

 Power controlled
 Bandwidth fully utilized

✅ Simple explanation for juniors (use this!)

The top picture shows traditional testing where bandwidth is fixed and wasted when a
core finishes early.
The bottom picture shows SSN testing where bandwidth is shared dynamically, so no
bandwidth is wasted and test finishes faster.

✅ One-line interview explanation

This figure shows that traditional linear testing wastes scan bandwidth due to fixed
allocation, while SSN uses iterative bandwidth sharing to maximize utilization and
reduce overall test time.

✅ Key takeaway (remember this)

 Same bandwidth
  Different usage
 SSN = smarter scheduling
 Result = shorter test time

If you want, I can: ✅ Add numbers to this example

✅ Explain how SSH schedules bandwidth
✅ Map this figure directly to Tessent SSN logs
✅ Turn this explanation into PPT speaker notes

Just tell me 👍
SSN datapackets
EDT
 SSN does not stream raw scan bits
 It streams packets that represent scan payload
 Payload may be:

 EDT compressed data

 Chain test data
 Continuity patterns
 Manufacturing patterns