Nyjil CHB0408011 SOC524-PT08

System On a Programmable
Chip
ASSIGNMENT
Centre Name: Electronics and
Communication Engineering
Course Name: M.Sc (Engg) in Real Time
POSTGRADUATE ENGINEERING AND MANAGEMENT

Embedded System
PROGRAMME (PEMP)
Name of the Student : Nyjil George
Student Registration No : CHB0408011
Module Leader at MSRSAS: Mr.Sanket Dessai

________________
PART TIME 2008 BATCH
M.S.Ramaiah School of Advanced Studies

New BEL Road, Gnanagangothri Campus, MSR Nagar, Bangalore-560 054
Tel/Fax: 23605539/23601983; website: http://www.msrsas.org
M.S Ramaiah School of Advanced Studies –Postgraduate Engineering and Management Programme (PEMP)
Declaration Sheet
Delegate’s Name Nyjil George
Reg No CHB0408011
M.Sc (Engg) in Real Time Embedded
Course Batch PT-2008
System
Module Code ESD524
Module Title System On A Programmable Chip.
Module Start Date 19-12-2009 Submission Date 13 – 02 - 2010
Module Leader Mr. Sanket Dessai
Submission Arrangements
This assignment must be submitted to Academic Records Office (ARO) by the submission date before 1730 hours
for both Full-Time and Part-Time students.
Extension requests
Extensions can only be granted by the Head of the Department / Course Manager. Extensions granted by any other
person will not be accepted and hence the assignment will incur a penalty. A copy of the extension approval must be
attached to the assignment submitted.
Late submission Penalties
Unless you have submitted proof of Mitigating Circumstances or have been granted an extension, the penalties for a
late submission of an assignment shall be as follows:
• Up to one week late: Penalty of one grade (5 marks)
• One-Two weeks late: Penalty of two grades (10 marks)
• More than Two weeks late: Fail - 0% recorded (F2)
All late assignments must be submitted to Academic Records Office (ARO). It is your responsibility to ensure that
the receipt of a late assignment is recorded in the ARO. If an extension was agreed, the authorization should be
submitted to ARO during the submission of assignment.
To ensure assignments are written concisely, the length should be restricted a limit indicated in the assignment
questions. Each participant is required to retain a copy of the assignment in his or her record in case of any loss.
Declaration
The assignment submitted herewith is a result of my own investigations and that I have conformed to the guidelines
against plagiarism as laid out in the PEMP Student Handbook. All sections of the text and results, which have been
obtained from other sources, are fully referenced. I understand that cheating and plagiarism constitute a breach of
University regulations and will be dealt with accordingly.
Signature of the
Nyjil George Date 20/01/2010
Delegate
Date stamp from Signature of

ARO ARO Staff
Signature of Signature of
Module Leader Course Manager
System On A programmable Chip ii

Contents
_______________________________________________________________________
Title Page i
Declaration ii
Abstract iii
List of Tables iv
List of Figures v
Acknowledgement vii
1.0 System On A Chip, An Introduction. 1
1.0.1 VARIOUS TECHNOLOGIES. 1
1.0.2 SYMMETRIC AND ASSYMMETRIC MPSOC. 1
1.0.3 COMPARISON, SMPSOC AND ASMPSOC. 3
1.1 CACHE MECHANISM IN MPSoC. 3
1.1.1 MESI protocol 5
1.2 OPERATING SYSTEMS FOR MPSOC. 5
2.0 32 Bit A.L.U Design 7
2.1 Adder/Subtracted Design. 8
2.2 Logic Operations. 9
2.3 VHDL Code For One Bit ALU. 9
2.4 VHDL Code For 32 Bit ALU. 10
2.5 Explanation of 32 Bit ALU with Test Benches. 11
2.6 32 BIT ALU VHD FILE 12
2.7 Test Bench Programme to test All Design Possibilities. 14
2.8 32 Bit ALU DESIGN Conclusion and Result. 17
3.0 Porting Micro C OS on Xilinx FPGA. 18
3.1 µC/OS-II. 18
3.2 Xilinx FPGA SPARTAN 3. 18
3.3 Configuration of Micro C Source OS. 18
3.4 COMPILE AND BUILD MICRO C OS IMAGE 22
3.5 Porting The Image to the Target Board. 25
3.6 Application Program. 25
3.7 OUTPUT 26
3.8 Result And Conclusion. 26
4.0 Bibliography 27
System On A programmable Chip iii

Abstract
_______________________________________________________________________
The development method and implementation procedures of a Multi processor system on

a chip is describing in this Assignment report. Recent technological trends have led
to the introduction of multi-processor systems on a chip (MPSoCs). It can be
expected that the number of processors on such chips will continue to increase.
Power efficiency is frequently the driving force having a strong impact on the
architectures being used.
PART B is describing the development of 32-bit ALU design. An ALU
(Arithmetic Logic Unit) is a combinatorial circuit performing arithmetic and logical
operations. It’s the central execution unit of a CPU, and its complexity can vary. A
simple ALU has two inputs for the operands, one input for a control signal that selects
the operation, and one output for the result.
System On A programmable Chip iv

PART C is Describing that design and development of any application and

port it to micro Cos on a Xilinx Spartan 3 FPGA .
System On A programmable Chip v

List of Tables
_______________________________________________________________________
Table 01 ALU Logic Operations. 9
Table 02 .Com Port Setting for porting. 24
System On A programmable Chip vi

List of Figures
_______________________________________________________________________
Fig 1.1 ASMP 3

Fig 1.2 Cache memory basics 4
Fig 1.3 Cash Memory Architecture in MPSOC. 4
Fig 2.0 Arithmetic and Logic Unit. 7
Fig 2.1 ALU XOR 7
Fig 2.2 ALU Parallel Adder. 8
Fig 2.3 Adder/Subtracted Design. 8
Fig 2.4 Logic Operations. 9
Fig 2.5 32 Bit ALU Synthesis. 11
Fig 2.6 32 Bit ALU Functions. 12
Fig 2.7 ALU Functions. 17
Fig 3.0 System Builder. 19
Fig 3.1 Hardware Configuration. 20
Fig 3.2 Base System Buider. 20
Fig 3.3 configuration. 21
Fig 3.4 Hardware Diagram 21
Fig 3.5 Configuration 23
Fig 3.8 Output. 26
System On A programmable Chip vii

Acknowledgement
_______________________________________________________________________
I wish to express my profound thanks to all those who helped in making this assignment
a reality.
I am especially grateful to the great Director MSRSAS ,Dr.Shankarpal for his
time-to-time, much needed, valuable guidance. Without the full support and cheerful
encouragement of Mr. Sanket Dessai the assignment would not have been completed in
time.
Finally I thank all my class colleagues for having good group discussions, which
helped me to understand the concept better.
System On A programmable Chip viii

CHAPTER 1
-- PART A
______________________________________________________________________________
1.0 System On A Chip, An Introduction.

Modern system-on-chip design shows a clear trend toward integration of multiple processor
cores on a single chip. Designing a multiprocessor system-on-chip (MPSOC) requires an understanding
of the various design styles and techniques used in the multiprocessor. Multiprocessor Systems-on-Chips
covers both design techniques and applications for MPSOCs. Design topics include multiprocessor
architectures, processors, operating systems, compilers, methodologies, and synthesis algorithms, and
application areas covered include telecommunications and multimedia. The SoC chip includes processors
and numerous digital, analog, mixed signal peripherals like Counters, timer, PWMs, RTC, power on
reset, ADCs, DACs, filters, USB, Ethernet, I2C, SPI, Voltage regulator, power management etc.
An integrated circuit that implements most or all of the functions of a complete electronic system
Memory chip is not a system but a component Contains memory, instruction-set processor (CPU),
specialized logic, bus, other digital functions… Generally tailored to the application rather than
being a general-purpose chip. A new crisis to SoC design is increases in functionality, reliability,
bandwidth decreases in cost, power consumption high-intension silicon with Register-Transfer-
Level hardware design techniques. Pressure on chip designers is productive gap, growing cost, time-
to-market. Major Challenges is silicon density, design and verification tools & complexity, bug cost,
software and complex standard.
1.0.1 VARIOUS TECHNOLOGIES.
Parallel Computing: Simultaneous use of multiple processors, all components of a single
architecture, to solve a task. Typically processors identical, single user (even if machine multiuser)
Distributed Computing: Use of a network of processors, each capable of being viewed as a
computer in its own right, to solve a problem. Processors may be heterogeneous, multiuser, usually
individual task is assigned to a single processors
1.0.2 SYMMETRIC AND ASSYMMETRIC MPSOC.
Symmetric MPSOC means, two or more identical processors can connect to a single shared main
memory. Most common multiprocessor systems today use an SMP architecture. In the case of multi-
core processors, the SMP architecture applies to the cores, treating them as separate processors.
SMP systems allow any processor to work on any task no matter where the data for that task are
located in memory, provided that each task in the system is not in execution on two or more
processors at the same time; with proper operating system support, SMP systems can easily move
tasks between processors to balance the workload efficiently.
Fig 1.0. Symmetric MPSOC.
In the case of multi-core processors, the SMP architecture applies to the cores, treating
them as separate processors. SMP systems allow any processor to work on any task no matter where
the data for that task are located in memory; with proper operating system support, SMP systems can
easily move tasks between processors to balance the workload efficiently.
Uni-processor and SMP systems require different programming methods to achieve

maximum performance. Therefore two separate versions of the same program may have to be
maintained, one for each. Programs running on SMP systems may experience a performance
increase even when they have been written for uni-processor systems. This is because hardware
interrupts that usually suspend program execution while the kernel handles them can execute on an
idle processor instead. The effect in most applications is not so much a performance increase as the
appearance that the program is running much more smoothly. In some applications, particularly
compilers and some distributed computing projects, one will see an improvement by a factor of the
number of additional processors. In situations where more than one program executes at the same
time, an SMP system will have considerably better performance than a uni-processor because
different programs can run on different CPUs simultaneously.
Asymmetric MPSoC means a system assigns certain tasks only to certain processors. In particular,
only one processor may be responsible for fielding all of the interrupts in the system or perhaps even
performing all of the I/O in the system. This makes the design of the I/O system much simpler,
although it tends to limit the ultimate performance of the system.
System On A programmable Chip 2

The Massachusetts Institute of Technology (MIT) and Digital Equipment Corporation (DEC)
was introduced the ASMP by early 70s. ASMP allows applications to run specific subtasks on
processors separate from the "master" processor. ASMP computers are composed of multiple
physical processors that are unique, and thus not symmetrical. These processors are defined as either
master or slave: master processors are more capable than slaves and are given full control over what
the slave processors do.
Fig 1.1 ASMP
1.0.3 COMPARISON, SMPSOC AND ASMPSOC.

In SMP, each processor is able to access the entire memory map, there are no master or slave
processors. In this case each processor is non-unique and has equal power. This means that they can
share memory between themselves and can interact with each other directly, regardless of how many
there are in the system. People commonly confuse these architectures and as such it is important to
define the differences. In regards to the operating system, a SMP machine is able to spawn any
process/task on any of the processors available. Because SMP systems have no master or slave
processors, each logical unit is able to complete a given task. In an ASMP system, a certain
processor may not be able to complete a task for a number of reason such as the an inability to
access the entire memory map, special purpose nature of the processor (e.g. a coprocessor), and thus
tasks must be give to it by master processor. Therefore, it is up to the programmer to make sure the
processors are being used to their maximum potential. In an ASMP environment, a programmer has
to worry about whether a processor can complete a given task and how to make the processors
communicate effectively to distribute tasks.
1.1 CACHE MECHANISM IN MPSoC.
Cache memory is fast acting memory than RAM, normally it is Built in with CPU, or located
next to it on a separate chip. The CPU uses cache memory to store instructions that are repeatedly
required to run programs, improving overall system speed. The advantage of cache memory is that
the CPU does not have to use the motherboard’s system bus for data transfer. Whenever data must

be passed through the system bus, the data transfer speed slows to the motherboard’s capability. The
CPU can process data much faster by avoiding the bottleneck created by the system bus.
Fig 1.2 Cache memory basics.

The modern architectures of processors using of multi-cores structures to gain performance
versus power consumption more efficiently. While at each core there is private L1 cash, the L2 cash
is common for all cores, therefore in such systems exists non-trivial problem of cash coherency
support. Cash coherency algorithm must guarantee that all processors uses most update cash lines
and prevent from using outdated cash lines.
Fig 1.3 Cash Memory Architecture in MPSOC.

In MPSOC there are two deferent type of Cache memory architecture that is, Software based Cache
and Hardware based Cache.
Software Based:MPARM is the best example for the software based Cash memory architecture.
The ISS is modeled as a C++ class (CArmProc) and is embedded into a SystemC wrapper
(armsystem). The wrapper allows the usage of the ISS in a SystemC environ, while the bus interface
(implemented in the class STBus initiator) is in charge to translate the ARM requests
toward the bus, to bus-specific protocol requests. In addition, the core contains its cache
as a data member of type CCache. This is a base class from which other classes that
implement specific cache types can be implemented: the fully associative CAssociativeCache), the
directmapped (CDirectCache), and set-associative cache (CSetAssociativeCache).

Hardware Based: The type of interconnect of the multiprocessor architecture: When processors
are connected through a shared medium (such as a bus), protocols can use broadcasting to enforce
coherence. These protocols are called snoopy protocols. These schemes apply to small-scale bus-
based multiprocessors, because of the limited scalability of buses. In absence of a shared medium as
interconnect.
1.1.1 MESI protocol

The MESI protocol makes it possible to maintain the coherence in cached systems. It is based on the
four states that a block in the cache memory can have. These four states are the abbreviations for
MESI: modified, exclusive, shared and invalid. States are explained below:
Modified: Actually, it is an exclusive-modified state. It means that the cache has the only copy that
is correct in the whole system. The data which are in the main memory are wrong. Figure below
explains this in a more detailed way.
Exclusive: Exclusive without having been modified. That is, this cache is the only one that has the
correct value of the block. Data blocks are according to the existing ones in the main memory.
Shared: Shared without having been modified. Another processor can have the data into the cache
memory and both copies are in their current version.
Invalid: It is a non-valid state. The data you are looking for are not in the cache, or the local copy
of these data is not correct because another processor has updated the corresponding memory
position.
1.2 OPERATING SYSTEMS FOR MPSOC.
Another critical demand in SoC designs is to meet realtime constraints of embedded
applications and operating systems. Real-time operating systems (RTOS) are commonly used in
embedded systems. A hard real-time system provides a guarantee that the response to an event must
happen within a specied deadline while a soft real-time system attempts to do its best to meet the
timing constraint. Regardless of any realtime system, given a hardware system, software engineers
make an e_ort to optimize software to meet real-time requirements. As described, the exibility
requirement puts more pressure on the software-side for real-time demands. During a design cycle, if
a software optimization fails, it would cause a redesign of the hardware system architecture for
meeting real-time constraints. Hardware-software co-design often detects design issues in the early
stage to eliminate as many potential problems as possible. Nonetheless, if a software optimization
fails, the burden eventually falls on to the hardware side, forcing hardware engineers to trade o_ the
exibility by employing hardcore IPs for timecritical circuit blocks. a new-born generation of System-
on- Chip (SoC) architectures consisting of complex integrated components communicating with

each other at very high-speed rates is being envisioned. One of their main design challenges will be
the prototyping and power optimization of SoCs consisting of hundreds of processing cores. The OS
can select the voltage and frequency setup of the processor according to their workload and
attending to power, thermal or, in this case, reliability constraints. Also, in the case of heterogeneous
MPSoCs where there are different processing cores, the OS can select the assignment of the tasks to
balance the workload or reduce the premature aging of the devices.
The recent trends of OS development are more moving towards optimizing these factors. Run
time utilization, Resource optimization , Predictability , Reliability , Robustness, POSIX 1003.1b
API including threads, RTEID/ORKID based Classic API, TCP/IP Stack, high
performance port of FreeBSD TCP/IP stack, UDP, TCP, ICMP, DHCP, RARP, TFTP,
RPC, FTPD, HTTPD, CORBA, SNMP, Debugging, GNU debugger (gdb), DDD GUI
interface to GDB thread aware, debug over Ethernet, debug over Serial Port,
Filesystem Support, In-Memory Filesystem (IMFS), TFTP Client Filesystem, FTP
Client Filesystem, FAT Filesystem (IDE and CompactFlash), NFS client,
multitasking capabilities, homogeneous and heterogeneous multiprocessor
systems, event-driven, priority-based, preemptive scheduling, optional rate
monotonic scheduling, intertask communication and synchronization, priority
inheritance, responsive interrupt management, dynamic memory allocation,
high level of user Configurability scripting and Python scripting language.

CHAPTER 2
Part B.
2.0 32 Bit A.L.U Design
Arithmetic and Logic Unit (A.L.U.) – the most significant component inside the C.P.U.
for our learning of the “behind the scene”. It is the chief of operations of the computer. A.L.U.
performs two major operations in processing data: all mathematical computations (addition,
subtraction, ultiplication, and division) and all logical operations (comparisons of data such as;
greater than, less than, equal, greater than or equal to, and less than or equal to). These processing
are the main concentration of how a computer process data, and is the foundation of the “behind the
scene.
Fig 2.0 Arithmetic and Logic Unit.

where the “d” output implements the function of “a” and “b” selected by the “S” control inputs. Note
that the ALU is purely combinational logic and contains no registers and latches. The arithmetic
functions are much more complex to implement than the logic functions. Consider the circuitry
needed to implement

Fig 2.1 ALU XOR

Contrast this with the circuit for the parallel adder.
Fig 2.2 ALU Parallel Adder.

The xor operation requires the signals to travel through only one gate whereas the parallel adder
circuit requires, in the worst case, the signal to travel through all 32 single bit adders. This has two
significant consequences.
1. The worst case delay for the ALU is determined by the carry chain in the adder.
2. The synthesizer will spend a great deal of time trying to optimize (reduce the delay) of the carry
chain for long carry chains. This is why it is impractical to synthesize all 32 bits at once.
2.1 Adder/Subtracted Design.
The adder can be turned into an adder subtracter by noting that
a - b = a + (-b)
where -b is formed (in the 2’s complement representation) by inverting all of the b-bits
and adding one to the lease significant bit. For the ALU, we want to control when the bbits
are inverted, i.e.
• addition: do not invert b-bits, carry in is zero

• subtraction: invert b-bits, carry in is one

The following circuit implements this behavior.
When S=0, the circuit adds; when S=1, the circuit subtracts.
Fig 2.3 Adder/Subtracted Design.

2.2 Logic Operations.
The logic operations are implemented by disabling the carry chain. Extra circuitry as needed can be
added to the adder/subtracter cells to implement the desired logic functions for the ALU. The carry
chain is disabled by forcing the carry in to each bit position to be ‘0’ (not open circuit). The
following circuit disables the carry this way.
Fig 2.4 Logic Operations.

The lines, S(1),S(2), select the following circuit functions.
S1Function S0 Function
00 XOR
01 XNOR
10 ADD

11 Subtract
Table 01 ALU Logic Operations.
2.3 VHDL Code For One Bit ALU.
entity ALU_cell is port(

signal S: in std_logic_vector(1 downto 0);
signal a,b,cin: in std_logic;
signal d,cout: out std_logic);
end ALU_cell;
architecture combo of ALU_cell is
signal p,pnot,g: std_logic;
--internal nodes for b,c inputs to adder
signal c,bint: std_logic
component swcf020 port(
signal DATA1: in std_logic;
signal CTL2: in std_logic;
signal O: out std_logic);
end component;
begin
bint <= S(0) xor b;
g <= a and bint;
p <= a xor bint;
pnot <= not p;
d <= p xor c;
c<=S(1) and cin;
top: swcf020
port map(
DATA1=>g,
CTL2=>pnot,
O=>cout
);
bot: swcf020
port map(
DATA1=>cin,
CTL2=>p,
O=>cout
);
end combo;
2.4 VHDL Code For 32 Bit ALU.
entity alu32 is port(
signal S: in std_logic_vector(2 downto 0);
signal a,b: in std_logic_vector(31 downto 0);
signal d: out std_logic_vector(31 downto 0);
signal Cin: in std_logic;
signal Cout: out std_logic;
signal V: out std_logic);
end alu32;
architecture combo of alu32 is
signal c: std_logic_vector(7 downto 0);
component alu4 port(

signal S: in std_logic(2 downto 0);

signal a,b: in std_logic(3 downto 0);
signal d: out std_logic_vector(3 downto 0);
signal Cin: in std_logic;
signal Cout: out std_logic;
signal V: out std_logic);
end component;
begin
slice7: alu4
port map(
S => S,
a => a(31 downto 28),
b => b(31 downto 28),
d => d(31 downto 28),
Cin => c(7),
Cout => Cout
V => V
);
c(0) <= Cin;
gen026: for i in 0 to 6 generate
slice: alu4 port map(
S=>S,
Cin=>c(i),
Cout=>c(i+1)
a=>a(4*i+3 downto 4*i),
b=>b(4*i+3 downto 4*i),
d=>d(4*i+3 downto 4*i),
);
end generate;
end combo;
2.5 Explanation of 32 Bit ALU with Test Benches.

The previous section of 32 bit ALU is now implemented in the Xilinx ISE tool 10.1. The ISE Design
Suite is by Xilinx. The ISE Design Suite features include design entry and synthesis supporting
Verilog or VHDL, place-and-route (PAR), completed verification and debug using ChipScope Pro
tools, and creation of the bit files that are used to configure the chip

Fig 2.5 32 Bit ALU Synthesis.

Fig 2.6 32 Bit ALU Functions.

2.6 32 BIT ALU VHD FILE
----------------------------------------------------------------------------------
-- Module Name: aludesign - Behavioral
-- Project Name: MSRSAS ALU
-- Target Devices:
-- Tool versions:
-- Description:
--
-- Dependencies:
--
-- Revision:
-- Revision 0.01 - File Created
-- Additional Comments:
--
----------------------------------------------------------------------------------
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;

use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;
---- Uncomment the following library declaration if instantiating

---- any Xilinx primitives in this code.
--library UNISIM;
--use UNISIM.VComponents.all;
entity aludesign is
Port ( A : in STD_LOGIC_VECTOR (31 downto 0);
B : in STD_LOGIC_VECTOR (31 downto 0);
Sel : in STD_LOGIC_VECTOR (1 downto 0);
Res : out STD_LOGIC_VECTOR (31 downto 0));
end aludesign;
architecture Behavioral of aludesign is

begin
process(A,B,Sel)
begin
-- use case statement to achieve
-- different operations of ALU
case Sel is
when "00" =>
Res <= A + B;
when "01" =>
Res <= A - B;
when "10" =>
Res <= A or B;
when "11" =>
Res <= A and B;
when others =>

Res <= "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX";

end case;
end process;
end Behavioral;
2.7 Test Bench Programme to test All Design Possibilities.

--------------------------------------------------------------------------------
-- Copyright (c) 1995-2003 Xilinx, Inc.
-- All Right Reserved.
--------------------------------------------------------------------------------
-- ____ ____
-- / /\/ /
-- /___/ \ / Vendor: Xilinx
-- \ \ \/ Version : 10.1.03
-- \ \ Application : ISE
-- / / Filename : test_tbw.vhw

-- /___/ /\ Timestamp : Sat Jan 26 21:20:06 2008

-- \ \ / \
-- \___\/\___\
--Command:
--Design Name: test_tbw
--Device: Xilinx
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;
USE IEEE.STD_LOGIC_TEXTIO.ALL;
USE STD.TEXTIO.ALL;
ENTITY test_tbw IS
END test_tbw;
ARCHITECTURE testbench_arch OF test_tbw IS
FILE RESULTS: TEXT OPEN WRITE_MODE IS "results.txt";
COMPONENT MSRSASALU
PORT (
Op_A : In std_logic_vector (31 DownTo 0);
Op_B : In std_logic_vector (31 DownTo 0);
Op_Sel : In std_logic_vector (2 DownTo 0);
Output : Out std_logic_vector (31 DownTo 0)
);
END COMPONENT;
SIGNAL Op_A: std_logic_vector (31 DownTo 0) :=
"00000000000000000000000000000000";
SIGNAL Op_B: std_logic_vector (31 DownTo 0) :=
"00000000000000000000000000000000";
SIGNAL Op_Sel : std_logic_vector (2 DownTo 0) := "000";
SIGNAL Output: std_logic_vector (31 DownTo 0) :=
"00000000000000000000000000000000";
BEGIN
UUT : MSRSASALU

PORT MAP (
Op_A => Op_A,
Op_B => Op_B,
Op_Sel => Op_Sel,
Output => Output
);
PROCESS
BEGIN
WAIT FOR 50 ns;
Op_Sel <= "000";
Op_A <= "00000000000000110000000000000100";
Op_B <= "00000000001110000000000000000011";
WAIT FOR 50 ns;
Op_Sel <= "001";
Op_A <= "00000000000000000000111000000111";
Op_B <= "00000000000000010000000000000011";
WAIT FOR 50 ns;
Op_Sel <= "010";
Op_A <= "00000000000001100000000001000000";
Op_B <= "00000000000010000011000000000011";
WAIT FOR 50 ns;
Op_Sel <= "011";
Op_B <= "00000000001110000000000001000000";
Op_A <= "00000000010000000001100000000011";
WAIT FOR 50 ns;
Op_Sel <= "100";
Op_A <= "00001100000000000000000000000101";
Op_B <= "00000000000000000000100000000011";
WAIT FOR 50 ns;
Op_Sel <= "101";
Op_A <= "00000000000000110000000000001001";
Op_B <= "00000000000000000000010000000101";
WAIT FOR 50 ns;

Op_Sel <= "110";

Op_A <= "00000000000000011000000000001001";
Op_B <= "00000000000000000000000000001011";
WAIT FOR 50 ns;
Op_Sel <= "111";
Op_A <= "00000000000011010000000000001001";
Op_B <= "00000110000000000000000000001111";
END PROCESS;
END testbench_arch;
Fig 2.7 ALU Functions.

2.8 32 Bit ALU DESIGN Conclusion and Result.
Design of 32 bit ALU using HLDs, Verification of the 32 bit ALU with suitable test benches,
Implementation of the carry-over and shift operations in the 32 bit ALU. ,Determination of relative
timing between various ALU operations. Realization of the hardware on a Spartan 5 board for the 32
bit ALU designed. Timing constraints were verified and the realization of the 32 Bit ALU using the
RL logic used is verified as feasible.

PART C CHAPTER 3
______________________________________________________________________________
3.0 Porting Micro C OS on Xilinx FPGA.

To port the OS on the Spartan FPGA, we need to configure necessary hardware
first. Spartan -3 FPGA has micro Blaze soft IP core and power PC hardware IP core.
This part of assignment we are using the micro blaze software IP core.
3.1 µC/OS-II.
Most of µC/OS-II is written in highly portable ANSI C, with target microprocessor-specific code
written in assembly language. Assembly language is kept to a minimum to make µC/OS-II easy to
port to other processors. µC/OS-II is a completely portable, ROMable, scalable, preemptive, real-
time, multitasking kernel. µC/OS-II is written in ANSI C and contains a small portion of assembly
language code to adapt it to different processor architectures. To date, µC/OS-II has been ported to
over 45 different processor architectures. A ‘port’ is the part of the software that adapts µC/OS-II to
different processor architectures. The files that comprise the MicroBlaze port are included as a
readymade package from Micrium website as an example µC/OS-II-based application.
3.2 Xilinx FPGA SPARTAN 3.
The MicroBlaze Spartan3A DSP 1800A Embedded Development Board utilizes Xilinx Spartan-3E
XC3SD1800A-4FG676 device. The board includes 125MHz System Clock, RS232 serial ports, 8
DIP switches, 4 push buttons, 8 LEDs, VGA port, 4 SPI Ports, 10/100/1000 Ethernet port, 64MBit
SPI flash, 16 MB of parallel NOR flash and 128MB DDR2 SDRAM. User I/O is supported with a
168 Pin EXP mezzanine connector, 2 Digilent 6 pin ports, and a general purpose 30 pin I/O
connector. The MicroBlaze(TM) 32-bit soft processor is a RISC-based engine with a 32 register by
32 bit LUT RAM-based Register File, with separate instructions for data and memory access. It
supports both on-chip BlockRAM and/or external memory. All peripherals are implemented on the
FPGA fabric.
3.3 Configuration of Micro C Source OS.
The Micro C Os is free downloadable from Micrium Website that is AN-1013.Zip.The content of
this Zip is the following Directories.
1 Micrium\AppNotes\AN1xxx-RTOS\AN1013-uCOS-II-MicroBlaze
2 \Micrium\Software\EvalBoards\Xilinx\Generic\GNU\EX1_OS
3 \Micrium\Software\EvalBoards\Xilinx\Generic\GNU\BSP
4 \Micrium\Software\uCOS-II\Source
5 \Micrium\Software\uCOS-II\Ports\MicroBlaze\GNU
6 \edk_user_repository\Micrium\bsp\uCOS-II_v2_90_a

Fig 3.0 System Builder.
Choose the Micro blaze IP core and staptan-3 device in the next screen. Also choose the clock
required for the application, debug method and RAM memory required as shown below screen shot.

Fig 3.1 Hardware Configuration.
Now choose the peripheral of your choice for the application here. I have chosen GPIO for LED
interface, RS 233 for connectivity and push buttons. Also configure the memory mapping; I have
used the default memory mapping.
Fig 3.2 Base System Buider.

Fig 3.3 configuration.
Fig 3.4 Hardware Diagram

3.4 COMPILE AND BUILD MICRO C OS IMAGE

Generate the bit stream file form the Xilinx studio. This will freeze the hardware configuration
of the FPGA for this particular application. This bit stream file should be used with Xilinx Platform
SDK IDE for developing multi tasking program. platform studio software and open Xilinx Platform
SDK IDE for developing multi tasking program with micro blasé processor.the bsp.h is defining the
following constants.
1 BSP_INTC_DEVICE_ID: This constant represents interrupt controller’s device ID.

2 BSP_INTC_TIMER1_ID: This is the ID for timer’s interrupt within the interrupt
controller.
3 BSP_INTC_ADDR: This is the base address of your interrupt controller. The board
support routines expect a Xilinx OPB Interrupt Controller to be present in the system.
4 BSP_TIMER1_ADDR: This is the base address of the timer that will provide µC/OS-
II’s tick interrupt. The board support routines assume that a Xilinx OPB
Timer/Counter is used
5 BSP_GPIO_ADDR: This is the base address of a GPIO peripheral that is connected
to LEDs. bsp.c assumes that you have a Xilinx OPB GPIO core, with the first bit of
this GPIO representing an LED. If this is not the case, you may need to modify the
LED routines defined in bsp.c.
6 BSP_TMR_VAL: This constant, which is involved in the initialization of the above
mentioned timer, should be defined using OS_TICKS_PER_SEC, the µC/OS-II
configuration constant that normally determines the frequency of the operating
system’s tick interrupts. Specifically, assuming that
XPAR_CPU_CORE_CLOCK_FREQ_HZ represents the timer’s frequency,
BSP_TMR_VAL should be defined as XPAR_CPU_CORE_CLOCK_FREQ_HZ /
OS_TICKS_PER_SEC.

Fig 3.5 Configuration

3.5 Porting The Image to the Target Board.

To port the image onto the target board compile the project once again after we added
the new piece of code that does the LED toggling. Make sure the program complies without errors.
Below screen shot shows the successful build process result After the complication and build
process, go to the File menu/ Device configuration/ Program FPGA” as shown in the screen shot.
This will take us to a window where in we can program the FPGA.
Step1: Connect the Host Computer to target board
Step2: open Hyper terminal
Step3: Switch on the target board.
Step4: Use the software tool and download the image to target board.
Table 02 .Com Port Setting for porting.

Port Com 1
BPS 9600
Data
bits 8
Parity None
Stop 1
Bits
Flow None

Control
3.6 Application Program.

/*
Description: SoC assignment, uCOS2 Porting on Xilinx FPGA with 32bit Microblaze soft core
processor
Version: 1.1
Author:
Date: Feb5th,2010
*/
#include "includes.h"
#define LED_DATAa 0x55
#define LED_DATAb 0xaa
OS_STK Task1Stk[TASK1_STK_SIZE];
void Task1(void *pdata)
{
BSP_InitIO();
//LED_Write(LED_DATA);
while(1)
{
xil_printf("Task1 is in execution...\r\n");
LED_Write(LED_DATAa);
OSTimeDlyHMSM(0,0,3,0);
LED_Write(LED_DATAb);
OSTimeDlyHMSM(0,0,3,0);
}
}
int main(void)
{
BSP_IntDisAll();
OSInit();
OSTaskCreate(Task1,0,&Task1Stk[TASK1_STK_SIZE - 1],TASK1_PRIO);
OSStart();
}
3.7 OUTPUT

USB to Jtag
Converter
Power Supply
Fig 3. 8 Output.
3.8 Result And Conclusion.
The Porting of µC- OS on FPGA has been successfully completed .

Configured the Micro C OS on Xilinx Board, Configure the timer Interrupt, Compiled the Image and
downloaded to Board.
4.0 Bibliography
________________________________________________________________________________
[1] Lathi B.P, Modern Digital and Analog communications systems, PRISM publications, Indian
Low Price Edition, Aug 2009
[2] Roger W. Peterson, Introduction to MPSoC Communication, Prentice Hall Publications, Aug
2009
[3] Santhanam, Anand; Vishal Kulkarni, Digital development on an Embedded Device.

DeveloperWorks. IBM, October 2007;
[4] u-COSII Explained, Online. Geocites, Available from:

http://www.geocities.com/SiliconValley/2151/huffman.html Accessed: [14 Jan 2010].

[5] u-COSII porting, Online Available from:

http://www.dsprelated.com/groups/matlab/show/6208.php Accessed: [14 Jan 2010].
[6] u-COSII: A brief tutorial. Online Available from: http http://en.wikipedia.org/wiki/Direct-

sequence_spread_spectrum. Accessed: [25 Jan 2010].
[7] u-COSII - The Complete Guide. Online Available from:

http://www.ele.uri.edu/Courses/ele436/labs/DSSS.pdf. Accessed: [25 Jan 2010].
[8] Ambler, Scott William, The Xilinx SoC Complete Guide. Cambridge University Press. ISBN
0-521-54018-6. November 2004. Available from: http://www.dctcompletereference.org.
Accessed: [13 Jan 2010].
[9] Schoonees, J.A.; Braun, R.M, A note on the MPSoC signals crosstalk, Communications and
Signal Processing 1993. International Conference. IEEE International Conference vol.1 256
– 260.
© IEEE Digital Object Identifier 10.1109/COMSIG.1993.365860
[10] Morelos-Zaragoza, R.H.; Shu Lin, u-COSII block-modulation codes for unequal error
protection, Embedded Engineering. Information Theory, IEEE Transactions on Volume 41,
Issue 2, March 1995 Page(s):576 - 581
© IEEE Digital Object Identifier 10.1109/18.370154
[11] Prabhu, V.K, u-COSII and Offset Modulation with Bandlimiting Filters Computer
Engineering, Aerospace and Electronic Systems, IEEE Transactions on Volume AES-17,
Issue 1, Jan. 1981 Page(s):2 - 8
© IEEE Digital Object Identifier 10.1109/TAES.1981.309029
[12] Wright, C.; Cowan, C.; Morris, J.; Smalley, S, G, Digital security modules: general security
support for the Communication techniques: an empirical study of comprehension. 26 June
2002 Page(s):13 - 22
© IEEE 10.1109/VISSOF.2002.1019790
[13] Riihimaki, J, Kukkala, P. Kangas, T. Hannikainen, M. Hamalainen, A methodology for

finding source-level vulnerabilities of the u-COSII FPGA variables. System-on-Chip,
International Symposium on Nov. 2005 Page(s):108 - 111
© IEEE 10.1109/ISSOC.2005.1595656
[14] How to Cite References. Online. Academic Services Group, Faculty of Business
Administration, University of Ulster. Available from:
http://www.busmgt.ulst.ac.uk/business/pi/resmeth/plag.doc [6 July 2009].

Appendix
________________________________________________________________________________

Nyjil CHB0408011 SOC524-PT08

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Nyjil CHB0408011 SOC524-PT08

Cargado por

Copyright:

Formatos disponibles

System On a Programmable

POSTGRADUATE ENGINEERING AND MANAGEMENT

Module Leader at MSRSAS: Mr.Sanket Dessai

PART TIME 2008 BATCH

M.S.Ramaiah School of Advanced Studies

Date stamp from Signature of

System On A programmable Chip ii

System On A programmable Chip iii

The development method and implementation procedures of a Multi processor system on

System On A programmable Chip iv

PART C is Describing that design and development of any application and

System On A programmable Chip v

System On A programmable Chip vi

Fig 1.1 ASMP 3

System On A programmable Chip vii

System On A programmable Chip viii

1.0 System On A Chip, An Introduction.

1.0.2 SYMMETRIC AND ASSYMMETRIC MPSOC.

Fig 1.0. Symmetric MPSOC.

Uni-processor and SMP systems require different programming methods to achieve

System On A programmable Chip 2

Fig 1.1 ASMP

1.0.3 COMPARISON, SMPSOC AND ASMPSOC.

1.1 CACHE MECHANISM IN MPSoC.

System On A programmable Chip 3

Fig 1.2 Cache memory basics.

Fig 1.3 Cash Memory Architecture in MPSOC.

System On A programmable Chip 4

1.1.1 MESI protocol

System On A programmable Chip 5

System On A programmable Chip 6

Fig 2.0 Arithmetic and Logic Unit.

System On A programmable Chip 7

Fig 2.1 ALU XOR

Fig 2.2 ALU Parallel Adder.

System On A programmable Chip 8

• subtraction: invert b-bits, carry in is one

Fig 2.3 Adder/Subtracted Design.

Fig 2.4 Logic Operations.

System On A programmable Chip 9

entity ALU_cell is port(

System On A programmable Chip 10

signal S: in std_logic(2 downto 0);

2.5 Explanation of 32 Bit ALU with Test Benches.

System On A programmable Chip 11

Fig 2.5 32 Bit ALU Synthesis.

System On A programmable Chip 12

Fig 2.6 32 Bit ALU Functions.

System On A programmable Chip 13

---- Uncomment the following library declaration if instantiating

architecture Behavioral of aludesign is

System On A programmable Chip 14

Res <= "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX";

2.7 Test Bench Programme to test All Design Possibilities.

System On A programmable Chip 15

-- /___/ /\ Timestamp : Sat Jan 26 21:20:06 2008

System On A programmable Chip 16

System On A programmable Chip 17

Op_Sel <= "110";

Fig 2.7 ALU Functions.

System On A programmable Chip 18

3.0 Porting Micro C OS on Xilinx FPGA.