1serial Protocol Bridge

7/26/2019 1serial Protocol Bridge

1/88


2/88

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


3/88

ii

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.


4/88

iii


5/88

iv

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


6/88

v

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.72.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


7/88

vi

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


8/88

vii

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


9/88

viii

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


10/88

ix

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


11/88

x

ACRONYMS

1.

CPOLclock polarity

2.

CPHAclock phase

3. DSPdigital signal processor

4. ESWembedded software

5.

EEPROMelectrically erasable programmable read only memory

6.

FPGAfield programmable gate array

7.

GPSglobal positioning system

8. I2Cinter integrated circuit

9.

LCDliquid crystal display

10.

MISOmaster in slave out

11. MOSI- master out slave in

12.

MODFmode fault

13.

NACK- not acknowledge

14. RTC -real time clock

15. SPIserial protocol interface

16.

SCLKserial clock

17. SSslave select

18. SDAserial data

19.

SCLserial clock


12/88

xi

20. SPCRserial peripheral control register

21.

SPSRserial peripheral status register

22.

SPDRserial peripheral data I/ O register

23. SPIFSPI transfer complete flag

24. SSELslave select

25.

UMLunified modeling language

26.

UML-RTunified modeling language-real time

27.

VHDLvery high speed hardware descriptive language

28. WCOLwrite collision

29.

1Gfirst generation

30.

3Gthird generation


13/88

1

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


14/88

2

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


15/88

3

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.


16/88

4

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


17/88

5

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.


18/88

6

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


19/88

7

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


20/88

8

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

Devices

Max Speed

(KBPS)

Max

Distance Ft

Pin Count

RS-232 No peer full 2 20 30 2

RS-422 No multi drop half 10 10000 4000 1

RS-485 No multi point half 32 10000 4000 2

I2C Yes master/ slave half *1 3400 1000


21/88

9

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.


22/88

10

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.


23/88

11

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


24/88

12

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].


25/88

13

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


26/88

14

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


27/88

15

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.


28/88

16

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 I2CSPI 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


29/88

17

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


30/88

18

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 speeds-

100kbits/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.


31/88

19

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


32/88

20

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


33/88

21

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.


34/88

22

Figure 3.3 Use case diagram for I2C master.


35/88

23

Figure 3.4 State diagram for I2C master.


36/88

24

Figure 3.5 Sequence diagram for I2C master write use case.


37/88

25

Figure 3.6 Sequence diagram for I2C master read use case


38/88

26

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.


39/88

27

Figure 3.8 State diagram for I2C slave.


40/88

28

Figure 3.9 Sequence diagram for I2C slave write use case.


41/88

29

Figure 3.10 Sequence diagram for I2C slave read use case.


42/88

30

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.


43/88

31

Figure 3.12 State diagram for SPI master

Figure 3.13 Sequence diagram for SPI master data exchange use case.


44/88

32

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.


45/88

33

Figure 3.15 State diagram for SPI slave.

Figure 3.16 Sequence diagram for SPI slave.


46/88

34

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.


47/88

35

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.


48/88

36

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.


49/88

37

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


50/88

38

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.


51/88

39

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.


52/88

40

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 describingsimulation 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


53/88

41

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 1 0 1 1

STOP 010 idle stop_a idle 1 0 1

READ 100 idle rd_a rd_b rd_c

rd_d rd_e rd_f rd_g

rd_h rd_i idle

1 8-bit data read

from slave NACK

sent by master 1

WRITE 101 idle wr_a wr_b wr_c

wr_d wr_e wr_f

wr_g wr_h wr_i idle

1 8-bit data or 7-bit

address + read/write bit

ACK sent by slave

1

NOP 000 idle 1

Table 4.1 I2C master transition table


54/88

42

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


55/88

43

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


56/88

44

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.


57/88

45

Command Name Command Code State Transitions Signals Involved

CONFIG 010 idle config_a

config_b config_c

idle

SCLK

EXCHANGE 100 idle exchange_a

exchange_b idle

SCLK,MISO,MOSI,SS

NOP 000 idle none

Table 4.2 SPI master transition table

Figure 4.3 SPI master waveform generated through test bench


58/88

46

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


59/88

47

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.


60/88

48

Figure 4.5 I2C interface waveform generated using test bench

Figure 4.6 SPI interface waveform (master is reading back after writing)


61/88

49

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.


62/88

50

Figure 4.7 Complete I2C-SPI serial protocol bridge


63/88

51

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


64/88

52

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


65/88

53

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.


66/88

54

Core Voltage 1.2V

Logic Elements 114480

I/O pins 529

Memory Bits 3981312

Embedded multiplier 9-bit elements 532

PLL 4

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


67/88

55

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


68/88

56

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.


69/88

57

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


70/88

58

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


71/88

59

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.


72/88

60

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.


73/88

61

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
http://www.eetimes.com/design/embedded/4023975/Serial-Protocols-Comparedhttp://en.wikipedia.org/wiki/Field-programmable_gate_arrayhttp://en.wikipedia.org/wiki/Field-programmable_gate_arrayhttp://www.fpga4fun.com/I2C.htmlhttp://www.fpga4fun.com/I2C.htmlhttp://en.wikipedia.org/wiki/Field-programmable_gate_arrayhttp://www.eetimes.com/design/embedded/4023975/Serial-Protocols-Compared


74/88

62

[9] P.Venkateswaran, Madhumita Mukherjee, Arindam Sanyal, Snehasish Das and

R.Nandi, Design and Implementation of FPGA Based Interface Model for Scale-

Free 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 real-

time 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
http://www.ti.com/lit/ml/swpt034b/swpt034b.pdfhttp://www.ti.com/lit/ml/swpt034b/swpt034b.pdfhttp://www.angelfire.com/in/rajesh52/verilogvhdl.htmlhttp://www.angelfire.com/in/rajesh52/verilogvhdl.htmlhttp://www.fpga4fun.com/SPI.htmlhttp://en.wikipedia.org/wiki/Visual_Paradigm_for_UMLhttp://en.wikipedia.org/wiki/Visual_Paradigm_for_UMLhttp://www.fpga4fun.com/SPI.htmlhttp://www.angelfire.com/in/rajesh52/verilogvhdl.htmlhttp://www.ti.com/lit/ml/swpt034b/swpt034b.pdf


75/88

63

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 EditionRevision Name I2C_master

Top-level Entity Name I2C_master

Family Cyclone IV E

Total logic elements 77Total combinational functions 77

Dedicated logic registers 34Total registers 34Total pins 38

Total virtual pins 0

Total memory bits 0Embedded Multiplier 9-bit elements 0

Total PLLs 0

-----------------------------------------------------------------------------Fitter Summary

-----------------------------------------------------------------------------

Fitter Status Successful - Fri Aug 03 10:34:52 2012Quartus 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 EDevice EP4CE115F29C7

Timing Models Final

Total logic elements 77 / 114,480 ( < 1 % )Total combinational functions 77 / 114,480 ( < 1 % )

Dedicated logic registers 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 % )


76/88

64

-----------------------------------------------------------

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 TNSclk -2.293 -28.754

------------------------------------------------------------------------

Operating Settings and Conditions------------------------------------------------------------------------

Nominal Core Voltage 1.20 VLow Junction Temperature 0 C

High Junction Temperature 85 C

--------------------------------------------------------------------------

Clocks

--------------------------------------------------------------------------

Clock Name Type Period Frequency Rise Fallclk Base 1.000 1000.0 MHz 0.000 0.500


77/88

65

A.2 I2C slave implementation report

------------------------------------------------------------------------------

Analysis & Synthesis Summary

------------------------------------------------------------------------------

Analysis & Synthesis Status Successful - Fri Aug 03 10:42:56 2012Quartus II Version 10.0 Build 218 06/27/2010 SJ Web Edition

Revision Name I2C_slave

Top-level Entity Name i2c_slaveFamily Cyclone IV E

Total logic elements 73

Total combinational functions 65Dedicated logic registers 43

Total registers 43

Total pins 24Total virtual pins 0

Total memory bits 0Embedded Multiplier 9-bit elements 0Total PLLs 0

-----------------------------------------------------------------------------------

Fitter Summary-----------------------------------------------------------------------------------

Fitter Status Successful - Fri Aug 03 10:43:29 2012

Quartus II Version 10.0 Build 218 06/27/2010 SJ Web EditionRevision Name I2C_slave

Top-level Entity Name i2c_slave

Family Cyclone IV EDevice EP4CE115F29C7Timing Models Final

Total logic elements 73 / 114,480 ( < 1 % )

Total combinational functions 65 / 114,480 ( < 1 % )Dedicated logic registers 43 / 114,480 ( < 1 % )

Total registers 43


Total memory bits 0 / 3,981,312 ( 0 % )

Embedded Multiplier 9-bit elements 0 / 532 ( 0 % )

Total PLLs 0 / 4 ( 0 % )

-----------------------------------------------------------------------------

Operating Settings and Conditions-----------------------------------------------------------------------------




78/88

66

-----------------------------------------------------------------------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--------------------------------------------------------------------------------------------------------------


297.53 MHz 237.53 MHz SCL limit due to minimum period restriction

---------------------------------------------------------------

Slow 1200mV 85C Model Setup Summary

----------------------------------------------------------------

Clock Slack End Point TNSSCL -2.361 -32.188

-----------------------------------------------------------------


-----------------------------------------------------------------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


79/88

67

A.3 SPI master implementation report

-------------------------------------------------------------------------------


------------------------------------------------------------------------------


Revision Name SPI_master

Top-level Entity Name spi_masterFamily Cyclone IV E



Total registers 49



-------------------------------------------------------------------------------

Fitter Summary------------------------------------------------------------------------------


Quartus II Version 10.0 Build 218 06/27/2010 SJ Web EditionRevision Name SPI_master

Top-level Entity Name spi_master




Total registers 49




Total PLLs 0 / 4 ( 0 % )

----------------------------------------------------

Operating Settings and Conditions----------------------------------------------------




80/88

68

---------------------------------------------------------------------

Clocks

---------------------------------------------------------------------

Clock Name Type Period Frequency Rise Fallclk 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

---------------------------------------------------------


----------------------------------------------------------Clock Slack End Point TNS

clk -3.736 -115.546

----------------------------------------------------------

Slow 1200mV 85C Model Hold Summary-----------------------------------------------------------


clk 0.384 0.000

------------------------------------------------------------------------------

Slow 1200mV 85C Model Minimum Pulse Width Summary------------------------------------------------------------------------------


clk -3.000 -65.965


81/88

69

A.4 SPI slave implementation report

-------------------------------------------------------------------------------


------------------------------------------------------------------------------


Revision Name SPI_slave

Top-level Entity Name spi_slaveFamily Cyclone IV E



Total registers 77



-------------------------------------------------------------------------------

Fitter Summary------------------------------------------------------------------------------


Quartus II Version 10.0 Build 218 06/27/2010 SJ Web EditionRevision Name SPI_slave

Top-level Entity Name spi_slave




Total registers 77




Total PLLs 0 / 4 ( 0% )

----------------------------------------------------

Operating Settings and Conditions----------------------------------------------------




82/88

70

------------------------------------------------------------------Clocks

-------------------------------------------------------------------


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

------------------------------------------------------


-------------------------------------------------------

Clock Slack End Point TNSSCLK -8.839 -345.742

----------------------------------------------------------

Slow 1200mV 85C Model Hold Summary----------------------------------------------------------


SCLK 0.381 0.000

----------------------------------------------------------------------------

Slow 1200mV 85C Model Minimum Pulse Width Summary-----------------------------------------------------------------------------


SCLK -3.000 -101.945


83/88

71

A.5 I2C Master-slave interface implementation report.

-------------------------------------------------------------------------------


------------------------------------------------------------------------------

Analysis & Synthesis Status Successful - Thu Aug 09 17:59:58 2012Quartus II Version 10.0 Build 218 06/27/2010 SJ Web Edition

Revision Name I2C_ms_interface

Top-level Entity Name I2C_ms_interfaceFamily Cyclone IV E



Total registers 73



-------------------------------------------------------------------------------

Fitter Summary------------------------------------------------------------------------------

Fitter Status Successful - Thu Aug 09 18:00:27 2012

Quartus II Version 10.0 Build 218 06/27/2010 SJ Web EditionRevision Name I2C_ms_interface

Top-level Entity Name I2C_ms_interface




Total registers 73




Total PLLs 0 / 4 ( 0 % )

------------------------------------------------------------

Clocks------------------------------------------------------------

Clock Name Type Period Frequency Rise Fall------------------------------------------------------------

clock Base 1.000 1000.0 MHz 0.000 0.500


84/88

72

------------------------------------------------------------

--------------------------------------------------

Slow 1200mV 85C Model Fmax Summary

-----------------------------------------------

Fmax Restricted Fmax Clock Name Note166.78 MHz 166.78 MHz clock

-----------------------------------------------

-------------------------------------


-----------------------------------

Clock Slack End Point TNSclock -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-------------------------------------------------


85/88

73

A.6 SPI master-slave interface implementation report

-------------------------------------------------------------------------------


------------------------------------------------------------------------------


Revision Name SPI_interface

Top-level Entity Name spi_interfaceFamily Cyclone IV E



Total registers 91



-----------------------------------------------------------------------------

Fitter Summary------------------------------------------------------------------------------

Fitter Status Successful - Thu Aug 09 17:55:40 2012

Quartus II Version 10.0 Build 218 06/27/2010 SJ Web EditionRevision Name SPI_interface

Top-level Entity Name spi_interface




Total registers 91




Total PLLs 0 / 4 ( 0 % )


86/88

74

-------------------------------------------------------------

Clocks-------------------------------------------------------------


clock Base 1.000 1000.0 MHz 0.000 0.500

-------------------------------------------------------------

--------------------------------------------------

Slow 1200mV 85C Model Fmax Summary-----------------------------------------------


185.25 MHz 185.25 MHz clock

-----------------------------------------------

-------------------------------------


-----------------------------------Clock Slack End Point TNS

clock -4.398 -275.261-----------------------------------

------------------------------------Slow 1200mV 85C Model Hold Summary

----------------------------------


clock 0.384 0.000----------------------------------

---------------------------------------------------

Slow 1200mV 85C Model Minimum Pulse Width Summary

-------------------------------------------------Clock Slack End Point TNS

clock -3.000 -119.935

-------------------------------------------------


87/88

75

A.7 Serial protocol bridge implementation report

-------------------------------------------------------------------------


-------------------------------------------------------------------------


Revision Name I2C_SPI_BRIDGE

Top-level Entity Name I2C_SPI_BRIDGEFamily Cyclone IV E



Total registers 163



-----------------------------------------------------------------------------Fitter Summary

-----------------------------------------------------------------------------

Fitter Status Successful - Thu Aug 09 18:11:18 2012Quartus II Version 10.0 Build 218 06/27/2010 SJ Web Edition

Revision Name I2C_SPI_BRIDGE

Top-level Entity Name I2C_SPI_BRIDGEFamily Cyclone IV EDevice EP4CE115F29C7

Timing Models Final

Total logic elements 386 / 114,480 ( < 1 % )Total combinational functions 385 / 114,480 ( < 1 % )

Dedicated logic registers 163 / 114,480 ( < 1 % )

Total registers 163Total pins 69 / 529 ( 13 % )

Total virtual pins 0


Embedded Multiplier 9-bit elements 0 / 532 ( 0 % )Total PLLs 0 / 4 ( 0 % )


88/88

-------------------------------------------------------------

Clocks--------------------------------------------------------------


clk Base 1.000 1000.0 MHz 0.000 0.500

--------------------------------------------------------------

-----------------------------------------------Slow 1200mV 85C Model Fmax Summary

-----------------------------------------------


127.24 MHz 127.24 MHz clk----------------------------------------------

-------------------------------------

Slow 1200mV 85C Model Setup Summary-----------------------------------

Clock Slack End Point TNSclk -6.859 -390.679

-----------------------------------

------------------------------------


----------------------------------

Clock Slack End Point TNSclk 0.383 0.000

----------------------------------

---------------------------------------------------

Slow 1200mV 85C Model Minimum Pulse Width Summary-------------------------------------------------


clk -3.000 -212.455

-------------------------------------------------

Documents

1serial Protocol Bridge