Design of a Microcontroller Circuit with USB for M2M Application using GSM Network

(1)

King Saud University

College of Engineering

Department of electrical Engineering

Design of a Microcontroller Circuit with USB for M2M

Application using GSM Network

Submitted in partial fulfillment of the requirements for the Master’s Degree in the Department of Electrical Engineering, At the College of Engineering,

King Saud University

Prepared By:

Mohammed A. Al-Dalbehi

Supervised by

Prof.: Mohammed Abu El-Ela

Dr. Bandar Al-Mashari

(2)

Arabic abstract

ﺔﻟﺎﺳﺮﻟا

ﺺﺨﻠﻣ

ةﺪﺣﻮآ ﺐﺳﺎﺤﻟا ﻰﻠﻋ ﺪﻤﺘﻌﺗ ﺔﻤﻈﻧأ ﻰهو ﺔﻨﻤﻀﺘﻤﻟا ﺔﻤﻈﻧﻷا ءﺎﻨﺒﻟ ﺔﻴﺳﺎﺳﻷا ﺮﺋاوﺪﻟا ﻦﻣ ﻖﻴﻗﺪﻟا ﻢﻜﺤﺘﻤﻟا ﺮﺒﺘﻌﻳ ﺎﻣ ﺔﻣﻮﻈﻨﻣ ﻞﺧاد ﺎﻬﻤﺽ ﻢﺘﻳو ﺔﻴﺋﺎﻨﺏ . نﺈﻓ ﺔﻣﺎﻋ ﻒﺋﺎﻇﻮﺏ مﻮﻘﻳ يﺬﻟا ﻲﻟﻵا بﻮﺳﺎﺤﻟا ﺔﻔﻴﻇو ﺲﻜﻋ ﻰﻠﻋو ﺪﻳﺪﺤﺘﻟاﺔﻘﺏﺎﺳ ﻒﺋﺎﻇوﺎﻬﻟنﻮﻜﻳ ﺔﻨﻤﻀﺘﻤﻟاﺔﻤﻈﻧﻷا . ﻢﺘﻳةدﺎﻋو ﻰﺒﻠﺗ ﺚﻴﺤﺏﻖﻴﻗدﻢﻜﺤﺘﻤﻟ ﺔﻴﻠﺧاﺪﻟاﺔﻴﻨﺒﻟاﻢﻴﻤﺼﺗ ﺎﻬﻨﻤﻀﺘﺗ ﻲﺘﻟا ﺔﻴﻠﻜﻟا ﺔﻣﻮﻈﻨﻤﻟا ضاﺮﻏﺄﺏ ﻲﻔﺗ ﺚﻴﺤﺏ مﺪﺨﺘﺴﻤﻟا ﻞﺒﻗ ﻦﻣ ﺪﻳﺪﺤﺘﻟا ﺔﻘﺏﺎﺳ تﺎﺟﺎﻴﺘﺣا . ﻦﻜﻤﻳو اﻮﺳﻷﺎﺏ ﺔﺣﺎﺘﻤﻟا ﺔﻴﺳﺎﻴﻘﻟا ﺮﺋاوﺪﻟا تﺎﺌﻣ ﻦﻣﻖﻴﻗﺪﻟا ﻢﻜﺤﺘﻤﻟا رﺎﻴﺘﺧا ﻢﻤﺼﻤﻠﻟ ق . ﺔﺹﺎﺧ ةﺪﺣو ﻢﻴﻤﺼﺗ ﻪﻨﻜﻤﻳ وأ تﺎﻴﻨﻘﺗماﺪﺨﺘﺳﺎﺏ " ﻋمﺎﻈﻧ نﻮﻜﻴﻠﺳﺔﻘﻴﻗرﻰﻠ “ تﺎآﺮﺸﻟا ﻦﻣﺪﻳﺪﻌﻟاﻦﻣ ﺎﻴﻟﺎﺣﺔﺣﺎﺘﻤﻟا . نﺎﺴﻧﺈﺏ ﻪﻟﺁ لﺎﺼﺗا وأ ﻪﻟﺂﺏ ﻪﻟﺁ لﺎﺼﺗا ﺔﻴﻨﻘﺗ ﺔﺘﻤﺗﻷا ﺔﻣﺎﺗ ﺔﻤﻈﻧﻷأ ءﺎﻨﺏ ﻲﻓ ﺔﻣﺪﺨﺘﺴﻤﻟا ةﺪﻋاﻮﻟا تﺎﻴﻨﻘﺘﻟا ﻦﻣو لاﻮﺠﻟا ﺔﻜﺒﺵ ماﺪﺨﺘﺳﺎﺏ . ﻤﻈﻧﻷأ ﻩﺬﻬﻟ ﺮﺏﺪﻤﻟا ﻞﻘﻌﻟا روﺪﺏ ﻖﻴﻗﺪﻟا ﻢﻜﺤﺘﻤﻟا مﻮﻘﻳو ﺔ ﻩﺬه لﻼﺧ ﻦﻣ ﻦﻜﻤﻳ ﺚﻴﺣ ﻘﺘﻟا ﺲﻜﻌﻟا وأ نﺎﺴﻧإو ﻪﻟأوأ ىﺮﺧأو ﻪﻟﺁ ﻦﻴﺏ تﺎﻧﺎﻴﺒﻟاﻞﻘﻧ ﺔﻴﻨ . ﻞﻘﻧ ﻰﻓ ﺎﻬﺗءﺎﻔآو لاﻮﺠﻟاتﺎﻜﺒﺵ ﺮﻓﻮﺘﻟ اﺮﻈﻧو ﻢﻟﺎﻋوﺎﻴآﻮﻧ و نﻮﺴﻜﻳرا ﻞﺜﻣ لاﻮﺠﻟا تﺎآﺮﺵ ﻦﻣ ﺪﻳﺪﻌﻟا تﺮﻓو ﺪﻘﻓ ﺔﻴﻠﻤﻋ ﺔﻔﻠﻜﺗ نوﺪﺏ ﺔﻴﻤﻗﺮﻟا تﺎﻧﺎﻴﺒﻟا – دز ﻟااﺬه ﻲﻓ تﺎﻘﻴﺒﻄﺘﻟاﺾﻌﺒﻟ ﺔﻴﻟوأجذﺎﻤﻧ ﺮﻳﻮﻄﺘﻟ تاﺪﺣو ةﺪﻋقاﻮﺳﻷا ﻲﻓ لﺎﺠﻤ . ةﺮﺋاد ماﺪﺨﺘﺳا ﻢﺘﻳﺎﻣ ةدﺎﻋو عﻮﻧ ﻦﻣ ﺔﻴﺳﺎﻴﻘﻟا ﺔﻴﻟاﻮﺘﻤﻟا ﺔﻬﺟاﻮﻤﻟا RS232 ﺎﺼﺗﻼﻟ ل ﻞﺒﻘﺘﺴﻣ و ﻞﺳﺮﻤآ ﻞﻤﻌﻳ يﺬﻟا لاﻮﺠﻟا زﺎﻬﺟ ﻦﻴﺏ ﺔﻟﻵﺎﺏﻞﺼﺘﻤﻟاوﻖﻴﻗﺪﻟاﻢﻜﺤﺘﻤﻟاﻰﻠﻋىﻮﺘﺤﺗﻲﺘﻟاتﺎﻘﻴﺒﻄﺘﻟاةﺮﺋادﻦﻴﺏو تﺎﻧﺎﻴﺒﻠﻟ . ﺔﻌﻣﺎﺟ ﺔﻴﻟاﻮﺘﻣ ﺔﻬﺟاﻮﻣ ةﺮﺋاد ماﺪﺨﺘﺳا عﻮﻴﺸﻟ اﺮﻈﻧو ) USB ( ةﺮﺋاد ﻰﻠﻋ ﺎﻬﻗﻮﻔﺘﻟ نﻵأ ةﺰﻬﺟﻷا ﻢﻈﻌﻣ ﻰﻓ عﻮﻧ ﻦﻣ ﺔﻴﺳﺎﻴﻘﻟا ﺔﻴﻟاﻮﺘﻤﻟا ﺔﻬﺟاﻮﻤﻟا RS232 ﺔﻬﺟاﻮﻤﻟا ةﺮﺋاد ةﺮﺋاﺪﺏ ﻖﻴﻗﺪﻟا ﻢﻜﺤﺘﻤﻟا ةﺮﺋاد ﺪﻳوﺰﺗ نﺈﻓ عﻮﻧ ﻦﻣ ﺔﻌﻣﺎﺠﻟا ﺔﻴﻟاﻮﺘﻤﻟا USB ﺔﻜﺒﺵ ﻰﻠﻋ ﻢﻜﺤﺘﻟا ﺔﻤﻈﻧأو ﺎﻣﻮﻤﻋ ﻢﻜﺤﺘﻟأ ﺔﻤﻈﻧأ ءادأ ﻦﻣ ﻦﺴﺤﻳ فﻮﺳ صﻮﺼﺨﻟاﻪﺟوﻰﻠﻋلاﻮﺠﻟا . ا فﺪﻬﻟا ﺔﻌﻣﺎﺟ ﺔﻬﺟاﻮﻣ ةﺮﺋاد ﻰﻠﻋ ىﻮﺘﺤﺗﻖﻴﻗد ﻢﻜﺤﺘﻣةﺮﺋاد ﻢﻴﻤﺼﺗو حاﺮﺘﻗا ﻮه ﺚﺤﺒﻟا اﺬهﻦﻣ ﻲﺳﺎﺳﻷ ) USB ( تﺎﻘﻴﺒﻄﺘﻟ ﺔﻴﻟوﻷا جذﺎﻤﻨﻠﻟ ﻢﻴﻤﺼﺘﻟا تاﺪﺣو ﻲﻓ ﺎهﺮﻓاﻮﺗ ﺐﺟاﻮﻟاﺮﻳﻮﻄﺘﻟا تﺎﺟﺎﻴﺘﺣا ﻢﻴﻤﺼﺘﻟا ﻰﺒﻠﻳو لاﻮﺠﻟاﺔﻜﺒﺵ ماﺪﺨﺘﺳﺎﺏ ﻚﻟذوﺲﻜﻌﻟا وأ نﺎﺴﻧﺈﺏﻪﻟﺁ لﺎﺼﺗا وأﻪﻟﺂﺏﻪﻟﺁ لﺎﺼﺗا ﺔﻤﻈﻧأ ﺔﻴﻤﻟﺎﻌﻟاو ﺔﻴﻠﺤﻤﻟا . ﺎﻤآ ﺔﻤﻈﻧﻸﻟﺔﺜﻳﺪﺤﻟاﻢﻴﻤﺼﺘﻟاتاودأوتﺎﻴﻨﻘﺗماﺪﺨﺘﺳﺎﺏﻢﻴﻤﺼﺘﻟاﺔﺳرﺎﻤﻣوﻢﻠﻌﺗوﺔﺳاردﻲﻓﺎﻀﻳأﺚﺤﺒﻟاﺪﻋﺎﺴﻴﺳ ﻖﻴﻗﺪﻟاﻢﻜﺤﺘﻤﻠﻟﺔﺣﺮﺘﻘﻤﻟاةﺮﺋاﺪﻟاﺬﻴﻔﻨﺗو ﺔﺟﺬﻤﻧوةﺎآﺎﺤﻣلﻼﺧﻦﻣﻚﻟذوﺔﻴﻤﻗﺮﻟاﺔﻴﻧوﺮﺘﻜﻟﻹا .

(3)

Abstract

Microcontroller is a basic building block for implementing embedded systems. An embedded system is a special-purpose computer based block included in a given system . It has specific requirements and performs pre-defined tasks, unlike a general-purpose personal computer.. The designer of an embedded system may choose from off-shelf standard Microcontrollers chips or design his own structure using SoC (System On Chip) available technologies.

M2M (short for machine-to-machine, man-to-machine or mobile-to-machine) is a new and growing technology available in the market for designing and implementing fully automated systems.

Microcontroller acts like the brain of M2M which is estimated to get an exponential growth in the coming years. M2M enables the flow of data between machines and machines, and ultimately machines and people. Regardless of the type of machine or data, information usually flows from a machine over a network such as GSM network.

Many companies like Ericsson, Nokia and Z- world provide the market by a lot of M2M developer kits which mainly depend on Microcontrollers. These microcontrollers use the RS 232C standard serial interface to communicate with the other circuits within the M2M system. Using the USB interface instead of the RS232 will improve the system performance because of its advantages and flexibility. It is to be noted here, that most of Laptops are not equipped with RS232 interface.

The main objective of the thesis is to propose and design a Microcontroller structure that includes USB interface. On the other hand the design has to satisfy the requirements of developers employing the microcontroller in building M2M systems. The research also helps in studying and practicing new and advanced techniques in digital circuit simulation through using modern simulation packages to simulate the proposed Microcontroller.

(4)

Acknowledgments

First of all thanks for ALLAH for the success of this study ,Then I would like to thank My supervisors Prof. Mohammed Abu El-Ela and Dr. Bandar AL-Mashari for their efforts in assisting me with this thesis

Many thanks must also go to My Brother Hezam for his unlimited support not only in this time but in all stages of my life also my family and my friends many thanks

(5)

List of Figures

Figure I : Sony Ericsson GM47/GM48 module... 2

Figure 1.1: Microcontroller outline with its basic elements and internal connections ... 4

Figure 1.2: Microcontroller’s memory unit ... 5

Figure 1.3: Microcontroller Central Processing Unit block... 6

Figure 1.4: Microcontroller Buses ... 7

Figure 1.5: Microcontroller Ports ... 7

Figure 1.6: Timer unit... 8

Figure 1.7: A/D converter ... 9

Figure 1.8: Serial communication block in Microcontroller ... 9

Figure 1.9: UART block diagram ... 10

Figure 2.1: Bus Topology ... 14

Figure 2.2: A Typical Hub ... 15

Figure 2.3: USB cable... 16

Figure 2.4: USB cable connector types... 18

Figure 2.5: PID Format ... 20

Figure 2.6: ADDR Field ... 21

Figure 2.7: Endpoint Field ... 21

Figure 2.8: Data Field Format... 22

Figure 2.9: Token Format ... 23

Figure 2.10: SOF Packet... 23

Figure 2.11: Data Packet Format ... 24

Figure 2.12 : Handshake Packet... 25

Figure 3.1: Block Diagram of 8051 model ... 31

Figure 3.2: Simulation result of testing 8051 model... 33

Figure 3.3: Block Diagram of PicoBlaze... 35

Figure 3.4: Simulation result of PicoBlaze ... 41

Figure 4.1 :Maxim implementation for the USB to Microcontroller through UART ... 44

Figure 4.2 :block diagram of the FT245R chip... 45

(10)

Figure 4.4: proposed block diagram for Microcontroller with USB ... 47

Figure 4.5: Hardware verification for PicoBlaze code ... 48

Figure 4.6: Microcontroller with USB on board... 49

Figure 4.7: Block diagram of VHDL code ... 53

Figure 4.8: Hyper Terminal showing the program Menu ... 57

Figure 4.9: Test result in Hyper Terminal ... 58

Figure 4.10: Switches and LEDs Values after using the program... 58

Figure 5.1: Final System blocks... 60

Figure 5.2: On Board Final circuit... 63

(11)

List of Tables

Table 2.1: RS232 cable length according to Texas Instruments... 12 Table 3.1 Comparison between hard wired and FPGA implementation of Microcontroller 29 Table 3.2 8051 model blocks description ... 30

(12)

Abbreviations

8051 _{The Intel 8051 is a single chip microcontroller} ASCII American Standard Code for Information Interchange

bit stuffing (Also positive justification) is the insertion of non information bits _{into data.}

CRC cyclic redundancy check

DPLL Digital phase-locked loop,

FPGA Field-programmable gate array GPRS General Packet Radio Service

GSM Global System for Mobile communications

IC Integrated Circuit

ISDN Integrated Services Digital Network

LED light-emitting diode

LSb Least-Significant Bit

Mbps megabit per second

Microcontroller (also MCU or µC) is a computer-on-a-chip.

MSb Most-Significant Bit

NAK negative-acknowledge NRZI non-return-to-zero

PC personal computer

PID Packet Identifier Field

Protocol set of rules governing communication RS 232 Recommended Standard 232

SOF Start-of-Frame SOP Start-of-Packet

system C hardware description language

Verilog hardware description language

VHDL Very-High-Speed Integrated Circuits hardware description language WLAN Wireless LAN is a wireless local area network

(13)

INTRODUCTION

The target of this thesis is to develop M2M (machine-to-machine, man-to-machine or mobile-to-machine) module with USB (Universal Serial Bus) interface .This can be achieved by designing a Microcontroller circuit which has USB interface.

M2M Overview

The M2M is a new and growing technology available in the market for designing and implementing fully automated systems. Many companies like Ericsson, Nokia and Z- world provide the market by several M2M developer kits which mainly depend on employing Microcontrollers that may be interfaced to the built in GSM modules. In This work a survey study for the available kits in the market showed that most of them use the standard RS 232C serial interface to communicate with the other circuits within the M2M system. Using the USB interface instead of the RS232 will improve the system performance because of its advantages and flexibility. It is to be noted here, that most of Laptops are not equipped with RS232 interface.

M2M and Microcontroller

Microcontroller acts like the brain of M2M which is estimated to get an exponential growth in the coming years. M2M enables the flow of data between machines and machines, and ultimately machines and people. Regardless of the type of machine or data, information usually flows from a machine over a network, and then through a gateway to a system where it can be processed and analyzed. On other words, M2M allows a machine or device to transmit or receive its data remotely over a network such as GSM network.

Where the M2M technology can be used?

(14)

- Manufacturing : A lot of Manufacturer may use M2M to enable its customer to remotely collect data as an alternative to manual

- Facility Managements :Building operators can use M2M to monitor their equipments operation such as energy machines

- Medical Application : M2M can be used to collect data from remote diagnostic equipments in patients site ( i.e. Blood pressure ,weight)

- Security : sensors can be used to generate alarms when needed And many applications can be found for this active technology

M2M networks

M2M can be used in many networks like WLAN,WWAN and others networks but the cellular networks ( GSM ,GPRS ) is preferred because of Wide area coverage and High reliability

M2M development kits manufactures

Today many companies like Ericsson, Nokia and Z world provide M2M kits which can support new networks available

The developed Microcontroller circuit will be used with the Sony Ericsson GM47/GM48 module [1] available in the Electrical Engineering department Ericsson lab (see appendix A for its data sheet)

(15)

CHAPTER 1 Microcontroller Architecture

The main objective of this thesis is to develop M2M development kit with USB interface. This may be achieved by designing a Microcontroller Circuit having USB compatible interface.

1.1Introduction

Circumstances that we find ourselves today in the field of microcontrollers had their beginnings in the development of technology of integrated circuits. This development has made it possible to store hundreds of thousands of transistors into one chip. That was a prerequisite for production of Microprocessors IC chips, and the first computers were made by adding external peripherals such as memory, input-output lines, timers and others. Further increasing in the scale of integration makes it possible to design and impalement integrated circuits containing both processor and peripherals. That is how the first chip containing a Microcomputer, or what would later be known as a Microcontroller came about.

Microcontroller differs from a microprocessor in many ways. First and the most important is its functionality. In order for a microprocessor to be used, other components such as memory, or components for receiving and sending data must be added on circuit board. In short, that means that microprocessor is the very heart of the computer. On the other hand, Microcontroller is designed to be all of that in one. No other external components or fewer components are needed for its application because all necessary peripherals are already built in. Thus, we save both time and space needed to construct devices

1.2 Basic components in Microcontroller [2]

(16)

Figure 1.1: Microcontroller outline with its basic elements and internal connections

1.2.1 Memory unit

Memory is part of the Microcontroller whose function is to store data. The easiest way to explain it is to describe it as one big closet with lots of drawers. If we suppose that we marked the drawers in such a way that they can not be confused, any of their contents will then be easily accessible. It is enough to know the designation of the drawer and so its contents will be known to us for sure figure 1.2 showing simple block to describe memory.

(17)

Figure 1.2: Microcontroller memory unit

Memory components are exactly like that. For a certain input we get the contents of a certain addressed memory location and that's all. This means that we need to select the desired memory location on one hand, and on the other hand we need to wait for the contents of that location. An additional control lines designate as R/W (read/write). Control line is used in the following way: if r/w=1, reading is done, and if opposite is true then writing is done on the memory location. Memory is the first element, and we need a few operation of our Microcontroller.

1.2.2 Central Processing Unit

Let us add 3 more memory locations to a specific block that will have a built- in capability to multiply, divide, subtract, and move its contents from one memory location onto another. The part we just added in is called "central processing unit" (CPU). Its memory locations are called registers figure 1.3 showing CPU block.

(18)

Figure 1.3: Microcontroller Central Processing Unit block

Registers are therefore memory locations whose role is to help with performing various mathematical operations or any other operations with data wherever data can be found. Look at the current situation. We have two independent entities (memory and CPU) which are interconnected, and thus any exchange of data is hindered, as well as its functionality. If, for example, we wish to add the contents of two memory locations and return the result again back to memory, we would need a connection between memory and CPU. Simply stated, we must have some "way" through data goes from one block to another.

1.2.3 Bus

The way to connect blocks together is called "bus". Physically, it represents a group of 8, 16, or more wires. There are two types of buses: address and data bus. The first one consists of as many lines as the amount of memory we wish to address and the other one is as wide as data, in our case 8 bits or the connection line. First one serves to transmit address from CPU memory, and the second to connect all blocks inside the Microcontroller see Figure 1.4.

As far as functionality, the situation has improved, but a new problem has also appeared: we have a unit that's capable of working by itself, but which does not have any contact with the outside world, or with us! In order to remove this deficiency, let's add a block which contains several memory locations whose one end is connected to the data bus, and the

(19)

other has connection with the output lines on the Microcontroller which can be seen as pins on the electronic component.

Figure 1.4: Microcontroller Buses

1.2.4 Input-output unit

Ports are way to let Microcontroller connected with others. There are several types of ports: input, output or bidirectional ports. When working with ports, first of all it is necessary to choose which port we need to work with, and then to send data to, or take it from the port.

(20)

When working with it the port acts like a memory location. Something is simply being written into or read from it, and it could be noticed on the pins of the microcontroller.

1.2.5 Timer unit

Since we have the serial communication explained, we can receive, send and process data.

Figure 1.6: Timer unit

However, in order to utilize it in industry we need a few additionally blocks. One of those is the timer block which is significant to us because it can give us information about time, duration, protocol etc. The basic unit of the timer is a free-run counter which is in fact a register whose numeric value increments by one in even intervals, so that by taking its value during periods T1 and T2 and on the basis of their difference we can determine how much time has elapsed.

1.2.6 Analog to Digital Converter

As the peripheral signals usually are substantially different from the ones that Microcontroller can understand (zero and one), they have to be converted into a pattern which can be comprehended by a microcontroller. This task is performed by a block for analog to digital conversion or by an ADC. This block is responsible for converting an information about some analog value to a binary number and for follow it through to a CPU block so that CPU block can further process it.

(21)

Figure 1.7: A/D converter

1.2.7 Serial communication

Beside stated above we've added to the already existing unit the possibility of communication with an outside world.

In telecommunications and computer science, serial communications is the process of sending data one bit at one time, sequentially, over a communications channel or computer bus. This is in contrast to parallel communications, where all the bits of each symbol are sent together. Serial communications is used for all long-haul communications and most computer networks, where the costs of cable and synchronization difficulties make parallel communications impractical. Serial computer buses are becoming more common as improved technology enables them to transfer data at higher speeds.

(22)

1.2.7.1 Universal Asynchronous Receiver/Transmitter (UART)

A Universal Asynchronous Receiver/Transmitter (UART) is used to implement serial communication [3]. It is a standard piece of hardware. The CPU communicates with the UART by reading or writing one of eight bytes called ports. A computer system normally has more than one UART, so the port addresses depend on the particular UART being accessed. Each UART is associated with a different base address, and a particular port is specified by adding a specific index to that base address. The index for a particular port is independent of the UART, so we can characterize the ports by indices 0 through 7. Some of the UART ports can only be read, others can only be written, and both accesses are possible on some. Even when both accesses are allowed, however, they may be unrelated. For example, the UART has a data-in buffer register and a data-out buffer register. A simplified block diagram for the UART circuit is shown in Figure 1.9

(23)

1.2.7.2 RS-232

In telecommunications, RS-232 (Recommended Standard 232) is a standard for serial binary data signals connecting between a DTE (Data terminal equipment) and a DCE (Data Circuit-terminating Equipment). It is commonly used in computer serial ports.

In RS-232, data is sent as a time-series of bits. Both synchronous and asynchronous transmissions are supported by the standard. In addition to the data circuits, the standard defines a number of control circuits used to manage the connection between the DTE and DCE. Each data or control circuit only operates in one direction that is, signaling from a DTE to the attached DCE or the reverse. Since transmit data and receive data are separate circuits, the interface can operate in a full duplex manner, supporting concurrent data flow in both directions. The standard does not define character framing within the data stream, or character encoding.

The RS-232 standard defines the voltage levels that correspond to logical one and logical zero levels. Valid signals are plus or minus 3 to 15 volts. The range near zero volts is not a valid RS-232 level; logic one is defined as a negative voltage, the signal condition is called marking, and has the functional significance of OFF. Logic zero is positive, the signal condition is spacing, and has the function ON. The standard specifies a maximum open-circuit voltage of 25 volts;

Because the voltage levels are higher than logic levels typically used by integrated circuits, special intervening driver circuits are required to translate logic levels. These also protect the device's internal circuitry from short circuits or transients that may appear on the RS-232 interface, and provide sufficient current to comply with the slew rate (how fast the signal changes between levels) requirements for data transmission.

The cable length mentioned in the standard allows maximum communication speed to occur. If speed is reduced by a factor 2 or 4, the maximum length increases dramatically. Texas Instruments has done some practical experiments years ago at different baud rates to test the maximum allowed cable lengths. Keep in mind, that the RS232 standard was

(24)

originally developed for 20 kbps. By halving the maximum communication speed, the allowed cable length increases a factor ten!

Table 1.1: RS232 cable length according to Texas Instruments

1.2.7.3 Universal Serial Bus (USB)

This section presents an overview of the Universal Serial Bus (USB) architecture and key concepts [4]. The USB is a cable bus that supports data exchange between a host computer and a wide range of simultaneously accessible peripherals. The attached peripherals share USB bandwidth through a host scheduled, token-based protocol. The bus allows peripherals to be attached, configured, used, and detached while the host and other peripherals are in operation. In the next chapter the USB interface will be introduced in details.

RS232 cable length according to Texas Instruments Baud rate Maximum cable length (ft)

19200 50 9600 500 4800 1000 2400 3000

(25)

CAPTER 2

Universal Serial Bus (USB)

fundamentals

2.1 Introduction

In 1996, the first commercial version of USB (USB 1.0) was released. It supported a maximum data rate of 1.5 Mbps. The second version, USB 1.1[5], was released in 1998 and supported a maximum data rate of 12 Mbps. The current version, USB 2.0 [6], was released in April 2000 and supports a maximum data rate of 480 Mbps. Most new computers and associated peripheral devices such as printers and scanners support USB

2.2 USB System Description

A USB system is described by three definitional areas: - USB interconnect

- USB devices - USB host.

2.2.1 USB interconnect

The USB interconnect is the manner in which USB devices are connected to and communicate with the host. This includes the following:

- Bus Topology: Connection model between USB devices and the host.

- Inter-layer Relationships: In terms of a capability stack, the USB tasks that are performed at each layer in the system.

- Data Flow Models: The manner in which data moves in the system over the USB between producers and consumers.

- USB Schedule: The USB provides a shared interconnect.

Access to interconnect is scheduled in order to support isochronous data transfers and to eliminate arbitration overhead. The USB connects USB devices with the USB host. The USB physical interconnect is a tiered star topology. A hub is at the center of each star. Each wire segment is a point-to-point connection between the host and a hub or function,

(26)

or a hub connected to another hub or function. Figure 2.1 illustrates the topology of the USB.

Figure 2.1: Bus Topology

2.2.2 USB Host

There is only one host in any USB system. The USB interface to the host computer system is referred to as the Host Controller. The Host Controller may be implemented in a combination of hardware, firmware, or software. A root hub is integrated within the host system to provide one or more attachment points.

2.2.3 USB Devices

USB devices are divided into device classes such as hub, locator, or text device. The hub device class indicates a specially designated USB device that provides additional USB attachment points. USB devices are required to carry information for self-identification and generic configuration. They are also required at all times to display behavior consistent with defined USB device states. Two major divisions of device classes exist: hubs and functions.

(27)

2.2.3.1 Hubs

Hubs are a key element in the plug-and-play architecture of the USB. Figure 2-2 shows a typical hub. Hubs serve to simplify USB connectivity from the user’s perspective and provide robustness at low cost and complexity.

Figure 2.2: A Typical Hub

2.2.3.2 Functions

A function is a USB device that is able to transmit or receive data or control information over the bus. A function is typically implemented as a separate peripheral device with a cable that plugs into a port on a hub. However, a physical package may implement multiple functions and an embedded hub with a single USB cable. This is known as a compound device. A compound device appears to the host as a hub with one or more non-removable USB devices.

Each function contains configuration information that describes its capabilities and resource requirements. Before a function can be used, it must be configured by the host. This configuration includes allocating USB bandwidth and selecting function-specific configuration options.

(28)

Examples of functions include the following:

- A locator device such as a mouse, tablet, or light pen

- An input device such as a keyboard

- An output device such as a printer

- A telephony adapter such as ISDN.

2.3 Physical Interface

The USB transfers signal and power over a four-wire cable, shown in Figure 2-3. The signaling occurs over two wires on each point-to-point segment.

There are three data rates: - Low speed 1.5 Mbps - Full speed 12 Mbps - High speed 480 Mbps

2.3.1 Signaling

The USB uses a differential output driver to drive the USB data signal onto the USB cable. The static output swing of the driver in its low state must be below VOL (max) of 0.3V with a 1.5kΩ load to 3.6V and in its high state must be above the VOH (min) of 2.8V with a 15kΩ load to ground. Full-speed drivers have more stringent requirements, the output swings between the differential high and low state must be well-balanced to minimize signal skew. Slew rate control on the driver is required to minimize the radiated noise and cross talk. The driver’s outputs must support three-state operation to achieve bi-directional half-duplex operation

(29)

2.3.2 Power

The USB supports a range of power sourcing and power consuming agents; these include the following:

- Root port hubs: Are directly attached to the USB Host Controller. Hub power is derived from the same source as the Host Controller. Systems that obtain operating power externally, either AC or DC must supply at least five unit loads to each port. Such ports are called high-power ports. Battery powered systems may supply either one or five unit loads. Ports that can supply only one unit load are termed low-power ports.

- Bus-powered hubs: Draw all of their power for any internal functions and downstream ports from VBUS on the hub’s upstream port. Bus-powered hubs may only draw up to one unit load upon power up, and five unit loads after configuration. The configuration power is split between allocations to the hub, any non-removable functions and the external ports. External ports in a bus-powered hub can supply only one unit load per port regardless of the current draw on the other ports of that hub. The hub must be able to supply this port current when the hub is in the Active or Suspend state.

- Self-powered hubs: Power for the internal functions and downstream ports does not come from VBUS. However, the USB interface of the hub may draw up to one unit load from its upstream VBUS to allow the interface to function when the remainder of the hub is powered down. Hubs that obtain operating power externally (from the USB) must supply five unit loads to each port. Battery-powered

Hubs may supply either one or five unit loads per port.

- Low-power bus-powered functions: All power to these devices comes from VBUS. They may draw no more than one unit load at any time.

(30)

- High-power bus-powered functions: All power to these devices comes from VBUS. They must draw no more than one unit load upon power-up and may draw up to five unit loads after being configured.

- Self-powered functions: May draw up to one unit load from VBUS to allow the USB interface to function when the remainder of the function is powered down. All other power comes from an external (to the USB) source.

2.3.3 USB Cable

The USB cable connectors were specifically designed with the power pins longer than the signal pins so that power would always be applied before signals. Two different connector types were defined, to ensure that illegal configurations could not be made. An “A”-type connector defines the downstream end of the cable, and a “B”-type connector defines the upstream

(31)

2.4 Protocol

The USB host handles most of the complexity of the USB protocol, which makes the peripherals design simple and low cost. Data flow can be from host to device and from device to host. This section will talk in details about the USB protocol [7]

2.4.1 Bit Ordering

Bits are sent out onto the bus Least-Significant Bit (LSb) first, followed by the next LSb, through to the Most-Significant Bit (MSb) last. In figures 2.5 to 2.12, packets are displayed such that both individual bits and fields are represented (in a left to right reading order) as they would move across the bus.

2.4.2 Packet Field Formats

Before learning the different types of packets used by the protocol, let us view the different fields in the packets:

2.4.2.1 SYNC Field

The SYNC field appears at the start of each packet. It appears on the bus as idle followed by "KJKJKJKK" (encoded in NRZI encoding).The SYNC (synchronization) field allows the receiving peripheral synchronize its internal clock to the incoming data. The following packets description will ignore this field (for simplicity) but we mustn't forget its existence.

2.4.2.2 Packet Identifier Field

A packet identifier (PID) immediately follows the SYNC field of every USB packet. A PID consists of a four-bit packet type field followed by a four-bit check field as shown in Figure 2.6. The PID indicates the type of packet and, by inference, the format of the packet and the type of error detection applied to the packet. The four-bit check field of the PID ensures reliable decoding of the PID so that the remainder of the packet is interpreted correctly. The PID check field is generated by performing a one’s complement of the packet type field. A PID error exists if the four PID check bits are not complements of their respective packet identifier bits.

(32)

Figure 2.5: PID Format

The host and all functions must perform a complete decoding of all received PID fields. Any PID received with a failed check field or which decodes to a non-defined value is assumed to be corrupted and it, as well as the remainder of the packet, is ignored by the packet receiver. If a function receives an otherwise valid PID for a transaction type or direction that it does not support, the function must not respond. For example, an IN-only endpoint must ignore an OUT token.

2.4.2.3 Address Fields

Function endpoints are addressed using two fields: the function address field and the endpoint field. A function needs to fully decode both address and endpoint fields. Address or endpoint aliasing is not permitted, and a mismatch on either field must cause the token to be ignored. Accesses to non-initialized endpoints will also cause the token to be ignored.

2.4.2.3.1 Address Field

The function address (ADDR) field specifies the function, via its address, that is either the source or destination of a data packet, depending on the value of the token PID. As shown in Figure 2.6, a total of 128 addresses are specified as ADDR<6:0>. The ADDR field is specified for IN, SETUP, and OUT tokens. By definition, each ADDR value defines a single function. Upon reset and power-up, a function’s address defaults to a value of zero and must be programmed by the host during the enumeration process.

(33)

Function address zero is reserved as the default address and may not be assigned to any other use.

Figure 2.6: ADDR Field

2.4.2.3.2 Endpoint Field

An additional four-bit endpoint (ENDP) field, shown in Figure 2.7 permits more flexible addressing of functions in which more than one endpoint is required. Except for endpoint address zero, endpoint numbers are function-specific. The endpoint field is defined for IN, SETUP, and OUT token PIDs only.

All functions must support a control pipe at endpoint number zero (the Default Control Pipe). Low-speed devices support a maximum of three pipes per function: a control pipe at endpoint number zero plus two additional pipes (either two control pipes, a control pipe and a interrupt endpoint, or two interrupt endpoints). Full-speed functions may support up to the maximum of 16 endpoint numbers of any type.

(34)

2.4.2.4 Frame Number Field

The frame number field is an 11-bit field that is incremented by the host on a per-frame basis. The frame number field rolls over upon reaching its maximum value of 7FFH, and is sent only in SOF tokens at the start of each frame.

2.4.2.5 Data Field

The data field may range from zero to 1,023 bytes and must be an integral number of bytes. Figure 2.8 shows the format for multiple bytes. Data bits within each byte are shifted out LSb first.

Figure 2.8: Data Field Format

2.4.3 Packet Formats

2.4.3.1 Token Packets

Figure 2.9 shows the field formats for a token packet. A token consists of a PID, specifying either IN, OUT, or SETUP packet type; and ADDR and ENDP fields. For OUT and SETUP transactions, the address and endpoint fields uniquely identify the endpoint that will receive the subsequent Data packet. For IN transactions, these fields uniquely identify which endpoint should transmit a Data packet. Only the host can issue token packets. IN PIDs define a Data transaction from a function to the host OUT and SETUP PIDs define Data transactions from the host to a function.

(35)

Figure 2.9: Token Format

Token packets have a five-bit CRC that covers the address and endpoint fields as shown above. The CRC does not cover the PID, which has its own check field. Token and SOF packets are delimited by an EOP after three bytes of packet field data. If a packet decodes as an otherwise valid token or SOF but does not terminate with an EOP after three bytes, it must be considered invalid and ignored by the receiver.

2.4.3.2 Start-of-Frame Packets

Start-of-Frame (SOF) packets are issued by the host at a nominal rate of once every 1.00ms _0.0005ms. SOF packets consist of a PID indicating packet type followed by an 11-bit frame number field as illustrated in Figure 2-10.

Figure 2.10: SOF Packet

The SOF token comprises the token-only transaction that distributes an SOF marker and accompanying frame number at precisely timed intervals corresponding to the start of each frame. All full-speed functions, including hubs, receive the SOF packet. The SOF token does not cause any receiving function to generate a return packet; therefore, SOF delivery

(36)

to any given function cannot be guaranteed. The SOF packet delivers two pieces of timing information. A function is informed that an SOF has occurred when it detects the SOF PID. Frame timing sensitive functions, which do not need to keep track of frame number (e.g., a hub), need only decode the SOF PID; they can ignore the frame number and its CRC. If a function needs to track frame number, it must comprehend both the PID and the time stamp. Full-speed devices that have no particular need for bus timing information may ignore the SOF packet.

2.4.3.3 Data Packets

A data packet consists of a PID, a data field containing zero or more bytes of data, and a CRC as shown in Figure 2-11. There are two types of data packets, identified by differing PIDs: DATA0 and DATA1. Two data packet PIDs are defined to support data toggle synchronization

Figure 2.11: Data Packet Format

Data must always be sent in integral numbers of bytes. The data CRC is computed over only the data field in the packet and does not include the PID, which has its own check field.

2.4.3.4 Handshake Packets

Handshake packets, as shown in Figure 2-12, consist of only a PID. Handshake packets are used to report the status of a data transaction and can return values indicating successful reception of data, command acceptance or rejection, flow control, and halt conditions. Only transaction types that support flow control can return handshakes. Handshakes are always returned in the handshake phase of a transaction and may be returned, instead of data, in the data phase. Handshake packets are delimited by an EOP after one byte of packet field. If a

(37)

packet decodes as an otherwise valid handshake but does not terminate with an EOP after one byte, it must be considered invalid and ignored by the receiver.

Figure 2.12 Handshake Packet

There are three types of handshake packets:

ACK indicates that the data packet was received without bit stuff or CRC errors over the data field and that the data PID was received correctly. ACK may be issued either when sequence bits match and the receiver can accept data or when sequence bits mismatch and the sender and receiver must resynchronize to each other. An ACK handshake is applicable only in transactions in which data has been transmitted and where a handshake is expected. ACK can be returned by the host for IN transactions and by a function for OUT or SETUP transactions.

NAK indicates that a function was unable to accept data from the host (OUT) or that a function has no data to transmit to the host (IN). NAK can only be returned by functions in the data phase of IN transactions or the handshake phase of OUT transactions. The host can never issue NAK. NAK is used for flow control purposes to indicate that a function is temporarily unable to transmit or receive data, but will eventually be able to do so without need of host intervention.

STALL is returned by a function in response to an IN token or after the data phase of an OUT transaction STALL indicates that a function is unable to transmit or receive data, or that a control pipe request is not supported. The host is not permitted to return a STALL under any condition.

(38)

2.4.4 Data Flow Types

The USB supports functional data and control exchange between the USB host and a USB device as a set of either unidirectional or bidirectional pipes. USB data transfers take place between host software and a particular endpoint on a USB device. Such associations between the host software and a USB device endpoint are called pipes. In general, data movement though one pipe is independent from the data flow in any other pipe. A given USB device may have many pipes. As an example, a given USB device could have an endpoint that supports a pipe for transporting data to the USB device and another endpoint that supports a pipe for transporting data from the USB device.

2.4.5 Transfer Types

The USB transports data through a pipe between a memory buffer associated with a software client on the host and an endpoint on the USB device. Data transported by message pipes is carried in a USB-defined structure, but the USB allows device-specific structured data to be transported within the USB-defined message data payload. The USB also defines that data moved over the bus is pocketsize for any pipe (stream or message), but ultimately the formatting and interpretation of the data transported in the data payload of a bus transaction is the responsibility of the client software and function using the pipe.

However, the USB provides different transfer types that are optimized to more closely match the service requirements of the client software and function using the pipe. An IRP uses one or more bus transactions to move information between a software client and its function.

The designers of a USB device choose the capabilities for the device’s endpoints. When a pipe is established for an endpoint, most of the pipe’s transfer characteristics are determined and remain fixed for the lifetime of the pipe. Transfer characteristics that can be modified are described for each transfer type.

(39)

The USB defines four transfer types:

- Control Transfers: non-periodic, host software-initiated request/response communication typically used for command/status operations.

- Isochronous Transfers: Periodic, continuous communication between host and device typically used for time-relevant information. This transfer type also preserves the concept of time encapsulated in the data. This does not imply, however, that the delivery need of such data is always time-critical.

- Interrupt Transfers: Small-data, low-frequency, bounded-latency communication.

- Bulk Transfers: Non-periodic, large-packet bursty communication, typically used for data that can use any available bandwidth and can also be delayed until bandwidth is available.

2.4.5.1 Control Transfers

Control transfers allow access to different parts of a device. Control transfers are intended to support configuration/command/status type communication flows between client software and its function. A control transfer is composed of a Setup bus transaction moving request information from host to function, zero or more Data transactions sending data in the direction indicated by the Setup transaction, and a Status transaction returning status information from function to host. The Status transaction returns “success” when the endpoint has successfully completed processing the requested operation.

2.4.5.2 Isochronous Transfers

In non-USB environments, isochronous transfers have the general implication of constant-rate, error tolerant transfers. In the USB environment, requesting an isochronous transfer type provides the requester with the following:

- Guaranteed access to USB bandwidth with bounded latency

- Guaranteed constant data rate through the pipe as long as data is provided to the pipe

(40)

- In the case of a delivery failure due to error, no retrying of the attempt to deliver the data.

While the USB isochronous transfer type is designed to support isochronous sources and destinations, it is not required that software using this transfer type actually be isochronous in order to use the transfer type.

2.4.5.3 Interrupt Transfers

The interrupt transfer type is designed to support those devices that need to send or receive small amounts of data infrequently, but with bounded service periods. Requesting a pipe with an interrupt transfer type provides the requester with the following:

- Guaranteed maximum service period for the pipe

- Retry of transfer attempts at the next period, in the case of occasional delivery failure due to error on the bus.

2.4.5.4 Bulk Transfers

The bulk transfer type is designed to support devices that need to communicate relatively large amounts of data at highly variable times where the transfer can use any available bandwidth. Requesting a pipe with a bulk transfer type provides the requester with the following:

- Access to the USB on a bandwidth-available basis

- Retry of transfers, in the case of occasional delivery failure due to errors on the bus

- Guaranteed delivery of data, but no guarantee of bandwidth or latency.

Bulk transfers occur only on a bandwidth-available basis. For a USB with large amounts of free bandwidth, bulk transfers may happen relatively quickly; for a USB with little bandwidth available, bulk transfers may trickle out over a relatively long period of time.

(41)

CAPTER 3

Implementation of Microcontroller core in FPGA

3.1 Introduction

The circuit designers of systems containing Microcontroller have tow choice to impalement their system. These two choices are:

1- Using off-shelf Microcontroller chips available in the market. In this case they have to spend some time in searching the configuration that is closely meets their requirements.

2- Build exactly the optimized configuration that impalement their system using FPGA. This solution is some times cost effective, secure, more resistant to reverse engineering and flexible if the designer has good knowledge of VHDL programming rather than assembly language typically needed for off-shelf m-controllers. A comparison table showing advantage and disadvantages of the above two choices is given in table 3-1 [26]

Points of Comparison Using Hard wired off-shelf Using FPGA Cost Cost effective for small scale

production

Cost effective for mass production Power consumption Fixed as the circuit is hard

wired

Can be optimized

Resistance for reverse engineering Can be cracked Very high resistive Hardware skills needed for testing

prototype

Needs high skills Needs Less skills

Availability of Software tools Highly Available Highly Available Needs of adding additional digital

circuits

Added on board Added on chip

Needs of adding additional analog circuits

May be on chip according to configuration

(42)

Table 3.1 Comparison between hard wired and FPGA implementation of Microcontroller

In this work, the Microcontroller will be implemented using FPGA technology to support serial data communication through USB interface.

A survey for some available Microcontroller cores had been done. Some free cores provided by some educational or industrial companies were found, one of the famous cores is the core prepared by the University of California under the name of Dalton Project .

Another one is the Microcontroller core designed for Xilinx FPGA’s families is PicoBlaze which written by Ken Chapman Senior Staff Engineer -Spartan FPGA Applications Specialist in Xilinx. The above two cores will be considered in some details in the following sections.

3.2 Synthesizable VHDL Model of 8051 (Dalton project)

The Intel 8051 is an 8-bit micro-controller. This micro-controller is capable of addressing 64K of program memory and 64K of data memory. The implementation below is written in Synthesizable VHDL and models the actual Intel implementation.

3.2.1 Block Diagram.

Figure 3.1 gives a block diagram for the 8051 model, where we can identify the following blocks:

Block Description

8051_alu Model of an ALU that performs 8051 specific arithmetic.

8051_dec Model of a decoder that decodes the non-uniform 8051 instructions into uniform _{representations.} 8051_ram Model of 128 bytes of RAM, specific to 8051, e.g., bit-addressable. This model _{is described behaviorally as a sequential logic block.} 8051_rom Model of up to 64K bytes of ROM, specific to 8051.

8051_ctr Model of the core 8051 processor. This model is described behaviorally as a _{sequential logic block.} 8051_dbg This entity is there for debugging only. Currently, it outputs a trace of each

(43)

Table 3.2: 8051 model blocks description

Each one of these blocks is already build and available as a VHDL code. The designer has to verify the connectivity of these blocks to implement an 8051 core. Verification procedure is given below.

Figure 3.1: Block Diagram of 8051 model

3.2.2 Verification Procedure of the 8051 model

1-A simple test program in Assembly language is needed. It is written either directly in Assembly or may be written in C language if the designer is not familiar with the assembly language. Different compilers are available to change C programs into Assembly instructions [8].The following testing C code written to verify the computability of this code to 8051 instructions

(44)

/*---*/ #include <reg51.h> #include <math.h> /*---*/ Void main () { float x = 3.0; float y = 4.0;

float xx, yy, xx_yy, sqrt_xx_yy; xx = x * x; yy = y * y; xx_yy = xx + yy; sqrt_xx_yy = sqrt(xx_yy); P3 = (unsigned char)sqrt_xx_yy while(1); }

2- KEIL compiler [8] was used to Compile C file into Intel hex format

3- To Convert hex file into a VHDL ROM model we have used the written C program with the source codes of the project but one problem appears here : this program works under Unix operating system ,so user must spent some times in learning Linux commands. A proposed solution is to use a Linux-like environment for Windows called Cygwin [9] 4- Using Cygwin with any windows operating systems, the VHDL ROM model for this program is then obtained.

5- Finally the project was simulated using ALDEC tool V 6.3 [10].The simulation results obtained are correctly confirmed as shown in Figure 3.2.

(45)

Figure 3.2: Simulation result of testing 8051 model

3.3 PicoBlaze core for Microcontroller 3.3.1 Introduction

There are literally dozens of 8-bit Microcontroller architectures and instruction sets. one Modern FPGAs can efficiently implement practically any 8-bit microcontroller, and available FPGA soft cores support popular instruction sets such as the PIC, 8051, AVR, 6502 microcontrollers and 8080, and Z80 Microprocessors.. One of the available free cores for an 8-bits Microcontroller is the PicoBlaze Microcontroller core [11]. It is a compact, capable, and cost-effective fully embedded 8-bit RISC Microcontroller optimized for the Spartan-3, Virtex-II, and Virtex-II Pro FPGA families [11].The PicoBlaze Microcontroller core provides cost-efficient Microcontroller-based control and simple data processing.

(46)

The PicoBlaze Microcontroller can provide the following advantages and facilities:

1- It is optimized for efficiency and low deployment cost. It occupies just 96 FPGA slices, or only 12.5% of an XC3S50 FPGA and a miniscule 0.3% of an XC3S5000 FPGA. In typical implementations, a single FPGA block RAM stores up to 1024 program instructions, which are automatically loaded during FPGA configuration. Even with such resource efficiency, the PicoBlaze Microcontroller performs a respectable 44 to 100 million instructions per second (MIPS) depending on the target FPGA family and speed grade.

2- Its core is totally embedded within the target FPGA and requires no external resources. The PicoBlaze Microcontroller is extremely flexible. The basic functionality is easily extended and enhanced by connecting additional FPGA logic to the microcontroller’s input and output ports.

3- As a microcontroller, it provides abundant, flexible I/O at much lower cost than off-the-shelf controllers. Similarly, the PicoBlaze peripheral set can be customized to meet the specific features, function, and cost requirements of the target application. Because the PicoBlaze Microcontroller is delivered as synthesizable VHDL source code, the core is future-proof and can be migrated to future FPGA architectures, effectively eliminating product obsolescence fears. Being integrated within the FPGA, the PicoBlaze Microcontroller reduces board space, design cost, and inventory.

4- It reduces system cost because it is a single-chip solution, integrated within the FPGA and sometimes only occupying leftover FPGA resources.

5- The PicoBlaze Microcontroller is resource efficient. Consequently, complex applications are sometimes best portioned across multiple PicoBlaze microcontrollers with each controller implementing a particular function, for example, keyboard and display control, or system management.

(47)

3.3.2 PicoBlaze Microcontroller Features

Figure 3.3: Block Diagram of PicoBlaze

As shown in the block diagram in Figure 3-3, the PicoBlaze Microcontroller supports the following features:

• 16 byte-wide general-purpose data registers

• 1K instructions of programmable on-chip program store, automatically loaded during FPGA configuration

• Byte-wide Arithmetic Logic Unit (ALU) with CARRY and ZERO indicator flags • 64-byte internal scratchpad RAM

• 256 input and 256 output ports for easy expansion and enhancement • Automatic 31-location CALL/RETURN stack

• Predictable performance, always two clock cycles per instruction, up to 200 MHz or 100 MIPS in a Virtex-II Pro FPGA

• Fast interrupt response; worst-case 5 clock cycles

• Optimized for Xilinx Spartan-3, Virtex-II, and Virtex-II Pro FPGA architectures—just 96 slices and 0.5 to 1 block RAM

(48)

3.3.3 PicoBlaze Microcontroller Functional Blocks

3.3.3.1 General-Purpose Registers

The PicoBlaze Microcontroller includes 16 byte-wide general-purpose registers, designated as registers s0 through sF. For better program clarity, registers can be renamed using an assembler directive. All register operations are completely interchangeable; no registers are reserved for special tasks or have priority over any other register. There is no dedicated accumulator; each result is computed in a specified register.

3.3.3.2 (1,024)-Instruction Program Store

The PicoBlaze Microcontroller executes up to 1,024 instructions from memory within the FPGA, typically from a single block RAM. Each PicoBlaze instruction is 18 bits wide. The instructions are compiled within the FPGA design and automatically loaded during the configuration process

3.3.3.3 Arithmetic Logic Unit (ALU)

The byte-wide Arithmetic Logic Unit (ALU) performs all Microcontroller calculations, including:

• Basic arithmetic operations such as addition and subtraction • Bitwise logic operations such as AND, OR, and XOR • Arithmetic compare and bitwise test operations • Comprehensive shift and rotate operations

All operations are performed using an operand provided by any specified register (sX).

The result is returned to the same specified register (sX). If an instruction requires a second operand, then the second operand is either a second register (sY) or an 8-bit immediate constant (kk).

(49)

3.3.3.4 Flags

ALU operations affect the ZERO and CARRY flags. The ZERO flag indicates when the result of the last operation resulted in zero. The CARRY flag indicates various conditions, depending on the last instruction executed.

The INTERRUPT_ENABLE flag enables the INTERRUPT input.

3.3.3.5 (64)-Byte Scratchpad RAM

The PicoBlaze Microcontroller provides an internal general-purpose 64-byte scratchpad RAM, directly or indirectly addressable from the register file using the STORE and FETCH instructions.

The STORE instruction writes the contents of any of the 16 registers to any of the 64 RAM locations. The complementary FETCH instruction reads any of the 64 memory locations into any of the 16 registers. This allows a much greater number of variables to be held within the boundary of the processor and tends to reserve all of the I/O space for real inputs and output signals.

The six-bit scratchpad RAM address is specified either directly (ss) with an immediate constant, or indirectly using the contents of any of the 16 registers (sY). Only the lower six bits of the address are used; the address should not exceed the 00 - 3F range of the available memory.

3.3.3.6 Input/Output

The Input/Output ports extend the PicoBlaze microcontroller’s capabilities and allow the Microcontroller to connect to a custom peripheral set or to other FPGA logic. The PicoBlaze Microcontroller supports up to 256 input ports and 256 output ports or a combination of input/output ports. The PORT_ID output provides the port address. During an INPUT operation, the PicoBlaze Microcontroller reads data from the IN_PORT port to a specified register, sX. During an OUTPUT operation, the PicoBlaze Microcontroller writes the contents of a specified register, sX, to the OUT_PORT port.

(50)

3.3.3.7 Program Counter (PC)

The Program Counter (PC) points to the next instruction to be executed. By default, the PC automatically increments to the next instruction location when executing an instruction. Only the JUMP, CALL, RETURN, and RETURNI instructions and the Interrupt and Reset Events modify the default behavior. The PC cannot be directly modified by the application code; computed jump instructions are not supported.

The 10-bit PC supports a maximum code space of 1,024 instructions (000 to 3FF hex). If the PC reaches the top of the memory at 3FF hex, it rolls over to location 000.

3.3.3.8 Program Flow Control

The default execution sequence of the program can be modified using conditional and non-conditional program flow control instructions.

The JUMP instructions specify an absolute address anywhere in the 1,024-instruction Program space.

CALL and RETURN instructions provide subroutine facilities for commonly used sections of code. A CALL instruction specifies the absolute start address of a subroutine, while the return address is automatically preserved on the CALL/RETURN stack.

If the interrupt input is enabled, an Interrupt Event also preserves the address of the preempted instruction on the CALL/RETURN stack while the PC is loaded with the interrupt vector, 3FF hex. Use the RETURNI instruction instead of the RETURN instruction to return from the interrupt service routine (ISR).

3.3.3.9 CALL/RETURN Stack

The CALL/RETURN hardware stack stores up to 31 instruction addresses, Enabling nested CALL sequences up to 31 levels deep. Since the stack is also used during an interrupt operation, at least one of these levels should be reserved when interrupts are enabled.

The stack is implemented as a separate cyclic buffer. When the stack is full, it overwrites the oldest value. Consequently, there are no instructions to control the stack or the stack pointer. No program memory is required for the stack.

(51)

3.3.3.10 Interrupts

The PicoBlaze Microcontroller has an optional INTERRUPT input, allowing the PicoBlaze Microcontroller to handle asynchronous external events. In this context, “asynchronous” relates to interrupts occurring at any time during an instruction cycle. However, recommended design practice is to synchronize all inputs to the PicoBlaze controller using the clock input.

The PicoBlaze Microcontroller responds to interrupts quickly in just five clock cycles.

3.3.3.11 Reset

The PicoBlaze Microcontroller is automatically reset immediately after the FPGA configuration process completes. After configuration, the RESET input forces the processor into the initial state. The PC is reset to address 0, the flags are cleared, interrupts are disabled, and the CALL/RETURN stack is reset.

3.3.5 Verification of PicoBlaze code

In order to work with the PicoBlaze core, two codes have to be developed.

1- Assembly code (these is a special assembly instructions designed for the PicoBlaze) and represents the program structure for solving a given physical or mathematical problem. The assembler of this Microcontroller is used to change this code into ROM VHDL code.

2- The second code is the top level code to connect the ROM to the Microcontroller and assign IN, OUT ports

A simple example is given below for a chosen simple physical problem. This problem is a simple continuous status checking of 8 switches, and takes an action according to their status. This check is commonly needed by an imbedded system and may be considered as a basic subroutine. The action taken by the program was to turn a LED ON or OFF following the status of the assigned switch. The input /output relation for this program is: LED N =

ON if Switch N = ON .

(52)

Where 0 ≤ N<8

For this Example as mentioned above an assembly program need to be written to read switches value and update LEDs in continues loop as following

--- CONSTANT sws_port, 02 ; Read switches on this port

CONSTANT leds_port, 08 ; Update LEDs at this port

;--- - Loop reading Switches from the board and display it in board LED's start: INPUT s0, sws_port

OUTPUT s0,leds_port JUMP start

---

And also a VHDL code (see appendix B) was written as top level where it contains the following parts

1- Declaration of KCPSM3

It is the PicoBlaze Microcontroller core 2- Declaration of program ROM

This ROM will contain the converted Assembly program in step one of the verification process

3- Signals used to connect KCPSM3 to program ROM and I/O logic To connect above Elements to the design

5- KCPSM3 input/output ports

To define a process to read and write Data of the Switches and LEDs from the mentioned port ID

Figure 3.4 gives the simulation verifications of table 3-2 for the VHDL code using Aldec 6.1 tool.

(53)

Figure 3.4: Simulation result of PicoBlaze

Experimental verification had been also done and will be presented in the next chapter. As a conclusion of this chapter the PicoBlaze Microcontroller may be used to impalement our circuit since it has many advantages mentioned above and it is suitable for using with Xilinx FPGA