presentation

Design and development of an all-digital
testing system for static RAM based on
Xilinx™ Spartan-3 FPGA
Advisor: Dott. Marcello DeMatteis
Co-Advisor: Prof. Andrea Baschirotto
Co-Advisor: Dott. Cristiano Calligaro
Università degli Studi di Milano-Bicocca
Dipartimento di Informatica, Sistemistica e Comunicazione
Corso di Laurea Magistrale in Informatica
Master’s thesis presentation by
Luca Terrazzan
738846

Index
 Introduction
 System Components
 Algorithms
 System Design
 Experimental Results
 Conclusions

Introduction
In aerospace applications electronic devices are constantly placed
in a hostile environment, leading to a number of negative effects
generated from the exposure to charged particles that may
negatively affect the desired component behavior.
Such effects might cause temporary or permanent damage to
integrated circuits:
 SEU – Single Event Upset
 MBU – Multiple Bit Upset
 …

Introduction
IC might also present different intrinsic errors, generating several
undesired effects:
 Stuck-at faults
 Address decoder faults
 . . .
For this reasons a testing system is required in order to verify
memory behaviour under both nominal and radioactive
conditions before its deployment or commercial production.

Overview

Static Memory
The developed system tested memories are RedCat Devices RC7C4096MCT
and RC7C4096MCX Multi-Chip Modules, each integrating four
RC7C1024RHST and RC7C1024RHSX static RAM respectively.
RC7C4096MC are still in pre-commercial development stages, thus being
ideal test subjects.
RC7C1024RHST
Process CMOS 180nm 6 metals
Die Area 3,944x5,18 mm
VDD (IO) 3.3V
VDD (core) 1.8V
TID >300Krad(Si)
Foundry TowerJazz
RC7C1024RHSX
Process CMOS 180nm 6 metals
Die Area 3,944x5,18 mm
VDD (IO) 3.3V
VDD (core) 1.8V
TID >300Krad(Si)
Foundry X-Fab

Memory Signals
Signal Width Descr
Chip Enable (CE) 1 Enable Chip operations
Write Enable (WE) 1 Enable writing
Output Enable (OE) 1 Enable Reading
Address Bus (A) 17 8 MSB = column, 9 LSB = row
Data Bus (Q) 8 Stores data to read or write
RC7C1024RHS has 512 x 256 positions, each containing 8 bits
and thus storing 512 x 256 x 8 = 1 Mb of information.

Multi-Chip Module
The RC7C4096MC integrates four
SRAM in the same package, but is
used as a single IC.
CE and Data Buses are separated for
each die, but other control signals
are the same for all four integrated
chips.
As a result, the RC7C4096MC
stores up to 4 Mb of information.
RC7C1024RHST RC7C4096MCT
RC7C1024RHSX RC7C4096MCX

Integration Board – XEM3001
XEM3001
Producer Opal Kelly
Gate Count 400 000
Clock 1- 50Mhz
Interface USB 2.0 A
FPGA Xilinx Spartan-3
LEDs 8
Buttons 4

GUI
Developed withVB based interface, used for:
• Issuing algorithms to FPGA along with input parameters
• Gather algorithms results from FPGA (log file)
• Display result data

Communication API
Software communications to the integration board are possible
through a dedicated Opal Kelly C library.
This library has the appropriate functions to interact with the
USB module three primitives:
• Wires: used for the single transfer of a 16bits data bus
• Pipes: used to stream errors data from FPGA to aVB vector
• Triggers: used to signal specific events, like algorithms ends,
stream end signal, etc...
Each of these must be first declared through HDL code during
the FPGA programming.

Algorithms
Three different algorithms: two for standard write and read
procedures (used mainly in test under irradiation) and one for
full memory scan (called march test, used mainly in electrical
tests).
Write
• Write a
pattern on
the memory
Read
• Check
memory
content
• Detect
errors
• Save log file
MarchTest
• Full memory
scan
• Detect
intrinsic
faults
• Save log file

Pattern
Standard write procedure works with an input pattern.A pattern is made by
two bytes, which are written alternated on every memory position:
The AA-55 (or 55-AA) is a common
pattern called checkerboard.
With patterns, the user can specify
the data to write on selected
memory region. But is also used to
compare read data in read
algorithm.

Log File
Text file containing each found error. Every row stores
information about a single error entry, saving its position and the
XOR operation between the written and read data.
Error position Pattern XOR read data

Error size
 Each die has 217 locations
 Each Error Entry needs 25 = 17 (address) + 8(XOR) bits
In worst case scenario (e.g. 217 errors) …
217 x 25 = 400KB (432KB for march test)
too much for FPGA registers!
(plus 2 extra bits for march test entries)
Errors are stored into the FPGA internal RAM (called XRAM). Each time a
error is read, its data is saved into the XRAM until full capacity is reached;
once that happens, the algorithm halts and wait for XRAM data to be
streamed to PC before resuming operations.

FPGA RAM (XRAM)
XRAM
Capacity 16Kb
Ports 2
Word size 32 bits
Maximum Errors 512
The XRAM is a dual-port static RAM, with
word size of 32 bits. Since an error entry
needs 25(or 27) bits, it fits into a XRAM
word with a waste of 7 (or 5) bits per error
entry.
This way up to 512 errors can be stored.
After that, the XRAM data needs to be
downloaded to PC before saving any other
entry.

March Test
 Scan all memory address in both ascending and descending order
 Each address is checked for faults
 Several state-of-the-art march tests, each with a specific sequence of
actions
 Actions syntax:
Ascending addressing Descending addressing
Either ascending or
descending addressing
W0 , W1 : write 0 or 1 at the current
address
R0 , R1 : check for 0 or 1 at the
current address

MATS++
 MATS++ (Modified AlgorithmTest Sequence) is the chosen march test
implementation
 It is capable of detecting Stuck-at Faults (SAF),Transition Faults (TF) and
Address Decoder Faults (AF)
Its definition is:
W0 R0W1 R1W0 R0
Faults are detected in three possible phases, knowing which phase generated
the error entry is fundamental to understand how the fault generated.
MATS++ log files error entries store two extra bits to indicate the phase.

Log File Visualization
Log files are visualized displaying a scaled graphic
representation of the memory. Here errors are drawn
based on the Log File type:
 For read algorithm log files, memory content is drawn on
the display area.While highlighting eventual errors in
green.

Log File Visualization
 For march test log files, only error entries locations are drawn.
Each with a specific colour based on the MATS++ phase (or
phases) which detected a fault in that location.
No error Phase 1 Phase 2 Phase 3
Phase 1+2 Phase 1+3 Phase 2+3 Phase 1+2+3

System Design
SRAM
XEM3001
PC
PLL USB
Jumper
Spartan-3
FSM
Clock
mana
ger
XRAM
manager

System Design
SRAM
XEM3001
PC
PLL USB
Spartan-3
FSM logic
Clock
manager
XRAM
manager
Control
Selector
J
GUI
XRAM

FPGA Programming
Red modules have been designed and implemented through
HDL(Verilog) code (except for GUI).
HDL defines FPGA behaviour by altering its internal circuit
configuration FPGA is not a microcontroller!
FPGA manages both algorithm logic and communications.

FSM Logic
Contains the FSMs that implement every algorithm logic.Write and read algorithms
are simple FSM that cycle through memory positions.
Write FSM simply goes through every address of the specified region, while selecting
pattern byte in the same state as the address increase.

FSM Logic
The read FSM behave similarly to write, but incorporating three states for XRAM
buffering whenever an error is found.
When the XRAM is full, the whole algorithm is stopped until a PC trigger is received.

FSM Logic
The FSM implementing MATS++ algorithm is made to reflect its definition.The first step (the
writing of 0 in all memory cells) is carried out with a standard write before starting the march
test.
Each read operation actually incorporates the three-state XRAM buffering, while also providing
the current phase to the error entry.

XRAM Manager
The XRAM manager module is used to download XRAM data to PC when full
capacity has been reached.
It is synchronized with the USB clock, since it has to communicate with PC.
When the trigger is off, the
current XRAM address is reset.
When the XRAM is full, the PC
software activates xram_trigger,
thus starting the download
procedure: at each clock cycle
the current address is increased,
and its content is sent through
the pipe_data bus.

Clock Manager and Control Selector
The Clock Manager receives the PLL clock directly from
the XEM3001, it then divides it before feeding it to the main
FSM module.
The Control Selector module manage the different control
signals and provides them to the SRAM according to user’s
inputs. It uses an undivided clock from the Clock Manager
in order to set each cotnrol signal between each main FSM
clock cycle.

Index
 Introduction
 System Components
 System Design
 Experimental Results
 Conclusions

Radiation Test
Tests under radioactive
exposure were made at the
University of Palermo. Here
the memory has been
exposed to gamma rays
from a Cobalt-60 source.
The XEM3001 – and
therefore the FPGA – was
protected in a lead
container, while also
shielding cables where
possible. PC was located in
an adjacent protected
room.

Radiation Tests
Radiation test applied repeated write-read standard algorithms,
usually alternating AA-55 and 55-AA patterns.
This allows for every memory cell to assume both logic values at
least one time while also preserving the checkerboard pattern.
Random behaviour have been noted when certain write-read
operation were issued. However, since we could not directly
observe every system components during tests execution, it was
impossible to determine whether the cause was a testing sytem
defect or gamma rays infiltration beneath the shield.
Tests are still ongoing for RC7C4096MCX and RC7C4096MCT
Multi-Chip Module devices.

March Test
MATS++ was executed on different RC7C4096MC devices,
although – at the current moment – still a small number of
tests have been performed to verify its results.
MarchTests are still ongoing and are being developed for
other kinds of SRAM (whose functioning have already been
tested) in order to ascertain the correctness of MATS++
results.

March Test
March Test produced different error entries for different chips.
However, as mentioned before, their significance is still to be proved
with further development and implementations on other devices.
Additional validation processes may include MATS++ algorithm
variations or different components set-up and environment.

Conclusions
We developed a functioning testing system through FPGA
and software programming – while at the same time
implementing their communications – which was sucessfully
deployed on actual in-development SRAM.
While all tests are still undergoing development, the
proposed design performed different tasks as expected,
even though its results will have to be further validated
through additional testing and confrontations.

Future Developments
 MATS++ implementation for different devices (like single
RC7C1024 SRAM)
 Digitally controlled Power Supply
 Higher frequence tests
 New MarchTest versions to detect other fault types

presentation

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to presentation

Similar to presentation (20)

presentation