system on chip for telecommand system design

SYSTEM-ON-CHIP(SoC) FOR TELECOMMAND
SYSTEM DESIGN
June 2015

Abstract
The emerging developments in semiconductor technology have made possible to design entire sys-
tem onto a single chip, commonly known as System-on-Chip (SoC).This drives the semiconductor
manufacturing industry to the integration of multiple complex components in a single chip. This
is achieved by integrating all the components into a single chip. This project is concerned with the
design of SoC for detecting and correcting the error which may occur in the memory unit due to
radiation in LEO (Lower Earth Orbit) and due to stuck-at faults in memory unit in space station.
The error free data is feed to the predestined processor using the serial communication protocol
(UART) and perform its function speciﬁed in the data input which is sent from the ground station.
The increases in Space Systems capabilities kindled by the On-board data processing capabilities
can be overcome by optimizing the SoCs to provide cost effective, high performance, and reli-
able data. The design of Telecommand system for transfer of signals from ground station to space
station by the integration of SRAM (Static Random Access Memory), Telecommand processor.
i

Contents
1 INTRODUCTION 1
1.1 What is SoC ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2 SoC DESIGN METHODOLOGY 3
3 Design Architcture 4
3.1 Design of SRAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2 Why use an SRAM? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.3 RTL Schematic of SRAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.4 Flow Chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4 TELECOMMAND and TELEMETRY processor 9
4.1 Design of TELECOMMAND and TELEMETRY Processor Unit . . . . . . . . . . 9
4.2 Hamming Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.2.1 Error Correction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.3 Designing (n, k, t) Hamming Code . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.3.1 The (11, 7, 1) Hamming Code . . . . . . . . . . . . . . . . . . . . . . . . 12
4.4 Calculation of Redundancy Values . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.5 Syndrome Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5 Integration of SRAM with Telecommand and Telemetry Processor Unit 14
5.1 RTL Schematic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6 SIMULATION RESULTS AND DISCUSSION 16
6.1 Parity Generator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.2 Error Detector / Syndrome Generator . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.3 Error Corrector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
6.4 Top Processor Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
6.5 Top Processor Output (with test bench) . . . . . . . . . . . . . . . . . . . . . . . . 17
7 Advantages,Disadvantages and Applications 18
7.1 Advantages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
ii

7.2 Disadvantages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
7.3 Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
8 Results and Discussions 19
8.1 Xilinx Device Utilization Summaries . . . . . . . . . . . . . . . . . . . . . . . . . 19
8.2 Clock Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
9 Conclusions and Future Scope 21
10 Datasheet 22
10.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
10.2 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
10.3 Summary of Spartan-3E FPGA Attributes . . . . . . . . . . . . . . . . . . . . . . 24
10.4 Architectural Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
10.5 Conﬁguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
10.6 I/O Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
10.7 Package Marking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
10.8 VQ100 Footprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
iii

List of Figures
3.1 Block diagram of soc design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2 Block diagram of 2k x32 bit sram . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.3 RTL Schematic of SRAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.4 Flow chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1 Telecommand and Telemetry Processor . . . . . . . . . . . . . . . . . . . . . . . 9
4.2 : ECC Code word format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.1 Integration of sram with Telecommand and Telemetry Processor unit . . . . . . . . 14
5.2 RTL Schematic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.1 Parity Generator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.2 Error Detector / Syndrome Generator . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.3 Error Corrector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
6.4 Top Processor Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
6.5 Top Processor Output (with test bench) . . . . . . . . . . . . . . . . . . . . . . . . 17
10.1 Spartan-3E family architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
10.2 Spartan-3e qfp package marking example . . . . . . . . . . . . . . . . . . . . . . 27
10.3 Spartan-3e bga package marking example . . . . . . . . . . . . . . . . . . . . . . 27
10.4 Spartan-3e cp132 and cpg132 package marking example . . . . . . . . . . . . . . 28
10.5 VQ100 Package footprint (top view) . . . . . . . . . . . . . . . . . . . . . . . . . 28
10.6 VQ100 Package footprint (top view) cont.. . . . . . . . . . . . . . . . . . . . . . . 29
iv

List of Tables
4.1 Hamming code bits representation . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.2 (11, 7, 1) Hamming code bit representation . . . . . . . . . . . . . . . . . . . . . 12
8.1 Xilinx device utilization summaries . . . . . . . . . . . . . . . . . . . . . . . . . 19
8.2 Clock report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
10.1 Summary of Spartan-3E FPGA attributes . . . . . . . . . . . . . . . . . . . . . . 24
10.2 32-Bit hamming code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
10.3 64-Bit hamming code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
10.4 64-Bit hamming code cont.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
v

LIST OF ABBREVIATIONS
ECC Error Control Coding
EDAC Error Detection And Correction
EDO Extended Data Output
FEC Forward Error Correction
FPGA Field Frogrammable Gate Array
IP Intellectual Protocol
LEO Low Earth Orbit
OBS On Board System
SEU Single Event Upset
SoC System On Chip
SRAM Static Random Access Memory
UART Universal Asynchronous Receiver Transmitter
VLSI Very Large Scale Integration
i

Chapter 1
INTRODUCTION
A system on a chip or System-on-Chip (SoC or SOC) is an Integrated Circuit (IC) that integrates
all components of a computer or other electronic system into a single chip. It is a collection of all
components and subcomponents of a system on to a single chip[1]. SoC design allows high perfor-
mance, good process technology, miniaturization, efficient battery life time and cost sensitivities.
This revolution in design had been used by many designers of complex chips, as the performance,
power consumption, cost, and size advantages of using the highest level of integration made avail-
able have proven to be extremely important for many designs. The emerging technologies in the
field of semiconductors, along with the use of the SoC design, have made this possible. System
development based on the use of a core-based architecture, where the reusable cores are inter-
connected by means of a standard on-chip bus, which is the most common way to integrate the
cores into the SoC[2] .This design methodology has been proven to be very effective in terms of
development time and productivity since it reuses existing Intellectual Property (IP) cores[3]. In
a SoC design which uses multi-million gates the design and test engineers face various problems
such as signal integrity problems, heavy power consumption concerns and increase in testability
challenges. The semiconductor industry has continued to make impressive improvements in the
achievable density of very large-scale integrated circuits. In order to keep pace with the levels of
integration available,design engineers have developed new methodologies and techniques to man-
age the increased complexity inherent in these large chips .One such emerging methodology is SoC
design, wherein predesigned blocks called IP blocks, IP cores or virtual components are obtained
from internal sources or third parties and combined into a single chip. These reusable IP cores may
include embedded processors, memory blocks, interface blocks, analog blocks and components
that handle application specific processing functions[1]. The corresponding software components
are also provided in reusable forms which include real time operating systems, kernels, library
functions and device drivers.
1

SYSTEM-ON-CHIP(SoC) FOR TELECOMMAND SYSTEM DESIGN
1.1 What is SoC ?
1. The VLSI manufacturing technology advances has made possible to put millions of transis-
tors on a single die. It enables designers to put systems-on-chip that move everything from
the board onto the chip eventually.
2. SoC is a high performance microprocessor, since we can program and give instruction to the
uP to do whatever you want to do.
3. SoC is the efforts to integrate heterogeneous or different types of silicon IPs on to the same
chip, like memory, uP, random logics, and analog circuitry.
DEPT OF ECE, JCE, BELAGAVI 2

Chapter 2
SoC DESIGN METHODOLOGY
Every technological improvement in the integrated circuit industry is followed by the development
of new design technology. The design methodologies can be grouped into the following Categories:
• Area-Driven Design
• Timing Driven Design
• Block-Based Design
• IP- Core Based Design
• Platform Based Design
In this Project Report, the IP core Based Design Methodology is used. Since each and every
component is being checked by itself it is easy to integrate them. It facilitates timing closure and
functional correctness and also it meets the need of many different designs thereby enhancing the
conﬁgurability.
3

Chapter 3
Design Architcture
In this Project Report an On-Board System (OBS) of a small Satellite is implemented in the form
of a telecommand SoC. Soft IP cores written in the hardware description language VHDL (Verilog
Code) are used to build the SoC. The resulting subsystem is the integration of SRAM, and Teleme-
try and Telecommand Processor (EDAC Unit) was designed. The Block Diagram of the design is
shown in Fig. 3.1 The telecommand input data is send from ground station to the space station it is
given as input to the SRAM . In space applications it is well known that in Low Earth Orbit (LEO)
stored digital data suffers from SEUs. These upsets are induced naturally by radiation. Bit-ﬂips
caused by SEUs are a well-known problem in memory chips and error detection and correction
techniques have been an effective solution to this problem. For the secure transaction of data be-
tween the CPU of the on board computer and its local RAM, the program memory has generally
been designed by applying the Hamming code in the error detection and correction unit so that
the errors can be detected and corrected and the resultant output will be a error free data[4]. The
resultant error free data is fed to the processor ,so that it will process the error free data and also it
will collect all the on -board data signals and produce the resultant data output.
Figure 3.1: Block diagram of soc design
3.1 Design of SRAM
Static random-access memory (SRAM) is a type of semiconductor memory that uses bistable latch-
ing circuitry to store each bit. The Dynamic RAM memory can be deleted and refreshed while
running the program, where as Static RAM is not possible to refresh the programs. But it is still
volatile in the conventional sense that data is eventually lost when the memory is not powered.
4

Fig3.2 Block diagram of 2K x32 bit SRAM The basic architecture of a static RAM includes one
or more rectangular arrays of memory cells with support circuitry to decode addresses, and im-
plement the required read and write operations[5]. The block diagram of 2k x 32 bit SRAM is
shown in Fig.3.2. SRAM memory arrays are arranged in rows and columns of memory cells called
wordlines and bitlines, respectively. Each memory cell has a unique location or address defined
by the intersection of a row and column, which is linked to a particular data input/output pin. The
total size of the memory, the speed at which the memory must operate, layout and testing require-
ments, and the number of data inputs and outputs on the chip determines the number of arrays on
a memory chip. Memory arrays are an essential building block in any digital system. The aspects
of designing an SRAM are very vital to designing other digital circuits. The majority of space
taken in an integrated circuit is the memory. Consider an Nxn SRAM array where ’N’ indicates the
number of bytes and ’n’ indicates the byte size. The size of an SRAM with m address lines and n
data lines is 2/m words, or 2/ m x n bits.
Figure 3.2: Block diagram of 2k x32 bit sram
3.2 Why use an SRAM?
There are many reasons to use an SRAM or a DRAM in a system design. Design tradeoffs include
density, speed, volatility, cost, and features. All of these factors should be considered before you
select a RAM for your system design.
• Speed: The primary advantage of an SRAM over a DRAM is its speed. The fastest DRAMs
on the market still require five to ten processor clock cycles to access the first bit of data.
Although features such as EDO and Fast Page Mode have improved the speed with which
subsequent bits of data can be accessed, bus performance and other limitations mean the
processor must wait for data coming from DRAM. Fast, synchronous SRAMs can operate

at processor speeds of 250 MHz and beyond, with access and cycle times equal to the clock
cycle used by the microprocessor. With a well designed cache using ultra-fast SRAMs,
conditions in which the processor has to wait for a DRAM access become rare.
• Density: Because of the way DRAM and SRAM memory cells are designed, readily avail-
able DRAMs have significantly higher densities than the largest SRAMs.
• Volatility: While SRAM memory cells require more space on the silicon chip, they have
other advantages that translate directly into improved performance. Unlike DRAMs, SRAM
cells do not need to be refreshed. This means they are available for reading and writing data
100% of the Time.
• Cost: If cost is the primary factor in a memory design, then DRAMs win hands down. If,
on the Other hand, performance is a critical factor, and then a well-designed SRAM is an
effective cost performance solution.
• Custom features: Most DRAMs come in only one or two flavors. This keeps the cost down,
but doesn’t help when you need a particular kind of addressing sequence, or some other cus-
tom feature. SRAMs are tailored, via metal and substrate, for the processor or application that
will be using them. Features are connected or disconnected according to the requirements of
the user. Likewise, interface levels are selected to match the processor levels. Provides Pro-
cessor specific solutions by producing a chip with a standard core design, plus metal mask
options to define feature sets.

3.3 RTL Schematic of SRAM
Figure 3.3: RTL Schematic of SRAM

3.4 Flow Chart
Figure 3.4: Flow chart

Chapter 4
TELECOMMAND and TELEMETRY
processor
Figure 4.1: Telecommand and Telemetry Processor
4.1 Design of TELECOMMAND and TELEMETRY Processor
Unit
Error Correction Codes (ECC) and error detection and correction (EDAC) schemes have been
implemented in memory designs to tolerate faults and enhance reliability[9]. Extra check bits
(parity bits) have to be stored along with the information bits, so the hardware overhead includes
the encoding decoding circuit and the memory space for check bits. ECC can protect the memory
from attacks of hard and soft errors. The modiﬁed Hamming Code are the most widely used Single-
9

Error Correctable codes. Here we are using extended Hamming code where we use a overall parity
bit in addition to remaining bits. The code word format is shown in Fig 4.2.
Figure 4.2: : ECC Code word format
4.2 Hamming Code
Hamming code error detection and correction methodology is used for error free communication.
In communication system[3] .The transmitted and received data between source and destination
may be corrupted due to any type of noise. In order to ﬁnd the original transmitted data we use
Hamming code error detection and correction technique[6]. In hamming code error detection and
correction technique to get error free data at destination, we encrypt information data according
to even and odd parity method before transmission of information at source end. Hamming codes
are still widely used in computing telecommunication and other applications[8] .lt is also applied
in data compression and block turbo codes. Because of the simplicity of Hamming codes they are
widely used in computer memory. The hamming code representation of various data bits are shown
in TABLE 4.1. belongs to the family of (n, k) linear block codes where
Block length (n) =2^m 1....... (1)
Number of message bits (k) =2^m-m-1......... (2)
Number of parity bits (m) = n-k ...........(3)
Table 4.1: Hamming code bits representation
DATA BITS CHECK BITS TOTAL BITS
1 2 3
4 3 7
7 4 11
8 4 12
32 6 38
64 7 71

4.2.1 Error Correction
Use of simple parity allows detection of single-bit errors in a received message. Correction of these
errors requires more information, since the position of the corrupted bit must be identiﬁed if it is to
be corrected. (If a corrupted bit can be detected, it can be corrected by simply complementing its
value.) Correction is not possible with one parity bit since any bit error in any position produces
exactly the same information, i.e., error. If more bits are included in a message, and if those bits
can be arranged such that different corrupted bits produce different error results, then corrupted
bits could be identiﬁed.
Forward error correction (FEC).Digital communication systems, par particularly those used in
military, need to perform accurately and reliably even in the presence of noise and interference.
Among many possible ways to achieve this goal, forward error-correction coding is the most
effective and economical. Forward error-correction coding (also called channel coding) is a type
of digital signal processing that improves reliability of the data by introducing a known structure
into the data sequence prior to transmission. This structure enables the receiving system to detect
and possibly correct errors caused by corruption from the channel and the receiver. As the name
implies, this coding technique enables the decoder to correct errors without requesting retransmis-
sion of the original information. Hamming code is a typical example of forward error correction.
In a communication system that employs forward error-correction coding, the digital information
source sends a data sequence to an encoder. The encoder inserts redundant (or parity)bits, thereby
outputting a longer sequence of code bits, called a code word. These code words can then be trans-
mitted to a receiver, which uses a suitable decoder to extract the original data sequence.
4.3 Designing (n, k, t) Hamming Code
The (n, k, t) code refers to an n-bit code word having k data bits (where n > k) and r (=nk) error-
control bits called redundant or redundancy bits with the code having the capability of correcting t
bits in the error (i.e., t corrupted bits). If the total number of bits in a transmittable unit (i.e., code
word) is n (=k+r), r must be able to indicate at least n+1 (=k+r+1) different states. Of these, one
state means no error, and n states indicate the location of an error in each of the n positions. So
n+1 states must be discoverable by r bits; and r bits can indicate 2r different states. Therefore, 2r
must be equal to or greater than n+1: 2r e n +1 or 2r e k + r +1
The value of r can be determined by substituting the value of k (the original length of the data
to be transmitted).
For example, if the value of k is 7, the smallest r value that can satisfy this constraint is 4: 24 e
7+4+1.

4.3.1 The (11, 7, 1) Hamming Code
The Hamming code can be applied to data units of any length. It uses the relationship between data
and redundancy bits discussed above, and has the capability of correcting single-bit errors.
For example, a 7-bit ASCII code requires four redundancy bits that can be added at the end of
the data unit or interspersed with the original data bits to form the (11, 7, 1) Hamming code. In
Table 4.2, these redundancy bits are placed in positions 1, 2, 4 and 8 (the positions in an 11-bit
sequence that are powers of 2). For clarity in the examples below, these bits are referred to as r1,
r2, r4 and r8.
In the Hamming code, each r bit is the parity bit for one combination of data bits as shown
below:
r1: bits 1, 3, 5, 7, 9, 11
r2: bits 2, 3, 6, 7, 10, 11
r4: bits 4, 5, 6, 7
r8: bits 8, 9, 10, 11
Each data bit may be included in more than one calculation. In the sequences above, for ex-
ample, each of the original data bits is included in at least two sets, while the r bits are included in
only one set.
Table 4.2: (11, 7, 1) Hamming code bit representation
4.4 Calculation of Redundancy Values
The redundancy bits generation is shown below
r1: bits 1, 3, 5, 7, 9, 11
r2: bits 2, 3, 6, 7, 10, 11
r4: bits 4, 5, 6, 7
r8: bits 8, 9, 10, 11
The Hamming code implementation for an ASCII character, in the ﬁrst step, each bit of the
original character is placed in its appropriate position in the 11-bit unit. In the subsequent steps, the
even parities for the various bit combinations are calculated. The parity value for each combination
is the value of the corresponding r bit.

4.5 Syndrome Generation
The syndrome is the possibility of error which can be generate in the encoder. The syndrome
generation is performed by comparing the received parity bits and generated parity bits in the
decoder. The received parity bits are from P0 to P4 and the generated parity bits from P0 to P4 are
compared. If the bits in both paritys are mismatch (produce non zero output), then we can say that
there is an error. If it gives zero output, then there is no error in parity bits from P0 to P4 and data
bits from D1 to D7. The generated syndrome is sent to both the error logic and the decode logic to
detect and correct the error.

Chapter 5
Integration of SRAM with Telecommand
and Telemetry Processor Unit
In space applications it is well known that in LEO stored digital data suffers from SEUs caused by
radiations. These radiations may be ultraviolet radiation, infrared radiation and gamma radiation.
This change in data caused by SEUs is a well-known problem in memory chips and error detection
and correction techniques have been an effective solution to this problem. For the secure transaction
of data between the CPU of the on board computer and its local RAM, the program memory has
generally been designed by applying the Hamming code.
In order to have the secure transmission of data between a central processing unit and its local
random access memory (RAM) the traditional means of EDAC is a Hamming code. In the theory of
error control the designation (n, k) denotes a block code that takes a k-bit data word and maps it to
an n-bit code word. For computers on board a satellite, and using the latest high density byte-wide
RAMs, there is however a deﬁnite risk of two error bits occurring within one byte of stored data;
either from the impact of a particularly energetic SEU, or from a second SEU creating a second
error, and before the computer has had time to wash the ﬁrst error.
Figure 5.1: Integration of sram with Telecommand and Telemetry Processor unit
14

5.1 RTL Schematic
Figure 5.2: RTL Schematic

Chapter 6
SIMULATION RESULTS AND
DISCUSSION
The architecture was written in Verilog HDL and synthesized by XILINX ISE 13.2. after syn-
thesizing this Verilog HDL code tests were done with XILINX. The following ﬁgure gives the
simulated results.
6.1 Parity Generator
Figure 6.1: Parity Generator
6.2 Error Detector / Syndrome Generator
Figure 6.2: Error Detector / Syndrome Generator
16

6.3 Error Corrector
Figure 6.3: Error Corrector
6.4 Top Processor Output
Figure 6.4: Top Processor Output
6.5 Top Processor Output (with test bench)
Figure 6.5: Top Processor Output (with test bench)

Chapter 7
Advantages,Disadvantages and Applications
7.1 Advantages
• Simple encoding
• Linear operations
• Fast encoding
• Less amount of redundancy than Repetition Code.
• In case of any change the conﬁguration then no need to change the hardware components
only needs to change the code as per speciﬁc function.
7.2 Disadvantages
• High amount of parity.
• It corrects only one bit correction.
7.3 Applications
• We can use it in satellite communication, which are in lower orbit for error detection and
correction.
• In wireless communication for error detection and correction.
• In wire line communication for error detection and correction.
18

Chapter 8
Results and Discussions
Table shows synthesis report which gives information of the cell usage, device utilization con-
straint, timing summary. The device utilization gives information of the total hardware utilized. In
this the integration of SRAM and Telecommand and Telemetry Processor done so the data input
is fed to the SRAM ,due to some radiations in the space the data stored in the SRAM gets ﬂipped
.It is passed to the Telecommand and Telemetry Processor unit in order to detect and correct the
errors.
8.1 Xilinx Device Utilization Summaries
Table 8.1: Xilinx device utilization summaries
19

8.2 Clock Report
Table 8.2: Clock report

Chapter 9
Conclusions and Future Scope
The primary focus in SoC verification is on checking the integration between the various compo-
nents. Rather than implementing each of these components separately, the role of the SoC designer
is to integrate them onto a chip to implement complex functions in a relatively short time. Since
IP cores are pre-designed and preverified, the designer can concentrate on the complete system
without having to worry about the correctness or performance of the individual components. The
conventional telecommand system is designed with SRAM, Telecommand and Telemetry Proces-
sor and they are integrated to form a SoC design. The simulation of each system is done separately
and then integrated to produce final output. Future work includes the ASIC implementation of the
entire design.
21

Chapter 10
Datasheet
10.1 Introduction
The Spartan˝o-3E family of Field-Programmable Gate Arrays (FPGAs) is specifically designed to
meet the needs of high volume, cost-sensitive consumer electronic applications. The five-member
family offers densities ranging from 100,000 to 1.6 million system gates, as shown in Table 10.1.
The Spartan-3E family builds on the success of the earlier Spartan-3 family by increasing the
amount of logic per I/O, significantly reducing the cost per logic cell. New features improve sys-
tem performance and reduce the cost of configuration. These Spartan-3E FPGA enhancements,
combined with advanced 90 nm process technology, deliver more functionality and bandwidth per
dollar than was previously possible, setting new standards in the programmable logic industry. Be-
cause of their exceptionally low cost, Spartan-3E FPGAs are ideally suited to a wide range of con-
sumer electronics applications, including broadband access, home networking, display/projection,
and digital television equipment. The Spartan-3E family is a superior alternative to mask pro-
grammed ASICs. FPGAs avoid the high initial cost, the lengthy development cycles, and the in-
herent inflexibility of conventional ASICs. Also, FPGA programmability permits design upgrades
in the field with no hardware replacement necessary, an impossibility with ASICs.
10.2 Features
• Very low cost, high-performance logic solution for high-volume, consumer-oriented appli-
cations
• Proven advanced 90-nanometer process technology
• Multi-voltage, multi-standard SelectIO interface pins
• Up to 376 I/O pins or 156 differential signal pairs
• LVCMOS, LVTTL, HSTL, and SSTL single-ended signal standards
22

• 3.3V, 2.5V, 1.8V, 1.5V, and 1.2V signaling
• 622+ Mb/s data transfer rate per I/O
• True LVDS, RSDS, mini-LVDS, differential HSTL/SSTL differential I/O
• Enhanced Double Data Rate (DDR) support
• DDR SDRAM support up to 333 Mb/s
• Abundant, flexible logic resources
• Densities up to 33,192 logic cells, including optional shift register or distributed RAM sup-
port
• Efficient wide multiplexers, wide logic
• Fast look-ahead carry logic
• Enhanced 18 x 18 multipliers with optional pipeline
• IEEE 1149.1/1532 JTAG programming/debug port
• Hierarchical SelectRAM memory architecture
• Up to 648 Kbits of fast block RAM
• Up to 231 Kbits of efficient distributed RAM
• Up to eight Digital Clock Managers (DCMs)
• Clock skew elimination (delay locked loop)
• Frequency synthesis, multiplication, division
• High-resolution phase shifting
• Wide frequency range (5 MHz to over 300 MHz)
• Eight global clocks plus eight additional clocks per each half of device, plus abundant low-
skew routing
• Configuration interface to industry-standard PROMs
• Low-cost, space-saving SPI serial Flash PROM
• Low-cost Xilinx˝o Platform Flash with JTAG
• Fully compliant 32-/64-bit 33 MHz PCI support (66 MHz in some devices)

• Low-cost QFP and BGA packaging options
• Common footprints support easy density migration
• XA Automotive version available
10.3 Summary of Spartan-3E FPGA Attributes
Table 10.1: Summary of Spartan-3E FPGA attributes
10.4 Architectural Overview
The Spartan-3E family architecture consists of five fundamental programmable functional ele-
ments:
• Configurable Logic Blocks (CLBs) contain flexible Look-Up Tables (LUTs) that implement
logic plus storage elements used as flip-flops or latches. CLBs perform a wide variety of
logical functions as well as store data.

• Input/Output Blocks (IOBs) control the flow of data between the I/O pins and the internal
logic of the device. Each IOB supports bidirectional data flow plus 3-state operation. It
supports a variety of signal standards, including four high-performance differential standards.
Double Data-Rate (DDR) registers are included.
• Block RAM provides data storage in the form of 18-Kbit dual-port blocks.
• Multiplier Blocks accept two 18-bit binary numbers as inputs and calculate the product.
• Digital Clock Manager (DCM) Blocks provide self-calibrating, fully digital solutions for
distributing, delaying, multiplying, dividing, and phase-shifting clock signals.
These elements are organized as shown in Figure 10. 1. A ring of IOBs surrounds a regular array
of CLBs. Each device has two columns of block RAM except for the XC3S100E, which has
one column. Each RAM column consists of several 18-Kbit RAM blocks. Each block RAM is
associated with a dedicated multiplier. The DCMs are positioned in the center with two at the top
and two at the bottom of the device. The XC3S100E has only one DCM at the top and bottom,
while the XC3S1200E and XC3S1600E add two DCMs in the middle of the left and right sides. The
Spartan-3E family features a rich network of traces that interconnect all five functional elements,
transmitting signals among them. Each functional element has an associated switch matrix that
permits multiple connections to the routing.
Figure 10.1: Spartan-3E family architecture

10.5 Configuration
Spartan-3E FPGAs are programmed by loading configuration data into robust, reprogrammable,
static CMOS configuration latches (CCLs) that collectively control all functional elements and
routing resources. The FPGAs configuration data is stored externally in a PROM or some other
non-volatile medium, either on or off the board. After applying power, the configuration data is
written to the FPGA using any of seven different modes:
• Master Serial from a Xilinx Platform Flash PROM
• Serial Peripheral Interface (SPI) from an industry-standard SPI serial Flash
• Byte Peripheral Interface (BPI) Up or Down from an industry-standard x8 or x8/x16 parallel
NOR Flash
• Slave Serial, typically downloaded from a processor
• Slave Parallel, typically downloaded from a processor
• Boundary Scan (JTAG), typically downloaded from a processor or system tester
Furthermore, Spartan-3E FPGAs support MultiBoot configuration, allowing two or more FPGA
configuration bitstreams to be stored in a single parallel NOR Flash. The FPGA application con-
trols which configuration to load next and when to load it.
10.6 I/O Capabilities
The Spartan-3E FPGA Select IO interface supports many popular single-ended and differential
standards. Spartan-3E FPGAs support the following single-ended standards:
• 3.3V low-voltage TTL (LVTTL)
• Low-voltage CMOS (LVCMOS) at 3.3V, 2.5V, 1.8V, 1.5V, or 1.2V
• 3V PCI at 33 MHz, and in some devices, 66 MHz
• HSTL I and III at 1.8V, commonly used in memory applications
• SSTL I at 1.8V and 2.5V, commonly used for memory applications Spartan-3E FPGAs sup-
ports the following differential standards
• LVDS
• Bus LVDS
• Mini-LVDS

• RSDS
• Differential HSTL (1.8V, Types I and III)
• Differential SSTL (2.5V and 1.8V, Type I)
• 2.5V LVPECL input
10.7 Package Marking
Figure provides a top marking example for Spartan-3E FPGAs in the quad-ﬂat packages. Figure
3 shows the top marking for Spartan-3E FPGAs in BGA packages except the 132-ball chip-scale
package (CP132 and CPG132). The markings for the BGA packages are nearly identical to those
for the quad-ﬂat packages, except that the marking is rotated with respect to the ball A1 indicator.
Figure 10.2 shows the top marking for Spartan-3E FPGAs in the CP132 and CPG132 packages.
On the QFP and BGA packages, the optional numerical Stepping Code follows the Lot Code.
The 5C and 4I part combinations can have a dual mark of 5C/4I. Devices with a single mark are
only guaranteed for the marked speed grade and temperature range. All 5C and 4I part combina-
tions use the Stepping 1 production silicon.
Figure 10.2: Spartan-3e qfp package marking example
Figure 10.3: Spartan-3e bga package marking example

Figure 10.4: Spartan-3e cp132 and cpg132 package marking example
10.8 VQ100 Footprint
VQ100 Footprint In Figure 10.5 , note pin 1 indicator in top-left corner and logo orientation.
Figure 10.5: VQ100 Package footprint (top view)

Figure 10.6: VQ100 Package footprint (top view) cont..

Bibliography
[1] International Journal of Advanced Research in Computer and Communication Engineering
Vol. 2, Issue 3, March 2013System on Chip (SoC) for Telecommand System Design Rajes-
vari.R, Manoj.G, Angelin Ponrani.M
[2] Hwang. S and Abraham J. A. (200 I) "Reuse of addressable system bus tor SoC testing," Proc.
IEEE Int. ASIC/SoC Conf pp .215-219.
[3] Qingdong Meng.,Zhaolin Li.,Fang Wang.(2010) "Functional veriﬁcation of external memory
interface IP core based on restricted random testbench"International conference on computer
Engineering and Technology.
[4] DESIGN OF HAMMING CODE USING VERILOG HDL By Varun Jindal
[5] 2013 International Conference on Signal Processing, Image Processing and Pattern Recogni-
tion [ICSIPR] IP Core Based Architecture of Telecommand System on Chip (SoC) for Space-
craft applications Rajesvari.R, Manoj.G, Angelin Ponrani.M
[6] P. Chen., Yeh Y. T., Chen C.H., Yeh J. C and Wu C. W. (2006)"An Enhanced EDAC Method-
ology for Low Power PSRAM", IEEE International Test Conference.
[7] Chao-Da Huang, Jin-Fu Li, Member, IEEE, and Tsu-Wei Tseng"ProTaR: An Intrastructure IP
tor Repairing RAMs in SoCs".
[8] K. Gupta and Prof R. L. Dua.(20 I I) " 30 BIT Hamming Code tor Error Detection and Correc-
tion with Even Parity and Odd Parity Check Method by using VHDL", International Journal
of Computer Applications (0975 - 8887) Volume 3 5- No.13.
30

32-Bit Hamming Code
Table 10.2: 32-Bit hamming code

64-Bit Hamming Code
Table 10.3: 64-Bit hamming code

Table 10.4: 64-Bit hamming code cont..

system on chip for telecommand system design

Recommended

Recommended

More Related Content

What's hot

What's hot (19)

Viewers also liked

Viewers also liked (19)

Similar to system on chip for telecommand system design

Similar to system on chip for telecommand system design (20)

Recently uploaded

Recently uploaded (20)

system on chip for telecommand system design