1serial Protocol Bridge

SERIAL PROTOCOL BRIDGE
A thesis submitted to the Graduate School of the

University of Cincinnati
in partial fulfillment of the requirements for the degree of
Masters of Science
In the Department of Computer Engineering of

College of Engineering & Applied Sciences
By
Neena Sharma
August 14, 2012
B.E -Electronics & Communication Engineering
June 2008
Committee Chair: Dr. Carla Purdy
Abstract
Mobile devices are entering in every sphere of our life. With the introduction of
newer features these devices are becoming more and more data centric. Apart from
data storage another major concern in such scenarios is data movement. Many
protocols exist to aid in data movement within the mobile devices as well as to
communicate with the outside world. Among these protocols serial communication
protocols are most widely used protocols due to their low pin requirement and ease
of implementation. Usually the protocol followed by a device depends on the
amount of data that it needs to transfer as well as the speed with which it is
required to communicate. But there are situations when a single device has
different protocol requirements in two different situations. In such situations a
bridge is required such that device can follow communication protocol according
to the situational requirement rather than being bound to one kind of protocol.
In this research, a serial protocol bridge has been designed that consists of two
most widely used serial protocol controllers. It helps a particular device to
communicate with either of the protocol seamlessly. The bridge has been designed
using UML 10.0. All the design modules of bridge have been coded in VHDL and
simulated using Model Sim Altera 6.5e. Further these modules were compiled for
EP4CE115F29C7 FPGA chip on Cyclone IV Altera DE115 board using Quartus II.
ii
iii
Acknowledgement
I would like to gratefully acknowledge the enthusiastic supervision of Dr. Carla

Purdy during this work. Also I am thankful to all my friends from University of
Cincinnati, for being the surrogate family during these two years and for their
continued moral support.
Finally, I am forever indebted to my parents and Mohit Ahuja, my husband, for

their understanding, endless patience and encouragement when it was most
required.
Neena Sharma
iv
Contents
1. Introduction..1
1.1. Motivation..1
1.2. Research summary.4
2. Background..6
2.1. Introduction6
2.1.1. RS232...7
2.1.2. RS-422 and RS-485.7
2.1.3. I2C...7
2.1.4. SPI...8
2.2. Hardware architecture for mobile devices.9
2.2.1. Evolution of mobile phones..10
2.3. Embedded system design.13
2.4. FPGA based design..14
2.5. Conclusion15
3. Design.16
3.1. Introduction..16
3.2. Basics of I2C protocol..17
3.3. Basics of SPI protocol..19
3.4. Design methodology20
3.4.1. Designing I2C master.21
3.4.2. Designing I2C slave26
3.4.3. Designing SPI master..30
v
3.4.4. Designing SPI slave32

3.5. Bridge formation34
3.6. Conclusion..38
4. Implementation.39
4.1. Introduction.39
4.2. I2C master40
4.3. I2C slave..42
4.4. SPI master44
4.5. SPI slave/.46
4.6. Bridge formation..47
4.7. Hardware implementation54
4.8. Camera example revisited55
4.9. Conclusion56
5. Conclusion..57
References...61
Appendix A..63
A.1 I2C master implementation report ..........63
A.2 I2C slave implementation report .... 65
A.3 SPI master implementation report ..... 67
A.4 SPI slave implementation report ...... ...69
A.5 I2C master-slave interface implementation report....71
A.6 SPI master-slave interface implementation report....73
A.7 Serial protocol bridge implementation report .........75
vi
List of Figures
1.1
Camera with different protocols for different purposes..3
2.1
The canonical Harvard architecture .............10
2.2
Cellular system of second generation... 11
2.3
TI OMAP4 architecture [10] ................12
3.1
Typical I2C transaction..........................19
3.2
Typical SPI transaction..........................20
3.3
Use case diagram for I2C master.......22
3.4
State diagram for I2C master.........23
3.5
Sequence diagram for I2C master write use case..24
3.6
Sequence diagram for I2C master read use case...25
3.7
Use case diagram for I2C slave.26
3.8
State diagram for I2C slave...27
3.9
Sequence diagram for I2C slave write use case28
3.10 Sequence diagram for I2C slave read use case. 29

3.11 Use case diagram for SPI master...30
3.12 State diagram for SPI master.31
3.13 Sequence diagram for SPI master data exchange use case31
3.14 Use case diagram for SPI slave.32
3.15 State diagram for SPI slave...33
vii
3.16 Sequence diagram for SPI slave data exchange use case..33
3.17 SPI master writes to I2C slave through serial protocol bridge34
3.18 I2C master writes to SPI slave through serial protocol bridge35
3.19 SPI master performs read on I2C slave through serial protocol bridge36
3.20 I2C master performs read on SPI slave through serial protocol bridge36
3.21 Complete Bridge37
4.1
I2C master waveform generated through test bench42
4.2
I2C slave generated through test bench.43
4.3
SPI master waveform generated through test bench.45
4.4
SPI slave waveform generated through test bench46
4.5
I2C interface waveform generated using test bench..48
4.6
SPI interface waveform (master is reading back after writing).48
4.7
Complete I2C-SPI serial protocol bridge..50
4.8
I2C master writes to SPI slave through serial protocol bridge.51
4.9
I2C master reads SPI slave through serial protocol bridge...51
4.10 SPI master writes to I2C slave through serial protocol bridge..52
4.11 SPI master reads I2C slave through serial protocol bridge...52
4.12 Camera example revisited.55
viii
List of Tables
2.1
Properties of typical serial protocol buses...8
4.1
I2C master transition table41
4.2
SPI master transition table.45
4.3
Typical characteristics of EP4CE115F29C7 FPGA chip...54
4.4
Hardware implementation details for all design modules.54
ix
ACRONYMS
1.
CPOL clock polarity
2.
CPHA clock phase
3.
DSP digital signal processor
4.
ESW embedded software
5.
EEPROM electrically erasable programmable read only memory
6.
FPGA field programmable gate array
7.
GPS global positioning system
8.
I2C inter integrated circuit
9.
LCD liquid crystal display
10.
MISO master in slave out
11.
MOSI- master out slave in
12.
MODF mode fault
13.
NACK- not acknowledge
14.
RTC -real time clock
15.
SPI serial protocol interface
16.
SCLK serial clock
17.
SS slave select
18.
SDA serial data
19.
SCL serial clock

x
20.
SPCR serial peripheral control register
21.
SPSR serial peripheral status register
22.
SPDR serial peripheral data I/ O register
23.
SPIF SPI transfer complete flag
24.
SSEL slave select
25.
UML unified modeling language
26.
UML-RT unified modeling language-real time
27.
VHDL very high speed hardware descriptive language
28.
WCOL write collision
29.
1G first generation
30.
3G third generation
xi
Chapter 1
Introduction
1.1 Motivation
Mobile devices are entering into every part of our lives. As consumer expectations
from these devices keeps on increasing with time, the data movement required
inside the system in order to incorporate the newly introduced features. This makes
mobile devices more and more data centric. With the increase in data handling
capacity of the mobile devices there increases the need for smarter communication
protocols so that overall system performance can also meet the user expectations.
Serial communication is the most widely used method of data transfer in today's
mobile embedded world due to its speed and the number of pins required for data
transfer. Efficiency of a mobile embedded system depends on the speed with which
it can transfer data to the inside as well as the outside world. Hence any equipment
that can enhance the speed of data movement can be of great importance for the
overall efficiency of the system. Considering the importance of speed of data
movement, a lot of effort is being put into improving the serial communication
protocols used inside mobile devices. There are many serial communication
protocols available, each having different characteristics such as speed, hand
1
shaking methodology, and number of bits transferred in single transfer cycle.
A deeper look into the mobile embedded world reveals that each of these protocols
uses a master-slave configuration. Some of the protocols support multiple masters
on the same communication bus. Some are capable of communicating with
multiple slaves. In a typical mobile embedded system, each peripheral is slave to
one of these protocols and is capable of transferring data on command of its
respective master. Hence along with the main controller there are several other
controllers handling each type of serial protocol being used in the mobile system.
In a typical mobile system each peripheral is connected to the master of one of the
serial communication protocol according to its speed and latency requirements.
Inside the mobile system, some data transfers can be low speed and high latency
while others are needed to be high speed with low latency. Hence we need to
incorporate different protocols and use them as per the need. As long as the
peripherals inside these mobile devices, with different speed demands, are in
separate spheres, there will not be any issue while deciding which protocol is
appropriate for which peripheral. But the problem is when the same peripheral
requires low data rate in one situation and high data rate in another situation. For
example, inside a mobile phone when a user decides to click an image, the user
2
sends a capture command to the camera by pressing a button on the device. This
command is going to be a short command and it needs to be served as fast as
possible. But the situation is totally opposite when the image has been captured
and the user press the save button. In this situation the data that needs to be
transferred is a huge amount but the user doesn't mind if it takes a while to save the
image into the memory especially if the device is transferring the image data in the
background. Hence the mobile device will use two different protocols for two
different types of data exchange with the same peripheral, which is the camera in
the above example. One way to handle this will be making the peripheral slave to
both the protocols. This will require additional space and routing overhead for the
designer because we need to make the camera available to both the protocols and it
should be able to respond to both the above situations accordingly. Figure 1.1
depicts the above scenario.
Figure 1.1 Camera with different protocols for different purpose.

3
A simpler way to handle the above situation is to have a bridge through which the
master of one protocol will be able to send and receive data from the slave of
another protocol. This will require each peripheral in the mobile device to be slave
of only one of the protocol. It will be made accessible to other protocols through
the bridge. This is one feasible solution to the problem and is the main motivation
behind this research.
1.2 Research summary

In this research we will be discussing various protocols that are used inside the
mobile embedded systems. We will also be studying the trends in mobile phone
architecture which will help us understand the changes that occurred in mobile
devices from 1G to 3G. We will also be discussing different serial communication
protocols and their characteristics. After this discussion we will be deciding the
two most commonly used serial communication protocols to be used while
designing and implementing the serial protocol bridge.
In the design phase of the project we will be exploring UML (unified modeling
language) and using its features such as use case diagrams, sequence diagrams and
state machines to describe the protocol bridge fully and design its components.
State machine are the most common way of implementing embedded systems on
4
an FPGA (field programmable gate array). We will also be implementing the serial
protocol bridge design on ALTERA ModelSim STARTER EDITION 6.5e that is
standard for the ALTERA DE115 board. After successful designing and
implementation of the serial protocol bridge state machine, we will be generating
test waveforms and demonstrating its use for sending and receiving data across the
two different protocols. We will also be implementing our designs on FPGA chip
present on ALTERA DE115 board.
Success of this project will demonstrate a way of handling the above described
situations in a better and more efficient manner. This bridge is ultimately going to
reduce the wiring on PCB board and result in the reduction of overall size of the de
vice. As now each device will be slave to only one protocol and other protocols can
reach it through the bridge. It will also serve as a base for implementing serial
protocol bridge for other protocols.
Chapter 2
Background
2.1 Introduction
Embedded systems are becoming common in every sphere of our life. One
common feature of embedded system is communication between different
peripherals. Embedded system designers have a large number of choices when it
comes to moving data both within the embedded world and between the system
and the outside world. Various attempts have been made to distinguish these
protocols based on the way data is being transferred-for example, serial vs parallel,
or based on the speed with which the data is being transferred. There are many
different reasons why serial communication is preferred over parallel
communication. These include the low pin count as well as the need for connecting
systems with a PC during development and/or in the field [1].
Various serial protocols for communication buses are available in the market have
their own advantages and disadvantages. A thorough study of protocols is
necessary before deciding which protocol will suffice for the system. The choice of
serial bus should not only meet the speed requirement but it should also consider
other factors such as the life of the product and the number of devices to be
connected. A detailed analysis of available serial protocols is required. We will
6
describe the commonly used protocols.
2.1.1 RS-232: It is the most common interface found on every computer these
days. It is a FULL DUPLEX if 2 pairs of Transmitter and receiver are deployed at
each end. Varying levels of voltages are transmitted in order to transmit logic 0
and 1. It is capable of speed up to 115.2Kbps.
2.1.2 RS-422 and RS-485: It is a simplex bus capable of communicating at a

speed of 10Mbps and a maximum distance of 4,000 feet. A similar pair can be
deployed for communicating between receiver and transmitter making the system
full duplex. RS 485 on the other hand is a half-duplex bus capable of attaining
speed equivalent to that of RS-422.
2.1.3 I2C: Inter- Integrated bus, patented by Philips is a half-duplex, synchronous

multi-master bus that requires only 2 wires (SDA and SCL) to communicate
among several devices. It is an addressable protocol where slaves can have 7-bit or
10-bit addresses .During communication master generates clock and in case slave
is not ready for the communication slave can do clock stretching where clock is
held low indicating the master to wait. This protocol is also capable of handling
multi master through a process called arbitration which gives access to bus to
winning master. This protocol is used for rather low speeds and low distances
typically within the system.
2.1.4 SPI: Serial Peripheral Interface is a full duplex bus targeted for small
distance communication within the embedded system. It consists of four signals
with maximum achievable data rates up to 1Mbps. Disadvantage of SPI over I2C
is the requirement of dedicated select line for each slave.
Table 2.1 summarizes the various serial protocols discussed above along with their
typical properties.
Name
Sync
Type
Duplex
Max
Max Speed Max
Pin Count
Devices
(KBPS)
Distance Ft
RS-232
No
peer
full
20
30
RS-422
No
multi drop
half
10
10000
4000
RS-485
No
multi point
half
32
10000
4000
I2C
Yes
master/ slave
half
*1
3400
<10
SPI
Yes
master/ slave
full
*1
>1000
<10
3+1
Table 2.1 Properties of typical serial protocol buses

*Depends
on bus capacitance.
2.2 Hardware architecture for mobile devices

Two main factors that have fueled the sales of mobile devices are a) reduction of
the footprints of devices themselves, such as cellular handsets and small computers;
and b) the success in developing low power hardware which allows devices to
operate autonomously for hours and even days. [3] . Along with that there has been
a significant change in the architecture of these devices. These are becoming more
and more data centric which require them to have an increasing computational
performance. The main challenge for designers therefore for is to increase
performance while keeping power consumption to a minimum. It has been said that
DSP (digital signal processing) are to cellular telephones as microprocessors is to
desktop systems, that is, the heart of the whole design [3] . But over a period of
time even DSP design has undergone a large number of changes that have resulted
in todays mobile phone architectures. Traditionally DSP architecture used the
concept of the canonical Harvard architecture. It required two output buses for the
address generated for the processor: a data address and a code address [3]. It was a
non-cache system using buffers to speed up computation. The majority of the
instructions used to be of the type multiply- Accumulate. A typical Harvard
architecture is shown in Figure 2.1.
Figure 2.1 The canonical Harvard architecture
2.2.1 Evolution of mobile phone

The most generic 1G mobile phone architecture included a DSP as its heart and
additional analog circuitry for handling RF section. Apart from DSP and RF
section an additional micro controller is used for handling keypad, and display
system. The 2G phones added other features to the 1G such as MP3 and camera
which use similar block architecture. All mobiles in 2G resulted from a transition
from an analog to digital handling of transmitted data. A 2G mobile phone
architecture has been described in Figure 2.2. After that came an era of internet
over mobile phones also known as 2.5G. This is what most of the mobile phone
vendors were doing until the last decade.
10
Figure 2.2 Cellular system of second generation
The third generation of mobile phones is responsible for moving from voice to data
centric systems. Now a days a single device can be used for telephony, a database,
a general purpose computer, a gaming machine, a music player and/or a digital
camera [3] . This also calls for an intelligent power management tackled by an
increased parallelism in the architecture. Various techniques applied for achieving
this include pipeline control, cache hit prediction, variable instruction length and
data compression for transmission. Current research in mobile devices
architectures for low power devices has concentrated in exposing the data pipeline
to the software, handling efficiently compressed variable length code, reducing
power consumption of caches and memory, and also in exploring extreme data
11
compression for saving transmission power [3]. Moore's law is increasing the
available computational power exponentially [3]. With more and more data centric
applications, mobile phones are evolving to be a more general device incorporating
everything that a modern computer has along with the basic voice transfer
functionality. This calls for an increased parallelism in mobile phone architecture.
Figure 2.3 depicts the TI OMAP44X architecture contained in most smart phones.
Figure2.3 TI OMAP4 architecture [10].
12
2.3 Embedded system design

In this era of embedded intelligence where machines are becoming smarter, a need
arises for powerful design tools for both hardware and software based designs.
When it comes to designing embedded software system, UML (Unified Modeling
Language) seems the obvious choice. UML is gaining popularity from real time
system designers [6]. UML is capturing much attention in the ESW community as
a possible solution for raising the level of abstraction to a level where productivity
can be improved, errors can be easier to identify and correct, better documentation
can be provided, and embedded software designers can collaborate more
effectively [4]. However, real time UML may not suffice for stream processor
designs because of their special needs [6]. Along with UML we need a highly
programmable platform for embedded system development. Hence for complete
system development a unified embedded system development methodology is
required. Many enhancements have been proposed to the existing UML to make it
a more powerful embedded systems design tool. UML-RT [5] is a profile that
extends UML with stereotyped active objects, called capsules, to represent system
components. The UML-RT profile defines a model with precise execution
semantics; hence it is suitable for capturing system behavior and supporting
simulation or synthesis tools [4]. But UML-RT is too restrictive a model because
capsules' behavior is defined by state charts. So it has been proposed that we
13
associate capsules also with other models of computation such as synchronous

data-flow, co-design finite state machines [4]. A new UML platform has been
proposed in [4] where suggestions have been made for introducing new building
blocks to represent specific platform concepts, choosing proper UML diagrams and
considering QoS and other non-critical design factors.
2.4 FPGA based design

While dealing with the hardware-software paradigm, it is important to decide what
part of the system should be implemented as hardware and what part should be
implemented as software. The greatest advantage of implementing a software
based system is the flexibility it provides in case of re usability. In case one wants
to exploit advantages of both hardware as well as software, FPGA is an excellent
choice, as it can be programmed multiple times along with providing the
robustness of hardware system. An FPGA by definition is a field programmable
gate array where an array of gates can be configured as per the requirements. It is
generally configured using hardware description languages such as VHDL (very
high speed hardware descriptive language) and Verilog [11, 13]. A recent trend has
been to take the coarse-grained architectural approach a step further by combining
the logic blocks and interconnects of traditional FPGAs with embedded
microprocessors and related peripherals to form a complete "system on a
14
programmable chip".6]. The flexibility provided by FPGA makes it an excellent

choice for prototyping as well as developing full-fledged projects.
2.5 Conclusion
So far, we have discussed how each new generation of embedded mobile devices is
becoming smarter and more capable and how important it is to have powerful
design tools for designing such smart devices. In all these devices buses play a
vital role for transferring data within the system as well as enabling the device to
communicate with the outside world.. These have been discussed in detail to give a
better understanding of each protocol. Since there are many buses available for use,
choosing the right bus becomes a matter of high importance. With this arise other
issues such as what should be the deciding factor to choose the bus for your
embedded system. Even inside a specific set of buses there are questions about
how to deal with the overhead of switching between different buses and how this
overhead can be minimized to increase the overall efficiency of the system. In my
research an attempt has been made to address the above issues and a system has
been devised to reduce the switching overhead among various buses and thus
improve the overall efficiency of the system. I will be focusing mainly on serial
protocols used inside mobile phone embedded systems and will be exploiting UML
for designing a serial protocol bridge and implementing the same on FPGA.
15
Chapter 3
Design
3.1 Introduction
As discussed in the last chapter, serial communication plays an important role in
embedded systems. In this research a serial protocol bridge intended for mobile
phone applications is implemented. I2C and SPI serial protocols are invariably
deployed in all mobile applications. Thus an I2C SPI protocol bridge will provide
a way to communicate between various slave devices. This project will be based on
one of the available UML platform descriptions and will not be focusing on
making changes to the UML as such. Rather the focus will be on exploring serial
protocols used inside todays mobile devices.
A typical mobile phone mother board consists of a high speed processor at its heart
and various other peripherals such as keypad, LCD, camera, GPS, TV out, speakers,
microphone, etc. The processor uses some protocol to communicate with each of
these peripherals depending on the speed requirement. It contains a controller for
each of the protocols and each device is considered as a slave to one of the
controllers. For example, an I2C master is required for communication with an I2C
slave and an SPI master is required for communicating with an SPI slave. We will
be implementing a serial protocol bridge such that inter protocol communication is
16
made possible, saving the overhead of switching between different masters or

slaves and exchanging data seamlessly between different protocols. For example if
an SPI master wants to read output of an RTC (real time clock) chip which is an
I2C slave, we can use the I2C-SPI protocol bridge where bridge can store RTC
data to EEPROM using I2C master and SPI master can read data from EEPROM
which is an SPI slave.
There are various design methodologies for implementing such a protocol bridge.
First of all the detail of the various components of the bridge is to be decided.
Further each component will be implemented independently as a state machine
based on flow charts and state diagrams. Thus we will implement a module based
design. In rest of this chapter I will be putting some light on design methodology
used for implementing the serial protocol bridge.
3.2 Basics of I2C protocol

The I2C protocol is considered to be the most basic serial protocol intended for use
inside an embedded system. It is a 2 wire protocol- SCL (serial clock line) and
SDA (serial data line). As it has a single data line, data can either be sent or
received. Hence it is capable of performing a half-duplex communication. It is a
multi-master protocol where a process known as arbitration is used to decide the
17
winning master among various masters. Then the winning master generates the
clock and sends a start bit followed by the 7 or 10-bit address of the slave. All
communications in I2C are carried as an 8-bit transfer. The 10 bit address is broken
down into 7 bits and 3 bits and sent as 2 byte transfer. The 7-bit address is
appended with 1 additional R/W bit indicating whether a read or a write operation
is to be performed. In case a slave is not ready for data transfer it can keep the
clock line low as long as it is not ready for the transfer. This phenomenon is known
as clock stretching. After each successful byte transfer, an acknowledgment is sent
by the receiver. In case the master wants to stop a read operation it sends not
acknowledge signal (NACK). A more detailed description on I2C can be found at
[8]. Figure 3.1 shows a waveform for a typical I2C transaction. An I2C transaction
begins with a 'start' condition, followed by the address of the device we wish to
speak to, a bit to indicate if we want to read or write, the data written or read, and
finally a 'stop'. An I2C master is capable of communicating at 4 different speeds100kbits/s (standard mode), 400kbits/s (fast mode), 1Mbits/s (fast plus mode) and
3.4Mbits/s (high speed mode). Typical voltages used are 3.3 V and 5 V.
18
Figure 3.1 Typical I2C transactions
3.3 Basics of SPI protocol

The SPI protocol is a full duplex communication protocol where each data transfer
is an exchange of 1 byte of data. It consists of 4 signals- MISO (master in slave
out), MOSI (master out slave in), SCK (serial clock) and SS (slave select). It is
generally used for exchanging bulk data between a single master-slave pair. An SPI
master comprises 3 basic registers -SPCR (serial peripheral control register), SPSR
(serial peripheral status register) and SPDR (serial peripheral data I/O register). A
master is capable of setting the phase and polarity of clock signal by changing
values of CPHA (clock phase) and CPOL (clock polarity) bits in the SPCR register.
Further it selects the slave by pulling the slave select line high. A byte of data is
exchanged by sending a byte on the MOSI line and simultaneously receiving a
byte on the MISO line. SPIF (SPI transfer complete flag) in SPSR is set after
successful completion of data transfer. WCOL (write collision) and MODF (mode
fault) flags in SPSR are used to indicate faults during unsuccessful transfer. A more
detailed explanation on these flags can be found at [14]. Figure 3.2 shows the
19
waveform for a typical SPI transaction. The line MOSI is 'master output' and
MISO is the 'slave output'. The master pulls SSEL down to indicate beginning of
communication to the slave. Since SPI is full duplex, both lines toggles
simultaneously, with different data going from master to slave and slave to master.
Master pulls SSEL up to indicate transfer is over. Master can keep SSEL low until
communication is not over and pulls SSEL high only to indicate that transfer is
over. Typical SPI frequency is 100MHz.
Figure 3.2 Typical SPI transactions.
3.4 Design methodology

An existing UML profile (UML 10.0) [15] has been used for designing the bridge.
There are different ways to implement the bridge based on the requirements.
(i) When I2C master is required to communicate with the SPI slave bridge will
consist of I2C slave - SPI master.
(ii) When SPI master is required to communicate with the I2C slave bridge will
consists of SPI slave- I2C master.
(iii) In the third case there is a combination of both in order to make
20
communication between 2 protocols seamless.

Based on the above requirement, the protocol bridge can be divided into 4 modules:
I2C master, I2C slave, SPI master and SPI slave. All these modules have been
implemented as state machines and a detailed design for each of these modules has
been described in the following sections.
3.4.1 Designing I2C master

For designing an I2C master UML profile 10.0 has been used. First a basic use case
diagram has been designed as shown in Figure 3.3. Further a state diagram has
been generated representing various states an I2C master can attain along with the
stimulation for changing one state to another. A fully descriptive state diagram has
been shown in Figure 3.4. A sequence diagram for read and write use cases is
shown which puts a light on the sequence of events that take place during the entire
communication between I2C master and slave. Figure 3.5 shows a detailed
sequence diagram for an I2C master write use case and Figure 3.6 shows a detailed
sequence diagram for read operation.
21
Figure 3.3 Use case diagram for I2C master.
22
Figure 3.4 State diagram for I2C master.
23
Figure 3.5 Sequence diagram for I2C master write use case.
24
Figure 3.6 Sequence diagram for I2C master read use case
25
3.4.2 Designing I2C slave

The I2C slave has been designed on the same lines as the I2C master. First a use
case diagram has been drawn in Figure 3.7, to depict the basic functionality of the
I2C slave. Figure 3.8 is an elaborated state diagram for the I2C slave. And at last a
sequence diagrams for read and write use cases are shown in Figure 3.9 and Figure
3.10 which elaborates the sequence of events occurring during a typical I2C
communication.
Figure 3.7 Use case diagram for I2C slave.
26
Figure 3.8 State diagram for I2C slave.
27
Figure 3.9 Sequence diagram for I2C slave write use case.
28
Figure 3.10 Sequence diagram for I2C slave read use case.
29
3.4.3 Designing SPI master

Figure 3.11 shows the basic use case diagram for the SPI master. In the case of the
SPI master as mentioned before 3 registers -SPCR, SPSR and SPDR- play a vital
role. Hence the state diagram in Figure 3.12 and the sequence diagram in Figure
3.13 show checking of the various bits in these registers at different stages of
communication.
Figure 3.11 Use case diagram for SPI master.
30
Figure 3.12 State diagram for SPI master
Figure 3.13 Sequence diagram for SPI master data exchange use case.
31
3.4.4 Designing SPI slave

An SPI slave has a lot less work load compared to an SPI master, as the slave need
not worry about setting of the clock phase as well as clock polarity. Hence
designing an SPI slave is lot simpler. Figure 3.14 shows the use case diagram for
an SPI slave. As SPI communication is full duplex data is sent and received
simultaneously. Thus the state diagram for the SPI slave is quiet similar to the SPI
master, excluding the clock generation part. Figure 3.15 shows an elaborated state
diagram for an SPI slave and Figure 3.16 which depicts the sequence of events that
take place on the slave side of SPI communication.
Figure 3.14 Use case diagram for SPI slave.
32
Figure 3.15 State diagram for SPI slave.
Figure 3.16 Sequence diagram for SPI slave.
33
3.5 Bridge formation

In order to form a serial protocol bridge we need to combine the above modules
so that the master of one serial protocol is able to communicate with the slave of
another serial protocol. The most obvious way of combining modules of different
protocols is through shared memory. When one protocol writes into its slave
device, the master from the other protocol can write the data stored in the shared
memory to its own slave. In this manner the goal achieved will be a master of one
protocol writing into the slave of the other protocol. Figure 3.17 and Figure 3.18
depicts this operation.
Figure 3.17 SPI master writes to I2C slave through serial protocol bridge.
34
Figure 3.18 I2C master writes to SPI slave through serial protocol bridge.
Similarly a read can be done in the reverse order. That is, the master inside the
bridge can do a read operation on its corresponding slave which is outside the
bridge and store the read data into the shared memory. And then the master
(outside the bridge) of the other protocol can perform a read operation on the slave
device which is part of the bridge. The goal achieved is a read operation performed
on the slave of one protocol by the master of another protocol. Figure 3.19 and
Figure 3.20 depicts the operation described above.
35
Figure 3.19 SPI master performs read on I2C slave through serial protocol bridge.
Figure 3.20 I2C master performs read on SPI slave through serial protocol bridge.
36
Another approach to the implementation is a combination of above the described

bridges where the bridge contains all four components- SPI master, SPI slave and
I2C master and I2C slave, thus enabling the communication between the two types
of protocols seamlessly. Figure 3.21 depicts the block diagram of the universal
bridge described above.
Figure 3.21 Complete bridge
37
3.6 Conclusion
So far we have discussed various ways in which the serial protocol bridge can be
implemented. We have also seen how we can break the whole design into 4 main
modules and we have used UML 10.0 to design each of the modules
independently. Use case diagrams, state diagrams and sequence diagrams have
been used to design the fully working modules and further block diagrams have
been used to combine these modules into the serial protocol bridge. Now we can
move further into implementation of each of the designed modules. Next chapter
will comprise the implementation details along with simulation of the four
modules that we have designed in this chapter.
38
Chapter 4
Implementation
4.1 Introduction
In the previous chapter we have designed the four basic modules for an I2C-SPI
serial protocol bridge using UML 10.0. We have also seen how each of these
modules can be represented using a state machine diagram. In this chapter we will
be focusing on how each of these state machines can be implemented using HDL
(hardware description language). In industry standards two main hardware
languages are used in order to simulate and test the designs before actually
experimenting with the hardware. These are VHDL (very high speed integrated
circuit hardware descriptive language) and Verilog [11, 13]. Both these languages
have their specific uses. Verilog is used where gate level implementation is
required whereas VHDL is more useful while implementing system level modules.
As in our design we are more focused on a system level implementation of the

serial protocol bridge, we will be simulating our designs using VHDL. Each of the
four state machines will be implemented independently with a test bench providing
incoming signals that ideally should be sent by other modules. After simulating
each of these state machines, we will be integrating these modules together in
order to create the higher level systems as described in the chapter 3.
39
While implementing a state machine we will define certain commands that will
decide transition from one state to the next. Here each command will be driving
signals and data through multiple states. All the commands will have one common
state that helps in easy transitioning between successive commands. In the rest of
the chapter we will describe the four basic modules of the serial protocol bridge
along with their combinations which we have implemented in order to form the
complete bridge. Each of our designs has been implemented in VHDL and
instantiated on ALTERA DE-115 board with a CYCLONE IV E chip. In this
chapter we will be describing simulation waveforms. All the simulations have been
done in ModelSim ALTERA STARTER EDITION 6.5e.
4.2 I2C master

I2C master state machine has five main commands- NOP, READ, WRITE, START
and STOP. Reset has not been included as a state; rather it is included as a signal to
the state machine. Each of these commands has been further divided into multiple
states depending upon the number of bits that are needed to be transmitted or
received during its execution. Each bit is transmitted on a fresh clock cycle. So in
order to transmit a 7 bit address, 7 clock bits are required. Idle state is the shared
state among all commands and solves the problem of transitioning between various
40
commands. Master also has an 8-bit memory in order to save the received bit.
Figure 4.1 shows typical I2C master state machine waveforms. It depicts the
transitions on SDA line during each command. Table 4.1 describes various state
transitions involved in each of the valid I2C master commands.
Command Name
Command Code
State Transitions
SDA Transitions
START
010
idle start_a start_b idle
1011
STOP
010
idle stop_a idle
101
READ
100
idle rd_a rd_b rd_c
1 8-bit data read
rd_d rd_e rd_f rd_g
from slave NACK
rd_h rd_i idle
sent by master 1
idle wr_a wr_b wr_c
1 8-bit data or 7-bit
wr_d wr_e wr_f
address + read/write bit
wr_g wr_h wr_i idle
ACK sent by slave
WRITE
101
1
NOP
000
idle
Table 4.1 I2C master transition table
41
Figure 4.1 I2C master waveform generated through test bench
4.3 I2C slave

I2C slave state machine has been implemented on the same lines as I2C master.
The most basic difference between I2C slave and I2C master is that the slave is not
capable of initiating any data transfer. So it is not having any READ or WRITE
command. Rather it will be detecting SDA (serial data) line for start bit and once it
detects a start bit it changes its state to match the address being sent. After
matching the address received with its own address, it sends acknowledge bit and
42
jumps to either read or write state depending on the value of read/write bit sent by
I2C master. Hence I2C slave cannot be commanded to read or write directly by the
host. Figure 4.2 shows typical I2C slave waveform.
Figure 4.2 I2C slave generated through test bench
43
4.4 SPI master

SPI master state machine contains 3 main commands -CONFIG, EXCHANGE and
NOP. In case of SPI, data is sent and received simultaneously, hence there is no
explicit read or write command. Exchange command serves the purpose of both
read and write. SPI master selects SPI slave by pulling the SS (slave select) line
connected to the desired port low. Apart from that SPI CONFIG command is very
important as it sets the register values needed during data exchange. It mainly sets
value for CPOL (clock polarity) and CPHA (clock phase). CPOL if set to '0'
indicates that no data will be exchanged when SCLK (serial clock) is at level '0'
and if set to '1' data will not be exchanged at level '1' of SCLK. Similarly CPHA is
set or reset during CONFIG command. Setting of CPHA bit to '1' indicates that
data will be exchanged on the falling edge whereas when CPHA is set to '0' data is
exchanged on the rising edge. After successful setting of these bits, SPI master
pulls SS (slave select) line low and data is exchanged. While implementing SPI
master, each of these main states has been broken down to multiple states in order
to add the delay required to get into right configuration before actual data exchange
can occur. Figure 4.3 shows a typical waveform of SPI master communicating with
SPI slave. Table 4.2 describes state transitions for typical SPI commands.
44
Command Name
Command Code
State Transitions
Signals Involved
CONFIG
010
idle config_a
SCLK
config_b config_c
idle
EXCHANGE
idle exchange_a
100
SCLK,MISO,MOSI,SS
exchange_b idle
NOP
000
idle
Table 4.2 SPI master transition table
Figure 4.3 SPI master waveform generated through test bench
45
none
4.5 SPI slave

SPI slave also needs to set its registers in order to send or receive data from SPI
master. Hence SPI slave state machine has a CONFIG command. But it is not
supporting any exchange command, as it depends on SPI master for data exchange.
It can only send or receive when master indicates this by pulling its SS (slave
select) line low. Hence it continuously monitors its SS line for data exchange.
Figure 4.4 shows a typical SPI slave waveform.
Figure 4.4 SPI slave waveform generated through test bench
46
4.6 Bridge formation

Till now we have done simulation of individual modules for the serial protocol
bridge. Now we will be generating new state machines using the above modules as
components in order to form a fully functional bridge. As described in the chapter
3, in Figure 3.19 and Figure 3.20, we can form a serial protocol bridge using 2 of
the above modules or we can combine all four modules as described in Figure 3.21.
We will be creating two independent interfaces before forming the complete serial
protocol bridge. One of the interfaces will combine I2C Master and I2C Slave
forming an I2C interface. Another interface will combine SPI master and SPI slave
forming an SPI interface. These interfaces are formed in order to reduce the
number of components required for the complete bridge. Figure 4.5 and Figure 4.6
depicts a typical waveform for I2C interface and SPI interface respectively.
47
Figure 4.5 I2C interface waveform generated using test bench
Figure 4.6 SPI interface waveform (master is reading back after writing)
48
Now, as we have two interfaces ready, we will be combining these two interfaces
together in order to form the complete bridge. Hence the bridge now is going to
have these two interfaces as its components rather than 4 modules as its component.
The state machine for the complete or full serial protocol bridge is then going to
have four different modes- I2C_WRITE_SPI, I2C_READ_SPI, SPI_WRITE_I2C
and SPI_READ_I2C. These four modes are basically four different ways bridge
can be used. Along with two interfaces complete bridge will also be having shared
memory. There are two 8-bit registers in order to share data. One register is used
for sharing data between I2C slave and SPI master and the other one is used in
order to share data between I2C master and SPI slave. This has been done so that
the serial protocol bridge can be used in any of the four possible modes. Figure 4.7
depicts block diagram of serial protocol bridge having two interfaces and two
shared memories. Figure 4.8 depicts waveform of serial protocol bridge in
I2C_WRITE_SPI mode. Figure 4.9 depicts waveform of serial protocol bridge in
I2C_READ_SPI mode. Figure 4.10 depicts waveform of serial protocol bridge in
SPI_WRITE_I2C mode and Figure 4.11 depicts waveform of serial protocol bridge
in SPI_READ_I2C mode.
49
Figure 4.7 Complete I2C-SPI serial protocol bridge
50
Figure 4.8 I2C master writes to SPI slave through serial protocol bridge
Figure 4.9 I2C master reads SPI slave through serial protocol bridge
51
Figure 4.10 SPI master writes to I2C slave through serial protocol bridge
Figure 4.11 SPI master reads I2C slave through serial protocol bridge
52
4.7 Hardware implementation

All the simulations have been done using ModelSim ALTERA 6.5e. The code has
been targeted for FPGA cyclone IV E chip family on ALTERA DE115 board.
Hardware compilation has been done for device EP4CE115F29C7N using
QUARTUS II. Table 4.3 describes typical values for the on board FPGA chip. The
FPGA device has total of 114,480 LUTs (logic units), 529 pins, 3,981,312 memory
bits and 4 PLLs. It can work at 250 MHz (max) frequency. We have successfully
implemented all the design modules of serial protocol bridge on the FPGA chip on
ALTERA DE115 board. The successful simulation and compilation has proved the
functioning of the bridge. The hardware implementation reports for have been
included in Appendix A. As the design modules are not communicating with actual
slave devices we have simulated all designs at 170X2 MHz for the sake of
uniformity. An interesting fact observed while implementing the bridge on FPGA
is that although we have used basic design modules as components in order to form
interfaces and further we used interfaces as components to form the bridge but the
total logic units of the comprising modules is less as compared to sum of
individual components. Table 4.4 depicts the hardware implementation details of
all the design modules.
53
Core Voltage
1.2V
Logic Elements
114480
I/O pins
529
Memory Bits
3981312
Embedded multiplier 9-bit elements
532
PLL
Global clocks
20
temperature
0-85(Celsius)
Table 4.3 Typical characteristics of EP4CE115F29C7 FPGA chip
Table 4.4 Hardware implementation details for all design modules

54
4.8 Camera example revisited

The problem explained through Figure 1.1can be solved using the above designed
serial protocol bridge. Now camera can be slave to only one protocols master and
can be accessed by other protocols through bridge. This will make the designing of
mobile devices simpler. It is also going to reduce the wiring on the PCB (printed
circuit board). Hence using the serial protocol bridge will reduce the overall size of
the device along with making it simpler and easier to implement. Figure 4.12
depicts the change in camera example with the use of serial protocol bridge.
Figure 4.12 Camera example revisited
55
4.9 Conclusion
In this chapter we have successfully done the simulation of all the modules
designed in the previous chapter. Two interfaces were designed, simulated and
implemented successfully. We have also successfully demonstrated the fully
functional serial protocol bridge in all possible modes. Hence the inter protocol
communication was made possible using the bridge and the same has been
depicted in the waveforms generated through test benches.
56
Chapter 5
Conclusion
In this research we have designed and implemented an I2C-SPI serial protocol

bridge. Both these protocols are used for serial communication in embedded
mobile devices and almost all the peripherals inside these devices use one of the
serial protocols. Serial protocols work in master-slave configuration. Hence each
peripheral is slave to one of the protocols and is accessible through its respective
master. But there are many scenarios when the master of one protocol type wants
to communicate with the slave of another protocol. The bridge that we have
designed and implemented in this research is capable of making communication
between the devices of different protocols seamless as the master of one can access
the slave of another via the serial protocol bridge. We have seen different ways of
implementing the bridge depending on the requirements. As an outcome of this
research we have come to the conclusion that complex systems can be designed
and implemented by breaking them down into smaller modules. While designing
the serial protocol bridge we have used a bottom up approach.
Firstly we have discussed the available protocols needed for transmitting data from
one peripheral to another. The background chapter also sheds light on the
57
importance of serial communication in the embedded world. A table summarizing

the typical characteristics of some of the most used protocols has been included.
Apart from that, trends in mobile phone architectures were discussed and at the end
the conclusion has been drawn that I2C and SPI are most widely used serial
communication protocols in mobile phone embedded systems. Hence these two
protocols were chosen for implementation in the serial protocol bridge.
During the design phase we have used an existing UML platform for designing the
modules in our design. We described the four basic modules of serial protocol
bridge- I2C slave, I2C master, SPI slave and SPI master using use case diagrams,
sequence diagrams and state diagrams. The elaborated sequence diagrams and state
diagrams helped us in clarifying the basic concepts of I2C and SPI protocol
communication. In the end of the chapter final bridge formation was discussed and
block diagrams were included to demonstrate how the basic modules could be
combined to allow communication between I2C and SPI devices.
In the implementation chapter we have successfully implemented the four basic

modules of the serial protocol bridge. After generating the waveforms for the basic
modules two interfaces were designed and tested successfully. Waveforms were
generated in order to describe the functioning of these two interfaces. At last a final
58
state machine was implemented that included the two previously generated
interfaces as its components along with two shared 8-bit registers. This final state
machine could work in four modes. Below is a list of the four modes in which the
state machine could be used
a) I2C master writing to SPI slave
b) I2C master reading from SPI slave
c) SPI master writing to I2C slave
d) SPI master reading from I2C slave
Hence we successfully demonstrated the fully functional I2C-SPI serial protocol

bridge and waveforms were generated through test benches for each mode.
Implementation has been done using ModelSim ALTERA STARTER EDITION
6.5e and was targeted for ALTERA DE115 board. The complete bridge Along with
all design modules has been successfully implemented on board.
By using this bridge we are able to solve the issue discussed in chapter 1 where
each device was required to be slave to all the protocols it was communicating
with. With this bridge each peripheral needs to be slave to only one protocol. This
will reduce the wiring and as a result reduce the overall size of the device.
59
Future prospects
This research has been concluded with a fully functional I2C-SPI serial protocol
bridge. It has been simulated for ALTERA board and can be used in real time
scenarios by adding protocol compatible slave devices to the board. All the
simulations have been done in VHDL and can be done for other languages as well.
This bridge can be tested for actual size reduction of mobile devices. This can
improve the on-board communication among different peripherals and thus can
improve overall efficiency of the system. A good exercise will be
1.
To add ALTERA specific protocol to the bridge and communicate with the
peripherals on the ALTERA DE115 board like LCD, LEDs.

2.
Add USB protocol to the bridge and communicate with the mouse and other
USB devices.
3.
Add RS-232 protocol to the existing bridge and make it communicate with
the PC.
4.
We can also add parallel protocols to the existing serial protocol bridge and
make it a universal protocol bridge.

5.
We can add I2C or SPI specific slave devices and use bridge to communicate
with them. Most widely used I2C device for test purposes is RTC chip. Dont
forget to change clock speeds of the prototype before using it with actual I2C or
SPI slave.
60
References
[1]http://www.eetimes.com/design/embedded/4023975/Serial-Protocols-Compared,
May 31 2002
[2] A. K. Oudjida, M. L. Berrandjia, R. Tiar, A. Liacha, K. Tahraoui, FPGA
Implementation of I2C & SPI protocols: a comparative study, 16th IEEE
International Conference on Electronics, Circuits, and Systems, December 2009,
pp. 507-510.
[3] Margarita Esponda, Trends in Hardware Architecture for Mobile Devices,
Technical Report B-04-17, Freie Universitt Berlin, Fachbereich Mathematik und
Informatik, November 2004
[4] R. Chen, M. Sgroi, G. Martin, L. Lavagno, A. Sangiovanni-Vincentelli, and J.

Rabaey, Embedded system design using uml and platforms, In Forum Design
Languages FDL 02. Marseille, France, September 2002.
[5] B. Selic, J. Rumbaugh, Using UML for modeling complex real-time systems,
Rational Software Corporation, March 1998.
[6] http://en.wikipedia.org/wiki/Field-programmable_gate_array
[7] Jan Jrjens, Secure Systems Development with UML, Springer Publications,
2005, ISBN 978-3-540-00701-2
[8] http://www.fpga4fun.com/I2C.html, 2008
61
[9] P.Venkateswaran, Madhumita Mukherjee, Arindam Sanyal, Snehasish Das and

R.Nandi, Design and Implementation of FPGA Based Interface Model for ScaleFree Network using I2C Bus Protocol on Quartus II 6.0, International Conference
on Devices for Communication 2009
[10] http://www.ti.com/lit/ml/swpt034b/swpt034b.pdf
[11] Douglas J Smith, HDL Chip Design: A Practical Guide for Designing,
Synthesizing and Simulating ASICs and FPGAs using VHDL or Verilog, Doone
Publications, 1996 ISBN 0-9651934-3-8
[12] http://www.angelfire.com/in/rajesh52/verilogvhdl.html
[13] G. Martin, L. Lavagno, J. Louis-Guerin, Embedded UML: a merger of realtime UML and co-design, Proceedings of CODES 2001, Copenhagen, Apr. 01, pp.
23-28
[14] http://www.fpga4fun.com/SPI.html, May 13 2009.
[15] http://en.wikipedia.org/wiki/Visual_Paradigm_for_UML, July 19 2012.
[16] J. da Silva Jr., M. Sgroi, F. De Bernardinis, S.F Li, A. Sangiovanni-Vincentelli

and J. Rabaey, Wireless protocols design:
challenges and opportunities,
Proceedings of the 8th IEEE International Workshop on Hardware/Software

Codesign, CODES '00, S.Diego, CA, USA, May 2000
62
Appendix A
A.1 I2C master implementation report

-----------------------------------------------------------------------------Analysis & Synthesis Summary
-----------------------------------------------------------------------------Analysis & Synthesis Status
Successful - Fri Aug 03 10:34:01 2012
Quartus II Version
10.0 Build 218 06/27/2010 SJ Web Edition
Revision Name
I2C_master
Top-level Entity Name
I2C_master
Family
Cyclone IV E
Total logic elements
77
Total combinational functions
77
Dedicated logic registers
34
Total registers
34
Total pins
38
Total virtual pins
0
Total memory bits
0
Embedded Multiplier 9-bit elements 0
Total PLLs
0
----------------------------------------------------------------------------Fitter Summary
----------------------------------------------------------------------------Fitter Status
Quartus II Version
Revision Name
I2C_master
I2C_master
Family
Cyclone IV E
Device
EP4CE115F29C7
Timing Models
Final
77 / 114,480 ( < 1 % )
77 / 114,480 ( < 1 % )
34 / 114,480 ( < 1 % )
Total registers
34
Total pins
38 / 529 ( 7 % )
Total virtual pins
0
Total memory bits
0 / 3,981,312 ( 0 % )
Embedded Multiplier 9-bit elements 0 / 532 ( 0 % )
Total PLLs
0/4(0%)
63
----------------------------------------------------------Slow 1200mV 85C Model Fmax Summary

----------------------------------------------------------Fmax
Restricted Fmax Clock Name Note
303.67 MHz
250.0 MHz
clk
limit due to minimum period restriction
-----------------------------------------------------------Slow 1200mV 85C Model Hold Summary
-----------------------------------------------------------Clock Slack End Point TNS
clk 0.382 0.000
-----------------------------------------------------------------------Slow 1200mV 85C Model Minimum Pulse Width Summary
-----------------------------------------------------------------------Clock Slack End Point TNS
clk
-3.000 -46.690
-----------------------------------------------------------------------Slow 1200mV 85C Model Setup Summary
-----------------------------------------------------------------------Clock Slack End Point TNS
clk
-2.293 -28.754
-----------------------------------------------------------------------Operating Settings and Conditions
-----------------------------------------------------------------------Nominal Core Voltage
1.20 V
Low Junction Temperature 0 C
High Junction Temperature 85 C
-------------------------------------------------------------------------Clocks
-------------------------------------------------------------------------Clock Name Type Period Frequency
Rise
Fall
clk
Base 1.000 1000.0 MHz 0.000 0.500
64
A.2 I2C slave implementation report

-----------------------------------------------------------------------------Analysis & Synthesis Summary
Quartus II Version
Revision Name
I2C_slave
i2c_slave
Family
Cyclone IV E
73
65
43
Total registers
43
Total pins
24
Total virtual pins
0
Total memory bits
0
Total PLLs
0
----------------------------------------------------------------------------------Fitter Summary
----------------------------------------------------------------------------------Fitter Status
Quartus II Version
Revision Name
I2C_slave
i2c_slave
Family
Cyclone IV E
Device
EP4CE115F29C7
Timing Models
Final
73 / 114,480 ( < 1 % )
65 / 114,480 ( < 1 % )
43 / 114,480 ( < 1 % )
Total registers
43
Total pins
24 / 529 ( 5 % )
Total virtual pins
0
Total memory bits
0 / 3,981,312 ( 0 % )
Total PLLs
0/4(0%)
----------------------------------------------------------------------------Operating Settings and Conditions
----------------------------------------------------------------------------Nominal Core Voltage
1.20 V
65
----------------------------------------------------------------------Clocks
----------------------------------------------------------------------Clock Name Type Period Frequency Rise Fall
SCL
Base 1.000 1000.0 MHz 0.000 0.500
-------------------------------------------------------------------------------------------------------------Slow 1200mV 85C Model Fmax Summary
-------------------------------------------------------------------------------------------------------------Fmax
297.53 MHz 237.53 MHz
SCL
limit due to minimum period restriction
--------------------------------------------------------------Slow 1200mV 85C Model Setup Summary
---------------------------------------------------------------Clock Slack End Point TNS
SCL -2.361 -32.188
----------------------------------------------------------------Slow 1200mV 85C Model Hold Summary
----------------------------------------------------------------Clock Slack End Point TNS
SCL 0.384 0.000
---------------------------------------------------------------------------------Slow 1200mV 85C Model Minimum Pulse Width Summary
---------------------------------------------------------------------------------Clock Slack End Point TNS
SCL -3.210 -58.465
66
A.3 SPI master implementation report

------------------------------------------------------------------------------Analysis & Synthesis Summary
Quartus II Version
Revision Name
SPI_master
spi_master
Family
Cyclone IV E
114
114
49
Total registers
49
Total pins
63
Total virtual pins
0
Total memory bits
0
Embedded Multiplier 9-bit elements
0
Total PLLs
0
------------------------------------------------------------------------------Fitter Summary
-----------------------------------------------------------------------------Fitter Status
Quartus II Version
Revision Name
SPI_master
spi_master
Family
Cyclone IV E
Device
EP4CE115F29C7
Timing Models
Final
114 / 114,480 ( < 1 % )
Total combinational functions 114 / 114,480 ( < 1 % )
49 / 114,480 ( < 1 % )
Total registers
49
Total pins
63 / 529 ( 12 % )
Total virtual pins
0
Total memory bits
0 / 3,981,312 ( 0 % )
Total PLLs
0/4(0%)
---------------------------------------------------Operating Settings and Conditions
---------------------------------------------------Nominal Core Voltage
1.20 V
67
--------------------------------------------------------------------Clocks
--------------------------------------------------------------------Clock Name Type Period Frequency Rise Fall
clk
Base 1.000 1000.0 MHz 0.000 0.500
-----------------------------------------------------------Slow 1200mV 85C Model Fmax Summary
------------------------------------------------------------Fmax
Restricted Fmax Clock Name
211.15 MHz 211.15 MHz
clk
--------------------------------------------------------Slow 1200mV 85C Model Setup Summary
---------------------------------------------------------Clock Slack End Point TNS
clk -3.736 -115.546
---------------------------------------------------------Slow 1200mV 85C Model Hold Summary
----------------------------------------------------------Clock Slack End Point TNS
clk 0.384 0.000
-----------------------------------------------------------------------------Slow 1200mV 85C Model Minimum Pulse Width Summary
-----------------------------------------------------------------------------Clock Slack End Point TNS
clk -3.000 -65.965
68
A.4 SPI slave implementation report

Quartus II Version
Revision Name
SPI_slave
spi_slave
Family
Cyclone IV E
237
205
77
Total registers
77
Total pins
59
Total virtual pins
0
Total memory bits
0
0
Total PLLs
0
------------------------------------------------------------------------------Fitter Summary
-----------------------------------------------------------------------------Fitter Status
Quartus II Version
Revision Name
SPI_slave
spi_slave
Family
Cyclone IV E
Device
EP4CE115F29C7
Timing Models
Final
228 / 114,480 ( < 1 % )
205 / 114,480 ( < 1 % )
77 / 114,480 ( < 1 % )
Total registers
77
Total pins
59 / 529 ( 11 % )
Total virtual pins
0
Total memory bits
0 / 3,981,312 ( 0 % )
Total PLLs
0 / 4 ( 0% )
---------------------------------------------------Operating Settings and Conditions
---------------------------------------------------Nominal Core Voltage
1.20 V
69
-----------------------------------------------------------------Clocks
------------------------------------------------------------------Clock Name Type Period Frequency Rise Fall
SCLK
Base 1.000 1000.0 MHz 0.000 0.500
---------------------------------------------------------Slow 1200mV 85C Model Fmax Summary
---------------------------------------------------------Fmax
Restricted Fmax Clock Name
101.64 MHz 101.64 MHz
SCLK
-----------------------------------------------------Slow 1200mV 85C Model Setup Summary
------------------------------------------------------Clock Slack End Point TNS
SCLK -8.839 -345.742
---------------------------------------------------------Slow 1200mV 85C Model Hold Summary

---------------------------------------------------------Clock Slack End Point TNS
SCLK 0.381 0.000
---------------------------------------------------------------------------Slow 1200mV 85C Model Minimum Pulse Width Summary
----------------------------------------------------------------------------Clock Slack End Point TNS
SCLK -3.000 -101.945
70
A.5 I2C Master-slave interface implementation report.

Successful - Thu Aug 09 17:59:58 2012
Quartus II Version
Revision Name
I2C_ms_interface
I2C_ms_interface
Family
Cyclone IV E
144
136
73
Total registers
73
Total pins
42
Total virtual pins
0
Total memory bits
0
0
Total PLLs
0
------------------------------------------------------------------------------Fitter Summary
-----------------------------------------------------------------------------Fitter Status
Quartus II Version
Revision Name
I2C_ms_interface
I2C_ms_interface
Family
Cyclone IV E
Device
EP4CE115F29C7
Timing Models
Final
145 / 114,480 ( < 1 % )
73 / 114,480 ( < 1 % )
Total registers
73
Total pins
42 / 529 ( 8 % )
Total virtual pins
0
Total memory bits
0 / 3,981,312 ( 0 % )
Total PLLs
0/4(0%)
-----------------------------------------------------------Clocks
-----------------------------------------------------------Clock Name Type Period Frequency Rise Fall
-----------------------------------------------------------clock
Base 1.000 1000.0 MHz 0.000 0.500
71
------------------------------------------------------------------------------------------------------------Slow 1200mV 85C Model Fmax Summary

----------------------------------------------Fmax
166.78 MHz 166.78 MHz
clock
----------------------------------------------------------------------------------Slow 1200mV 85C Model Setup Summary
----------------------------------Clock Slack End Point TNS
clock -4.996 -105.177
---------------------------------------------------------------------Slow 1200mV 85C Model Hold Summary
---------------------------------Clock Slack End Point TNS
clock 0.283 0.000
-----------------------------------------------------------------------------------Slow 1200mV 85C Model Minimum Pulse Width Summary
------------------------------------------------Clock Slack End Point TNS
clock -3.000 -96.805
-------------------------------------------------
72
A.6 SPI master-slave interface implementation report

Quartus II Version
Revision Name
SPI_interface
spi_interface
Family
Cyclone IV E
215
215
91
Total registers
91
Total pins
76
Total virtual pins
0
Total memory bits
0
Total PLLs
0
----------------------------------------------------------------------------Fitter Summary
-----------------------------------------------------------------------------Fitter Status
Quartus II Version
Revision Name
SPI_interface
spi_interface
Family
Cyclone IV E
Device
EP4CE115F29C7
Timing Models
Final
215 / 114,480 ( < 1 % )
91 / 114,480 ( < 1 % )
Total registers
91
Total pins
76 / 529 ( 14 % )
Total virtual pins
0
Total memory bits
0 / 3,981,312 ( 0 % )
Total PLLs
0/4(0%)
73
------------------------------------------------------------Clocks
------------------------------------------------------------Clock Name Type Period Frequency Rise Fall
clock
Base 1.000 1000.0 MHz 0.000 0.500
-------------------------------------------------------------------------------------------------------------Slow 1200mV 85C Model Fmax Summary
----------------------------------------------Fmax
185.25 MHz 185.25 MHz
clock
----------------------------------------------------------------------------------Slow 1200mV 85C Model Setup Summary
clock -4.398 -275.261
clock 0.384 0.000
clock -3.000 -119.935
-------------------------------------------------
74
A.7 Serial protocol bridge implementation report

------------------------------------------------------------------------Analysis & Synthesis Summary
------------------------------------------------------------------------Analysis & Synthesis Status
Quartus II Version
Revision Name
I2C_SPI_BRIDGE
I2C_SPI_BRIDGE
Family
Cyclone IV E
393
385
163
Total registers
163
Total pins
69
Total virtual pins
0
Total memory bits
0
0
Total PLLs
0
----------------------------------------------------------------------------Fitter Summary
----------------------------------------------------------------------------Fitter Status
Quartus II Version
Revision Name
I2C_SPI_BRIDGE
I2C_SPI_BRIDGE
Family
Cyclone IV E
Device
EP4CE115F29C7
Timing Models
Final
386 / 114,480 ( < 1 % )
163 / 114,480 ( < 1 % )
Total registers
163
Total pins
69 / 529 ( 13 % )
Total virtual pins
0
Total memory bits
0 / 3,981,312 ( 0 % )
Total PLLs
0/4(0%)
75
------------------------------------------------------------Clocks
-------------------------------------------------------------Clock Name Type Period Frequency
Rise Fall
clk
Base 1.000 1000.0 MHz 0.000 0.500
--------------------------------------------------------------
----------------------------------------------Slow 1200mV 85C Model Fmax Summary

----------------------------------------------Fmax
127.24 MHz 127.24 MHz
clk
---------------------------------------------------------------------------------Slow 1200mV 85C Model Setup Summary
clk -6.859 -390.679
clk 0.383 0.000
clk -3.000 -212.455
-------------------------------------------------
76

1serial Protocol Bridge

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

1serial Protocol Bridge

Uploaded by

Copyright:

Available Formats

SERIAL PROTOCOL BRIDGE

A thesis submitted to the Graduate School of the

In the Department of Computer Engineering of

Committee Chair: Dr. Carla Purdy

I would like to gratefully acknowledge the enthusiastic supervision of Dr. Carla

Finally, I am forever indebted to my parents and Mohit Ahuja, my husband, for

3.4.4. Designing SPI slave32

Camera with different protocols for different purposes..3

The canonical Harvard architecture .............10

Cellular system of second generation... 11

TI OMAP4 architecture [10] ................12

Typical I2C transaction..........................19

Typical SPI transaction..........................20

Use case diagram for I2C master.......22

State diagram for I2C master.........23

Sequence diagram for I2C master write use case..24

Sequence diagram for I2C master read use case...25

Use case diagram for I2C slave.26

State diagram for I2C slave...27

Sequence diagram for I2C slave write use case28

3.10 Sequence diagram for I2C slave read use case. 29

I2C master waveform generated through test bench42

I2C slave generated through test bench.43

SPI master waveform generated through test bench.45

SPI slave waveform generated through test bench46

I2C interface waveform generated using test bench..48

SPI interface waveform (master is reading back after writing).48

Complete I2C-SPI serial protocol bridge..50

I2C master writes to SPI slave through serial protocol bridge.51

I2C master reads SPI slave through serial protocol bridge...51

Properties of typical serial protocol buses...8

I2C master transition table41

SPI master transition table.45

Typical characteristics of EP4CE115F29C7 FPGA chip...54

Hardware implementation details for all design modules.54

CPOL clock polarity

CPHA clock phase

DSP digital signal processor

ESW embedded software

EEPROM electrically erasable programmable read only memory

FPGA field programmable gate array

GPS global positioning system

I2C inter integrated circuit

LCD liquid crystal display

MISO master in slave out

MOSI- master out slave in

MODF mode fault

NACK- not acknowledge

RTC -real time clock

SPI serial protocol interface

SCLK serial clock

SDA serial data

SCL serial clock

SPCR serial peripheral control register

SPSR serial peripheral status register

SPDR serial peripheral data I/ O register

SPIF SPI transfer complete flag

SSEL slave select

UML unified modeling language

UML-RT unified modeling language-real time

VHDL very high speed hardware descriptive language

WCOL write collision

shaking methodology, and number of bits transferred in single transfer cycle.

Figure 1.1 Camera with different protocols for different purpose.