The design of a CMOS sensor camera system for a nanosatellite /

UNIVERSITEIT•STELLENBOSCH•UNIVERSITY
jou kennisvennoot
•
your knowledge partner
The Design of a CMOS Sensor Camera System
for a Nanosatellite
by
Eric Albert Baker
Thesis presented in partial fullment of the requirements for
the degree of Master of Electronic Engineering with
Computer Science at the University of Stellenbosch
Department of Electric and Electronic Engineering
University of Stellenbosch
Private Bag X1, 7602 Matieland, South Africa
Supervisor: Prof P.J. Bakkes
October 2006
Declaration
I, the undersigned, hereby declare that the work contained in this thesis is my own
original work and that I have not previously in its entirety or in part submitted it
at any university for a degree.
Signature: . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
E.A.
Baker
Date: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
i
Abstract
The Design of a CMOS Sensor Camera System
for a Nanosatellite
E.A.
Baker
Department of Electric and Electronic Engineering
University of Stellenbosch
Private Bag X1, 7602 Matieland, South Africa
Thesis: MScEng (Electric and Electronic with Computer Science)
October 2006
This thesis relates to the design of a camera system for a nanosatellite based on
a CMOS image sensor.
The design specications and constraints are considered
followed by the proposal of a versatile design with all the required functions implemented on a single FPGA. These functions include bad block management, data
routing, an EDAC, a soft-core processor, glue logic to external devices, and communication busses.
The Altera Nios II soft-core processor is implemented in this design, which enables simple changes to be made in software. A good mixture of intellectual property soft-cores, open-source cores, and user created logic are utilised in this broad
base design, containing a combination of hardware, digital logic, and software.
Low power and compact devices are selected for this design to minimize the
power usage and the physical size of the camera system. The system's peak power
consumption is
952mW
which is below the required maximum consumption of
1W .
This design's performance is therefore ideal for a subsystem onboard a nanosatellite.
ii
Uittreksel
Die Ontwerp van 'n CMOS Sensor Kamerastelsel
vir 'n Nanosatelliet
(The Design of a CMOS Sensor Camera System
for a Nanosatellite)
E.A.
Baker
Departement Elektries en Elektroniese Ingenieurswese
Universiteit van Stellenbosch
Privaatsak X1, 7602 Matieland, Suid Afrika
Tesis: MScIng (Elektries en Elektronies met Rekenaarwetenskap)
Oktober 2006
Hierdie tesis handel oor die ontwerp van 'n kamerastelsel vir 'n nanosatelliet gebaseer op 'n CMOS beeld sensor.
Die ontwerp spesikasies en beperkings word
ondersoek, gevolg deur die voorstel van 'n buigbare ontwerp wat al die verlangde
funksies implementeer op 'n enkele FPGA. Hierdie funksies behels die bestuur van
defektiewe geheuesegmente, data verskuiwing, foutopsporing en -herstel, 'n sagtekern verwerker, verbindingslogika na eksterne toestelle en kommunikasie busse.
Die Altera Nios II sagte-kern verwerker is toegepas in hierdie ontwerp, wat
toelaat dat eenvoudige veranderinge in sagteware aangebring kan word. 'n Goeie
versameling van intellektuele eiendom sagte-kerne, oopgestelde bronkode kerne en
gebruiker-geskepte logika word gebruik in hierdie omvattende ontwerp wat bestaan
uit 'n kombinasie van hardeware, digitale logika en sagteware.
Lae kragverbruik- en kompakte komponente word vir hierdie ontwerp gekies om
kragverbruik en die siese grootte van die kamerastelsel te minimeer. Die stelsel se
iii
iv
UITTREKSEL
piek kragverbruik is
van
952mW
wat minder is as die verlangde maksimum kragverbruik
1W .
Die ontwerp se werkverrigting is dus ideaal vir 'n substelsel aan boord van 'n
nanosatelliet.
Acknowledgements
I would like to express my sincere gratitude to the following people:
ˆ
Professor P.J. Bakkes (thesis supervisor) for his support and interest in the
project,
ˆ
Johan Grobbelaar for the PCB layout,
ˆ
Liza Baker and Johan Schoonwinkel for taking time out of their busy schedules
to proof read this document,
ˆ
Johannes, Janto and Gerrit who were always willing to give advice.
v
Dedications
Hierdie tesis word opgedra aan my familie,
vir hulle ondersteuning, liefde en gebede.
vi
Contents
Declaration
i
Abstract
ii
Uittreksel
iii
Acknowledgements
v
Dedications
vi
Contents
vii
List of Figures
x
List of Tables
xii
List of Abbreviations and Symbols
xiii
1 Introduction
1
1.1
Aims and Objectives
. . . . . . . . . . . . . . . . . . . . . . . . . .
2
1.2
The Rest of the Document . . . . . . . . . . . . . . . . . . . . . . .
3
2 Background
5
2.1
Nanosatellites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2.2
Kodak KAC-1310 CMOS Image Sensor . . . . . . . . . . . . . . . .
7
2.3
NAND Flash Memory
. . . . . . . . . . . . . . . . . . . . . . . . .
11
2.4
Altera Nios II . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
2.5
Communication Methods . . . . . . . . . . . . . . . . . . . . . . . .
18
vii
viii
CONTENTS
3 Design Specications
3.1
22
Design Constraints
. . . . . . . . . . . . . . . . . . . . . . . . . . .
4 System Design Overview
4.1
FPGA Considerations
4.2
VHDL Design Overview
4.3
23
32
. . . . . . . . . . . . . . . . . . . . . . . . .
32
. . . . . . . . . . . . . . . . . . . . . . . .
34
Design Implementation Changes . . . . . . . . . . . . . . . . . . . .
45
5 Detailed System Design
46
5.1
VHDL Design Detail
. . . . . . . . . . . . . . . . . . . . . . . . . .
46
5.2
Nios II and Components Design . . . . . . . . . . . . . . . . . . . .
58
5.3
Hardware Design
67
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
6 Simulations and Results
77
6.1
VHDL Simulations
. . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2
Nios II Simulations and Measurements
6.3
Kodak KAC-1310 Interfacing
6.4
Demonstration Board Testing and Measurements
6.5
Work in progress
77
. . . . . . . . . . . . . . . .
89
. . . . . . . . . . . . . . . . . . . . .
90
. . . . . . . . . .
93
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
95
7 Conclusions and Recommendations
96
7.1
Conclusions
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
96
7.2
Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . .
98
List of References
99
Appendices
102
A Kodak KAC-1310 Datasheet
103
B Samsung K9K4G08U0M Datasheet
105
C imageexporter_regs.h
107
D image_exporter_avalon_interface.vhd
109
E cmosimager.c
114
ix
CONTENTS
F Demonstration Board Schematics
117
G Power Regulators
123
G.1
National Semiconductor LM2651
. . . . . . . . . . . . . . . . . . .
123
G.2
ST LF25CPT
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
123
G.3
Texas Instuments SN105125
. . . . . . . . . . . . . . . . . . . . . .
123
List of Figures
1.1
Block Diagram of a possible Nanosatellite
2.1
Block Diagram of a Proposed Camera Design
. . . . . . . . . . . . . .
6
2.2
Bayer RGB Pattern CFA . . . . . . . . . . . . . . . . . . . . . . . . . .
9
2.3
Bayer CMY Pattern CFA
. . . . . . . . . . . . . . . . . . . . . . . . .
9
2.4
Samsung K9K4G08U0M Memory Array Organisation . . . . . . . . . .
12
2.5
Write Data & Read Status Operation . . . . . . . . . . . . . . . . . . .
13
2.6
Read Data Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
2.7
Block Erase Operation . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
2.8
Example of a Nios II Processor System . . . . . . . . . . . . . . . . . .
16
3.1
Single Frame Capture Mode (SFRS)
. . . . . . . . . . . . . . . . . . .
23
3.2
Default Row Sync Waveforms
. . . . . . . . . . . . . . . . . . . . . . .
25
3.3
NAND ash page write sequence
. . . . . . . . . . . . . . . . . . . . .
27
4.1
System Block Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
4.2
Dual Clock FIFO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
4.3
Data Router with EDAC Block Diagram . . . . . . . . . . . . . . . . .
37
4.4
NAND Flash Memory Interface Block Diagram
. . . . . . . . . . . . .
38
4.5
An Example of the proposed Bad Block Table organisation . . . . . . .
39
4.6
Bad Block Table & Address Manager Block Diagram
. . . . . . . . . .
41
5.1
Bad Block Table & Address Manager Flow Chart
. . . . . . . . . . . .
48
5.2
Valid Block Address Generation Flow Chart . . . . . . . . . . . . . . .
51
5.3
The Nios II based camera system in SOPC Builder
. . . . . . . . . . .
60
5.4
Nios II system integrating an EPCS Controller . . . . . . . . . . . . . .
61
5.5
I C Module's Avalon slave timing conguration
2
x
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . .
2
65
LIST OF FIGURES
xi
5.6
CMOS Image Sensor Interface's Avalon slave timing conguration . . .
66
5.7
Image Exporter's Avalon slave timing conguration
. . . . . . . . . . .
67
5.8
JTAG Indirect Conguration Device Programming
. . . . . . . . . . .
68
5.9
Termination Scheme on Cyclone II LVDS Transmitter . . . . . . . . . .
71
5.10 Altera MegaWizard generated PLL with Locked signal output . . . . .
72
5.11 Design routing and layout - Top layer . . . . . . . . . . . . . . . . . . .
76
5.12 Design routing and layout - Bottom layer . . . . . . . . . . . . . . . . .
76
6.1
Load Bad Block Table Waveforms, Segment 1
. . . . . . . . . . . . . .
79
6.2
Load Bad Block Table Waveforms, Segment 2
. . . . . . . . . . . . . .
80
6.3
Block Diagram of Image Exporter with Simulation signal names . . . .
81
6.4
Store Bad Block Table Waveforms, Segment 1 . . . . . . . . . . . . . .
83
6.5
Store Bad Block Table Waveforms, Segment 2 . . . . . . . . . . . . . .
84
6.6
Store Bad Block Table Waveforms, Segment 3 . . . . . . . . . . . . . .
85
6.7
Store Bad Block Table Waveforms, Segment 4 . . . . . . . . . . . . . .
86
6.8
Erase All Sequence Waveform . . . . . . . . . . . . . . . . . . . . . . .
88
6.9
Avalon access times to CMOS Image Sensor Interface Module
91
. . . . .
6.10 Sub-sampled photo taken with the camera system (160×100 pixels)
. .
92
A.1
Kodak KAC-1310 CMOS Image Sensor Datasheet, Page 5
. . . . . . .
104
B.1
Samsung K9K4G08U0M NAND Flash Datasheet, Page 2 . . . . . . . .
106
F.1
Design Schematic Page 1 . . . . . . . . . . . . . . . . . . . . . . . . . .
118
F.2
Design Schematic Page 2 . . . . . . . . . . . . . . . . . . . . . . . . . .
119
F.3
Design Schematic Page 3 . . . . . . . . . . . . . . . . . . . . . . . . . .
120
F.4
Design Schematic Page 4 . . . . . . . . . . . . . . . . . . . . . . . . . .
121
F.5
Design Schematic Page 5 . . . . . . . . . . . . . . . . . . . . . . . . . .
122
G.1
National Semiconductor LM2651 Datasheet, Page 1 . . . . . . . . . . .
124
G.2
ST LF25CPT Datasheet, Page 1
. . . . . . . . . . . . . . . . . . . . .
125
G.3
Texas Instruments SN105125 Datasheet, Page 1 . . . . . . . . . . . . .
126
List of Tables
2.1
Bus state with two nodes transmitting simultaneously . . . . . . . . . .
21
3.1
Readout Times compared to MCLK
. . . . . . . . . . . . . . . . . . .
24
3.2
Data Rates compared to MCLK . . . . . . . . . . . . . . . . . . . . . .
25
3.3
NAND Flash Burst and Continuous Write Data Rates
. . . . . . . . .
27
5.1
Nios II Processor Conguration
. . . . . . . . . . . . . . . . . . . . . .
59
xii
List of Abbreviations and Symbols
µs
microsecond
ms
millisecond
ns
nanoseconds
A
Ampere, SI-unit for electric current
ADC
Analogue to Digital Converter
ALE
Address Latch Enable signal
ANSI C
American National Standards Institute C programming language
API
Application Program Interface
AS
Active Serial
ASDI
AS Data Input
ASIC
Application Specic IC
AWB
Auto White Balance
BGA
Ball-Grid Array
CAN
Controller Area Network
CFA
Colour Filter Array
CISC
Complex Instruction Set Computer
CLK
Clock
CMOS
Complementary Metal Oxide Semiconductor
CMY
Cyan, Magenta, Yellow
CPU
Central Processing Unit
CSMA/BA
DCLK
Carrier Sense Multiple Access/Bitwise Arbitration
Data Clock
xiii
LIST OF ABBREVIATIONS AND SYMBOLS
DMIPS
Dhrystone MIPS
DPGA
Digitally Programmable Ampliers
ECC
Error Checking and Correcting
EDAC
Error Detection and Correction
EEPROM
EPCS
Electrically Erasable Programmable Read Only Memory
Altera family signature on a part number that refers to serial conguration devices.
EPROM
Erasable Programmable Read Only Memory
ESL
Electronic Systems Laboratory
FFT
Fast Fourier Transform
FIFO
First-in First-out
FPGA
Field Programmable Gate Array
HAL
Hardware Abstraction Layer
HCLK
Horizontal Clock
HDL
Hardware Description Language
Hz
Hertz = per second
2
xiv
I C
Inter-Integrated Circuit
IC
Integrated Circuit
IDE
Integrated Development Environment
IP
Intellectual Property
JTAG
Joint Test Action Group
k
kilo =
LED
Light Emitting Diode
LEO
Low Earth Orbit
LSB
Least Signicant Bit
M
Mega =
Mb
Megabit
MB
Megabyte
MCLK
Master Clock
103
106
LIST OF ABBREVIATIONS AND SYMBOLS
xv
MHz
Mega Hertz
MIPS
Million Instructions per Second
MMU
Mass Memory Unit
MSB
Most Signicant Bit
MSEL
Mode Select
NAND
Not AND logic operation
OBC
On-Board Computer
OR
A Boolean logic operation that is true if any of the inputs are true.
PC
Personal Computer
PCB
Printed Circuit Board
PLL
Phase Locked Loop
QFP
Quad Flat Pack
RAM
Random Access Memory
RE
Read Enable signal
RF
Radio Frequency
RGB
Red, Green, Blue
RISC
Reduced Instruction Set Computer
ROM
Read Only Memory
SCL
Serial Clock signal
SDA
Serial Data signal
SERDES
Serializer/Deserializer
SOF
Start Of Frame
SOPC
System On a Programmable Chip
SRAM
Static RAM
SUNSAT-1
Stellenbosch UNiversity's 1st SATellite
SXGA
Super Extended Graphics Array
UART
Universal Asynchronous Receiver Transmitter
V
Volt
VCLK
Vertical Clock
LIST OF ABBREVIATIONS AND SYMBOLS
VHDL
VHSIC Hardware Description Language
VHSIC
Very High-Speed Integrated Circuit
VTU
Video Data Transmission Link
XOR
Exclusive OR
xvi
Chapter 1
Introduction
The Electrical and Electronic Engineering department at Stellenbosch University
has been designing and building low earth orbit (LEO) satellites since 1991. The
rst satellite, SUNSAT-1 (Stellenbosch University Satellite), was launched in 1999.
This was also South Africa's rst satellite.
The Electronic Systems Laboratory (ESL) was established to serve as a facility
where SUNSAT-1 could be designed and built, and also for continuing satellite
research. Following the success of the rst satellite, engineers at Stellenbosch have
been involved with designing new satellites and doing further research.
Currently post-graduate engineers at Stellenbosch University are developing a nanosatellite. The main purpose of the nanosatellite project is to train engineers using
practical experience by facilitating their involvement in an elite and exhilarating
real-world application.
Nanosatellite missions have the advantage that state-of-the-art instruments can be
tested since these satellites are manufactured on a short time scale and at low cost.
This is not only ideal for science but also for instrument testing and education.
Designing a new, small and low power camera system for the nanosatellite ts
perfectly into this scenario.
1
CHAPTER 1.
1.1
INTRODUCTION
2
Aims and Objectives
The main objective of this thesis is to design a small, low power camera system
for a nanosatellite. Figure 1.1 shows a possible subsystem conguration onboard a
nanosatellite and illustrates the integration of a camera into the satellite system.
The camera system communicates with the On-board Computer (OBC) via the
Figure 1.1:
Block Diagram of a possible Nanosatellite
CAN bus. Images are stored in the Mass Memory unit (MMU) and downloaded to
the Video Data Transmission (VTU) Modem with a LVDS connection. The VTU
Modem transmits the images to the ground station with a RF link.
CHAPTER 1.
INTRODUCTION
3
A Kodak KAC-1310 Image Sensor is supplied to be integrated into this camera
system.
This project will concentrate on acquiring images from this sensor and
storing them in a suitable mass memory. Versatility and upgradeability will be a
key concern of the design as the nal specications and requirements for the camera
are uncertain at the time of design.
This camera system is not intended as a fully functional prototype, but as a demonstration of the small size, power usage and versatility of the camera design. These
factors are considered in all design decisions of the thesis.
1.2
The Rest of the Document
Chapter 2 briey discusses the concept of a nanosatellite and why a CMOS image sensor is well suited for a camera application onboard a nanosatellite.
The
KAC-1310 CMOS Image Sensor is then discussed in more detail and various interpolation algorithms are mentioned. This is followed by an explanation on the basic
operations of NAND ash memory. The concept of invalid blocks in these devices
is also introduced. The Altera Nios II is discussed giving a brief overview of what
soft-core processors entail. Finally, this chapter concludes by briey giving some
background information on communication protocols used in the design.
Chapter 3 looks more closely at the design specications and investigates the various
design constraints. Preliminary calculations on data rate requirements are made
and problems associated with designing components for nanosatellites are discussed.
In Chapter 4, important design decisions are made and a proposed architecture
for the nal design is given. The selection of a FPGA is argued and the intended
functionality of each VHDL component is explained. Changes to the initial design
requirements are also addressed.
Chapter 5 looks in detail at the VHDL design for the demonstration camera. The
hardware design and implementation is discussed and an embedded soft-core processor is congured.
CHAPTER 1.
INTRODUCTION
Chapter 6 shows the results and simulations for the system design.
4
The VHDL
system design is simulated before the PCB is built. The PCB is built and checked
and minor mistakes are discussed. A power analysis of the board and a discussion
on work in progress concludes the chapter.
Chapter 7 is the nal chapter of the thesis with conclusions that were drawn from
the project. Proposals for future studies and suggestions to improve the design are
given.
Chapter 2
Background
2.1
Nanosatellites
A nanosatellite is dened as a satellite weighing in the range of 1kg and 10kg.
Smaller and lighter nanosatellites require smaller and cheaper launch vehicles and
are occasionally launched in multiples. They can also be piggyback launched, using
excess capacity on larger launch vehicles.
Furthermore, since the overall cost risk in the mission is much lower, more up to
date but less space proven technology can be incorporated into nanosatellites than
can be used in larger, more expensive missions.
2.1.1 Application signicance
Cost is not the only reason for the use of miniaturised satellites.
Miniaturised
satellites can accomplish missions that larger satellites are unsuitable for, such as:
ˆ
Constellations for low data rate communications,
ˆ
Using formations to gather data from multiple points,
5
CHAPTER 2.
BACKGROUND
ˆ
In-orbit inspection of larger satellites, and
ˆ
Experimenting with new, less space proven technology.
6
2.1.2 Power & Physical constraints
The smaller dimensions of a nanosatellite infer less area for solar panels and thus
less power is generated for the satellite to operate from. Therefore, any component
used on the nanosatellite must be extra small and use power conservatively. Various
methods of reducing power consumption exist. A widely used method to reduce the
average power consumption is duty cycling of all components not requiring constant
power [1]. Another simple method is to slow down operating clock frequencies on
the satellite's subsystems.
The use of low power devices also aids in reducing power usage. Subsystems like
cameras, see Figure 2.1, can use CMOS Image sensors. These sensors use low power
and virtually no external components are needed. Research done at the ESL [2][3]
suggests using NAND ash memory for the mass memory unit. NAND ash is a
non-volatile, high-density memory, which uses very low power and is manufactured
in small, lightweight packages.
Figure 2.1:
Block Diagram of a Proposed Camera Design
CHAPTER 2.
2.2
7
BACKGROUND
Kodak KAC-1310 CMOS Image Sensor
2.2.1 Device Description
The Kodak KAC-1310 is a SXGA format pixel array, solid state CMOS sensor, with
1280x1024 active elements. The pixels have a
6.0µm pitch.
The pinned photodiode
architecture utilized in the pixels ensures high sensitivity and low noise.
The complete analogue image acquisition, digitising, and digital signal processing
of the image is integrated on the device. A 10-bit ADC converts the analogue data
to a 10 bit digital word stream.
A monochrome version image sensor without microlenses is available, but to further
enhance sensitivity an image sensor with Bayer (RGB or CMY) patterned Colour
Filter Array (CFA) microlenses can be used. See Figure 2.2 and Figure 2.3. Auto
White Balance (AWB) as well as exposure gain adjustment can be corrected in real
time with Digitally Programmable Ampliers (DPGAs).
Integrated timing and programming controls allow video or still image capture in
progressive scan modes. A progressive scan camera processes all the lines in order,
row by row, thus no interlacing of lines takes place. Frame rates are programmable
while keeping the Master Clock (MCLK) frequency constant. The sensor outputs
the valid frame, line, and pixel synchronisation signals needed to capture the images.
The image size is fully programmable to a user-dened window of interest (WOI).
Reduced resolution can be obtained by sub-sampling, while still maintaining a
constant eld of view. The eld of view is the part of the observable world that is
seen at any given moment.
2
The sensor is controlled by a two-line I C-compatible serial interface. See Section
2.5.1. The device operates from a single 3.3V power supply and no additional biases
are required. A single Master Clock is necessary for operation. The Master Clock
can range from 1 to 20 MHz.
CHAPTER 2.
8
BACKGROUND
2.2.2 Operation
The KAC-1310 sensor consists of a
1280 × 1024
pixel array.
The fundamental
operation of a pixel relies on the photoelectric eect where a physical property of
silicon allows it to detect photons of light. The photons produce electron-hole pairs
in the silicon, which are directly in proportion to the intensity and wavelength of
the incident illumination. By applying an appropriate bias, the electrons can be
collected and the resulting charge can be measured.
The pixel architecture consists of four transistors, which permit all pixels in a row
to have common Reset, Transfer, and Row Select control signals. These signals are
used to access the pixels.
All the pixels in the device have common supply and
ground connections. This optimized cell architecture allow for a higher ll factor
and improves noise reduction and antiblooming.
The sensor needs a means to measure the dark level oset, which is used downstream in the signal processing chain to perform auto black level calibration. Thus
at the periphery of the imaging section, there are additional pixels called isolation and dark pixels.
The dark pixels are made insensitive to photons because
they are covered by a light blocking shield, while isolation pixels eliminate inexact
measurements, caused by light piping into the dark pixels adjacent to the active
pixels.
The extra isolation pixels at the array's periphery are also useful for some colour
interpolation algorithms.
2.2.3 Image Formats - Bayer Pattern
In practice, there are a number of dierent ways that pixels are arranged in the
matrix array. The RGB Bayer lter, similar to Figure 2.2, is the most common.
The RGB Bayer lter is composed of alternating lters of Red (R) and Green (G)
for odd rows and alternating lters of Green (G) and Blue (B) for even rows.
Another alternative is the CMY Bayer lter illustrated in Figure 2.3, which consists
CHAPTER 2.
9
BACKGROUND
Figure 2.2:
Bayer RGB Pattern CFA [4]
of Cyan (C), Magenta (M) and Yellow (Y) lters. Bayer CMY has the advantage of
a 50% increase in sensitivity [4] over the RGB pattern due to the higher quantum
eciency (QE) and larger wavelength spread per colour. This makes Bayer CMY
a better choice for low light applications.
Figure 2.3:
Bayer CMY Pattern CFA [4]
As each raw pixel of the sensor is behind a colour lter, the output of the sensor is
a mosaic of monochrome pixels in one of the colour components (e.g. intensity in
red, green, or blue). An algorithm is thus needed to estimate the colour levels of
the other colour components of each pixel.
CHAPTER 2.
10
BACKGROUND
2.2.4 Demosaicing algorithms
A demosaicing algorithm is a mathematical process used to interpolate a complete
image from the raw matrix data received from the colour ltered image sensor.
Demosaicing is also known as CFA interpolation or colour reconstruction.
There are various demosaicing methods. Some produce better results for natural
scenes while others are preferred for printed material, which typically has a high
contrast and a limited colour palette.
This shows the inherent diculty in esti-
mating the unknown pixel colours. Naturally, there is also the trade-o between
computational complexity and the quality of estimation.
The following are some demosaicing algorithms:
ˆ
Quick interpolation is a low grade, nearest neighbour replication. This method
simply copies the correct colour component of an adjacent pixel. Quick interpolation is not computational intensive, but is unsuitable for any application
where quality is required.
ˆ
Simple interpolation algorithms are uncomplicated mathematical operations
using only nearby instances of the same colour component. The simplest is
the bilinear interpolation method. In this method, the blue value of a nonblue pixel is computed as the average of the adjacent blue pixels, and similar
for red and green.
Variations of this method include bicubic-, spline- and
laplacian interpolation.
ˆ
Synthetic eld based interpolation algorithms rst compute an alternate representation from which the colour components is then interpolated. Examples
are Hue interpolation and Log hue interpolation.
ˆ
Adaptive algorithms adapt its method of estimation according to characteristics of the area surrounding the relevant pixel.
Various commercial products implement proprietary estimation methods.
Very
little is freely known about these estimation techniques, but it is likely that they
incorporate similar methods as mentioned above.
CHAPTER 2.
2.3
11
BACKGROUND
NAND Flash Memory
Flash memory is a non-volatile memory storage medium, which means that it does
not need power to maintain the information stored on the chip. The name, ash
memory, is derived from the organization, of the microchip, so that a section of
memory cells are erased in a single action or ash.
The erasure is caused by
Fowler-Nordheim tunnel injection during which electrons pierce through a thin
dielectric material to remove an electronic charge from a oating gate associated
with each memory cell. NAND Flash devices have internal charge pumps that are
needed to generate the high voltages for writing and erasing.
2.3.1 Memory Organisation and Interface
The NAND Flash device's main memory array consists of blocks that are divided
into pages. Each page is split up into two sections: the data area and the spare
area.
The spare area is typically used for housekeeping data such as checksum
values.
A practical example of the memory organisation is shown in Figure 2.4.
Note that in this example a page consists of 2112 bytes, 2048 data bytes and 64
spare bytes.
NAND ash devices make use of an indirect interface.
There are no dedicated
address, command, or data lines. Instead, bidirectional I/O lines combined with
some control lines are used. For example, address cycles are multiplexed onto the
I/O lines with the ALE control line high. A similar setup is used for command and
data cycles.
Higher density devices have more address cycles to access greater amount of blocks
or pages. The table in Figure 2.4 shows the format of the ve address cycles needed
to address 4224Mbits (528MB).
Using the indirect interface scheme reduces pin counts and allows for upgrades to
future densities by maintaining consistency in the system board design.
CHAPTER 2.
12
BACKGROUND
Figure 2.4:
Samsung K9K4G08U0M Memory Array Organisation [5]
2.3.2 Operation
2.3.2.1 Writing/Programming
NAND ash is programmed on a page-by-page basis. The programming sequence
is illustrated in Figure 2.5. Serial data loading begins by inputting the Serial Data
Input command (80h), followed by ve cycle address inputs and then the serial
page data. The Page Program Conrm command (10h) initiates the programming
process. The device now goes into a non-volatile programming period where the
loaded data is stored in the appropriate page. The
R/B
control line can be mon-
itored to determine when programming is complete. This delay period,
typically
200µs
but can last up to
tP ROG ,
is
700µs.
The result of the internal write operation (success or failure) can be determined
by issuing the Status Register Output command (70h), reading the status and
inspecting the Write Status Bit (I/O0 ).
CHAPTER 2.
13
BACKGROUND
Figure 2.5:
Write Data & Read Status Operation [5]
2.3.2.2 Reading
The process of reading a page of data is similar to writing a page. This is illustrated
in Figure 2.6. Sequential reading of data is initiated by rst inputting the command
00h and ve address cycles followed by 30h.
A waiting period follows, during which
data is transferred from the main memory array to the internal page register of the
NAND ash device. The data transfer delay,
tR ,
is a maximum of
25µs
[5]. Data
can now be read out sequentially by pulsing the read enable (RE ) line.
Figure 2.6:
Read Data Operation [5]
2.3.2.3 Erasing
The Erase operation is performed on a block-by-block basis and can be accomplished by writing the three address cycles of a specic block to the device. The
address cycles must be preceded by the Erase Setup command (60h) and followed
by the Erase Conrm command (D0h). See Figure 2.7 for a clearer explanation.
The NAND ash device will enter a busy state,
tBERS ,
of typically
2ms
to
3ms
during which the block will be erased.
According to a basic property of NAND ash devices, a write operation can only
change a stored bit from a logic 1 to a logic 0. The erase operation is thus required
CHAPTER 2.
14
BACKGROUND
Figure 2.7:
Block Erase Operation [5]]
to change the stored bit from a logic 0 to a logic 1. Therefore, it is critical that the
entire block in which a page resides is erased before the page can be written.
2.3.3 Bad Blocks
NAND ash memory was designed to serve as a low cost solid-state mass storage.
To obtain a bigger production yield the existence of initial bad blocks up to a
certain percentage is permissible. This lowers production costs.
Valid blocks have the same quality level and bad blocks do not aect the performance of the valid blocks.
Initial bad blocks are marked by the supplier during
extensive environmental and functional testing. The system design must mask out
the bad blocks with address mapping techniques, as the marked bad blocks' reliability is not guaranteed by the manufacturer. The manufacturer guarantees that
the rst block, placed at
00h,
is a valid block.
Blocks have a limited write/erase capability. Each block can be erased or reprogrammed from 100,000 times to 1,000,000 times and therefore more bad blocks will
occur during the lifetime of the device.
According to [3], the primary wear out
mechanism is believed to be excess charge trapped in the oxide of a memory cell,
and the net eect is that the erase times increase until an internal timer times out.
This error is then reported back to the system controller through the reading of
the status register.
A reference table of the bad blocks needs to be kept to insure that no bad blocks
are accessed again.
CHAPTER 2.
2.4
15
BACKGROUND
Altera Nios II
2.4.1 Introduction to the Nios II
The Nios II is a soft-core embedded processor from Altera. A soft processor is a
processor created out of the congurable logic in an FPGA.
The Nios II is designed to be exible, giving the user control of a number of features
such as the cache sizes, interfaces, and execution units.
In addition, hardware
support for certain operations, such as multiplication and division can be added or
removed. The congurability allows the user to trade-o features for size, in order
to achieve the necessary performance for the target application.
Programmable logic has reached such a state of advancement in terms of speed and
density that it has become an attractive alternative for implementing RISC and
CISC processors. It can form a system within which processing, peripherals, data
paths, and algorithms can be placed to create powerful, exible, and upgradeable
systems. Programmable logic is now available in forms and sizes that range from
the traditional use as glue logic up to structured ASIC replacements.
The Nios II family of 32-bit RISC embedded processors delivers more than 100
DMIPS of performance when implemented in the Cyclone II FPGA family. Since
the processors are soft-core and exible, it is possible to choose from a nearly
unlimited combination of system congurations thereby enabling the processor to
meet the requirements with regard to features, level of performance and cost.
The Nios II processor family consists of three cores, fast (Nios II/f ), standard
(Nios II/s) and economy (Nios II/e), each optimized for a specic price and performance range. All three cores share a common 32-bit instruction set architecture
and are 100 percent binary code compatible. A library of commonly used peripherals and interfaces is included in the Nios II development kit.
A complete list
of SOPC builder-ready Intellectual Property (IP) and peripherals can be found at
the Altera Web page. The interface-to-user-logic wizard in the SOPC Builder software enables the creation of custom peripherals and their integration into Nios II
processor systems.
CHAPTER 2.
BACKGROUND
16
2.4.2 Avalon On-chip Bus
The Avalon [6] bus is a simple bus architecture designed to connect the on-chip
processor and peripherals into a working Nios II processor-based system, as illustrated in Figure 2.8. The Avalon is an interface that species the port connections
between master and slave components. It also species the timing by which these
components communicate.
Figure 2.8:
Example of a Nios II Processor-based System [7]
The Avalon bus supports advanced features, like latency aware peripherals, streaming peripherals and multiple bus masters. Multiple units of data can be transferred
between peripherals during a single bus transaction. Slave-side arbitration is used
for the interaction between Avalon masters and slaves. When two or more masters
attempt to access the same slave simultaneously, slave-side arbitration determines
which master gains access to the slave.
CHAPTER 2.
BACKGROUND
17
The Nios II's instruction and data buses are both implemented as Avalon master
ports.
The data master port connects to both the peripheral and the memory
components, while the instruction master port only connects to the memory components.
2.4.3 Development Tools
A complete set of tools are available for the hardware design, including Quartus II
design software, the SOPC Builder system development tool, ModelSim-Altera software, and SignalTap II embedded logic analyzer.
The SOPC Builder system development tool is used for creating, conguring and
generating a hardware Nios II processor-based system. Launching from within the
Quartus II design software, SOPC Builder provides an intuitive, wizard-driven,
graphical user interface for creating, conguring, and generating system-on-a-programmable-chip (SOPC) designs.
To make the software design ow as easy as possible, it is possible to accomplish all
software development tasks including editing, building, debugging programs, and
ash programming within the Nios II IDE.
To develop and debug a Nios II processor-based system a PC, an Altera FPGA device and a JTAG download cable is required. The Nios II architecture supports a
JTAG debug module that provides on-chip emulation features, enabling the processor to be controlled from a remote host PC. The Nios II IDE can communicate with
the JTAG module on the Nios II processor-based system. This allows downloading
of programs to memory, starting and stopping program execution, setting breakpoints and watch points, analysing registers and memory, and collecting real-time
execution data.
CHAPTER 2.
2.5
18
BACKGROUND
Communication Methods
2.5.1 I2C
2
2
I C [4][8] is a two-wire serial bus and was originally developed by Philips. I C does
not need a chip select or arbitration logic, making it cheap and simple to implement
in hardware.
2
The two I C signals are serial data (SDA) and serial clock (SCL). Together, these
signals make it possible to support serial transmission of 8-bit bytes of data over
2
the two-wire serial bus. The device that initiates a transaction on the I C bus is
termed the master (Not to be confused with the Avalon master and slave). The
master normally controls the clock signal. The data on the
the master switches the
SCL
SDA line is valid when
line from high to low. A device being addressed by
the master is called a slave.
2
If an I C slave is slower than the master it can hold o the master in the middle of
a transaction using clock stretching. Clock stretching is when the slave keeps
SCL
2
low until it is ready to continue. Most I C slave devices do not use this feature,
but every master supports it.
2
The I C protocol supports multiple masters, but most system designs include only
one. There may be one or more slaves on the bus. Both masters and slaves can
receive and transmit data bytes.
2
Each I C-compatible hardware slave device comes with a predened device address.
The master transmits the device address of the intended slave at the beginning of
every transaction. Each slave is responsible for monitoring the bus and responding
only to its own address.
This addressing scheme limits the number of identical
2
slave devices that can exist without contention on an I C bus.
The master begins the communication by issuing the start condition [9]. The master
continues by sending a unique 7-bit slave device address, with the most signicant
bit (MSB) rst. The eighth bit after the start, the
Read/W rite,
species whether
the slave is now to receive (0) or to transmit (1). This is followed by an
ACK
bit
CHAPTER 2.
19
BACKGROUND
issued by the receivers, acknowledging receipt of the previous byte. The transmitter
(slave or master, as indicated by the bit) then transmits a byte of data starting with
the MSB. At the end of the byte, the receiver (whether master or slave) issues a
new
ACK
bit. This 9-bit pattern is repeated if more bytes need to be transmitted.
A write transaction is when the slave is receiving. When the master is done transmitting all of the data bytes it wants to send to the slave, it monitors the last
ACK
and then issues the stop condition. In a read transaction where the slave is
transmitting, the master does not acknowledge the nal byte it receives. This tells
the slave that its transmission is done. The master then issues the stop condition.
2.5.2 LVDS
Low voltage dierential signalling [10], or LVDS, is an electrical signalling system
that can run at very high speeds over cheap, twisted-pair copper cables.
It was
introduced in 1994 and its use has since become popular in very high-speed networks
and computer buses.
LVDS uses the dierence in voltage between two wires to signal information. Depending on the logic level to be sent, the transmitter sends a small current, nominally 3.5mA, into one of the wires. The current passes through a resistor, matched
to the characteristic impedance of the cable at the receiving end, approximately
100Ω to 120Ω, and then returns in the opposite direction along the other wire.
The
voltage dierence across the resistor is therefore about 350mV. The receiver senses
the polarity of this voltage to determine the logic level.
The small amplitude of the signal and the tight electric- and magnetic-eld coupling
between the two wires reduces the amount of radiated electromagnetic noise.
The low common-mode voltage (the average of the voltages on the two wires) of
about 1.25V allows LVDS to be used with a wide range of integrated circuits with
power supply voltages down to 2.5V or lower. The low dierential voltage, about
350mV as stated above, causes LVDS to consume very little power compared to
other systems. For example, the static power dissipation in the LVDS load resistor
CHAPTER 2.
20
BACKGROUND
is 1.2mW, compared to the 90mW [11] dissipated by the load resistor for an RS-422
signal. This power eciency is maintained at high frequencies because of the low
voltage swing.
LVDS is often used for serial data transmission, which involves sending data bitby-bit down a single wire, as opposed to parallel transmission, during which several
bits, usually in multiples of eight, are sent down many wires at once. Its high speed
(a maximum data rate of 655 Mbit/s over twisted-pair copper wire) and its use of
in-channel synchronisation, makes it possible to send serial data faster than could
be done with a parallel bus.
When serial data transmission is not fast enough, data can be transmitted in parallel
using an LVDS pair for each bit. This system is called bus LVDS, or BLVDS, and
uses a higher driving current of 10mA, instead of 3.5mA.
2.5.3 CAN Bus
Controller Area Network (CAN) [10] is a multicast, shared, serial bus standard,
originally developed in the 1980's by Robert Bosch GmbH. CAN was specically
designed to be robust in electromagnetically noisy environments and utilizes a differential bus with special transceivers to support bit-wise arbitration.
It can be
even more robust against noise if twisted pair wire is used. CAN was initially created for automotive purposes as a vehicle bus, but is today used in a variety of
embedded control applications.
Bit rates up to 1Mbit/s are possible at networks length below 40m. Decreasing the
bit rate allows longer network distances (e.g. 125kbit/s at 500m).
CAN transmits data through a binary model of dominant bits and recessive
bits, where a dominant bit is a logical 0 and a recessive bit is a logical 1.
If
one node transmits a dominant bit and another node transmits a recessive bit, the
dominant bit wins. This is similar to a logical AND between the two as illustrated
in Table 2.1.
CHAPTER 2.
21
BACKGROUND
Table 2.1:
Bus state with two nodes transmitting simultaneously
dominant (0)
recessive (1)
dominant (0)
dominant (0)
dominant (0)
recessive (1)
dominant (0)
recessive (1)
As an example, if node-A is transmitting a recessive bit, and node-B sends a dominant bit, node-A will see a dominant bit, and recognise that a collision occurred.
Node-B will continue sending bits, while node-A will stop. All other collisions are
invisible, as the same data will be transmitted on the bus. A dominant bit is asserted by creating a voltage across the wires, while a recessive bit is simply not
asserted on the bus.
If any node sets a voltage dierence, all nodes sees it, and
hence a dominant bit is transmitted.
When two or more devices start transmitting at the same time, there is a priority
based arbitration scheme to decide which device will be granted permission to continue transmitting. Commonly a Carrier Sense Multiple Access/Bitwise Arbitration
(CSMA/BA) scheme is implemented.
During arbitration, each transmitting node monitors the bus state and compares
the received bit with its own transmitted bit. If a dominant bit is received, while
a recessive bit is transmitted, the node loses arbitration and stops transmitting.
Arbitration is performed during the transmission of the identier eld (ID). The
ID with the lowest numerical value has the highest priority. Each node starting to
transmit at the same time sends an ID starting from the MSB bit. As soon as a
node's ID is a larger number (lower priority) it will be sending a 1 (recessive bit)
and see a 0 (dominant bit), thus the node will stop transmitting. At the end of
ID transmission, all nodes, but one has stopped transmitting, allowing the highest
priority message to pass through unobstructed.
Chapter 3
Design Specications
A Kodak KAC-1310 Image Sensor was supplied to be integrated into a camera
system aimed to be used on a nanosatellite. No strict specications were given as
the nanosatellite was only in the concept phase. It was however desired that the
camera should be able to take images of at least
1024 × 1024
pixels and that it
should be capable of storing at least 100 of these images in non-volatile memory.
The LVDS standard was recommended for the fast data down link, while CAN bus
was optional for control of the camera system.
The requirements also suggested
the use of a soft-core processor in the design for control and possible real time
interpolation of the images. Furthermore, the camera system must also be able to
operate from a 5-12V power bus. The optics part of the application is not covered
in this thesis. Only an image acquiring and storing device is required.
22
CHAPTER 3.
3.1
DESIGN SPECIFICATIONS
23
Design Constraints
3.1.1 Timing and Data Rate Calculations
3.1.1.1 CMOS Sensor Calculations
The CMOS Sensor is capable of taking images in two modes, either Continuous
Frame Rolling Shutter capture mode (CFRS) for video capture or Single Frame
Rolling Shutter capture mode (SFRS) for still images. As the camera system will
take still images only, the timings and data rate calculations for SFRS alone will
be considered.
In SFRS mode, the total time to capture a frame is divided into two parts, the pixel
integration time and the readout time. See Figure 3.1. The pixel integration time,
also known as electronic exposure timing in photographic terms, can be widely
varied from a small fraction of the frame readout time to the entire frame time.
This electronic exposure time can be set by the user and will not inuence the data
rate calculations.
Figure 3.1:
Single Frame Capture Mode (SFRS) [4]
The image dimensions can be sized by setting the Window of Interest (WOI) registers, WOI Row Depth (wrd ) and WOI Column Depth (wcd ). The image can also
CHAPTER 3.
24
DESIGN SPECIFICATIONS
be padded with blanking pixels (invalid dark pixels) to slow down readout times
by increasing the Virtual Frame (VF) Column Width (vcw ). The readout time can
be calculated using:
Readout T ime = Trow × (wrd + 1)
(3.1.1)
where
Row T ime (Trow ) = (vcw + shA + shB + 19µs) × M CLKperiod
(3.1.2)
Table 3.1 gives a summary of readout times at dierent MCLK frequencies for a
1280 × 1024 pixel image.
default values of 10µs.
The Sample and Hold times, shA and shB, is kept at their
Table 3.1:
MCLK [MHz]
Readout Times compared to MCLK
Row Time [µs]
Readout Time [s]
1.00
1319.000
1.351
1.25
1055.200
1.081
1.50
879.333
0.900
1.75
753.714
0.772
2.00
659.500
0.675
2.25
586.222
0.600
2.50
527.600
0.540
2.75
479.636
0.491
3.00
439.667
0.450
4.00
329.750
0.338
5.00
263.800
0.270
10.00
131.900
0.135
15.00
87.933
0.090
20.00
65.950
0.068
The maximum data rate occurs during the Horizontal Clock (HCLK) bursts, Figure 3.1, where a pixel is readout on every rising edge of the HCLK. In each burst,
one row of pixel data is clocked out. The HCLK is a delayed MCLK and thus the
pixel rate is proportional to the MCLK frequency, Figure 3.2.
In Table 3.2 the eective data rate and the burst data rate for 10 and 8 bits/pixel
is shown for dierent MCLK frequencies. The eective data rate is the size of an
CHAPTER 3.
25
DESIGN SPECIFICATIONS
Default Row Sync Waveforms [4]
Figure 3.2:
image divided by the readout time, while the burst data rate is computed as the
readout of one pixel per MCLK period.
Table 3.2:
Data Rates compared to MCLK
Eective Data Rate [MB/s]
MCLK [MHz]
10 bits/pixel
8 bits/pixel
Burst Data Rate [MB/s]
10 bits/pixel
8 bits/pixel
1.00
1.16
0.93
1.19
0.95
1.25
1.45
1.16
1.49
1.19
1.50
1.74
1.39
1.79
1.43
1.75
2.02
1.62
2.09
1.67
2.00
2.31
1.85
2.38
1.91
2.25
2.60
2.08
2.68
2.15
2.50
2.89
2.31
2.98
2.38
2.75
3.18
2.55
3.28
2.62
3.00
3.47
2.78
3.58
2.86
4.00
4.63
3.70
4.77
3.81
5.00
5.78
4.63
5.96
4.77
10.00
11.57
9.25
11.92
9.54
15.00
17.35
13.88
17.88
14.31
20.00
23.14
18.51
23.84
19.07
Any image-capturing device will have to be able to capture pixels at the burst
data rate and must be able to process the image data at the eective data rate.
The eective data rate can be reduced by adding more blanking pixels and thus
increasing the readout time.
CHAPTER 3.
26
DESIGN SPECIFICATIONS
3.1.1.2 NAND Flash Data Rate Calculations
Writing large amounts of data to NAND ash memory can take longer than expected, as a write operation to NAND ash is always followed by a time delay.
This delay can last up to
700µs
[5] and only after this delay can a next page be
written to the device. The reason for this delay is that the device goes into a busy
state where the device transfers the data from its cache register to the ash cells.
See Figure 3.3.
The sequence to write a page of data to a NAND ash device is as follows:
1. Write 6 setup cycles,
2. Wait ALE signal to Data Loading time delay,
tADL , 100ns,
3. Write 2112 bytes of data (2048 data + 64 spare bytes),
4. Write 1 program command cycle,
5. Wait
tP ROG ,
which can last up to
700µs,
6. If desired check if write was successful.
A write cycle,
tW C ,
to write one byte, can be no shorter than
30ns
[5]. Therefore,
one page (2112 bytes) can be written at a maximum burst data rate of 31.79MB/s.
30ns×2112 = 63.36µs. Adding tP ROG , tADL and 7 setup cycles to this time gives 763.67µs needed to write one page and results in a continuous
Writing one page takes
data rate of 2.64MB/s.
This means that although the NAND ash device can handle high data rates in
excess of 30MB/s for data blocks less than a page size, it can only handle a continuous data rate of 2.64MB/s if multiple pages has to be stored. If needed this
data rate can be increased by using multiple NAND ash devices in a round-robin
fashion as described in [3].
Table 3.3 shows the burst and continuous data rates compared to dierent write
cycles,
tW C ,
that is capable when using a single NAND ash device.
CHAPTER 3.
Figure 3.3:
Table 3.3:
tW C
[ns]
27
DESIGN SPECIFICATIONS
NAND ash page write sequence [5]
NAND Flash Burst and Continuous Write Data Rates
Write time/page [us]
Burst write [MB/s]
Continuous write [MB/s]
30
763.670
31.79
2.637
31
765.789
30.76
2.630
32
767.908
29.80
2.623
33
770.027
28.90
2.616
34
772.146
28.05
2.609
35
774.265
27.25
2.601
36
776.384
26.49
2.594
37
778.503
25.77
2.587
38
780.622
25.10
2.580
39
782.741
24.45
2.573
40
784.860
23.84
2.566
45
795.455
21.19
2.532
50
806.050
19.07
2.499
3.1.2 Memory Capacity
The minimum capacity of the NAND ash memory depends on the size and the
amount of images that needs to be stored.
It is required that a minimum of a
100 images need to be stored, as images can only be downloaded to the ground
CHAPTER 3.
28
DESIGN SPECIFICATIONS
station when the satellite is in range. Images must also have a resolution of at least
1024x1024 pixels.
Assuming 10 bits/pixel, the standard output of the KAC-1310 CMOS image sensor,
the size of one image is 1.25MB/image. In order to store 100 images the NAND
ash device's memory capacity must exceed 125MB.
The preceding calculation was done for raw images - no demosaicing. If interpolation is considered, then 3 bytes/pixel is necessary, assuming that a 24bit/pixel
interpolation scheme is used. These images are 3 times larger in memory size and
thus the total storage size needed is 3
×
125MB = 375MB.
This is the minimum memory size, as no bad blocks in the NAND ash device
is taken into account in this calculation.
The failure of NAND ash blocks will
occur more rapidly in space than on earth because of radiation (Section 3.1.5).
Therefore, when choosing the capacity of the NAND ash memory, extra memory
must be allowed for bad blocks.
3.1.3 Power Constraints
Satellites are powered by both rechargeable batteries and solar panels. A nanosatellite's dimensions are much smaller than that of a larger satellite. Smaller dimensions
infer less area for solar panels and thus less power is generated for the satellite to
operate from. Therefore, any component used on the nanosatellite must use power
conservatively. This is one of the main design considerations for the camera system.
Preliminary calculations show that the peak power use of the camera system will
be more than 350mW as:
P owerKAC−1310 @13.5M Hz = 250mW
and
P owerSamsung
K9K4G08U 0M
= 30mA × 3.3V = 99mW
CHAPTER 3.
29
DESIGN SPECIFICATIONS
A design with a peak power usage preferably less than 1W will be attempted for
this thesis.
3.1.4 Physical Size and Mass Constraints
As mentioned before, a nanosatellite has small dimensions and thus onboard components must adhere to this constraint.
Component mass must be kept to a minimum, because the cost of launching a
satellite is directly proportional to its mass. The design should therefore attempt
to keep the camera's size and mass to the absolute minimum.
3.1.5 Radiation
This camera's application is for use onboard a satellite and will therefore be subjected to space radiation. Fortunately, the radiation of the camera's circuitry will
be reduced by the 2 - 3mm thick aluminium panels of the satellite's body.
Radiation of the CMOS sensor is of a bigger concern as it is not shielded by the
aluminium panels. The CMOS sensor is only covered by the optical lens system,
which does not provide protection from radiation.
The biggest source of space
radiation for LEO satellites is the sun [1]. As the camera will not be used to image
the sun, but more likely the earth, the lens system, and therefore the CMOS sensor,
will mostly face the earth. The earth does not produce radiation and therefore the
CMOS sensor will not be subjected to excessive radiation.
Studies done in the ESL on the radiation tolerance of NAND ash memory has
concluded that NAND ash memory should be capable of handling the radiation
experienced in LEO for at least 5 years.
This thesis will not test the design for radiation hardness, but will assume that the
satellite body and orientation will shield the system from radiation.
CHAPTER 3.
DESIGN SPECIFICATIONS
30
3.1.6 Bad Block Table
Any decent design that makes use of NAND ash memory must keep record of the
bad blocks in the NAND ash device. This can be done by storing the information
in a lookup table.
The bad block lookup table must be saved in a non-volatile
memory space so that the information will not be lost when power is removed. A
good place to store the bad block table would be in a known good block of the
NAND ash device.
The bad block table is dynamic as new bad blocks can form during the lifetime of
the device. The data structure of the bad block table must be suitable for random
bad block address changes and lookups must be relatively ecient. To allow for
random access the bad block table might be loaded into the memory of a controller
and should therefore be small as not to waste valuable resources.
3.1.7 Error Correcting Codes
Radiation and device degrading can cause bit ips in stored data. This corrupted
data can to some degree be corrected by using error correcting codes (ECC). Various
ECC codes exist, but a fundamental property of these codes is the need for extra
memory to store the computed codes. A very well known ECC is the Hamming
code. All these ECC codes are based on some form of parity bit scheme and are
limited to the extend of their correction capabilities.
For this design some controller that is capable of handling the required data rates,
while still processing the ECC codes, is needed. Extra storage memory will also be
necessary to store the nal ECC.
3.1.8 Optics
A camera system needs an optical element to focus the real image on the light
sensitive image-capturing instrument, like the CMOS image sensor.
CHAPTER 3.
31
DESIGN SPECIFICATIONS
The design of optical lenses is a eld of study in its own right and is very application
specic. As the exact use onboard the satellite or application of this camera system
is not yet known it was decided not to focus on the design of a lens system, but
rather on the capturing and storing of the image data from the CMOS image sensor.
3.1.9 Complexity and Reliability
The risk in making satellites is quite high and therefore the satellite and all subsystems must be extremely reliable. It is dicult to debug and x a system in space.
Systems must therefore be capable of either correcting themselves, or be able to
work with reduced functionality.
By keeping the design both simple and modular, future upgrades and maintenance
is easier.
Modular systems can be tested individually and faults localised more
easily.
3.1.10 Cost
As with any engineering project, cost must be kept to a minimum and this project is
no exception. The project is sponsored mainly by SunSpace
1
and other commercial
companies.
The project did not have unlimited resources, and therefore decisions made regarding component selection, choices between dierent development software, and the
number of PCB layers were all made keeping costs at a minimum.
1 SunSpace was established in 2000, through the Unistel Group and the Oce of Intellectual
Property of the University of Stellenbosch.
Chapter 4
System Design Overview
The design requires the use of a FPGA. FPGAs are very versatile and if designed
well the whole design can be very compact.
The design will only consist of the
CMOS image sensor, the NAND ash memory, a FPGA and the required power
system.
All the glue logic for the interfaces to the CMOS image sensor and NAND ash
memory can be implemented in the FPGA. It is possible to implement all the
communication drivers in the FPGA along with a soft processor to do the housekeeping work. The necessity for extra external memory can be avoided by choosing
the correct FPGA with enough internal RAM.
4.1
FPGA Considerations
Since the main system design is implemented in a FPGA, selecting the correct family of FPGA is of vital importance, especially when designing high-speed devices. If
the design grows to exceed the selected device there must be a device in the family
that is larger in capacity to migrate to.
Various FPGA vendors were considered but nally it was decided to use the Altera
Cyclone II family. The reasons for this choice will be discussed next:
32
CHAPTER 4.
ˆ
SYSTEM DESIGN OVERVIEW
33
Intellectual Properties (IP) - The Altera FPGAs supports mega functions
which include FIFOs, memory structures, LVDS drivers, JTAG UARTs, but
most importantly the Nios II soft-core processor. The Nios II is also very well
supported and documented.
ˆ
Internal RAM - The Altera Cyclone II families oer the highest amount of
internal RAM per device. Abundant internal RAM is needed, as no external
RAM will be used.
ˆ
Power usage - The Cyclone II uses half the power than the Cyclone I and
comparable Xilinx devices.
ˆ
Migration - The Cyclone II oers good migrating possibilities.
ˆ
Speed - Initial simulation with the Cyclone II proved that the Cyclone II
family is capable of the high internal clock speeds necessary for this design.
ˆ
Availability - The Cyclone II has been on the market for a reasonable amount
of time and is readily available.
ˆ
Development Software - The University of Stellenbosch has full licenses for
the Altera's development software and the author is fairly familiar with these
development tools.
ˆ
Capacity - The Cyclone II devices oer a high capacity of logic elements in
standard packages.
The Altera Cyclone II EP2C35F484C6 FPGA was selected to be utilised in the
design. Although SRAM based FPGA are not widely used in space applications
due to radiation upsets, the selection is still viable, as the radiation upsets will
not degrade the reliability of the satellite. The camera system is not a vital life
component of the satellite and if an upset should occur the camera can simply be
reset and recongured by the OBC.
The Cyclone II EP2C35F484C6 contains four phase lock loops (PLL) and hardware
multipliers.
It is capable of parity bit checking on internal memory and can do
Cyclic Redundancy Checks (CRC) [12] on the FPGA's conguration.
features make the Cyclone II a very appealing choice.
All these
CHAPTER 4.
4.2
34
SYSTEM DESIGN OVERVIEW
VHDL Design Overview
The following discussion will explain the system's VHDL design as seen in the grey
area of Figure 4.1.
Figure 4.1:
System Block Diagram
4.2.1 Data Widths
The CMOS image sensor outputs the pixel data in a 10-bit wide bus. The NAND
ash device has an 8 bit I/O bus. Packing 10 bits into 8-bit packets can become
a strenuous task and may cause that one image worth of data does not t perfectly into a NAND block partition or even worse, a page partition.
The result
of this is that one partition can contain the data of two images. This makes data
management more complex.
To reduce this complexity and future debugging eorts it was decided to keep the
design simple and choose the data width as 8 bits. The eect of this decision is
that the two least signicant bits from the CMOS image sensor output is discarded
and therefore the image colour depth is reduced.
that the required data rates can be relaxed.
An advantage of this choice is
CHAPTER 4.
SYSTEM DESIGN OVERVIEW
35
4.2.2 Data Routing
One of the main challenges of this design is transferring data from the CMOS image
sensor to the NAND ash memory device, while simultaneously downloading images
from the NAND ash memory.
It was decided to use two FIFOs to shift the data around. One FIFO is used to
transfer data to the NAND ash memory and the other FIFO to transfer data from
the NAND ash memory. Each FIFO will use a dual-clock system, meaning that
there are two separate clocks for reading from and writing to each individual FIFO.
See Figure 4.2.
Figure 4.2:
Dual Clock FIFO
By using two clocks, it is possible to input data into the FIFO at one particular
data rate while concurrently outputting data from the FIFO at a dierent data
rate. This attribute is very useful as image data can now be buered in the FIFO
and at a specied time be ushed out at a much higher data rate to the NAND
ash memory.
Writing data as fast as possible to the NAND ash reduces the average power of the
system, as the NAND ash device will only be operational for very short intervals.
The NAND ash device consumes
99mW
during a write or read operation but only
CHAPTER 4.
66µW
36
SYSTEM DESIGN OVERVIEW
during idle time. It thus makes sense to reduce the operational time of the
NAND ash device.
Similarly, the FIFO used to read the data from the NAND ash memory could be
used to buer the high-speed data from the NAND ash device and then output
the data at a slower rate for external devices.
A FIFO features optional signals such as asynchronous clear, empty-, full- and halffull signals. The asynchronous clear will be used to clear the FIFO on reset, while
the empty and full signals will be used to determine the status of the FIFOs. The
half-full signal warns that the FIFO is half-full and will be used to signal that the
buered data is ready to be shifted to the next module.
Having this feature, it was decided to make the FIFO's depth twice that of a NAND
ash page size. Thus
2 × 2048 bytes = 4096 bytes.
This allows the system to buer
a full page worth of data before writing it to NAND ash memory.
The deeper
Input-FIFO permits more than one page to be buered for when the NAND ash
memory is busy outputting read data into the Output-FIFO.
Seamless concurrent reading and writing to the mass NAND ash memory can be
implemented using this feature.
4.2.3 Error Detecting and Correcting
To make the mass memory more robust against radiation and random bit ips,
some form of error correcting code (ECC) needs to be implemented in an error
detecting and correcting (EDAC) scheme. NAND ash suppliers recommends using
Hamming code ECC to recover the error [13].
The recommended Hamming code algorithm computes 24 bits (3 bytes) for every
512 bytes of data. Thus to protect a full page of 2048 bytes, 12 bytes needs to be
added [14]. Fortunately, NAND ash comes with a spare area in each page where
these codes can be stored. This Hamming code can correct a single bit ip error
in each protected sector and detect if there is more than one error. Since the page
CHAPTER 4.
SYSTEM DESIGN OVERVIEW
is divided into four sectors,
4 × 512 bytes,
37
four ipped bits can be corrected in the
page if they all occur in separate sectors.
When a page is written to the ash memory 12 ECC bytes are computed and
appended to the stored data. When the same stored page is read from ash memory, the same algorithm is used to compute another 12-byte code word. The two
code words are then compared and any errors are detected. If possible, they are
corrected.
To implement this EDAC system a code word generator, a code word comparator,
FIFO and an error correction unit is necessary. The FIFO is needed to temporarily
store the read page while the second 12-byte code word is generated and compared
with the stored code word. This requirement works well with the data router FIFO
design in section 4.2.2. Figure 4.3 illustrates the data router FIFOs combined with
the EDAC system.
Figure 4.3:
Data Router with EDAC Block Diagram
4.2.4 NAND Flash Interface Module
The NAND Flash Interface module is implemented as a number of state machines
used to setup the correct command and address cycles for interfacing with the
NAND ash device. For each operation, i.e. writing, reading, erasing, or resetting,
there is a separate state machine. Each state machine controls the exact sequence
CHAPTER 4.
SYSTEM DESIGN OVERVIEW
38
of commands and addresses for its operation since the number of command and
address cycles diers for each command.
Figure 4.4:
NAND Flash Memory Interface Block Diagram
All the state machines need access to the control and data lines of the NAND ash
device and therefore a multiplexer will be implemented to connect the appropriate
state machine to these lines. A controller that receives commands from the outside
selects the appropriate state machine to execute the desired operation, while also
controlling the multiplexer.
4.2.5 Bad Block Table
The bad block table needs to be stored in non-volatile memory to preserve the data
during power cycling. As the camera system will be using NAND ash memory to
store non-volatile data, it is logical to store the bad block table in the NAND ash
device itself. The NAND ash manufacturer guarantees that the rst block of the
device is a valid block and that it is capable of 1000 program/erase cycles without
the need for error checking. The bad block table will therefore be stored in the rst
block of the NAND ash device.
CHAPTER 4.
39
SYSTEM DESIGN OVERVIEW
The negative eect of storing the bad block table in the ash memory is the complexity in accessing and updating the table dynamically. The bad block table will
therefore have to be loaded into external RAM at start up and again be stored at
the end of the camera's operation. The design is implemented in a FPGA where
RAM is predominantly limited.
The bad block table's memory footprint must
consequently be as small as possible.
Lookups and changes to the table must be ecient and should not require intensive
computation.
The method of keeping track of bad blocks used in [3] is unnecessarily complicated,
as it uses excess memory and is hard limited to the amount of bad blocks it can
keep track of. It also requires the table to be sorted periodically.
A much simpler and elegant solution is to represent the status of each block in the
NAND device as a single bit. Structuring the table in an
8 × 512
bit matrix not
only saves memory but sorting is redundant. Using this scheme the status of every
block is represented as valid or invalid. Any block's 12 bit address can now simply
be mapped and compared to the valid bit in the bad block table. See Figure 4.5.
Figure 4.5:
An Example of the proposed Bad Block Table organisation
This solution keeps track of all 4096 blocks in only 512 bytes, eectively four times
less memory than the proposed method in [3]. The table's size is also smaller than
a NAND ash device's page size and thus only one access to ash memory is needed
to load or store the bad block table.
CHAPTER 4.
SYSTEM DESIGN OVERVIEW
40
4.2.6 Image Storage Structure
The specication for the camera system requires that at least 100 images must be
stored in NAND ash memory. Before a decision can be made about a structure
to store these images in, some insight is needed:
A non-interpolated image is 1.25MB in size and will span 10 blocks of NAND ash
memory:
1.25M B
= 10 blocks
2048 bytes/page × 64 pages/block
An interpolated images is 3 times 1.25MB (Section 3.1.2) and will thus span 30
blocks of ash memory.
Bad blocks can also develop during the lifetime of the system and will cause the
memory space to become fragmented. Dividing the memory space into predened
image partitions will therefore not work. Keeping a le system is also to complex
and dicult to maintain.
A memory structure that is simple to implement and
easily organised is desired.
It was decided to use the ash memory space as a linear list of blocks. The bad
block table will map out all bad block addresses allowing the memory space to
appear continuous.
Images will be stored consecutively in ash from block 1 to
block 4095, skipping bad blocks, until the ash memory is full.
Images will be
downloaded from block 1 and a pointer will be kept to the last block and page
that has been downloaded. A second pointer will be kept to indicate the next open
block to where image data can be written.
Erasing individual blocks are not allowed, as this will leave the continuous memory
space fragmented and dicult to manage. Instead, the memory blocks can only be
erased all at once as a unit.
This method also implements some form of wear levelling as all the blocks in the
device are likely to be programmed and erased equally often.
CHAPTER 4.
41
SYSTEM DESIGN OVERVIEW
4.2.7 Bad Block Table & Address Manager Module
Valid addresses needs to be generated from the bad block table (BBT) on access
requests to the NAND ash device. The data router, bad block table and storage
structure must also operate in unison. This module will full this function.
The address manager creates incremental addresses starting at block 1. The generated address is compared to the block address, read from the bad block table, and
is skipped if it is marked as a bad block.
Figure 4.6:
Bad Block Table & Address Manager Block Diagram
When a request is received to write a page to ash memory the last written block
address is passed to the block address generator.
The block address generator
compares the address to the bad block table (Section 4.2.5) and if it is found to be
a bad block the address generator will increment the block address. This sequence
will be repeated until a valid block is found, after which the initiating process will
be signalled that a valid block address is available and that writing or reading may
commence. This ensures that only valid blocks are accessed.
The module will handle the following low-level requests:
ˆ
Load BBT - multiplexes the output of the Output-FIFO to the BBT memory,
and sends a command to the NAND Interface module to read the rst page
of block 0.
CHAPTER 4.
ˆ
SYSTEM DESIGN OVERVIEW
42
Store BBT - multiplexes the output of the BBT memory to the Input-FIFO.
Block 0 is erased before the write page command is send to the NAND Interface module.
ˆ
Erase all - starts erasing all the image data blocks, starting at block 1 and
ending at block 4095.
ˆ
Write page - requests a valid block and page address from the block address
generator and then writes the buered image from the Input-FIFO to the
NAND ash memory.
ˆ
Read page - requests a valid block and page address from the block address
generator starting from the last downloaded address. The NAND Interface
module is then commanded to read a page from NAND ash memory at the
generated address. The read data is then buered in the Output-FIFO.
ˆ
Reset ash - implemented for possible future use.
The Data Router with EDAC, NAND Interface Module and the Bad Block Table
& Address Manager Module will, from here on, collectively be known as the Image
Exporter.
4.2.8 Embedded System Controller
The whole design needs to be controlled and must be able to communicate with
the OBC. It was decided to use the Altera Nios II soft-core processor for this
purpose.
Using a processor enables changes to the system to be easily made in
software. Dierent interpolation algorithms can simply be written in a high level
programming language such as ANSI C. Many communication drivers are available
to interface directly with the Nios II system via the Avalon bus and changing to a
dierent protocol is as simple as adding the new soft-core module. Software drivers
exist for these modules and will have to be loaded.
The Nios II is very easy to use and debugging is facilitated by using the JTAG
UART. No extra hardware is required to use this feature as the standard JTAG
CHAPTER 4.
43
SYSTEM DESIGN OVERVIEW
interface is used. The JTAG controller interface is needed to download the FPGA
conguration le to the FPGA.
The Nios II will acquire the image data from the CMOS Image Sensor Interface
module. The Nios II will get an interrupt when a byte is received from the CMOS
Image Sensor. The Nios II will keep a page worth of data in memory to allow for
possible image processing. The data will be written to the Image Exporter via a
Direct Memory Access (DMA) controller. This will allow the Nios II processor to
be free to communicate with the OBC and to collect more image bytes from the
CMOS Image Sensor.
2
The Nios II will use an I C module to send commands to the CMOS Image Sensor.
A CAN bus module will communicate with the OBC. Both these modules interface
directly with the Nios II via the Avalon bus.
The software that will run onboard the Nios II processor will be stored in the
external non-volatile serial EPROM device where the FPGA's conguration le is
stored. The Nios II will boot from the EPROM device.
Finally the Nios II will control the Image Exporter by sending it the commands
discussed in section 4.2.7.
4.2.9 CMOS Image Sensor Interface
An interface from the Nios II to the Kodak KAC-1310 CMOS Image sensor is
needed.
This interface will supply the KAC-1310 with a 1.25MHz master clock.
Pixel data from the KAC-1310 will consequently arrive every
800ns1
on the ris-
ing edge of the HCLK. This data rate of 1.19MB/s (Table 3.2) is about half the
continuous data rate that the NAND ash memory can handle during writing and
reading (Table 3.3) and will give the Nios II more exible control of the system.
The CMOS Image Sensor Interface will interface with the Nios II via the Avalon bus
and will send an interrupt to the Nios II embedded system controller to read the
1 Calculated as 1 byte
1.25M Hz
= 800ns/byte
CHAPTER 4.
44
SYSTEM DESIGN OVERVIEW
latched pixel byte. The KAC-1310 master clock of 1.25MHz will allow the Nios II
processor 1.081 seconds to manage the image data. Please refer to Table 3.1. This
gives the Nios II ample time to do housekeeping work.
4.2.10 I2C
2
I C is a widely used protocol and open-source implementations of this code exist
freely on the internet.
2
It was decided to use the I C core from the Laboratory
of Architecture of the Processors FPSL, Federal Polytechnic School of Lausanne,
Switzerland, as this core has been developed and tested for a similar application.
In addition the drivers used for the application serve as a good example of how to
interface the Nios II with external user logic.
Unfortunately, the documentation
is in French, but translation services on the internet can be used to help with
interpretation.
4.2.11 CAN Bus
The CAN Bus protocol is also widely used and various implementations exists on
the internet. Opencores.org provides an open-source version, while various IP's are
for sale on the internet. As the project has limited funds, it is decided to use the
free Opencores.org version.
4.2.12 LVDS
As the Altera Cyclone II will be used, it is only appropriate to use the Mega
Functions provided by Altera. Altera provides a LVDS Transmitter Mega Function
that can be congured to t the application perfectly.
This LVDS Mega Function makes use of a single PLL and dierential paired pins
on the Cyclone II.
CHAPTER 4.
4.3
SYSTEM DESIGN OVERVIEW
45
Design Implementation Changes
It was later decided by the nanosatellite design team, that demosaicing of images
should not be done by the camera system, but rather be done on the OBC or ground
station. The camera's design was already implemented at the time of this decision
so the capability to do real time interpolation on the images was not removed from
the design, although further research and implementation of this feature was halted.
Chapter 5
Detailed System Design
In this chapter, the proposed design is implemented and discussed in detail. The
VHDL components are described individually and the operation of complex components are explained by ow charts. An appropriate Nios II system is selected for
the application, followed by component discussion and selection. A deviation from
the initial design due to unforeseen limitations is also covered.
5.1
VHDL Design Detail
A state machine design approach was used for the VHDL design, allowing the
implementation of a structured design.
VHDL, implemented as state machines,
can simply be expanded by adding a new state.
Debugging state machines is very eective as problems can readily be isolated to a
single state.
For this type of project, where data is transferred at high data rates, and where
the interface timing to external devices is of vital importance, a synchronous design
must be used. State machines work well in synchronous designs where all registers
are clocked by a global clock signal. Asynchronous actions are limited to an external
reset signal in order to force the circuit into a well-dened state after the power on.
46
CHAPTER 5.
47
DETAILED SYSTEM DESIGN
With VHDL one can implement a modular design approach. Individual components
can be designed and simulated before being integrated into the nal design.
The following sections describe each individual VHDL component in detail.
5.1.1 Bad Block Table & Address Manager Module
The Bad Block Table & Address Manager module is implemented as two processes.
The rst process handles all new commands. See Figure 5.1. The second process,
Figure 5.2, accesses the BBT and generates valid block addresses.
Both these
processes have access to a single port of the dual-port, internal FPGA memory
used to keep the Bad Block Table.
5.1.1.1 Command Handling Process
The Command Handling process consists of two parts (Figure 5.1). The rst part
decodes the new commands while the second part executes the commands. It was
decided to use a single, segmented state machine for all the command sequences,
as it is not necessary for the commands to execute in parallel. This allows for a
simple system, as multiple state machines running in parallel makes it much more
complex to access the same BBT memory region.
The following paragraphs explain each section of the command execution sequence:
Update Bad Block Table:
The Update Bad Block Table sequence will up-
date the BBT residing in the dual-port internal BBT memory. It uses the address
pointer currently in use and maps it to the appropriate byte address in the BBT
memory. This byte is then read and the correct bit is set to '0' to indicate that
this block is now marked as invalid and not suitable for future use.
The updated byte is rewritten to the BBT memory and the Idle state is entered,
where the Bad Block Table & Address Manager module will wait for a new command.
CHAPTER 5.
DETAILED SYSTEM DESIGN
Figure 5.1:
48
Bad Block Table & Address Manager Flow Chart
Wait for Flash to nish:
This state is used do determine if the NAND
Flash device is still in a busy state.
All the command sequences that put the
NAND Flash device in a busy state, will exit to this wait state. This wait state will
check if the write process was successful after a write command was executed on
the NAND Flash device. If not, this state passes through the Update Bad Block
Table sequence before going to the Idle state.
Load Bad Block Table:
The Bad Block Table & Address Manager module
is hard coded to load the BBT into the internal memory immediately after the
system is reset. This command can also be executed during the operation of the
camera system.
The Load BBT sequence will initially set the requested read address to block 0 of
CHAPTER 5.
DETAILED SYSTEM DESIGN
49
the NAND ash device and will multiplex the Output-FIFO to the internal BBT
memory region. A read command is sent to the NAND Flash Interface. The 512
bytes of BBT data from the NAND ash will now sequentially be clocked into the
internal BBT memory region.
Six more information bytes follow the 512 BBT bytes. The rst 3 bytes is a pointer
to the last written page address and the following 3 bytes points to the last downloaded page address. These pointers were saved along with the BBT on a previous
Store BBT sequence.
Lastly, the Output-FIFO is cleared by clocking out the rest of the dummy bytes in
the read page.
Store Bad Block Table:
To be able to replace data on the NAND Flash
device the block containing the data needs to be erased rst.
The Store BBT
sequence will thus rst erase block 0 of the NAND Flash device while routing the
output of the internal BBT memory to the Input-FIFO.
While the erasing of block 0 is executing the BBT data will be shifted into the
Input-FIFO along with the extra two, page address pointers. Given that the design
requires that a full page, i.e.
2048 bytes, must be written to ash memory, the
remainder of the 2048 bytes are lled with dummy bytes. These dummy bytes are
all
FFh
as 1's program faster in NAND ash memory.
Page Read:
The Page Read sequence rst checks whether all the pages have
not been downloaded by looking at the last downloaded page address pointer. If
not, this address pointer is incremented and passed on to the Address Generation
process. The Address Generation process compares this address to the BBT and
returns a valid block address starting from the queried address.
Once the valid address is received, the Page Read sequence commands the NAND
Flash Interface to start reading a page. This is the end of the sequence and it exists
to the Wait for Flash to Finish state.
CHAPTER 5.
DETAILED SYSTEM DESIGN
Page Write:
50
This sequence is similar to the Page Read sequence except that
it rst checks if the ash memory is not full by referring to the last written page address pointer. The Address Generation process then compares this address pointer
to the BBT, after which the address is returned and used in the write command to
the NAND Flash Interface.
This sequence also exists to the Wait for Flash to Finish state where a test is done
if the write was successful.
Erase All:
The Erase All sequence will erase all the blocks in the NAND Flash
device while skipping all the bad blocks. All the blocks, starting from block 1, are
sequentially erased. If the NAND Flash device reports an erase failure with a block,
refer to Figure 2.7, the BBT is immediately updated by jumping to the Update
Bad Block Table sequence.
After the block is masked out the erasing continues
until all the blocks have been erased.
Reset Flash:
This state sends the Reset command to the NAND Flash In-
terface after which the Bad Block Table & Address Manager module returns to the
Idle state.
5.1.1.2 Valid Block Address Generation Process
Only valid block addresses can be used when accessing the NAND Flash device as
it is not recommended to access bad blocks. The Valid Block Address Generation
Process will only generate a valid block address when the Command Handling
Process requests it. See Figure 5.2.
The Valid Block Address Generation Process operates by mapping the requested
block address to the corresponding bit in the BBT. If the value of this bit equals
`1', the address is returned as valid, but if the value equals `0', the current block
address is incremented and re-tested. This process will continue until a valid block
address is determined.
CHAPTER 5.
DETAILED SYSTEM DESIGN
Figure 5.2:
Valid Block Address Generation Flow Chart
51
CHAPTER 5.
52
DETAILED SYSTEM DESIGN
The generation of a valid block address is signalled to the Command Handling
Process by means of the Adr Generated signal.
The Valid Block Address Generation Process also checks that the generated block
address does not exceed the block address range of the NAND Flash device.
A
Last Block signal is used to indicate when this is true.
5.1.2 Data Router Module
The Data Router module's purpose is to link the FIFOs and EDAC components,
and to handle arbitration between the components. Arbitration comprises of ensuring that the dierent control signals of the FIFOs and EDAC components are
coordinated. This is accomplished by using counters and state machines to determine the progression of the data ow and then setting the appropriate signals at
the correct times.
An example of this arbitration would be when the EDAC Correction unit signals
that it is ready to correct the output of the Output-FIFO and that a read request
signal is needed for the Output-FIFO to shift its data out.
The Data Router module contains two multiplexers, which are controlled by the
Bad Block Table & Address Manager module.
The rst multiplexer selects the
input for the Input-FIFO from either the Nios II or from the BBT memory, while
the second multiplexer channels the output of the Output-FIFO to either the LVDS
downlink or the BBT memory. When an output channel is not selected, its input
is set to high impedance.
The Input-FIFO and the Output-FIFO are created by using an Altera Mega function. The dual-clock FIFOs are 4096 bytes deep and the read and write clocks are
synchronised.
The EDAC components include the ECC Generator, the ECC Detector, and the
Correction Unit.
The EDAC implements a Hamming algorithm that can detect
and correct one bit out of every 512 bytes.
A 24-bit code word is produced for
CHAPTER 5.
53
DETAILED SYSTEM DESIGN
every 512 bytes, resulting that four code words are produced for every page. The
following paragraphs describe each component of the EDAC in turn.
ECC Generator:
The ECC Generator produces the error codes for data re-
ceived from either the Nios II or the BBT memory. These error codes are appended
to the data when stored to ash and is thus stored in the spare area of a page.
ECC Detector:
When a page of data is read from the NAND ash memory it
passes through the ECC Detector before the data is buered in the Output-FIFO.
The same Hamming algorithm used in the ECC Generator is then applied to the
page of data and another four code words are produced. The new code words and
the previously generated words are then compared with a XOR operation.
The
following results are possible:
ˆ
all bits at `0' - no errors to report.
ˆ
12 bits at `1' - a 1-bit correctable error.
ˆ
only 1 bit at a `1' - an error in the code word.
ˆ
random data - a non-correctable error.
Before the data is shifted out of the Output-FIFO buer, the ECC Detector sends
out four 12-bit addresses and a status bit to the Correction Unit. The four 12-bit
addresses refer to the byte and bit address of any bit that is ipped, while the
status bit is set if an error needs to be corrected.
Correction Unit:
The Correction Unit corrects any 1-bit errors contained
within any of the four 512-byte segments of data in a page. The Correction Unit's
state machine stays idle until the four 12-bit addresses and status bits are received
from the ECC Detector. The Correction Unit then sends an acknowledge signal,
correction ready, to the controller in the Data Router Module which then activates
the read request signal of the Output-FIFO. The data is now shifted out through
CHAPTER 5.
DETAILED SYSTEM DESIGN
54
the Correction Unit. The Correction Unit waits for any corrupted bytes to pass
through and xes them when needed.
5.1.3 NAND Flash Interface Module
An interface from the FPGA to the NAND ash device is needed. This interface
must be able to handle all the command, address and data cycles to the NAND
ash device (Section 2.3.2). The timing requirements of this module are extremely
critical, as data will be transferred at high data rates. To implement such a critical
module accurately a non-synthesizable simulation model of the NAND ash device,
for simulation purposes, is required.
Unfortunately, Samsung does not supply synthesizable models of their newer NAND
ash devices, but refer users to a third party company. This third party company,
Denali Software, is not willing to supply their software to South Africa due to being
unable to grant the Educational License Agreement (ELA) request to South Africa
due to export issues.
Fortunately, the NAND Flash Interface module code from [3] is available.
This
interface was written for a slower NAND ash device, also manufactured by Samsung, and was simulated in conjunction with a synthesizable NAND ash model.
This NAND Flash Interface module was thus adopted and modied for faster and
bigger NAND ash memory devices. Excess code, that was application specic, was
removed and overall performance improved by combining or removing unnecessary
states.
The four main operations of the NAND Flash Interface module are to write a
page, read a page, erase a block, and reset the device. The operations each require
dierent command and address cycles; therefore, separate state machines are used
for each operation. A controlling state machine manages the other state machines
and receives commands from the Bad Block Table & Address Manager module.
The NAND Flash Interface module operates from two synchronous clocks.
The
slower clock, running at half the speed of the faster clock, drives the controlling
CHAPTER 5.
55
DETAILED SYSTEM DESIGN
state machine while the fast clock drives the four main operation state machines.
The minimum write/read cycle time given in [5], for the NAND ash device, is
30ns.
Data can thus be written or read at 31.79MB/s (Table 3.3), but to reduce
implementation complexity and to ensure that all timing requirements are met,
36ns. The RE Access T ime
18ns, inuences this decision.
the write/read cycle time must be relaxed to
constraint,
The
tREA ,
with a maximum time of
RE Access T ime
is the time between the falling edge of the
the time before the data on the
I/O
I/O
signal and
bus is guaranteed to be valid. Refer to [5] for
more detail. A state machine changing state every
that data on the
RE
timing
18ns,
will consequently ensure
bus is guaranteed to be valid.
The two clocks driving the NAND Flash Interface module is hence chosen as
27.775MHz and 55.555MHz with periods of
36ns and 18ns respectively.
This gives
a burst data read/write rate of 26.49MB/s, refer to Table 3.3, and a continuous
data write rate of 2.594MB/s to and from the NAND ash device.
Using these clocks in the rest of the design will reduce hardware. The rest of the
VHDL system will therefore also run from the 27.775MHz clock, while the Nios II
will run from the 55.555MHz clock.
5.1.4 CMOS Image Sensor Interface Module
The initial design for acquiring data from the KAC-1310 Image sensor could not be
implemented. The initial design comprised of sending an interrupt to the Nios II
when a new byte was latched. The Nios II would then collect the byte from the
CMOS Image Sensor Interface module and store it in a software array. As soon as
the array contained a full page of data, the DMA controller would be instructed to
move the data to the Image Exporter Unit.
An unforeseen matter complicated this process - the DMA controller's software
drivers are too large for the onboard memory (Section 5.2.2.2) of the Nios II system. In addition, a reduced functionality driver set for the DMA controller is not
available and this forces the design to nd an alternative solution.
CHAPTER 5.
56
DETAILED SYSTEM DESIGN
It is decided that the Nios II will have to act as a DMA controller. The Nios II
will still collect the data from the CMOS Image Sensor Interface module and store
it in a software array, but now the Nios II will move the data in the array to the
Image Exporter Unit instead of a DMA controller moving the data.
However, this poses a new problem. To move 2048 bytes of data from the array to
the Image Exporter unit, takes much longer than the time it takes for a new byte
to arrive from the KAC-1310 (800ns/byte, Section 4.2.9). The Nios II, operating
at 55.555MHz, can move one byte to the Image Exporter roughly every
216ns
(12
clock cycles). The Nios II processor is fully occupied during this transfer. The data
received from the KAC-1310 will thus have to be buered in a FIFO in the CMOS
Image Sensor Interface module.
To determine the minimum depth of this FIFO the following is derived:
Let the initial depth of the FIFO
D0 =
tneeded
tbyte
arrives
where
tneeded
is the time that
the Nios II will be busy transferring data to the Image Exporter and
tbyte
arrives is
the time period for each new byte arriving from the KAC-1310.
D0 , as bytes will
every tbyte leaves , the
Realising that the FIFO must be deeper than
still arrive while
bytes are read from the FIFO to the Nios II,
following is true:
tbyte leaves
tbyte leaves
+ D1
+...
= lim D0 + D0
n→∞
tbyte arrives
tbyte arrives
|
{z
} |
{z
}
D1
D2
tbyte leaves
tbyte leaves
+Dn
... + Dn−1
tbyte arrives
tbyte arrives
|
{z
}
DepthF IF O
Dn
(5.1.1)
CHAPTER 5.
57
DETAILED SYSTEM DESIGN
0
1
tbyte leaves
tbyte leaves
= lim D0
+ D0
+ ...
n→∞
tbyte arrives
tbyte arrives
n−1
n
tbyte leaves
tbyte leaves
+ D0
... + D0
tbyte arrives
tbyte arrives
(5.1.2)
0 1
tbyte leaves
tbyte leaves
= D0 lim
+
+ ...
n→∞
tbyte arrives
tbyte arrives
n−1 n
tbyte leaves
tbyte leaves
+
... +
tbyte arrives
tbyte arrives
= D0 lim
n→∞
n X
tbyte
leaves
tbyte
arrives
k=0
1−
= D0 lim
n→∞
1−
D0 =
tbyte leaves
tbyte arrives
tbyte leaves
tbyte arrives
tneeded
tbyte
arrives
k
(5.1.4)
n+1
1
= D0
Substituting
1−
tbyte leaves
tbyte arrives
(5.1.3)
(5.1.5)
tbyte leaves <1
as tbyte arrives (5.1.6)
into equation 5.1.6 gives:
DepthF IF O =
tbyte
tneeded
arrives − tbyte
(5.1.7)
leaves
Intuitively this result makes sense. The depth of the FIFO is determined by the
time needed, to write data to the Image Exporter, divided by the time dierence
between bytes entering and exiting the FIFO.
Using Equation 5.1.7 and letting
and
tbyte
leaves
= 121.5ns
tneeded = 2048 bytes × 216ns, tbyte
arrives
= 800ns
the minimum depth of the FIFO is calculated as:
DepthF IF O =
2048 bytes × 216ns
≈ 652 bytes
800ns − 121.5ns
CHAPTER 5.
1024 bytes (≥ 652 bytes) is therefore used
(≤ 252µs) for necessary housekeeping work.
A FIFO containing space for
the Nios II extra time
The time
tbyte
58
DETAILED SYSTEM DESIGN
leaves
= 121.5ns
and allows
has been determined through simulations of the
Nios II processor in ModelSim 5.8c. It was found that the longest time that the
486ns. Four bytes are thus
= 121.5ns/byte. The waveform of this
Nios II takes to read a 32-bit word from user logic is
486ns
read concurrently and resolves to
4 bytes
simulation is discussed in Section 6.2 and can be seen in Figure 6.9.
The FIFO used in the CMOS Image Sensor Interface module is therefore 256 by
32bit words deep and hence eectively capable of buering 1024 bytes. An asynchronous, dual-clock FIFO is implemented. The FIFO's input clock is driven by
the asynchronous HCLK and the FIFO's output clock is synchronised to the system
clock.
The CMOS Image Sensor Interface module now operates by receiving bytes from
the KAC-1310 on the rising clock edges of the HCLK and sets a ag, intended for
the Nios II, when a 32-bit word is ready to be read from the FIFO.
The master clock (MCLK) of 1.26MHz (≈
1.25M Hz 1 ) generated by the CMOS Im-
age Sensor Interface module for the KAC-1310 is created by dividing a 15.151MHz
2
clock with a counter, which ips the MCLK line on every sixth clock count.
5.2
Nios II and Components Design
5.2.1 Nios II Conguration
The Nios II processor is created and congured using SOPC Builder. The Nios II/f
core is selected for both its high processing speed of up to 62DMIPS, with a system
clock of 55.555MHz when implemented on a Cyclone II, and its faster access time
to other on-chip components. The Nios II/f core is a RISC, 32-bit processor with
1 This results in t
byte arrives = 792ns and DepthF IF O = 660 bytes ≤ 1024 bytes
2 Due to integer multiplication and division in the PLL only a 15.151MHz clock can be implemented in conjunction with the 55.555MHz and 27.775MHz clocks.
CHAPTER 5.
59
DETAILED SYSTEM DESIGN
the possibility for hardware multiplication and division. The Nios II/f core has a
Barrel Shifter and is capable of Dynamic Branch Prediction.
For this design the Nios II/f core is congured with a 4Kbyte instruction cache
(default), a 4Kbyte data cache (default), as well as hardware multiplication and
division. The Cyclone II contains 70, 9-bit element embedded hardware multipliers
of which four is utilised in the hardware multiplier of the Nios II/f processor. The
Nios II/f core takes up 1400-1800 logic elements (LE) of the Cyclone II.
For debug purposes, a JTAG Level 3 Debug Module is added. This module utilises
the JTAG Target Connection and can be used for software downloads, setting
software breakpoints, two hardware breakpoints and two data triggers. Instruction
trace and on-chip trace can be performed. The JTAG Level 3 Debug Module takes
up an additional 2400-2700 logic elements on the FPGA, but can be omitted in the
nal product.
Currently no Custom Instructions are added, but can be included if the need should
arise in the future.
The processor's Reset Address is set to the EPCS Controller (Section 5.2.2.1), the
Exception Address to the On-chip Memory (Section 5.2.2.2) and the Break Location
to the JTAG Debug Module. A summary can be seen in Table 5.1.
Table 5.1:
Nios II Processor Conguration
Processor Function
Memory Module
Oset
Address
Reset Address
epcs_controller
0x00000000
0x00008000
Exception Address
onchip_memory_0
0x00000020
0x00000020
Break Location
cpu_0/jtag_debug_module
0x00000020
0x00008820
The sections to follow discuss the supplementary components to the Nios II SOPC
design as seen in Figure 5.3.
CHAPTER 5.
DETAILED SYSTEM DESIGN
Figure 5.3:
The Nios II based camera system in SOPC Builder
60
CHAPTER 5.
DETAILED SYSTEM DESIGN
61
5.2.2 SOPC Components
5.2.2.1 EPCS Controller
The program code, which the Nios II will execute, needs to be stored in nonvolatile memory. The EPCS Controller provides a boot-loader feature that allows
the Nios II system to store the main program code in an EPCS serial conguration
device, which is a non-volatile memory.
As illustrated in Figure 5.4, the EPCS serial conguration device's memory can be
thought of as two separate regions:
ˆ
FPGA conguration memory - FPGA conguration data is stored in this
region.
ˆ
General-purpose memory - the remaining space is used for general-purpose
data and system software.
The ash programmer utility in the Nios II IDE allows the data to be managed
and programmed into the EPCS serial conguration device.
Figure 5.4:
Nios II system integrating an EPCS Controller [15]
CHAPTER 5.
62
DETAILED SYSTEM DESIGN
The EPCS Controller core contains a 1Kbyte on-chip memory for storing a bootloader program. The Nios II processor is congured (Table 5.1) to boot from the
EPCS Controller. Therefore, after reset the CPU rst executes code from the bootloader's ROM, which copies data from the EPCS general-purpose memory region
into the on-board memory (Section 5.2.2.2).
Then, program control transfers to
the onboard memory.
The Nios II IDE provides facilities to compile a program for storage in the EPCS
serial conguration device, and create a boot-up le to program into the EPCS
Controller. More information can be found in Altera's Nios II Flash Programmer
User Guide [16].
5.2.2.2 On-chip Memory
The Nios II processor system needs onboard RAM to store instructions and data
during execution.
In SOPC Builder an On-chip Memory component (onchip_memory_0 in Figure 5.3) is added. This memory is chosen to be RAM type memory and dual-port
access is disabled. Dual-port access would only have been necessary if the DMA
controller was implemented.
A memory width of 32-bits is selected to reduce memory access cycles and the
total memory size is chosen to be the maximum size that Quartus II's tter can t
on the Altera Cyclone II EP2C35F484C6 FPGA. The memory size of the On-chip
Memory component restricts the amount of software drivers that can be loaded
into the design. Due to tting constraints, the full system design can only occupy
77% of internal memory and hence only 24Kbytes can be allocated to the On-Chip
Memory component.
The default memory initialisation le onchip_memory_0.hex is used. This le is
created by the Nios II IDE and contains the embedded software of the system.
CHAPTER 5.
63
DETAILED SYSTEM DESIGN
5.2.2.3 JTAG UART
The JTAG UART core provides communication between the host development PC
and the Altera Cyclone II FPGA. This core is used as a stepping-stone to more
complex communication cores such as the CAN bus core and eliminates the need
for a separate RS-232 serial connection to the host PC for character I/O.
The JTAG UART core has an Avalon slave interface and therefore master peripherals, like the Nios II processor, communicate with the JTAG UART core by reading
and writing control and data registers. The core also provides bidirectional FIFOs
to improve bandwidth over JTAG connections.
For the Nios II processor, device drivers are provided, allowing software to access
the core using the ANSI C Standard Library stdio.h routines.
For the host PC,
Altera provides JTAG terminal software that manages the connection to the target,
decodes the JTAG data stream, and displays characters on the screen.
5.2.2.4 User Logic
All the developed VHDL logic components of the design forms part of the User
Logic and needs to be interfaced with the Nios II system. All these components
will conform to the Avalon slave standards.
A typical Avalon slave, User Logic peripheral, consists of the following functional
blocks [17]:
1. Peripheral Task Logic - This is the VHDL components that carry out the
functional operation of the peripheral.
2. Register File - The register le, written in ANSI C, provides a memory element
for input to, and output from, the peripheral task logic. See Appendix C for
an example of the Image Exporter's register le.
3. Avalon Interface - Written in VHDL, the Avalon interface, provides a standard
address mapped interface to the register le. The interface provides all the
CHAPTER 5.
64
DETAILED SYSTEM DESIGN
signal types necessary to access the register le.
See Appendix D for an
example of the Image Exporter's Avalon Interface.
3
4. Software Driver Functions - The software driver functions provide an interface
to the peripheral from the software application. The software requirements
vary according to the needs of the peripheral.
The most common routines
initialise the peripheral, read data from the peripheral, or write to the peripheral.
See Appendix E for an example of the CMOS Imager's software
driver.
The Interface to User Logic wizard is used to dene the Avalon slave interface ports
of the components. This includes mapping the signal names to Avalon signal types
and specifying timing requirements, such as setup and hold times, or wait states.
The following three units are user logic peripherals and are all implemented with
the Interface to User Logic wizard.
Only the important details concerning the
specic units are highlighted in the following paragraphs:
I2 C Module:
2
The I C module core can not operate faster than 50MHz as internal
control counters will overow when trying to maintain the slow SCL clock speeds.
The 27.775MHz clock, clk_slow, is therefore used to clock this core. Please refer
to Figure 5.3.
The Avalon slave timing is set to the default values as shown in Figure 5.5. When
2
reading from the I C module an Avalon master will hold the address-,
read-
and
chipselect signal valid for two clock cycles. On the second rising edge of the clock
data will be read from the readdata bus. An Avalon master writes to the module
by holding all the required signals valid for two clock cycles.
3 Please note that, should the driver's lename contains a `_', the le's code will be embedded
in the pre-initialisation system les of the Nios II processor and will be executed at start up. This
will cause errors if the driver is not intended to be an initialisation le. However, this function
may be useful if peripherals need to be initialised at start up. All register les with the _regs.h
extension will be included as initialisation les and thus embedded in the system les.
CHAPTER 5.
DETAILED SYSTEM DESIGN
Figure 5.5:
CMOS Imager:
65
I2 C Module's Avalon slave timing conguration
The CMOS Imager component forms the Avalon interface layer
to the CMOS Image Sensor Interface module. The CMOS Image Sensor Interface
module implements the buer FIFO, as discussed in Section 5.1.4.
The Avalon
Interface allows the Nios II to initialise the KAC-1310, to read pixel data from the
FIFO and to clear the contents of the FIFO.
The output data, from this FIFO, has a one clock latency on a read request and
therefore the Avalon slave timing illustrated in Figure 5.6 is selected. The Read
Wait time is set to zero extra clock cycles, while the Read Latency is increased to
one clock cycle later.
The write timing to the CMOS Imager component is not altered from the default,
as access to the write register is not time critical.
CHAPTER 5.
Figure 5.6:
DETAILED SYSTEM DESIGN
66
CMOS Image Sensor Interface's Avalon slave timing conguration
Image Exporter:
The Image Exporter component's interface and control logical
also operates from clk_slow. An external 55.555MHz clock is applied directly from
the PLL to drive the NAND Flash Interface Unit, which is internal to the Image
Exporter component.
This 55.555MHz clock is the same clock as clk, but the
Avalon slave interface does not allow components to be driven with more than one
clock. The fast clock input of the Image Exporter component is therefore dened
as an external signal in the Interface to User Logic wizard and connected to the
55.555MHz clock in the Quartus Block Diagram editor.
The write timing to the Image Exporter component is critical and set to execute
in a single clock cycle as illustrated in Figure 5.7.
CHAPTER 5.
DETAILED SYSTEM DESIGN
Figure 5.7:
5.3
67
Image Exporter's Avalon slave timing conguration
Hardware Design
5.3.1 FPGA and Conguration
The Altera Cyclone II EP2C35F484C6 FPGA is only manufactured in a Ball-grid
array (BGA) package [18]. With BGA packages, the I/O connections are on the
interior of the device, improving the ratio between pin count and board area, but
complicates debugging, as the pins are not directly accessible.
BGA packages can tolerate slightly imperfect placement during mounting as BGA
packages self-align during solder reow. Furthermore, BGA solder balls are considerably stronger than quad at pack (QFP) leads, resulting in robust packages that
can tolerate rough handling, which is ideal for satellite applications.
CHAPTER 5.
DETAILED SYSTEM DESIGN
68
The Cyclone II FPGA is a SRAM-based device and requires conguration data to
be reloaded at each power-up sequence. The design also necessitates a JTAG interface for debugging. The Active Serial (AS) conguration scheme is selected for this
design. To reduce the physical size of the design the JTAG Indirect Conguration
Device Programming technique is used.
With the JTAG Indirect Conguration
technique, both the JTAG interface and AS interface are bridged together, inside
the FPGA, with a serial ash loader design. This eliminates the use of a second
programming header on the PCB. The JTAG header can now be used for JTAG
conguration of the FPGA or for programming of the serial conguration device.
Serial conguration devices have a four-pin interface: serial clock input (DCLK),
serial data output (DATA), AS data input (ASDI), and an active low chip select (nCS). This four-pin interface connects to Cyclone II device pins, as shown
in Figure 5.8. The MSEL pins are setup to allow the fast active serial (40MHz)
conguration scheme. During device conguration, the Cyclone II reads the con-
Figure 5.8:
JTAG Indirect Conguration Device Programming [19]
CHAPTER 5.
69
DETAILED SYSTEM DESIGN
guration data via the serial interface and congures its SRAM cells. The FPGA
controls the conguration interface in the AS conguration scheme.
The EPCS16 serial conguration device [20] was selected for its memory size. The
EPCS16 has a capacity of 16,777,216 bits (2MB), of which approximately 7,071,234
bits [21] are used for the Cyclone II EP2C35's conguration le. The rest (9,705,982
bits
≈
1.16MB) can be used as a General Area to store code. Refer to Figure 5.4.
Intuitively it seemed possible to execute code stored in the EPCS serial ash memory, as all the necessary components (CPU Instruction and Data cache, On-Chip
RAM, and EPCS serial `secondary' memory) exists.
Unfortunately running code from the EPCS serial ash memory is not yet possible,
as discovered during the implementation of the design in hardware. The EPCS serial ash memory can, supplementary to being a conguration device, only be used
as a software boot-up medium and not as a secondary instruction storage memory.
The consequence of this is that the memory footprint of all the source code may
not exceed the memory size of the On-Chip memory (code footprint
≤
24Kbytes)
as no extra memory were included in the hardware design.
5.3.2 CMOS Image Sensor
The KAC-1310 Image sensor and a small PCB were supplied by SunSpace.
Al-
though these components were used for a previous project, it ts perfectly into this
camera system design. The PCB contains only the KAC-1310 and small components like resistors, decoupling capacitors, and choke inductors.
This PCB was designed to be attached to a lens system and connects to the rest of
the designed circuit through a 26-pin header. The power and all the clock-, pixel
2
data- and I C signals are interfaced through this header and a ribbon cable.
CHAPTER 5.
70
DETAILED SYSTEM DESIGN
5.3.3 NAND Flash Device
The Samsung K9K4G08U0M NAND ash device is selected for this design and
has a memory capacity of 512MB. As only 375MB is needed as determined in
Section 3.1.2 the extra 36.5% memory constitutes for bad blocks forming in the
device.
The
to
R/B
VCC
line is an open-drain driver. It requires a pull-up resistor,
and a decoupling capacitor,
CL , connected to ground.
A
Rp ,
connected
1kΩ resistor and a
100pF capacitor is selected according to the Samsung K9K4G08U0M datasheet [5].
Decoupling capacitors (100nF) are added between the
VCC
and ground pins to
reduce power supply noise to the device.
5.3.4 Communication Busses
All the LVDS and CAN bus signals are routed to a standard DB-9 female connector.
A device reset line (pin 1), a device enable line (pin 8) and a CRC error (pin 3)
signal are also routed to this DB-9 connector. These signals are intended as device
control signals for the OBC.
5.3.4.1 LVDS
A LVDS transmitter is implemented using Altera's LVDS MegaWizard in the
Quartus II software. The LVDS transmitter implements the serializer/deserializer
(SERDES) in logic elements and requires a phase-lock loop (PLL). The two LVDS
transmitting pins are manually placed on two dierentially paired pins located on
I/O Bank 8 of the Cyclone II. This I/O Bank is powered by 2.5V regulator, which
can be switched o when LVDS is not in use. This helps in reducing the overall
power usage of the camera system.
The resistor network, recommended by Altera, is implemented as shown in Figure 5.9. The resistor network attenuates the driver outputs to levels similar to the
CHAPTER 5.
71
DETAILED SYSTEM DESIGN
LVDS signalling, which is recognised by LVDS receivers with minimal eect on the
50Ω
trace impedance [22]. The two LVDS wires are routed to pins 4 and 5 of the
DB-9 connector.
Figure 5.9:
Termination Scheme on Cyclone II LVDS Transmitter
5.3.4.2 I2 C
2
SDA and SCL lines. The Kodak
3.3kΩ pull up resistors is followed.
The I C standard requires pull-up resistors on the
KAC-1310 datasheet's [4] suggestion to use
2
The I C
SDA
and
SCK
lines are bidirectional, open-drain pins on the FPGA,
which are set to high impedance when receiving or when transmitting a logic high.
These lines are connected to the 26-pin header (Section 5.3.2) that interfaces with
the KAC-1310 PCB from SunSpace.
5.3.4.3 CAN Bus
The CAN Bus physical layer is not part of the Bosch CAN standard, but transceiver
characteristics are included in the ISO 11898 (CAN High Speed) standard [23].
According to this standard
120Ω termination resistors are required.
are located on each end of the two-wire bus.
These resistors
CHAPTER 5.
72
DETAILED SYSTEM DESIGN
For testing of the CAN bus a PCAN-USB Adapter, from PEAK-System Technik,
will be used. PEAK-System Technik species that the
CAN -high
CAN -low
signal and the
signal must be connected to pins 2 and 7 respectively, of the DB-9
connector [24]. Pin 6 is connected to ground.
5.3.5 Clock and Reset
The FPGA requires an external clock source to execute the synchronous design. A
66.666MHz clock oscillator is selected for this design. To generate the required clock
frequencies of 55.555MHz, 27.775MHz and 15.151MHz for the design, an internal
PLL of the Cyclone II FPGA is used.
Figure 5.10:
Altera MegaWizard generated PLL with Locked signal output
This PLL is implemented using an Altera MegaWizard. See Figure 5.10. The PLL
locked signal is used as the global reset in the FPGA. This insures that the internal
state machines all reset and start simultaneously.
CHAPTER 5.
DETAILED SYSTEM DESIGN
73
5.3.6 Power System
5.3.6.1 Power Regulators
The design requires three dierent supply voltages. A 3.3V supply is needed for
the NAND ash device, the CMOS image sensor, and some of the FPGA's I/O
pins.
A 2.5V supply is needed for I/O Bank 8 of the FPGA to conform to the
LVDS signalling standard. The internal logic of the Cyclone II FPGA requires a
1.2V supply.
The preliminary specications of the design stated that the camera system should
operate from a power supply bus ranging anywhere between 5V and 12V. A National Semiconductor LM2651 1.5A high eciency, synchronous switching regulator
is chosen to convert the 5-12V power bus to a 3.3V power level. The LM2651 can
handle an input voltage range of 4V to 14V and is capable of supplying up to 1.5A
at an eciency of nearly 97%. See Appendix G.1 and [25] for detailed information
on the LM2651.
The 2.5V power supply voltage is achieved by using a ST LF25CPT Very Low
Drop regulator [26], which is powered by the 3.3V power supply. The LF25CPT
has a Shutdown Logic Control function which makes it possible to put the device
in an inhibit state and eectively shutting the regulator down.
This function is
used to power down I/O Bank 8 of the Cyclone II when LVDS is not in use. Refer
to Section 5.3.4.1.
A PowerPlay power analysis of the VHDL design in the Quartus II software stated
that
IIN T , of the Cyclone II EP2C35 FPGA, draws a maximum of 128.71mA during
operation. The Texas Instruments SN105125 150-mA Low Dropout regulator [27]
is selected as a suitable 1.2V power regulator and will also be powered from the
3.3V power supply.
CHAPTER 5.
74
DETAILED SYSTEM DESIGN
5.3.6.2 Power planes
The PLL circuits in Cyclone II devices contain analogue components embedded
in the digital device [19]. These analogue components have separate 1.2V power,
VCCA
P LL , and ground,
GN DA ,
pins to minimize noise generated by the digital
components. A choke circuit is used to isolate the
VCCA
P LL and
GN DA
from the
power to the rest of the circuit. See Appendix F for details.
The PCB consists of four layers of which, the two internal layers are used as power
planes, while the two external layers are used for signalling. One of the internal
layers is a dedicated ground plane, with a
PLL circuit.
contains
GN DA
power island for the analogue
The other internal layer is a 3.3V power plane.
1.2Vdigital , 1.2Vanalogue ,
and
2.5V
This power plane
power islands.
These ground and power planes distribute electrical power and heat better than
narrow tracks and minimise electromagnetic interference unintentionally formed by
the tracks.
5.3.7 Test Points and LEDs
To debug the circuit three status LEDs and multiple test points are added to the
PCB. The following test points are included in the design:
ˆ
18 General-purpose test points on unused FPGA I/O pins,
ˆ
Test points on all NAND ash device's pins,
ˆ
Test points on all voltage levels, including ground, and
ˆ
A test point on the clock oscillator's output.
The three LED's with current limiting resistors are:
ˆ
A power indicator LED (green),
CHAPTER 5.
75
DETAILED SYSTEM DESIGN
ˆ
FPGA congured LED (yellow), and an
ˆ
IP timeout indicator (red), also used as a `heartbeat' during debugging to
indicate that the design is downloaded to the FPGA correctly.
5.3.8 Device Placement and Routing
The I/O pins of the FPGA were manually grouped around the edges of the FPGA.
This was done to simplify routing and to keep tracks carrying similar signals the
same length. The propagation delay dierence, of the signals, is reduced by keeping
similar signal tracks the same length. I/O Bank 8 was used exclusively for the LVDS
signals as this I/O Bank is powered by the 2.5V power source.
When a PCB carries high frequencies, traces may need to be exact widths and
lengths to control the characteristic impedance of the traces.
High-speed PCB
design is a specialised skill and therefore, after the circuit was designed and drawn
in Altium's Protel DXP 2004, the schematic was given to a layout specialist to
design the PCB.
The specialist did device placement, and matched the LVDS and CAN bus traces'
characteristic impedance to the standards supplied by SunSpace.
The prototype PCB can be seen in Figures 5.11 and 5.12.
CHAPTER 5.
DETAILED SYSTEM DESIGN
Figure 5.11:
Figure 5.12:
Design routing and layout - Top layer
Design routing and layout - Bottom layer
76
Chapter 6
Simulations and Results
In this chapter, a report is given on the results and simulations for the system
design. The VHDL system design is tested by simulation for correct functionality.
The PCB is built and checked before a preliminary Nios II system is downloaded
to the Cyclone II. Interfacing to the KAC-1310 from the Nios II is then tested. An
initial Bad Block Table is created and a power analysis of the demonstration board
is done. A discussion on work in progress concludes the chapter.
6.1
VHDL Simulations
The correct functionality of the VHDL components can be simulated before they
are downloaded to the physical FPGA. Signals, internal to the FPGA and hidden
to the PCB, can be monitored within the simulator and speeds up development.
Altera's Quartus II 5.1 simulation software and ModelSim SE 5.8c were used to
simulate the design at various stages of development. All the simulations shown in
this chapter are gate-level timing simulations.
77
CHAPTER 6.
78
SIMULATIONS AND RESULTS
6.1.1 Critical Test Simulations
Numerous simulations were done during the development of the system to ensure
functionality and it is impossible to show and discuss them all in this thesis. Therefore, only critical test simulations are shown. These simulations demonstrate the
functionality of all the components with the help of examples.
6.1.1.1 Load Bad Block Table
A Load Bad Block Table sequence, refer to Section 5.1.1, demonstrates three key
parts of the design, namely a command decode, a page read, and an EDAC example.
Figures 6.1 and 6.2 illustrates the signal waveforms of a Load Bad Block Table
sequence.
Figure 6.3 claries the simulation signal names.
The paragraphs to
follow will discuss these signals in more detail.
Command Decode:
mand when the
(51h
The Image Exporter Module will only accept a new com-
readyN OT busy
= 01010001b )
signal is high.
is latched when the
See Figure 6.1.
cmd_enable
The command
signal is high. The rst 4 bits
in the command instruct that all the data must be routed to and from the Nios II.
The last 3 bits however override this instruction, as
001b
indicates a Load BBT
command which forces the output of the Output-FIFO to be routed to the BBT
memory region. This can be seen in Figure 6.1 where the data_out_bbt bus is set
to
00h
and the data_out_LVDS bus to high impedance (ZZ ).
NAND Flash Read Page:
by pulling the
command
30h
ce
The NAND Flash Read Page sequence is initiated
signal low before the command
are written to the ash device.
00h,
5 address cycles, and the
The 5 addresses are all
00h
since
the BBT is loaded from block 0, page 0. The device goes into a busy state and
the
ry _by
signal is manually forced low for simulation purposes. When
ry _by
is
forced high, the data is read from the ash device into the Output-FIFO, one byte
at a time, by toggling the
re
signal.
CHAPTER 6.
SIMULATIONS AND RESULTS
Figure 6.1:
Load Bad Block Table Waveforms, Segment 1
79
CHAPTER 6.
SIMULATIONS AND RESULTS
Figure 6.2:
Load Bad Block Table Waveforms, Segment 2
80
CHAPTER 6.
81
SIMULATIONS AND RESULTS
Figure 6.3:
Block Diagram of Image Exporter with Simulation signal names
From the simulation, it can be seen that the following data is being loaded as the
BBT:
5Ah, 01h, 02h, 03h,
etc. This is because a counter is used to fake the input
from the ash device, as no ash simulation model is available.
In addition, a
normal BBT will mostly consist of 1's, which will make it dicult to distinguish
between individual bytes read from the device.
The 512 bytes of BBT data from the NAND ash will now be sequentially clocked
into the Output-FIFO, followed by 1536 dummy bytes and 12 ECC bytes.
The
simulation waveforms continue on Figure 6.2
Error Detection and Correction:
To illustrate that the EDAC operates cor-
rectly, the rst byte, read from the ash device, is injected with a one-bit error. The
read byte is
5Ah = 01011010b ,
but should be
58h = 01011000b
according to the
ECC bytes read from the device on the data_io_nand bus, shown in Figure 6.2.
The 12 ECC bytes (55h,
55h, 59h,
and nine
00h's)
were computed for a data
CHAPTER 6.
82
SIMULATIONS AND RESULTS
stream created from a counter, where the rst data
bad_address
(0001h, 1000h, 1000h and 1000h)
00h
was replaced with
bad_strobe
58h.
As seen in the simulation the
and
signals sends 4 bad
addresses
to the Correction unit. Each address
indicates a possible bad byte in a 512-byte protected segment.
in
0001h
The MSB (0b )
indicates that a correctable error exists in the rst 512-byte protected
segment. The rest of the bits indicate that Byte 0, Bit 1 is at fault and needs to
be ipped. The correction can be seen on the
been corrected to
58h.
The
data_out_bbt
bus where
5Ah
has
1000h words indicate that no error or correctable error
exists in the following three 512-byte protected segments.
6.1.1.2 Store Bad Block Table
The Store Bad Block Table sequence, refer to Section 5.1.1, demonstrates a block
erase, status bit check and a page write.
After the Store Bad Block Table command (52h ) is given, the Store Bad Block Table
sequence starts by ushing the BBT from the internal BBT memory into the InputFIFO, while simultaneously instructing the NAND Flash Interface module to erase
Block 0 of the ash device. See Figure 6.4. The 512 BBT bytes are followed by the
last downloaded page- and last written page
addresses. Six demonstration pointer bytes (F Ch, 01h, 02h, F F h, 04h and 05h)
can be seen in Figure 6.5 on the data_in_bbt bus.
two 3-byte pointers used to store the
NAND Flash Erase Block:
eration. The
ce
Figure 6.4 also illustrates a ash block erase op-
signal is pulled low and the command
60h
is written to the ash
device. As the column and page address is not needed, only three address cycles
are written to the device. The address cycles are all
00h
since Block 0 is erased.
D0h command after which the device enters
a busy state (ry _by low) for a period of tBERS . This period can typically range between 2ms and 3ms. For demonstration purposes, this time was drastically reduced
to 80ns. The erase operation is complete when ry _by goes high.
The address cycles are followed by the
CHAPTER 6.
SIMULATIONS AND RESULTS
Figure 6.4:
Store Bad Block Table Waveforms, Segment 1
83
CHAPTER 6.
84
SIMULATIONS AND RESULTS
Figure 6.5:
Check Status Bit:
formed by writing a
a toggle of the
re
Store Bad Block Table Waveforms, Segment 2
Once the erase operation is complete a check status is per-
70h command to the ash device.
The status byte is read with
signal. If the LSB of the read status byte is
0b
then the erase
operation was successful.
NAND Flash Write Page:
operation.
After the
ce
Figures 6.6 and 6.7 demonstrates a page write
signal is pulled low the command
ash device. The ve address cycles are all
80h
is written to the
00h since the BBT is stored in Block 0,
Page 0. The counter generated BBT data and 12 ECC bytes are now written one
we signal. To mark the end of the page and to
initiate the program operation, the 10h command is written to the ash device.
The device enters a busy state (ry _by low) for a period of tP ROG , which can last
byte at a time while toggling the
CHAPTER 6.
SIMULATIONS AND RESULTS
Figure 6.6:
Store Bad Block Table Waveforms, Segment 3
85
CHAPTER 6.
SIMULATIONS AND RESULTS
Figure 6.7:
Store Bad Block Table Waveforms, Segment 4
86
CHAPTER 6.
up to
700us.
87
SIMULATIONS AND RESULTS
The
ry _by
goes high when the program command is complete. From
the simulation, it can be seen that the success of the write is tested by checking
the status bit again.
6.1.1.3 Valid Block Address Generation
To demonstrate the generation of valid block addresses, the Erase All sequence
(Section 5.1.1) is illustrated in Figure 6.8. The Erase All sequence will sequentially
erase all the blocks in the NAND ash device while skipping all the bad blocks in
the device.
Erasing starts at Block 0 of the ash device. A
check _block _adr_req
pulse indi-
cates that a new valid block address must be generated. The internal BBT memory
region is accessed and a byte containing BBT indicator bits (Figure 4.5) is read on
the
bbt_q _portA
Block Table, i.e.
bus. The simulation shows the rst two bytes read from the Bad
01111110b
and
11011111b .
The zero bits in these bytes indicate
that Block 0, Block 7, and Block 13 are marked as bad blocks. In practice, Block 0
will never be marked as a bad block, but for the simulation, the robustness of the
code is tested to make sure that the BBT can not accidentally be erased. When a
adr_generated signal goes high
the generated_block _adr bus.
valid block address is generated the
block address will be available on
and the valid
The shaded area in Figure 6.8 shows the erase page sequence for Block 1.
This
process will be repeated for all the valid blocks in the ash device. The simulation
shows that Block 7 and Block 13 are skipped and not erased, since they are marked
as bad blocks.
6.1.2 Creating the rst BBT
An altered version of the Image Exporter in conjunction with the Nios II system is
used to determine the initial BBT and to count the initial bad blocks found in the
NAND ash device. The number of bad blocks is then written to the screen of the
development PC via the JTAG UART.
CHAPTER 6.
SIMULATIONS AND RESULTS
Figure 6.8:
Erase All Sequence Waveform
88
CHAPTER 6.
SIMULATIONS AND RESULTS
89
Simulations indicated that this process should work, but in practice, some diculties were experienced when implemented on the demonstration board. It seemed
that the NAND ash device never returned from its busy state, because the R/B
pin would not return to logic high. It was discovered that the R/B pull-up resistor
was omitted from the schematic and PCB. After it was inserted, the NAND ash
device responded as expected.
Another problem surfaced, the Initial BBT Generator design reported that almost
all the blocks in the device were invalid! The reported number of bad blocks also
varied with every execution. Initially it was thought that timing errors were the
cause for these irregular results. A logic analyzer was hooked up to the test points
on the NAND ash chip. The logic analyzer showed that the signal timings were
correct and that hardly any initial bad blocks exist in the device. With the logic
analyzer, only blocks 1111, 3040, and 4062 were manually found as bad blocks.
The problem was thus localised in the VHDL code. After an in-depth inspection of
the code, it was realised that two state machines occasionally lost synchronisation
when the R/B line went high. This was an unforeseen case in the simulations, since
the R/B line was at all times controlled manually and not by a simulation model.
After both state machines were synchronised to the R/B line, the system reported
consistent results.
Eventually, ve bad blocks were found repeatedly in the NAND ash chip populated
on the demonstration board.
6.2
Nios II Simulations and Measurements
The Nios II IP is downloaded to the Cyclone II device via a JTAG cable. The Nios II
IP used for development is an evaluation version and requires the JTAG cable to
stay connected to the development board in order to prevent the Nios II IP to stop
functioning after one hour. Storing a Nios II IP core in the EPCS conguration
device is prohibited and this is enforced by the Altera software.
During implementation of the Nios II in hardware it was discovered that only a
CHAPTER 6.
90
SIMULATIONS AND RESULTS
reduced driver set for the Nios II system can be downloaded to the Cyclone II,
since the Onboard Memory size is limited to 24Kbytes (Section 5.2.2.2). The main
drawback of a reduced driver set is that drivers, relying on software functions based
on the getc command in ANSI C, are omitted. Consequently, the host PC is not
able to emulate an OBC by sending commands via the JTAG UART and thus
facilitates only one-way communication from the Nios II to the host PC.
The Nios II processor, executing code, can be simulated in ModelSim. This is useful
to determine Avalon bus access times to User Logic components, as information on
this topic is limited. Figure 6.9 shows an example where the CMOS Image Sensor
Interface's FIFO is accessed. This buer FIFO was packed with dummy counter
bytes and its output can be seen on the
readdata bus.
The example also illustrates
the speed (486ns/word) at which 32-bit words can be transferred from User Logic
to Onboard Memory.
6.3
Kodak KAC-1310 Interfacing
2
The CMOS Image Sensor Interface and the I C Module is used to access the KAC1310 from the Nios II. The CMOS Image Sensor Interface needs to generate a
MCLK for the operation of the KAC-1310. Due to timing constraints, the Quartus
tter program can not implement a working MCLK slower than 1.26MHz, from the
15.151MHz clock supplied by the PLL. This poses no problem as the pixel data
rate, of 1.19MB/s, can easily be handled when the KAC-1310 is clocked with a
MCLK of 1.26MHz.
The CMOS Image Sensor Interface initialises the KAC-1310 by pulling the KAC1310's INIT pin high for
1ms
and low for a further
1ms.
2
The I C Module is used for communication between the Nios II and KAC-1310.
2
However the I C Module software drivers had to be altered because the command
sequences did not comply with the KAC-1310's specications. The
SCL frequency
was also set in software to 50kHz as the KAC-1310 is a slave device that supports a
maximum clock rate (SCL) of
1/24th
2
MCLK [4]. The I C signals were scrutinized
CHAPTER 6.
SIMULATIONS AND RESULTS
Figure 6.9:
Avalon access times to CMOS Image Sensor Interface Module
91
CHAPTER 6.
92
SIMULATIONS AND RESULTS
with the help of an oscilloscope and found to operate perfectly. The setup regis-
2
ters in the KAC-1310 were updated successfully via the I C bus as the KAC-1310
responded as expected.
Figure 6.10:
Sub-sampled photo taken with the camera system (160×100 pixels)
2
When the KAC-1310 is instructed, via I C, to capture a sub-sampled image, pixel
data can be seen on the pixel data bus with an oscilloscope.
The FIFO in the
CMOS Image Sensor Interface latches these bytes and the Nios II outputs the data
to the host PC via the JTAG UART. Unfortunately, the image received does not
look like a photo, as shown in Figure 6.10.
To isolate the problem the input to the FIFO, in the CMOS Image Sensor Interface,
was replaced with a counter that increments on every rising edge of the received
HCLK. The counter data read from the FIFO to the host PC proved to be correct
and the problem was isolated to the latching of unsynchronised signals, external to
the FPGA. This debugging process was still in progress at the time of writing this
thesis.
CHAPTER 6.
6.4
93
SIMULATIONS AND RESULTS
Demonstration Board Testing and
Measurements
During the manufacturing of the PCB, two copies of the same PCB were made
to test the demonstration board systematically. After testing the blank PCB for
short circuits, the rst demonstration board was populated with the complete power
supply. This includes all the power regulators, necessary capacitors, inductors, and
resistors. The clock oscillator chip was also mounted on the board. All the power
regulators were successfully tested to output the correct voltage levels.
The clock oscillator provides a perfect 66.666MHz sinusoidal waveform. An oscilloscope with an FFT function was used to see if the clock oscillator added any
intolerable noise harmonics to the power rails.
As the clock's interference were
found to be negligible (-50dB for the rst harmonic measured on the 3.3V power
plane) it was decided to populate the second board with the Cyclone II.
To ease the placing of the BGA packaged Cyclone II the second board was at
rst only populated with the Cyclone II's decoupling capacitors, after which the
Cyclone II FPGA was placed on the PCB. This was done so that conducted heat
would not violate the integrity of the BGA ball connections during soldering of the
remaining components.
All the remaining components apart from the NAND ash chip were soldered onto
the second demonstration PCB. The functionality of the Cyclone II was veried
before the NAND ash chip was added. The Cyclone II and the EPCS conguration
device were conrmed to work by loading the EPCS conguration device with a
simple heartbeat design. The heartbeat design ashes a LED on and o and worked
since the rst time it was loaded.
Designs that are more complex were progressively loaded onto the FPGA and
incrementally tested, until the camera design was complete. The full design uses
22% of the total logic elements in the Cyclone II, which leaves ample space for
potential expansions.
CHAPTER 6.
94
SIMULATIONS AND RESULTS
6.4.1 Power and Area Calculations
Area
67mm × 69mm equalling
an area of 46.23cm while the SunSpace KAC-1310 PCB measures 32mm × 45mm,
2
equalling an area of 14.4cm . The total design thus have a remarkably compact
2
area of 60.63cm .
The dimensions of the demonstration PCB are
2
Power
The demonstration board's power consumption was measured with only
the power supply unit and clock oscillator installed on the board. This yielded a
power usage of
63mW .
After the remaining components were added to the board
and the heartbeat design was running on the system, the power usage increased to
534mW .
When the KAC-1310 board was connected to the demonstration board the power
usage increased to
910mW .
The Nios II was then instructed to initialise the KAC-
1310 and the power consumption surged to a further
was drastically reduced to
973mW
1.376W .
This power usage
when the KAC-1310 was instructed to make use
of an external bias resistor and to operate in the Soft Standby mode [4].
It is interesting to note that the power consumption of the camera system drops
to
852mW
while the Nios II waits for data from the Avalon bus. This is probably
because the Nios II's pipeline stalls until data arrives.
The demonstration board contains three LEDs, each consuming
7mW , 21mW
in
total, and this excess power can be subtracted from the system's total power usage.
The system's peak power consumption is thus
power usage of
952mW
and this is below the required
1W .
During power cycling of the camera system onboard the nanosatellite it is expected
that the camera will not operate longer than
952mW
at peak for
1.5
1.5
seconds gives a rating of
seconds at a time.
397µW h,
Consuming
which is exceptionally
low. If this camera system were to operate from a Nickel Metal Hydride (NiMH)
2300mAh, 1.5V AA Rechargeable Battery it would be able to take one photo, every
hour, for 362 days without the need to recharge the battery. This performance is
ideal for a subsystem onboard a nanosatellite.
CHAPTER 6.
6.5
SIMULATIONS AND RESULTS
95
Work in progress
The camera system does not take proper photos and this need to be corrected. As
mentioned before the debugging process was still in progress at the time of writing.
The next step in the debugging process would be to route counter bit lines out of
the FPGA and back into the I/O pins of the buer FIFO. By doing this, known
data can be latched by the FIFO and hopefully, the error can be identied and
corrected.
The Opencores.org open-source CAN bus module, selected for this design, lacks
documentation and the code is written in Verilog. The CAN bus core has not been
implemented on the FPGA as there was no time for the author to learn Verilog.
Further research on other available CAN bus cores needs to be done or Verilog must
be studied if the cheaper option is to be followed.Also CAN transceivers need to
be implemented in hardware, which is required to perform the bit-wise arbitration
by producing dominant and recessive bits on the bus.
Currently the LVDS downlink has not been tested in hardware, as no LVDS receiver
device was available for testing. The LVDS transmitter is provided by Altera and
it should work when tested in the future.
Chapter 7
Conclusions and Recommendations
7.1
Conclusions
In this thesis, a camera system for a nanosatellite based on a CMOS image sensor
is designed.
The design specications and constraints were investigated.
A ver-
satile design was proposed where all the required functions are implemented on a
single FPGA. This includes BBT management, data routing, an EDAC, a soft-core
processor, glue logic to external devices, and communication busses.
Low power
and compact devices were selected to minimize the power usage and the physical
size of the camera system.
The Altera Nios II/f soft-core processor was implemented as a controller for its
high processing speed and fast access time to other on-chip components. Using a
processor enables changes to the system to be easily made in software.
An alternative solution for transferring image data from the Nios II was found
when the DMA controller could not be implemented due to memory limitations.
The Nios II manually transfers the data from memory, while the data received
from the KAC-1310 is buered in a FIFO. Simulations of the Nios II processor
determined its access times to external logic enabling the minimum depth of this
FIFO to be derived.
96
CHAPTER 7.
97
CONCLUSIONS AND RECOMMENDATIONS
Although the author had no real previous experience with VHDL, VHDL logic
components were developed to be interfaced with the Nios II system.
All these
components conform to the Avalon slave standard.
The NAND ash memory size was selected large enough making the camera system
capable of storing more than a 100,
1024 × 1024
pixel, images. To make the mass
memory more robust against radiation and random bit ips, a Hamming EDAC
scheme was implemented in VHDL.
The occurrence of bad blocks during the lifetime of a NAND ash device posed an
internal address generation problem. This was solved with an
8 × 512
bit lookup
table, which enables the status of every block to be represented as valid or invalid.
By mapping out all the bad block addresses, the memory space appears continuous.
Wear levelling is accomplished by writing and erasing all blocks equally often.
One of the main challenges of this design was to transfer data from the CMOS
image sensor to the NAND ash memory device, while simultaneously downloading
images from the NAND ash memory. Dual-clock FIFOs were implemented to shift
the data around, making it possible to input data into the FIFO at one particular
data rate while concurrently outputting data from the FIFO at a dierent data
rate.
Components used on a nanosatellite must use power conservatively. Power regulators were chosen for their high eciency and compactness.
power consumption is
952mW
The system's peak
which is below the required power usage of
1W
making it ideal for a subsystem onboard a nanosatellite.
Although the project was cut short before the camera system could operate 100% as
intended, most of the system requirements were met. In addition, a good mixture
of IP soft-cores, open-source cores, and user created logic are utilised in this broad
base design, containing a combination of hardware, digital logic, and software.
The design was kept both simple and modular for straightforward upgrades and
maintenance in the future.
CHAPTER 7.
7.2
CONCLUSIONS AND RECOMMENDATIONS
98
Recommendations
The following recommendations are made with regards to the future development
of a camera system unit for the nanosatellite using a CMOS Image Sensor and
NAND ash memory:
ˆ
ECC can be done on smaller partitions, resulting in an even more reliable
data storage system.
ˆ
A backup of the original BBT can be stored in the second page of block 0 for
redundancy.
ˆ
A simple DMA controller can be written in VHDL to relieve the workload on
the Nios II processor.
ˆ
The LVDS download speed can be made adjustable for simpler interfacing
with slower systems.
Finally, complete functional-, radiation- and extreme temperature testing of the
demonstration board will give valuable information on how the camera system
might operate in a space environment.
List of References
[1]
Wertz, J.R. and Larson, W.J.:
Space Mission Analysis and Design.
Space
Technology Library, 3rd edn. Microcosm Press and Kluwer Academic Publishers, El
Segundo, California, 1999.
[2]
Bryer, B.:
Protection Unit for Radiation Induced Errors in Flash Memory Systems.
Master's thesis, University of Stellenbosch, 2004.
[3]
Horsburgh, I.J.:
The Development of a Mass Memory Unit for a Micro-Satellite
using NAND Flash Memory.
Master's thesis, University of Stellenbosch, 2005.
[4]
Kodak: KODAK KAC-1310 Image Sensor. Tech. Rep., Kodak, 2002.
[5]
Samsung: 512M x 8 Bit / 1G x 8 Bit NAND Flash Memory. Tech. Rep., Samsung
Electronics, 2005.
[6]
Altera:
Avalon Interface Specication.
Altera Corporation, San Jose, CA, 3rd edn,
2005. mnl_avalon_spec.pdf.
[7]
Altera:
Nios II Processor Reference Handbook.
Altera Corporation, San Jose, CA,
6th edn, 2006. n2cpu_nii51001.pdf.
[8]
Kalinsky, D. and Kalinsky, R.: Introduction to I2C. www.embedded.com, July
2001. http://www.embedded.com/story/OEG20010718S0073.
[9]
Laboratory of Architecture of the Processors FPSL: Fiche technique du module
I2 C. Tech. Rep., Federal Polytechnic School of Lausanne, Switzerland, 2005.
[10] The Free Encyclopedia. www.wikipedia.org, 2005-2006.
99
100
LIST OF REFERENCES
[11] National Semiconductor Corporation: National announces rst implementation of
new IEEE and TIA LVDS (Low Voltage Dierential Signal) standard.
www.national.com/news, April 1996.
http://www.national.com/news/1995/9502/dm95001dtp.html.
[12] Altera:
Error Detection & Recovery Using CRC in Altera FPGA Devices.
Altera
Corporation, San Jose, CA, 1st edn, 2006. an357.pdf.
[13] Memory Product & Technology Division:
Memory.
Samsung Electronics, 2nd edn, 1999.
[14] Memory Division Samsung Electronics:
Standard.
APPLICATION NOTE for NAND Flash
NAND Flash Spare Area Assignment
Samsung Electronics, February 2003.
spare_assignment_standard_20030221.pdf.
[15] Altera:
Designing With High-Density BGA Packages for Altera Devices.
Altera
Corporation, San Jose, CA, 4th edn, 2006. n2cpu_nii5v3.pdf.
[16] Altera:
Nios II Flash Programmer User Guide.
Altera Corporation, San Jose, CA,
1st edn, 2005. Ug_nios2_ash_programmer.pdf.
[17] Altera:
Developing Peripherals for SOPC Builder.
Altera Corporation, San Jose,
CA, 1st edn, 2004. an333.pdf.
[18] Altera:
Designing With High-Density BGA Packages for Altera Devices.
Altera
Corporation, San Jose, CA, 4th edn, 2006. an114.pdf.
[19] Altera:
Cyclone Device Handbook, Volume 1.
Altera Corporation, San Jose, CA,
1st edn, 2005. cyc_c5v1.pdf.
[20] Altera:
Altera Conguration Devices.
Altera Corporation, San Jose, CA, 2nd edn,
2005. cfg_ch1_vol_2 - Cong handbook Vol 2.
[21] Altera:
Serial Conguration Devices (EPCS1, EPCS4, EPCS16 & EPCS64)
Features.
Altera Corporation, San Jose, CA, 2nd edn, 2005. cyc_c51014 - Cong
handbook Vol2 Ch4.pdf.
[22] Altera:
Cyclone II Device Handbook, Volume 1.
2nd edn, 2005. cyc2_cii5v1.pdf.
Altera Corporation, San Jose, CA,
101
LIST OF REFERENCES
[23] Nilsson, S.: Controller area network - can information.
http://www.algonet.se/staann/developer/CAN.htm, June 1997.
Staann@algonet.se.
[24] PEAK System Technik:
PCAN-USB Adaptor Hardware Manual.
PEAK System
Technik GmbH, Darmstadt, Germany, 1.3 edn, 2002. PCAN-USB_ENG.pdf.
[25] National Semiconductor: LM2651 1.5A High Eciency Synchronous Switching
Regulator. Tech. Rep., National Semiconductor Corporation, 2005.
[26] ST: LF00 Series - Very Low Drop Voltage Regulators with Inhibit. Tech. Rep., ST,
2004.
[27] Texas Instruments: SN105125 150-mA Low Dropout Regulator with POK. Tech.
Rep., Texas Instruments Incorporated, 2002.
Appendices
102
Appendix A
Kodak KAC-1310 Datasheet
103
APPENDIX A.
KODAK KAC-1310 DATASHEET
Figure A.1:
Kodak KAC-1310 CMOS Image Sensor Datasheet, Page 5 [4]
104
Appendix B
Samsung K9K4G08U0M Datasheet
105
APPENDIX B. SAMSUNG K9K4G08U0M DATASHEET
Figure B.1:
Samsung K9K4G08U0M NAND Flash Datasheet, Page 2 [5]
106
Appendix C
imageexporter_regs.h
/*
Eric Baker - 2006/01/19
*/
# ifndef __IMAGEEXPORTER_REGS_H__
# define __IMAGEEXPORTER_REGS_H__
# include < io .h >
// Register Addresses
# define IE_COMMAND 0
# define IE_DATA
1
# define IE_STATUS 2
// Read from Image Exporter
# define IORD_IE ( base , offset )
IORD ( base , offset )
// Write to Image Exporter
# define IOWR_IE ( base , offset , data )
IOWR ( base , offset , data )
// input select bits mask
# define IMAGE_EXPORTER_COMMAND_INPUT_SELECT_MSK
# define IMAGE_EXPORTER_COMMAND_INPUT_SELECT_OFST
(0 xC0 ) // 11000000
(6)
// output select bits mask
# define IMAGE_EXPORTER_COMMAND_OUTPUT_SELECT_MSK
# define IMAGE_EXPORTER_COMMAND_OUTPUT_SELECT_OFST
(0 x30 ) // 00110000
(4)
// buffer in FIFO bit mask
# define IMAGE_EXPORTER_COMMAND_inFIFO_BUFFER_MSK
# define IMAGE_EXPORTER_COMMAND_inFIFO_BUFFER_OFST
(0 x08 ) // 00001000
(3)
107
108
APPENDIX C. IMAGEEXPORTER_REGS.H
// instruction bits mask
# define IMAGE_EXPORTER_COMMAND_INSTRUCTION_MSK
# define IMAGE_EXPORTER_COMMAND_INSTRUCTION_OFST
(0 x07 ) // 00000111
(0)
// status bits mask
# define IMAGE_EXPORTER_STATUS_FLASH_BUSY_MSK
# define IMAGE_EXPORTER_STATUS_FLASH_BUSY_OFST
# define IMAGE_EXPORTER_STATUS_inFIFO_HALF_FULL_MSK
# define IMAGE_EXPORTER_STATUS_inFIFO_HALF_FULL_OFST
# define IMAGE_EXPORTER_STATUS_inFIFO_FULL_MSK
# define IMAGE_EXPORTER_STATUS_inFIFO_FULL_OFST
# define IMAGE_EXPORTER_STATUS_outFIFO_EMPTY_MSK
# define IMAGE_EXPORTER_STATUS_outFIFO_EMPTY_OFST
# define IMAGE_EXPORTER_STATUS_FLASH_FULL_MSK
# define IMAGE_EXPORTER_STATUS_FLASH_FULL_OFST
# define IMAGE_EXPORTER_STATUS_ALL_IMAGES_DOWNLOADED_MSK
# define IMAGE_EXPORTER_STATUS_ALL_IMAGES_DOWNLOADED_OFST
(0 x01 )
(0)
(0 x02 )
(1)
(0 x04 )
(2)
(0 x08 )
(3)
(0 x10 )
(4)
(0 x20 )
(5)
// Constants
# define IMAGE_EXPORTER_INPUT_CAMERA
(0 x0 )
# define IMAGE_EXPORTER_INPUT_NIOS
(0 x1 )
# define IMAGE_EXPORTER_OUTPUT_LVDS
(0 x0 )
# define IMAGE_EXPORTER_OUTPUT_NIOS
(0 x1 )
# define IMAGE_EXPORTER_inFIFO_BUFFER_ENABLE
# define IMAGE_EXPORTER_inFIFO_BUFFER_DISABLE
# define IMAGE_EXPORTER_LOAD_BTT
(0 x1 )
# define IMAGE_EXPORTER_STORE_BTT
(0 x2 )
# define IMAGE_EXPORTER_ERASE_FLASH
(0 x3 )
# define IMAGE_EXPORTER_WRITE_PAGE
(0 x4 )
# define IMAGE_EXPORTER_READ_PAGE
(0 x5 )
# define IMAGE_EXPORTER_RESET_FLASH
(0 x6 )
# endif /* __IMAGE_EXPORTER_REGS_H__ */
// 0000
// 0001
// 0000
// 0001
0
1
// 0001
// 0010
// 0011
// 0100
// 0101
// 0110
// 00000001
// 00000010
// 00000100
// 00001000
// 00010000
// 00100000
Appendix D
image_exporter_avalon_interface.vhd
-- Eric Baker
-- 13 January 2006
LIBRARY ieee ;
USE ieee . STD_LOGIC_1164 . ALL ;
USE ieee . STD_LOGIC_unsigned . ALL ;
USE ieee . numeric_std . ALL ;
ENTITY image_exporter_avalon_interface is
PORT (
-- inputs :
address
: IN STD_LOGIC_VECTOR (1 DOWNTO 0);
chipselect
: IN STD_LOGIC ;
clk
: IN STD_LOGIC ;
reset
: IN STD_LOGIC ;
write
: IN STD_LOGIC ;
writedata
: IN STD_LOGIC_VECTOR (7 DOWNTO 0);
read : IN STD_LOGIC ;
-- outputs :
irq
readdata
-- exports :
clk55M
: OUT STD_LOGIC ;
: OUT STD_LOGIC_VECTOR (7 DOWNTO 0);
: IN STD_LOGIC ; -- from pll
-- Interface with NAND Flash lines
data_nand
: INOUT STD_LOGIC_VECTOR (7 DOWNTO 0);
ry_by : IN STD_LOGIC ;
-- Ready / busy line
ale
: OUT STD_LOGIC ;
-- Address latch enable
cle
: OUT STD_LOGIC ;
-- Command Latch enable
109
-- Bidirectional data lines
APPENDIX D. IMAGE_EXPORTER_AVALON_INTERFACE.VHD
110
we
: OUT STD_LOGIC ;
-- Write enable
re
: OUT STD_LOGIC ;
-- Read enable
wp
: OUT STD_LOGIC ;
-- Write Protect
ce
: OUT STD_LOGIC ;
-- Chip enable
-- Data in
data_in_camera
: IN STD_LOGIC_VECTOR (7 DOWNTO 0);
-- Data out
data_out_LVDS
: OUT STD_LOGIC_VECTOR (7 DOWNTO 0);
data_out_strobe
: OUT STD_LOGIC ;
-- test signals
l_wrt_p_a ,
l_dwn_p_a
: OUT STD_LOGIC_VECTOR (17 DOWNTO 0);
adr_generatedt ,
lastblk ,
ck_blk_adr_rq
: OUT STD_LOGIC ;
block_adrt
: OUT STD_LOGIC_VECTOR (11 DOWNTO 0);
bb_qat , bb_qbt
: OUT STD_LOGIC_VECTOR (7 DOWNTO 0);
rdreq_outQt
: OUT STD_LOGIC ;
dout2 , dout3 , dout4 ,
data_out_bbt ,
data_in_bbt
: OUT STD_LOGIC_VECTOR (7 DOWNTO 0);
bad_addresst
: OUT STD_LOGIC_VECTOR (12 DOWNTO 0);
bad_strobet
: OUT STD_LOGIC ;
cor_readyt ,
clk_outt
: OUT STD_LOGIC ;
wr_fifo , wr_flash
: OUT STD_LOGIC
);
END ENTITY image_exporter_avalon_interface ;
ARCHITECTURE image_exporter_avalon_interface_architecture
OF image_exporter_avalon_interface IS
COMPONENT image_exporter IS
PORT (
clk55M
: IN STD_LOGIC ; -- 55 MHz ClK in
clk
: IN STD_LOGIC ; -- 27.5 MHz Clk in
reset
: IN STD_LOGIC ; -- Global Reset
-- Interface with NAND Flash lines
data_nand
: INOUT STD_LOGIC_VECTOR (7 DOWNTO 0);
-- Bidirectional data lines
ry_by
: IN STD_LOGIC ; -- Ready / busy line
ale
: OUT STD_LOGIC ; -- Address latch enable
cle
: OUT STD_LOGIC ; -- Command Latch enable
we
: OUT STD_LOGIC ; -- Write enable
re
: OUT STD_LOGIC ; -- Read enable
wp
: OUT STD_LOGIC ; -- Write Protect
ce
: OUT STD_LOGIC ; -- Chip enable
-- Control from NIOS
command
: IN STD_LOGIC_VECTOR (7 DOWNTO 0);
-- command from NIOS
APPENDIX D. IMAGE_EXPORTER_AVALON_INTERFACE.VHD
111
-- Input_sel [7..6]| Output_sel [5..4]| Buffer_Image [3]| Instr [2..0]
cmd_ena
: IN STD_LOGIC ; -- accept command from NIOS
-- Warnings to NIOS
readyNOTbusy : OUT STD_LOGIC ; -- is system executing a command , ie . ready not busy
all_downloaded
: OUT STD_LOGIC ; -- all pages in flash have been downloaded
all_written : OUT STD_LOGIC ; -- all pages in flash have been written
rdempty_outQ : OUT STD_LOGIC ;
wrfull_inQ
: OUT STD_LOGIC ;
fifo_half_full
: OUT STD_LOGIC ; -- Interupt for NIOS to start Writing page to Flash
-- Data in
data_in_camera
: IN STD_LOGIC_VECTOR (7 DOWNTO 0);
data_in_nios
: IN STD_LOGIC_VECTOR (7 DOWNTO 0);
-- Data out
data_out_LVDS
: OUT STD_LOGIC_VECTOR (7 DOWNTO 0);
data_out_nios
: OUT STD_LOGIC_VECTOR (7 DOWNTO 0);
data_out_strobe
: OUT STD_LOGIC ;
-- test signals
l_wrt_p_a ,
l_dwn_p_a
: OUT STD_LOGIC_VECTOR (17 DOWNTO 0);
adr_generatedt ,
lastblk ,
ck_blk_adr_rq
: OUT STD_LOGIC ;
block_adrt
: OUT STD_LOGIC_VECTOR (11 DOWNTO 0);
bb_qat , bb_qbt
: OUT STD_LOGIC_VECTOR (7 DOWNTO 0);
rdreq_outQt
: OUT STD_LOGIC ;
dout2 , dout3 , dout4 ,
data_out_bbt ,
data_in_bbt
: OUT STD_LOGIC_VECTOR (7 DOWNTO 0);
bad_addresst
: OUT STD_LOGIC_VECTOR (12 DOWNTO 0);
bad_strobet
: OUT STD_LOGIC ;
cor_readyt ,
clk_outt
: OUT STD_LOGIC ;
wr_fifo , wr_flash
: OUT STD_LOGIC
);
END COMPONENT image_exporter ;
SIGNAL
SIGNAL
SIGNAL
SIGNAL
status_vector , status_vector_old : STD_LOGIC_VECTOR (7 DOWNTO 0);
command , data_in_nios , data_out_nios : STD_LOGIC_VECTOR (7 DOWNTO 0);
cmd_ena : STD_LOGIC ;
readyNOTbusy ,
all_downloaded ,
all_written ,
rdempty_outQ ,
wrfull_inQ ,
fifo_half_full : STD_LOGIC ;
BEGIN
status_vector <= " 00 " & all_downloaded & all_written & rdempty_outQ & wrfull_inQ
APPENDIX D. IMAGE_EXPORTER_AVALON_INTERFACE.VHD
112
& fifo_half_full & NOT readyNOTbusy ;
PROCESS ( clk , reset )
BEGIN
IF reset = '1 ' THEN
irq <= '0 ';
status_vector_old <= ( others = > '0 ');
ELSIF rising_edge ( clk ) THEN
IF ( status_vector XOR status_vector_old ) = 0 THEN
irq <= '0 ';
ELSE
irq <= '1 ';
END IF ;
status_vector_old <= status_vector ;
END IF ;
END PROCESS ;
PROCESS ( clk , reset )
BEGIN
IF reset = '1 ' THEN
cmd_ena <= '0 ';
command <= ( others = > '0 ');
data_in_nios <= ( others = > '0 ');
ELSIF rising_edge ( clk ) THEN
cmd_ena <= '0 ';
command (3) <= '0 ';
IF ( chipselect = '1 ' AND write = '1 ') THEN
CASE address IS
WHEN " 00 " = > command <= writedata ;
cmd_ena <= '1 '; -- latch valid command
WHEN " 01 " = > data_in_nios <= writedata ;
command (3) <= '1 '; -- make wrreq_inQ high to allow one byte into inFIFO .
-- command (3) not restricted by cmd_ena .
WHEN OTHERS = > NULL ;
END CASE ;
END IF ;
END IF ;
END PROCESS ;
PROCESS ( clk , reset )
BEGIN
IF reset = '1 ' THEN
readdata <= ( others = > '0 ');
ELSIF rising_edge ( clk ) THEN
IF ( chipselect = '1 ' AND read
CASE address IS
WHEN " 00 " = > readdata <=
WHEN " 01 " = > readdata <=
WHEN " 10 " = > readdata <=
= '1 ') THEN
command ;
data_out_nios ;
status_vector ;
APPENDIX D. IMAGE_EXPORTER_AVALON_INTERFACE.VHD
113
WHEN OTHERS = > NULL ;
END CASE ;
END IF ;
END IF ;
END PROCESS ;
ei : image_exporter PORT MAP ( clk55M ,
clk ,
reset ,
data_nand ,
ry_by ,
ale ,
cle ,
we ,
re ,
wp ,
ce ,
command ,
cmd_ena ,
readyNOTbusy ,
all_downloaded ,
all_written ,
rdempty_outQ ,
wrfull_inQ ,
fifo_half_full ,
data_in_camera ,
data_in_nios ,
data_out_LVDS ,
data_out_nios ,
data_out_strobe ,
l_wrt_p_a , l_dwn_p_a ,
adr_generatedt , lastblk , ck_blk_adr_rq ,
block_adrt ,
bb_qat , bb_qbt ,
rdreq_outQt ,
dout2 , dout3 , dout4 , data_out_bbt , data_in_bbt ,
bad_addresst ,
bad_strobet ,
cor_readyt , clk_outt ,
wr_fifo , wr_flash
);
END ARCHITECTURE image_exporter_avalon_interface_architecture ;
Appendix E
cmosimager.c
/* --- ------ ----- ------ ------ ----- ------ ----- ------ ----- ------ -----* Eric Baker - 2 June 2006
* - - - - - - - - - - - - - - - - - - - - - - - - - - -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - * cmosimager .c - Camera 2D interface library
* - - - - - - - - - - - - - - - - - - - - - - - - - - -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - */
# include " cmosimager . h "
# include " i2c . h "
# include " imageexporter . h "
# include " system . h "
# include " io . h "
# define
# define
# define
# define
# define
# define
page_size 2048
image_width 1280
image_height 1024
image_size image_width * image_height
page_total image_size / page_size
longbyte_total page_size /4
# define wait_millisec { int i ; for ( i =0; i <(3* ALT_CPU_FREQ /1000);) i ++;}
/*
* Standard configuration for KAC -1310
*/
void cmos_imager_configure ( int base )
{
/* Make sure that the INIT pin is high for at least 1 ms */
IOWR_CMOS ( base , CMOS_STANDBY , 0 x00 );
wait_millisec ;
/* Start Initialisation by making INIT pin low for 1 ms */
114
115
APPENDIX E. CMOSIMAGER.C
IOWR_CMOS ( base , CMOS_STARTINIT , 0 x00 );
wait_millisec ;
/* Reset all registers */
i2c_single_write ( I2C_MODULE_0_BASE , CMOS_I2C_ADDR , CMOS_RESETC , 0 x03 );
i2c_single_write ( I2C_MODULE_0_BASE , CMOS_I2C_ADDR , CMOS_RESETC , 0 x00 );
/* Use external Resistor and put in Soft Standby Active */
i2c_single_write ( I2C_MODULE_0_BASE , CMOS_I2C_ADDR , CMOS_POWERC , 0 x09 );
/* Tristate all pins */
i2c_single_write ( I2C_MODULE_0_BASE , CMOS_I2C_ADDR , CMOS_TC , 0 x00 );
/* Switch the TRIGGER pin off */
i2c_single_write ( I2C_MODULE_0_BASE , CMOS_I2C_ADDR , CMOS_TRIG , 0 x00 );
/* Put KAC -1310 in Single Frame Rolling Shutter Mode */
i2c_single_write ( I2C_MODULE_0_BASE , CMOS_I2C_ADDR , CMOS_CM , 0 x6A );
/* set global exposure gain register */
// i2c_single_write ( I2C_MODULE_0_BASE , CMOS_I2C_ADDR , CMOS_PGA_GGA , 0 xFF );
/* Clears the Buffer in the CMOS Imager Module */
IOWR_CMOS ( base , CMOS_BUFFER , 0 x00 );
}
void cmos_imager_capture_frame ( int base )
{
// ----------- valid code begin - - - - - - - - - - - - - - - /* debug command - subsample pic */
// i2c_single_write ( I2C_MODULE_0_BASE , CMOS_I2C_ADDR ,
// i2c_single_write ( I2C_MODULE_0_BASE , CMOS_I2C_ADDR ,
// i2c_single_write ( I2C_MODULE_0_BASE , CMOS_I2C_ADDR ,
// i2c_single_write ( I2C_MODULE_0_BASE , CMOS_I2C_ADDR ,
// i2c_single_write ( I2C_MODULE_0_BASE , CMOS_I2C_ADDR ,
/* debug command */
CMOS_SSC , 0 x1F );
CMOS_VF_RD_MSB , 0 x00 );
CMOS_VF_RD_LSB , 0 x28 );//0 xA1 );
CMOS_VF_CW_MSB , 0 x00 );
CMOS_VF_CW_LSB , 0 x28 );//0 x86 );
/* UnTristate all pins */
i2c_single_write ( I2C_MODULE_0_BASE , CMOS_I2C_ADDR , CMOS_TC , 0 x03 );
/* Clears the Buffer in the CMOS Imager Module */
IOWR_CMOS ( base , CMOS_BUFFER , 0 x00 );
/* Give command to capture image */
i2c_single_write ( I2C_MODULE_0_BASE , CMOS_I2C_ADDR , CMOS_TRIG , 0 x01 );
while (1) {
if ( longbyte_counter >= longbyte_total ) { // page_size bytes in buffer
int i ;
for ( i =0; i < longbyte_total ; i ++){ // loops once through the buffer
temp = buffer [i ];
APPENDIX E. CMOSIMAGER.C
116
IOWR_IE ( base , IE_DATA ,( unsigned char ) temp );
temp = temp > >8; // shifts 32 bit register to get next byte .
IOWR_IE ( base , IE_DATA ,( unsigned char ) temp );
temp = temp > >8;
IOWR_IE ( base , IE_DATA ,( unsigned char ) temp );
temp = temp > >8;
IOWR_IE ( base , IE_DATA ,( unsigned char ) temp );
/* check these out : memcpy (0 ,0 ,0); memset , bcopy */
}
page_counter ++;
if ( page_counter >= page_total ){
page_counter = 0;
return ; // one image saved to mass storage
}
longbyte_counter = 0;
}
else {
while ( IORD_CMOS ( base , CMOS_BUFFER )); // { insert image processing code here }
buffer [ longbyte_counter ] = IORD_CMOS ( base , CMOS_READDATA );
longbyte_counter ++;
}
}
}
Appendix F
Demonstration Board Schematics
This appendix contains the PCB schematics for the camera demonstration board.
117
Figure F.1:
Design Schematic Page 1
D
C
B
A
1
1
TIMEOUT
CRC_ERROR
CMOS_DS1W-DO
CMOS_SCL
CMOS_SDA
nENA_2.5V
CMOS_TRIG
CMOS_INIT
CMOS_MCLK
TIMEOUT
CRC_ERROR
CMOS_DS1W-DO
CMOS_SCL
CMOS_SDA
DATA_OUT
CMOS_TRIG
CMOS_INIT
CMOS_MCLK
FPGA_ab.schdoc
CAN_LOW
CAN_HIGH
CMOS_PIX9
CMOS_PIX8
CMOS_PIX7
CMOS_PIX6
CMOS_PIX5
CMOS_PIX4
CMOS_PIX3
CMOS_PIX2
CMOS_PIX1
CMOS_PIX0
2
2
CAN_LOW
CAN_HIGH
CMOS_PIX9
CMOS_PIX8
CMOS_PIX7
CMOS_PIX6
CMOS_PIX5
CMOS_PIX4
CMOS_PIX3
CMOS_PIX2
CMOS_PIX1
CMOS_PIX0
CMOS_SOF
CMOS_STROBE
CMOS_VCLK
CMOS_HCLK
NAND_R/nB
CLK0
RESET_n
FPGA_efg and Configuration
FPGA_efg.schdoc
ASDO
nCSO
ASDO
nCSO
NAND_IO7
NAND_IO6
NAND_IO5
NAND_IO4
NAND_IO3
NAND_IO2
NAND_IO1
NAND_IO0
CAN_HIGH
R16
120
CAN_LOW
CMOS_SOF
CMOS_STROBE
CMOS_VCLK
CMOS_HCLK
CMOS_PIX9
CMOS_PIX8
CMOS_PIX7
CMOS_PIX6
CMOS_PIX5
CMOS_PIX4
CMOS_PIX3
CMOS_PIX2
CMOS_PIX1
CMOS_PIX0
TIMEOUT
CRC_ERROR
CLK0
NAND_R/nB
RESET_n
RESET_n
NAND_CLE
NAND_ALE
NAND_nWE
NAND_nWP
NAND_R/nB
NAND_nRE
NAND_nCE
NAND_IO[7..0]
NAND_IO7
NAND_IO6
NAND_IO5
NAND_IO4
NAND_IO3
NAND_IO2
NAND_IO1
NAND_IO0
FPGA_cd.schdoc
CMOS_PIX9
CMOS_PIX8
CMOS_PIX7
CMOS_PIX6
CMOS_PIX5
CMOS_PIX4
CMOS_PIX3
CMOS_PIX2
CMOS_PIX1
CMOS_PIX0
TIMEOUT
CRC_ERROR
RESET_n
NAND_CLE
NAND_ALE
NAND_nWE
NAND_nWP
NAND_R/nB
NAND_nRE
NAND_nCE
NAND_IO[7..0]
Power,Clock and NAND.schdoc
3
3
CLK0
Date:
File:
A4
Size
Title
LVDS_txout(p)
LVDS_txout(n)
NAND_nWE
NAND_nWP
NAND_nRE
NAND_nCE
NAND_CLE
NAND_ALE
nENA_2.5V
CAN_LOW
CAN_HIGH
LVDS_p
LVDS_n
CMOS_DS1W-DO
CMOS_HCLK
CMOS_VCLK
CMOS_MCLK
CMOS_SCL
CMOS_SDA
CMOS_INIT
CMOS_SOF
CMOS_STROBE
CMOS_TRIG
LVDS_txout(n)
LVDS_txout(p)
120
R15
120
R13
LVDS_n
LVDS_p
Revision
R14
170
D
C
B
A
DEMONSTRATION BOARD SCHEMATICS
4
2006/09/30
Sheet of
C:\Documents and Settings\..\Top.SCHDOCDrawn By:
Number
LVDS_txout(p)
LVDS_txout(n)
NAND_nWE
NAND_nWP
NAND_nRE
NAND_nCE
NAND_CLE
NAND_ALE
nENA_2.5V
CAN_LOW
CAN_HIGH
LVDS_p
LVDS_n
CMOS_DS1W-DO
CMOS_HCLK
CMOS_VCLK
CMOS_MCLK
CMOS_SCL
CMOS_SDA
CMOS_INIT
CMOS_SOF
CMOS_STROBE
CMOS_TRIG
CLK0
4
APPENDIX F.
118
Figure F.2:
Design Schematic Page 2
D
C
B
A
3.3V
6
7
3
4
5
POK
Vout
L2
1
nENA_2.5V
CHOKE
60ohm, 6A
L3
COMP
nSD(SS)
FB
AGND
AGND
PGND
PGND
PGND
4
5
R12
47k
1
2
C86
10nF
R11
47k
3.3V
J7
R9
3.3V
GND
LF25CPT
5
4
C87
1nF
C80
1uF
Power 1.2V
ENA
1k
10
8
9
13
12
16
15
14
1
VIN VOUT
INH
NC
U6
C85
0.1uF
SN105125DBVR
EN
GND
Vin
VCB
AVIN
VIN
VIN
VIN
J1
Power 3.3V
LM2651MTC-3.3
CHOKE
60ohm, 6A
3.3V 3
2
1
U5
1
22uH
U4
1
SW
2
SW
L1
Power GND
1
J5
C77
0.1uF
0.1uF
1.2V
C89
0.1uF
3.3V
2
D Schottky
> 15V, 2A
C68
KA
+ C96
100uF
12V
1
D1
6
1
C79
2.2nF
C90
10uF
Power 2.5V
1
J8
C88
2.2uF
VCCA_PLL
C81
2.2uF
3.3V
1
2
C91
2.2uF
C92
2.2uF
C93
2.2uF
2
2.5V
Place 2.2uF Caps close to FPGA
1.2V
Place 2.2uF Caps close to FPGA
C78
4.7nF
R8
15k
C74
2.2uF
Place 2.2uF Caps close to FPGA
2u2/12v
+ C95
C69
C71
120uF
C72
C73
10uF 2.2uF2.2uF
3.3V
2
Vcc
Output
TIMEOUT
Optional
4
3
3.3V
Power In
1k
R10
Optional
JP2
1
2
ENA
C100
1uF
12V
LVDS_n
LVDS_p
CAN_LOW
CAN_HIGH
CRC_ERROR
RESET_n
1
6
2
7
3
8
4
9
5
C101
100nF
NAND_R/nB
NAND_nRE
NAND_nCE
NAND_CLE
NAND_ALE
NAND_nWE
NAND_nWP
DB9
3
OBC_connector1
LED3
Time out: RED LED
C102
10nF
Power: RED LED
Optional
Clock 66.667Mhz
1
J6
CLK0
+
D2
D Schottky SMS2100
> 15V, 2A
1k
R7
STCO31-SMD7x5 Metal Lid
Tri-State
GND
X1
3.3V
3
1
2
3
4
5
6
CLE
ALE
nWE
nWP
nRE
nCE
Date:
File:
A4
Size
Title
2
4
6
8
10
12
14
16
18
20
22
24
26
Header 13X2
1
3
5
7
9
11
13
15
17
19
21
23
25
J3
CMOS_STROBE
CMOS_HCLK
CMOS_VCLK
CMOS_MCLK
CMOS_PIX8
CMOS_PIX6
CMOS_PIX4
CMOS_PIX2
CMOS_PIX0
CMOS_SCL
NAND_IO7
NAND_IO6
NAND_IO5
NAND_IO4
NAND_IO3
NAND_IO2
NAND_IO1
NAND_IO0
Revision
3.3V
NAND_IO
8
7
6
5
4
3
2
1
NAND_IO7
NAND_IO6
NAND_IO5
NAND_IO4
NAND_IO3
NAND_IO2
NAND_IO1
NAND_IO0
D
C
B
A
DEMONSTRATION BOARD SCHEMATICS
4
2006/09/30
Sheet of
C:\Documents and Settings\..\Power,Clock and
Drawn
NAND.SCHDOC
By:
Number
CMOS_PIX9
CMOS_PIX7
CMOS_PIX5
CMOS_PIX3
CMOS_PIX1
13
36
38
44
43
42
41
32
31
30
29
NAND_IO7
NAND_IO6
NAND_IO5
NAND_IO4
NAND_IO3
NAND_IO2
NAND_IO1
NAND_IO0
Vss
Vss
PRE
I/O7
I/O6
I/O5
I/O4
I/O3
I/O2
I/O1
I/O0
CMOS_connector1
C103
100pF
R17
1k
3.3V
CMOS_DS1W-DO
CMOS_SDA
CMOS_INIT
CMOS_SOF
CMOS_TRIG
NAND Test 2
3.3V
Vcc
Vcc
R/nB
nRE
nCE
CLE
ALE
nWE
nWP
U3
C105 K9K4G08U0M
100nF
12
37
7
8
9
16
17
18
19
NAND Test 1
J4
R/nB
1
J2
C104
100nF
3.3V
R/nB
nRE
nCE
CLE
ALE
nWE
nWP
4
APPENDIX F.
119
Figure F.3:
Design Schematic Page 3
D
M5
M6
N1
CMOS_TRIG
N2
CMOS_INIT
P1
CMOS_MCLK
P2
CMOS_DS1W-DO
M8
M7
N6
N5
N3
N4
P3
R8
B
R7
P5
DATA_OUT
P6
R1
CMOS_SCL
R2
CMOS_SDA
T1
T2
P4
R4
U1
U2
R5
R6
V1
V2
T5
T6
T3
U3
C
W1
W2
Y1
Y2
W3
W4
Y3
Y4
W5
U4
V4
A
BANK 1
BANK 2
2
PLL1_OUTp
PLL1_OUTn
1
2
LVDS26p, (DPCLK1/DQS1L)/(DPCLK1/DQS1L)
IO, LVDS27n
LVDS26n
IO, LVDS27p, (DPCLK0/DQS0L)/(DPCLK0/DQS0L)
LVDS25p, DM0L/(DM1L1/BWS#1L1)
IO, LVDS28n, _/DQ1L17
LVDS25n, DQ1L0/DQ3L0
IO, LVDS28p
LVDS24p, DQ1L1/DQ3L1
IO
LVDS24n, DQ1L2/DQ3L2
IO, LVDS29n, DQ0L7/DQ1L16
LVDS23p
IO, LVDS29p, DQ0L6/DQ1L15
LVDS23n
IO
LVDS22p, DQ1L3/DQ3L3
IO, LVDS30n
LVDS22n
IO, LVDS30p
LVDS20p, DQ1L4/DQ3L4
IO, LVDS31n
LVDS20n, DQ1L5/DQ3L5
IO, LVDS31p
VREFB1N0
IO, VREFB2N1
LVDS18p
IO, LVDS36n, DQ0L5/DQ1L14
LVDS18n
IO, LVDS36p, DQ0L4/DQ1L13
LVDS17p, DQ1L6/DQ3L6
IO, LVDS37n, DQ0L3/DQ1L12
LVDS17n, DQ1L7/DQ3L7
IO, LVDS37p, DQ0L2/DQ1L11
LVDS16p, DQ1L8/DQ3L8
IO, LVDS38n, DQ0L1/DQ1L10
LVDS16n, (DM1L/BWS#1L)/(DM3L0/BWS#3L0)IO, LVDS38p, (CDPCLK0/DQS2L)/(CDPCLK0/DQS2L)
LVDS13p
IO, LVDS39n, DQ0L0/DQ1L9
LVDS13n
IO, LVDS39p, DM2L/(DM1L0/BWS#1L0)
LVDS12p
IO, LVDS40n, _/DQ1L8
LVDS12n
IO, LVDS40p, DQ2L7/DQ1L7
LVDS11p, (CDPCLK1/DQS3L)/(CDPCLK1/DQS3L)
IO, DQ2L6/DQ1L6
LVDS11n
IO, LVDS44n, DQ2L5/DQ1L5
LVDS10p, DQ3L0/DQ3L9
IO, LVDS44p, DQ2L4/DQ1L4
LVDS10n, DQ3L1/DQ3L10
IO, VREFB2N0
LVDS8p, DQ3L2/DQ3L11
IO, LVDS47n, DQ2L3/DQ1L3
LVDS8n, DQ3L3/DQ3L12
IO, LVDS47p, DQ2L2/DQ1L2
LVDS7p, DQ3L4/DQ3L13
IO, LVDS48n, DQ2L1/DQ1L1
LVDS7n
IO, LVDS48p, DQ2L0/DQ1L0
IO, PLL3_OUTn
VREFB1N1
IO, PLL3_OUTp
LVDS6p, DQ3L5/DQ3L14
IO, LVDS49n (CLKUSR)
LVDS6n, DQ3L6/DQ3L15
IO, LVDS49p (CRC_ERROR)
LVDS5p, DQ3L7/DQ3L16
IO, (nCSO)
LVDS5n, DQ3L8/DQ3L17
IO, (ASDO)
LVDS2p, (DM3L/BWS#3L)/(DM3L1/BWS#3L1)
LVDS2n
LVDS0p
LVDS0n
EP2C35F484C6N
IO,
IO,
IO,
IO,
IO,
IO,
IO,
IO,
IO,
IO,
IO,
IO,
IO,
IO,
IO,
IO,
IO,
IO,
IO,
IO,
IO,
IO,
IO,
IO,
IO,
IO,
IO,
IO,
IO,
IO,
IO,
IO
IO,
IO,
IO,
IO,
IO,
IO,
IO,
IO,
IO,
IO
IO,
IO,
U1A
1
J2
J1
J4
J3
L7
H2
H1
L8
J5
J6
G2
G1
H3
F2
F1
E2
E1
H6
H5
H4
G3
D2
D1
F3
G5
G6
F4
C2
C1
E4
E3
D6
D5
D4
D3
C3
C4
CRC_ERROR
nCSO
ASDO
CMOS_PIX1
CMOS_PIX0
CMOS_PIX3
CMOS_PIX2
CMOS_PIX7
CMOS_PIX6
CMOS_PIX5
CMOS_PIX4
CMOS_PIX9
CMOS_PIX8
B11
A11
E11
D11
H11
G11
B10
A10
F11
F10
C10
B9
A9
E9
D9
B8
A8
B7
CAN_LOW
A7
CAN_HIGH
F9
E8
D8
C9
D7
F8
E7
C7
G7
H7
B6
A6
B5
A5
B4
A4
A3
B3
BANK 3
BANK 4
4
3
Date:
File:
A4
Size
Title
Revision
D
A13
B13
A14
B14
F12
C13
A15
B15
A16
TIMEOUT
B16
F13
F14
D14
E14
B
A17
B17
F15
C14
D15
J14
H14
E15
D16
C16
H15
G16
A18
B18
A19
B19
A20
B20
C17
C
C18
A
DEMONSTRATION BOARD SCHEMATICS
4
2006/09/30
Sheet of
C:\Documents and Settings\..\FPGA_ab.SCHDOC
Drawn By:
Number
LVDS73n
IO, LVDS74p, (DPCLK9/DQS4T)/(DPCLK9/DQS4T)
LVDS73p, (DPCLK10/DQS5T)/(DPCLK10/DQS5T)
IO, LVDS74n
LVDS72n, DQ5T0/DQ3T0
IO, LVDS76p, DM4T/(DM5T1/BWS#5T1)
LVDS72p, DQ5T1/DQ3T1
IO, LVDS76n, _/DQ5T17
LVDS71n
IO, LVDS78n, DQ4T7/DQ5T16
LVDS71p
IO, VREFB4N1
LVDS70n, DQ5T2/DQ3T2
IO, LVDS80p, DQ4T6/DQ5T15
LVDS70p, DQ5T3/DQ3T3
IO, LVDS80n, DQ4T5/DQ5T14
LVDS69n, DQ5T4/DQ3T4
IO, LVDS81p, DQ4T4/DQ5T13
LVDS69p, DQ5T5/DQ3T5
IO, LVDS81n, DQ4T3/DQ5T12
VREFB3N0
IO, LVDS82p, DQ4T2/DQ5T11
LVDS67n, DQ5T6/DQ3T6
IO, LVDS82n, DQ4T1/DQ5T10
LVDS67p, DQ5T7/DQ3T7
IO, LVDS83p, DQ4T0/DQ5T9
LVDS64n, DQ5T8/DQ3T8
IO, LVDS83n, DM2T/(DM5T0/BWS#5T0)
LVDS64p, (DM5T/BWS#5T)/(DM3T0/BWS#3T0) IO, LVDS85p, (DPCLK8/DQS2T)/(DPCLK8/DQS2T)
LVDS62n
IO, LVDS85n
LVDS62p, (DPCLK11/DQS3T)/(DPCLK11/DQS3T)
IO, LVDS87p, _/DQ5T8
LVDS61n, DQ3T0/DQ3T9
IO, LVDS88p, DQ2T7/DQ5T7
LVDS61p, DQ3T1/DQ3T10
IO, LVDS88n, DQ2T6/DQ5T6
LVDS60n, DQ3T2/DQ3T11
IO, LVDS91p
LVDS60p, DQ3T3/DQ3T12
IO, LVDS91n
LVDS59n, DQ3T4/DQ3T13
IO, LVDS92p, DQ2T5/DQ5T5
LVDS59p, DQ3T5/DQ3T14
IO, LVDS92n, DQ2T4/DQ5T4
LVDS58p, DQ3T6/DQ3T15
IO, VREFB4N0
DQ3T7/DQ3T16
IO, LVDS95p
LVDS56p, DQ3T8/DQ3T17
IO, LVDS95n
VREFB3N1
IO, LVDS96p, (CDPCLK6/DQS0T)/(CDPCLK6/DQS0T)
LVDS55n
IO, LVDS96n
LVDS55p
IO, LVDS97p, DQ2T3/DQ5T3
LVDS53n
IO, LVDS97n, DQ2T2/DQ5T2
LVDS53p, (CDPCLK7/DQS1T)/(CDPCLK7/DQS1T)
IO, LVDS98p, DQ2T1/DQ5T1
LVDS52n, (DM3T/BWS#3T)/(DM3T1/BWS#3T1)
IO, LVDS98n, DQ2T0/DQ5T0
LVDS52p
IO, LVDS99p
LVDS51n
IO, LVDS99n
LVDS51p
LVDS50p
LVDS50n (DEV_CLRn)
EP2C35F484C6N
IO,
IO,
IO,
IO,
IO,
IO,
IO,
IO,
IO,
IO,
IO,
IO,
IO,
IO,
IO,
IO,
IO,
IO,
IO,
IO,
IO,
IO,
IO,
IO,
IO,
IO,
IO,
IO,
IO,
IO,
IO,
IO,
IO,
IO,
IO,
IO,
IO,
U1B
3
APPENDIX F.
120
Figure F.4:
Design Schematic Page 4
D
C
B
NAND_IO0
NAND_IO1
NAND_IO2
NAND_IO3
A NAND_IO6
NAND_IO7
NAND_IO4
NAND_IO5
L19
L18
K21
K22
J21
J22
L17
K17
H21
H22
K18
J20
H19
K20
J19
J18
J17
H16
J15
G21
G22
F21
F22
H18
H17
E21
E22
D21
D22
G17
G18
G20
E20
F20
C21
C22
C19
C20
D19
D20
E19
E18
BANK 6
2
1
Test1
Test3
Test5
Test7
Test9
Test11
Test13
Test15
Test17
M18
M19
N22
N21
P22
P21
M15
M16
P19
P20
N15
P15
R20
R22
R21
T22
T21
P18
P17
R19
R18
U22
U21
V22
V21
Y22
Y21
R17
W22
W21
U20
V20
U19
T18
U18
W18
Y20
Y19
W20
V19
Y18
Test14
Test15
Test16
Test17
Test12
Test13
Test10
Test11
Test4
Test5
Test6
Test7
Test8
Test9
Test0
Test1
Test2
Test3
NAND_nWE
NAND_nWP
NAND_nRE
NAND_nCE
NAND_CLE
NAND_ALE
AB12
AA12
AB13
AA13
U13
Y13
AB14
AA14
AB15
AA15
AB16
AA16
W14
V14
AB17
AA17
U14
Y14
W15
R14
R15
AB18
AA18
Y16
R16
T16
U15
V15
Y17
W16
AB19
AA19
AB20
AA20
BANK 7
BANK 8
4
3
Date:
File:
A4
Size
Title
4
2006/09/30
Sheet of
C:\Documents and Settings\..\FPGA_cd.SCHDOC
Drawn By:
Number
LVDS176p, (DPCLK4/DQS4B)/(DPCLK4/DQS4B)
IO, LVDS177n
LVDS176n
IO, LVDS177p, (DPCLK3/DQS5B)/(DPCLK3/DQS5B)
LVDS174p, DM4B/(DM5B1/BWS#5B1)
IO, LVDS178n, DQ5B0/DQ3B0
LVDS174n, _/DQ5B17
IO, LVDS178p, DQ5B1/DQ3B1
LVDS172n, DQ4B7/DQ5B16
IO, LVDS179n, DQ5B2/DQ3B2
VREFB7N1
IO, LVDS179p, DQ5B3/DQ3B3
LVDS170p, DQ4B6/DQ5B15
IO, LVDS180n
LVDS170n, DQ4B5/DQ5B14
IO, LVDS180p
LVDS169p, DQ4B4/DQ5B13
IO, LVDS181n, DQ5B4/DQ3B4
LVDS169n, DQ4B3/DQ5B12
IO, LVDS181p, DQ5B5/DQ3B5
LVDS168p, DQ4B2/DQ5B11
IO, VREFB8N0
LVDS168n, DQ4B1/DQ5B10
IO, LVDS183n, DQ5B6/DQ3B6
LVDS167p, DQ4B0/DQ5B9
IO, LVDS183p, DQ5B7/DQ3B7
LVDS167n, DM2B/(DM5B0/BWS#5B0)
IO, LVDS186n, DQ5B8/DQ3B8
LVDS165p, (DPCLK5/DQS2B)/(DPCLK5/DQS2B)IO, LVDS186p, (DM5B/BWS#5B)/(DM3B0/BWS#3B0)
LVDS165n
IO, LVDS188n
LVDS163p, _/DQ5B8
IO, LVDS188p, (DPCLK2/DQS3B)/(DPCLK2/DQS3B)
LVDS162p, DQ2B7/DQ5B7
IO, LVDS189n, DQ3B0/DQ3B9
LVDS162n, DQ2B6/DQ5B6
IO, LVDS189p, DQ3B1/DQ3B10
LVDS159p
IO, LVDS190n, DQ3B2/DQ3B11
LVDS159n
IO, LVDS190p, DQ3B3/DQ3B12
LVDS158p, DQ2B5/DQ5B5
IO, LVDS191n, DQ3B4/DQ3B13
LVDS158n, DQ2B4/DQ5B4
IO, LVDS191p, DQ3B5/DQ3B14
VREFB7N0
IO, LVDS192n, DQ3B6/DQ3B15
LVDS155p
IO, LVDS192p, DQ3B7/DQ3B16
LVDS155n
IO, LVDS194p, DQ3B8/DQ3B17
LVDS154p, (CDPCLK3/DQS0B)/(CDPCLK3/DQS0B)
IO, VREFB8N1
LVDS154n
IO, LVDS195n
LVDS153p, DQ2B3/DQ5B3
IO, LVDS195p
LVDS153n, DQ2B2/DQ5B2
IO, LVDS197n
LVDS152p, DQ2B1/DQ5B1
IO, LVDS197p, (CDPCLK2/DQS1B)/(CDPCLK2/DQS1B)
LVDS152n, DQ2B0/DQ5B0
IO, LVDS198n, (DM3B/BWS#3B)/(DM3B1/BWS#3B1)
LVDS151p
IO, LVDS198p
LVDS151n
IO, LVDS199n
IO, LVDS199p
IO, LVDS200p
IO, LVDS200n (DEV_OE)
EP2C35F484C6N
IO,
IO,
IO,
IO,
IO,
IO,
IO,
IO,
IO,
IO,
IO,
IO,
IO,
IO,
IO,
IO,
IO,
IO,
IO,
IO,
IO,
IO,
IO,
IO,
IO,
IO,
IO,
IO,
IO,
IO,
IO,
IO,
IO,
IO,
U1D
3
Revision
AA11
AB11
AA10
AB10
V11
W11
R11
T11
AA9
AB9
Y10
AA8
AB8
U10
U9
W9
Y9
AA7
AB7
V9
W8
W7
V8
AA6
AB6
U8
Y7
T7
T8
AA5
AB5
Y6
Y5
AA4
AB4
AB3
LVDS_txout(p)
AA3
LVDS_txout(n)
D
C
B
A
DEMONSTRATION BOARD SCHEMATICS
2
2
4
6
8
10
12
14
16
18
Test Pins
JP1
Test0
1
Test2
3
Test4
5
Test6
7
Test8
9
Test10
11
Test12
13
Test14
15
Test16
17
LVDS126n
IO, LVDS127p, (DPCLK6/DQS1R)/(DPCLK6/DQS1R)
LVDS126p, (DPCLK7/DQS0R)/(DPCLK7/DQS0R)
IO, LVDS127n
LVDS125n, DM0R/(DM1R1/BWS#1R1)
IO, LVDS128p, DQ1R0/DQ3R0
LVDS125p, _/DQ1R17
IO, LVDS128n, DQ1R1/DQ3R1
LVDS124n, DQ0R7/DQ1R16
IO, LVDS129p
LVDS124p, DQ0R6/DQ1R15
IO, LVDS129n
LVDS123n
IO, LVDS130p
LVDS123p
IO, LVDS130n
LVDS122n
IO, LVDS131p
LVDS122p
IO, LVDS131n
IO, LVDS132p
LVDS120n, DQ0R5/DQ1R14
IO, LVDS132n
LVDS120p, DQ0R4/DQ1R13
IO, VREFB6N0
VREFB5N1
IO, LVDS134p, DQ1R2/DQ3R2
LVDS117n, DQ0R3/DQ1R12
IO, LVDS134n, DQ1R3/DQ3R3
LVDS117p, DQ0R2/DQ1R11
IO, LVDS135p, DQ1R4/DQ3R4
LVDS116n, DQ0R1/DQ1R10
IO, LVDS135n, DQ1R5/DQ3R5
LVDS116p
IO, LVDS137p, DQ1R6/DQ3R6
IO, LVDS137n, DQ1R7/DQ3R7
LVDS114n, DQ0R0/DQ1R9
IO, LVDS138p, DQ1R8/DQ3R8
LVDS114p, DM2R/(DM1R0/BWS#1R0)
IO, LVDS138n, (DM1R/BWS#1R)/(DM3R0/BWS#3R0)
LVDS112n
IO, LVDS139p, (CDPCLK4/DQS3R)/(CDPCLK4/DQS3R)
LVDS112p, (CDPCLK5/DQS2R)/(CDPCLK5/DQS2R)
IO, LVDS139n
LVDS111n, _/DQ1R8
IO, LVDS140p, DQ3R0/DQ3R9
LVDS111p, DQ2R7/DQ1R7
IO, LVDS140n, DQ3R1/DQ3R10
LVDS109n, DQ2R6/DQ1R6
IO, LVDS141p, DQ3R2/DQ3R11
LVDS109p, DQ2R5/DQ1R5
IO, LVDS141n, DQ3R3/DQ3R12
LVDS108n, DQ2R4/DQ1R4
IO, LVDS143p, DQ3R4/DQ3R13
LVDS108p
IO, LVDS145p, DQ3R5/DQ3R14
LVDS107n, DQ2R3/DQ1R3
IO, LVDS145n, DQ3R6/DQ3R15
LVDS107p, DQ2R2/DQ1R2
IO, VREFB6N1
VREFB5N0
IO, LVDS148p, DQ3R7/DQ3R16
LVDS105n, DQ2R1/DQ1R1
IO, LVDS148n, DQ3R8/DQ3R17
LVDS105p, DQ2R0/DQ1R0
IO, PLL4_OUTp
LVDS104n
IO, PLL4_OUTn
LVDS104p
IO
LVDS101n
IO, LVDS149p, (DM3R/BWS#3R)/(DM3R1/BWS#3R1)
LVDS101p
IO, LVDS149n
LVDS100n
IO, LVDS150p (nCEO)
LVDS100p
IO, LVDS150n (INIT_DONE)
PLL2_OUTp
IO
PLL2_OUTn
BANK 5
1
EP2C35F484C6N
IO,
IO,
IO,
IO,
IO,
IO,
IO,
IO,
IO,
IO,
IO
IO,
IO,
IO,
IO,
IO,
IO,
IO,
IO
IO,
IO,
IO,
IO,
IO,
IO,
IO,
IO,
IO,
IO,
IO,
IO,
IO,
IO,
IO,
IO,
IO,
IO,
IO,
IO,
IO,
IO,
IO,
U1C
APPENDIX F.
121
Design Schematic Page 5
D
C
B
A
1
1
C33
0.1uF
C34
0.1uF
VCCIO8
VCCIO8
VCCIO8
VCCIO8
VCCIO8
VCCIO7
VCCIO7
VCCIO7
VCCIO7
VCCIO7
VCCIO6
VCCIO6
VCCIO6
VCCIO6
VCCIO5
VCCIO5
VCCIO5
VCCIO5
VCCIO4
VCCIO4
VCCIO4
VCCIO4
VCCIO4
VCCIO3
VCCIO3
VCCIO3
VCCIO3
VCCIO3
VCCIO2
VCCIO2
VCCIO2
VCCIO1
VCCIO1
VCCIO1
VCCIO1
C37
0.1uF
AB2
T9
V10
W6
Y11
AB21
T14
V13
W17
Y12
AA22
M20
P16
T19
B22
G19
J16
L20
A21
C12
D17
E13
G14
A2
C6
C11
E10
G9
B1
J7
L3
AA1
M3
P7
T4
C36
0.1uF
2.5V
C35
0.1uF
0.1uF
0.1uF
C67
0.1uF
C66
0.1uF
C65
0.1uF
C64
C63
3.3V
2
VCCA_PLL
U6
U7
VCC D_PLL1
VCC A_PLL1
F17
F16
VCC D_PLL2
VCC A_PLL2
E5
E6
VCC D_PLL3
VCC A_PLL3
U16
U17
VCC A_PLL4
VCC D_PLL4
3
G8
G12
H8
H12
H13
J10
J11
J12
J13
K8
K9
K14
L9
L14
L16
M9
M14
N9
N14
P10
P11
P12
P13
P14
R10
R12
T12
T15
C39
0.1uF
C40
0.1uF
C41
0.1uF
C42
0.1uF
C43
0.1uF
C44
0.1uF
3
C50
0.1uF
C51
0.1uF
4
C53
0.1uF
Y15
Y8
W19
W13
W10
V17
V6
V3
T20
T13
T10
R3
N19
N16
N7
M4
K19
K16
K7
K3
H20
G13
G10
G4
F19
D18
D13
D10
V16
V18
T17
F5
F6
F7
F18
E17
E16
U5
V5
V7
C54
0.1uF
C55
0.1uF
EP2C35F484C6N
U1F
C56
0.1uF
1.2V
C57
0.1uF
0.1uF
C31
0.1uF
C29
0.1uF
C27
0.1uF
C11
0.1uF
C9
0.1uF
C7
C5
C58
0.1uF
0.1uF
C32
0.1uF
C30
0.1uF
C28
0.1uF
C10
0.1uF
C8
0.1uF
C6
5
C59
0.1uF
5
C60
0.1uF
C61
0.1uF
1K
R6
U11
U12
W12
V12
E12
D12
RESET_n
A12
B12
CLK0
M21
M22
NAND_R/nB
L21
L22
M2
CMOS_SOF
M1
CMOS_STROBE
L2
CMOS_VCLK
L1
CMOS_HCLK
C62
0.1uF
2
4
6
8
10
GND
3.3V
R4
1K
6
EP2C35F484C6N
CLK15, LVDSCLK7p INPUT
CLK14, LVDSCLK7n INPUT
CLK13, LVDSCLK6p INPUT
CLK12, LVDSCLK6n INPUT
CLK11, LVDSCLK5p INPUT
CLK10, LVDSCLK5n INPUT
CLK9, LVDSCLK4p INPUT
CLK8, LVDSCLK4n INPUT
CLK7, LVDSCLK3n INPUT
CLK6, LVDSCLK3p INPUT
CLK5, LVDSCLK2n INPUT
CLK4, LVDSCLK2p INPUT
CLK3, LVDSCLK1n INPUT
CLK2, LVDSCLK1p INPUT
CLK1, LVDSCLK0n INPUT
CLK0, LVDSCLK0p INPUT
U1G
Header 5X2
1
3
5
7
9
JTAG
R5
1K
6
Date:
File:
A3
Size
Title
nCE
MSEL0
MSEL1
TDI
TDO
TCK
TMS
DATA0
1
2
9
Number
R2 R3
10K 10K
3
4
5
10
8
16
7
15
nCSO
ASDO
L6
N18
L4
N20
7
2006/09/30
Sheet of
C:\Documents and Settings\..\FPGA_efg.SCHDOC
Drawn By:
NC
NC
NC
GND
DATA
DCLK
nCS
ASDI
EPCS16SI16N
NC
NC
NC
NC
NC
VCC
VCC
VCC
U2
R1
1K
3.3V
Config Done: GREEN LED
LED1
DCLK
CONF_DONE
nCONFIG
nSTATUS
GND
EP2C35F484C6N
C48
6
0.1uF 11
12
13
14
3.3V
K1
M17
N17
K5
L5
K2
K6
K4
U1E
7
8
Revision
8
D
C
B
A
DEMONSTRATION BOARD SCHEMATICS
2
C38
0.1uF
4
C52
0.1uF
GND
GND
GND
GND
GND
GND
GND
GND
GND
GND
GND
GND
GND
GND
GND
GND
GND
GND
GND
GND
GND
GND
GND
GND
GND
GND
GND
GND
GNDA_PLL4
GND_PLL4
GND_PLL4
GND_PLL3
GND_PLL3
GNDA_PLL3
GND_PLL2
GND_PLL2
GNDA_PLL2
GND_PLL1
GND_PLL1
GNDA_PLL1
VCC INT
VCC INT
VCC INT
VCC INT
VCC INT
VCC INT
VCC INT
VCC INT
VCC INT
VCC INT
VCC INT
VCC INT
VCC INT
VCC INT
VCC INT
VCC INT
VCC INT
VCC INT
VCC INT
VCC INT
VCC INT
VCC INT
VCC INT
VCC INT
VCC INT
VCC INT
VCC INT
VCC INT
GND
GND
GND
GND
GND
GND
GND
GND
GND
GND
GND
GND
GND
GND
GND
GND
GND
GND
GND
GND
GND
GND
GND
GND
GND
GND
GND
GND
GND
GND
GND
GND
GND
GND
GND
GND
GND
GND
GND
Figure F.5:
G15
H9
H10
J8
J9
K10
K11
K12
K13
K15
L10
L11
L12
L13
L15
M10
M11
M12
M13
N8
N10
N11
N12
N13
P8
P9
R9
R13
A1
A22
AA2
AA21
AB1
AB22
B2
B21
C5
C8
C15
APPENDIX F.
122
Appendix G
Power Regulators
G.1
National Semiconductor LM2651
G.2
ST LF25CPT
G.3
Texas Instuments SN105125
123
APPENDIX G. POWER REGULATORS
Figure G.1:
National Semiconductor LM2651 Datasheet, Page 1 [25]
124
APPENDIX G. POWER REGULATORS
Figure G.2:
ST LF25CPT Datasheet, Page 1 [26]
125
APPENDIX G. POWER REGULATORS
Figure G.3:
Texas Instruments SN105125 Datasheet, Page 1 [27]
126