I

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

April, 2008

II

Arabic abstract

ملخص الرسالة

يعتبر المتحكم الدقيق من الدوائر األساسية لبناء األنظمة المتضمنة وهى أنظمة تعتمد على الحاسب آوحدة

وعلى عكس وظيفة الحاسوب اآللي الذي يقوم بوظائف عامة فإن . بنائية ويتم ضمها داخل منظومة ما

تصميم البنية الداخلية لمتحكم دقيق بحيث تلبى وعادة يتم. األنظمة المتضمنة يكون لها وظائف سابقة التحديد

ويمكن . احتياجات سابقة التحديد من قبل المستخدم بحيث تفي بأغراض المنظومة الكلية التي تتضمنها

أو يمكنه تصميم وحدة خاصة . قللمصمم اختيار المتحكم الدقيق من مئات الدوائر القياسية المتاحة باألسوا

. المتاحة حاليا من العديد من الشرآات“ لى رقيقة سليكون نظام ع" باستخدام تقنيات

ومن التقنيات الواعدة المستخدمة في بناء أألنظمة تامة األتمتة تقنية اتصال آله بآله أو اتصال آله بإنسان

حيث يمكن من خالل هذه ةويقوم المتحكم الدقيق بدور العقل المدبر لهذه أألنظم. باستخدام شبكة الجوال

ونظرا لتوفر شبكات الجوال وآفاءتها فى نقل . نية نقل البيانات بين آله وأخرى أو أله وإنسان أو العكسالتق

زد –البيانات الرقمية بدون تكلفة عملية فقد وفرت العديد من شرآات الجوال مثل اريكسون و نوآيا وعالم

وعادة ما يتم استخدام دائرة . مجالفي األسواق عدة وحدات لتطوير نماذج أولية لبعض التطبيقات في هذا ال

بين جهاز الجوال الذي يعمل آمرسل و مستقبل ل لالتصاRS232المواجهة المتوالية القياسية من نوع

. للبيانات وبين دائرة التطبيقات التي تحتوى على المتحكم الدقيق والمتصل باآللة

فى معظم األجهزة أآلن لتفوقها على دائرة ) USB(ونظرا لشيوع استخدام دائرة مواجهة متوالية جامعة

فإن تزويد دائرة المتحكم الدقيق بدائرة دائرة المواجهة RS232المواجهة المتوالية القياسية من نوع

سوف يحسن من أداء أنظمة ألتحكم عموما وأنظمة التحكم على شبكة USBالمتوالية الجامعة من نوع

. الجوال على وجه الخصوص

( ألساسي من هذا البحث هو اقتراح وتصميم دائرة متحكم دقيق تحتوى على دائرة مواجهة جامعة الهدف ا

USB ( ويلبى التصميم احتياجات التطوير الواجب توافرها في وحدات التصميم للنماذج األولية لتطبيقات

آما . المحلية و العالمية أنظمة اتصال آله بآله أو اتصال آله بإنسان أو العكس وذلك باستخدام شبكة الجوال

سيساعد البحث أيضا في دراسة وتعلم وممارسة التصميم باستخدام تقنيات و أدوات التصميم الحديثة لألنظمة

. اإللكترونية الرقمية وذلك من خالل محاآاة و نمذجة وتنفيذ الدائرة المقترحة للمتحكم الدقيق

III

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.

IV

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

V

Table of Contents Arabic abstract .......................................................................................................................II

abstract ................................................................................................................................. III

Aknologment........................................................................................................................ IV

Table of Contents.................................................................................................................. V

List of Figures ...................................................................................................................... IX

List of Tables ....................................................................................................................... XI

Abbreviation .......................................................................................................................XII

INTRODUCTION ................................................................................................................. 1

M2M Overview .............................................................................................................. 1

M2M and Microcontroller .............................................................................................. 1

Where the M2M technology can be used?...................................................................... 1

M2M networks................................................................................................................ 2

M2M kits manufactures .................................................................................................. 2

CHAPTER 1 Microcontroller architecture ............................................................................ 3

1.1 Introduction............................................................................................................... 3

1.2 Basic components in Microcontroller....................................................................... 3

1.2.1 Memory unit.................................................................................................... 4

1.2.2 Central Processing Unit .................................................................................. 5

1.2.3 Bus .................................................................................................................. 6

1.2.4 Input-output unit ............................................................................................. 7

1.2.5 Timer unit........................................................................................................ 8

1.2.6 Analog to Digital Converter............................................................................ 8

1.2.7 Serial communication ..................................................................................... 9

1.2.7.1 Universal Asynchronous Receiver/Transmitter (UART) ................. 10

1.2.7.2 RS-232 .............................................................................................. 11

1.2.7.3 Universal Serial Bus (USB) .............................................................. 12

CHAPTER 2 Universal Serial Bus (USB) Fundamentals .................................................. 13

2.1 Introduction............................................................................................................. 13

VI

2.2 USB System Description ........................................................................................ 13

2.2.1 USB interconnect ........................................................................................... 13

2.2.2 USB Host ....................................................................................................... 14

2.2.3 USB Devices.................................................................................................. 14

2.2.3.1 Hubs ................................................................................................... 15

2.2.3.2 Functions............................................................................................ 15

2.3 Physical Interface.................................................................................................... 16

2.3.1 Signaling ........................................................................................................ 16

2.3.2 Power ............................................................................................................. 17

2.3.3 USB Cable ..................................................................................................... 18

2.4 Protocol ................................................................................................................... 19

2.4.1 Bit Ordering ................................................................................................... 19

2.4.2 Packet Field Formats...................................................................................... 19

2.4.2.1 SYNC Field........................................................................................ 19

2.4.2.2 Packet Identifier Field........................................................................ 19

2.4.2.3 Address Fields.................................................................................... 20

2.4.2.3.1 Address Field ...................................................................... 20

2.4.2.3.2 Endpoint Field..................................................................... 21

2.4.2.4 Frame Number Field .......................................................................... 22

2.4.2.5 Data Field........................................................................................... 22

2.4.3 Packet Formats............................................................................................... 22

2.4.3.1 Token Packets .................................................................................... 22

2.4.3.2 Start-of-Frame Packets....................................................................... 23

2.4.3.3 Data Packets....................................................................................... 24

2.4.3.4 Handshake Packets............................................................................. 24

2.4.4 Data Flow Types ............................................................................................ 26

2.4.5 Transfer Types ............................................................................................... 26

2.4.5.1 Control Transfers ............................................................................... 27

2.4.5.2 Isochronous Transfers........................................................................ 27

2.4.5.3 Interrupt Transfers ............................................................................. 28

2.4.5.4 Bulk Transfers.................................................................................... 28

VII

CHAPTER 3 Implementation of Microcontroller core in FPGA ........................................ 29

3.1 Introduction............................................................................................................. 30

3.2 Synthesizable VHDL Model of 8051 (Dalton project)........................................... 30

3.2.1 Block Diagram. .............................................................................................. 30

3.2.2 Verification Procedure of the 8051 model .................................................. 31

3.3 PicoBlaze core for Microcontroller ........................................................................ 33

3.3.1 Introduction.................................................................................................... 33

3.3.2 PicoBlaze Microcontroller Features .............................................................. 35

3.3.3 PicoBlaze Microcontroller Functional Blocks............................................... 36

3.3.3.1 General-Purpose Registers................................................................. 36

3.3.3.2 (1,024)-Instruction Program Store ..................................................... 36

3.3.3.3 Arithmetic Logic Unit (ALU)............................................................ 36

3.3.3.4 Flags................................................................................................... 37

3.3.3.5 (64)-Byte Scratchpad RAM ............................................................... 37

3.3.3.6 Input/Output....................................................................................... 37

3.3.3.7 Program Counter (PC) ....................................................................... 38

3.3.3.8 Program Flow Control ....................................................................... 38

3.3.3.9 CALL/RETURN Stack ...................................................................... 38

3.3.3.10 Interrupts .......................................................................................... 39

3.3.3.11 Reset................................................................................................. 39

3.3.4 Verification of PicoBlaze code ...................................................................... 39

CHAPTER 4 Microcontroller with USB interface .............................................................. 42

4.1 Introduction............................................................................................................. 42

4.2 Implementation of USB .......................................................................................... 42

4.2.1 USB Cores for FPGA.................................................................................... 42

4.2.1.1 Physical Layer...................................................................................... 43

4.2.1.2 Protocol layer ....................................................................................... 43

4.2.2 Serial Interfacing to Microcontroller ............................................................ 44

4.2.3 Parallel Interfacing to Microcontroller controller......................................... 45

4.3 Hardware verification of Microcontroller Core with USB interface ...................... 46

VIII

4.4 Experimental Work................................................................................................. 47

4.4.1 Hardware verification of PicoBlaze testing code........................................... 47

4.4.2 Integrating the FPGA board (NEXYSII) with (FT245R) USB Chip ............ 48

4.4.3 Assembly and VHDL codes for Microcontroller with USB.......................... 49

4.4.3.1 PicoBlaze assembly program for Microcontroller with USB.............. 49

4.4.3.2 VHDL code for testing Microcontroller with USB interface .............. 53

4.4.4 Testing the overall circuit .............................................................................. 57

CHAPTER 5 GSM module with USB................................................................................. 60

5.1 Introduction............................................................................................................. 60

5.2 Hardware of the GSM Module with USB............................................................... 60

5.3 VHDL code of the GSM Module with USB .......................................................... 61

5.3.1 UART Implementation Using FPGA............................................................. 61

5.3.1.1 Start bit................................................................................................. 61

5.3.1.2 Data bits ............................................................................................... 62

5.3.1.3 Parity bit............................................................................................... 62

5.3.1.4 Stop bits ............................................................................................... 62

5.4 Assembly code of the GSM Module with USB .................................................... 63

5.5 Testing the overall circuit ....................................................................................... 63

Conclusion ........................................................................................................................... 65

Future work.......................................................................................................................... 66

Referances ........................................................................................................................... 67

Appendix A: Sony Ericsson GM47/GM48.......................................................................... 69

Appendix B: VHDL Top level code for Verification of PicoBlaze code ........................... 88

Appendix C: FT245R (Parallel to USB chip data sheet) ..................................................... 92

Appendix D: Digilent NEXYS II Board schematic........................................................... 104

Appendix E: PicoBlaze assembly program for Microcontroller with USB....................... 116

Appendix F: VHDL code for testing Microcontroller with USB interface ...................... 125

Appendix G: PicoBlaze assembly program for GSM Module with USB ......................... 131

Appendix H: VHDL code for GSM Module with USB ................................................... 136

Appendix I: PicoBlaze Instruction Set .............................................................................. 144

Appendix J: PicoBlaze VHDL code ................................................................................ 149

IX

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

Figure 4.3 :NEXYSII board................................................................................................. 46

X

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

Figure 5.3: Final System working ....................................................................................... 64

XI

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

XII

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 WWAN Wireless Wide Area Network

1

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?

There are many fields that M2M can be used such as:

2

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

Figure I: Sony Ericsson GM47/GM48 module

3

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.1 Introduction

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]

Basic components of Microcontroller can be seen in figure 1.1

4

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.

5

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.

6

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

7

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.

Figure 1.5: Microcontroller Ports

8

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.

9

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.

Figure 1.8: Serial communication block in Microcontroller

10

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

Figure 1.9: UART block diagram

11

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

12

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

13

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,

14

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.

15

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.

16

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

Figure 2.3: USB cable

17

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.

18

- 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

Figure 2.4: USB cable connector types

19

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.

20

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.

21

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.

Figure 2.7: Endpoint Field

22

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.

23

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

24

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

25

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.

26

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.

27

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

28

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

29

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

Added on board

30

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 instruction that is executed.

31

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

32

/*-------------------------------------------------------------------*/

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

33

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.

34

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.

See appendix I for a complete instruction set for PicoBlaze.

35

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

• Assembler, instruction-set simulator support

36

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

37

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.

38

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.

39

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 .

LED N = OFF if Switch N = OFF .

40

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.

41

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

42

Chapter 4

Microcontroller with USB interface

4.1 Introduction

This chapter will discuss the most common available approaches to implement USB

interface this may lead us to choose one of them to be interfaced with the PicoBlaze core

selected in previous chapter.

4.2 Implementation of USB

The proposed solution to establish serial communication using USB protocol is to design a

circuit that can handle this communication protocol and interfaced it to the Microcontroller.

By looking for a suitable ways to achieve this task two approaches for USB protocol

implementation were found:

1- Using a Single IC chip for RS232 to USB conversion with a given Microcontroller

circuit equipped with a built-in UART.

2- Using a single chip parallel to USB conversion with any Microcontroller circuit, only

one 8-bits port is needed.

But as extra work to improve the design we start thinking to develop a soft core for the

USB protocol that can be integrated with a given Microcontroller core.

In this section each one of the above approaches will be explained in details and by the end

of this chapter the chosen one will be applied.

4.2.1 USB Cores for FPGA

Any USB device should be able to have interface with any industry standard

Microcontroller on one side and with any standard USB transceiver on the other side.

The core should implement all functionality required at physical (digital) layer and

protocol layer of USB specification.

43

4.2.1.1 Physical Layer

This layer is responsible of:

- Synchronization (DPLL)

- NRZI decoding / encoding

- Bit stuffing /un stuffing

- Parallel to serial conversion

- serial to Parallel conversion

this layer is simply divided into a transmitter and receiver , the transmitter converts the

data from Parallel to serial , stuff zero bits if needed then performs encoding process

.The receiver performs decoding process, un-stuff zeros if needed then converts the data

from serial to Parallel

4.2.1.2 Protocol layer

This layer is the layer responsible for understanding the host requests and doing the proper

actions. To develop this layer all fields and packets which is descried in chapter 2 for USB

must be generated.

Several trials had been done during this work to get a working core for this layer. No

dedicated block diagrams for this layer were available. On the other hand most of the

available free cores either those written in Verilog, System C or even in VHDL have

limited operational descriptions. Several efforts were done to put them in operation but

unfortunately they did not work. By contacting the owners of these cores, some of them did

not answer at all, while others demanded high price for their help. Other approach was to

contact companies that supply soft cores with full documents. The obtained prices for USB

cores are very high and out of the budget of this work. Also, they asked for some

justifications from the university that this core will not be used in industrial applications or

for developing any commercial product.

44

From the above it was concluded that we have to address the hardware solution as proposed

to implement the USB circuit, and in this case two choices, as regarding the

Microcontroller interfacing, are available:

1- Serial Interfacing to Microcontroller

2- Parallel Interfacing to microcontroller.

Both of these techniques will be introduced and analyzed.

4.2.2 Serial Interfacing to Microcontroller

This technique is the commonly used by most of the designers. Most of the available off-

shelf Microcontroller has built-in UART circuit. The RS 232 serial interface is a well

known serial data link, understood by most of the designers and almost all serial interfaces

for peripheral devices outside the physical layer of a given Data Terminal Equipments

(DTE) are built using this interface [12]. So, the most straight forward solution from the

IC,s manufacturing companies was to develop a single chip that converts between the

RS232 and the USB physical and protocol layers. Typical example for this solution is that

given by Maxim [13] that impalements USB interface with the PIC Microcontroller by

using the FT 232BM as shown in Figure 4.1

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

45

Several other implementations are also available in literature. One disadvantage of this

solution is the limitation of speed imposed by the maximum data rates supported by the

RS232 serial data link [3]. The USB physical circuit can support higher data rates and this

may be accomplished by going to parallel interfacing.

4.2.3 Parallel Interfacing to Microcontroller

Recently, introduced in the market some IC chips that work as USB peripheral controller

with parallel interface such as the PDIUSBD12 from Philips semiconductor [14] and the

FT245R from FDTI [15]. Since we have parallel interface (ports) in PicoBlaze

Microcontroller Core that may provide high connection speed (compared to Serial) FT245R

parallel to USB chip will be used (see appendix C for its data sheet). Figure 4.4 gives the

block diagram of this circuit where we can identify the following blocks:

Figure 4.2: block diagram of the FT245R chip

46

4.3 Hardware verification of Microcontroller Core with USB interface

From the previous section it clearly that using a USB chip with Parallel Interfacing can be

used and eliminate the speed restriction of using USB chip with serial interface. In chapter

3 a PicoBlaze core for Microcontroller was selected to be the used Microcontroller in this

study

In order to test the PicoBlaze micro controller core with the USB chip FT245R an

emulation testing board is needed. This board enables us to download the microcontroller

code onto the FPGA chip, make all the possible connections with the FFT245R chip and

provide USB standard socket. This board consists of four parts:

Part 1: FPGA test and development board containing the target FPGA chip with all the

necessary hardware and software facilities that enable downloading, testing and verifying a

given VHDL code.

NEXYSII board was chosen and supplied from Digilent Company [16], one of the most

popular companies for manufacturing development boards. Its schematic diagram is given

in appendix D, however, its Data sheet is not completed yet and it is under preparation

figure 4.3 showing this board.

Figure 4.3: NEXYSII board

47

Part 2 : An extension board (FX2BB ) that can be attached to the board of part1 to allow

adding more hardware components needed for system building .

Part 3: FT245R USB chip

Part 4: the Physical implementation of the USB B jack

A proposed test configuration is given in Figure 4.4

Figure 4.4: proposed block diagram for Microcontroller with USB

4.4 Experimental work

The block diagram given in Figure 4.4 is completely built in the laboratory and used to

verify the hardware functionality of the proposed design. The test is divided into three

steps:

Step1: testing the PicoBlaze VHDL code as written to impalement the Microcontroller on

NEXYSII board

Step 2: Integrate the hardware built in step1 with the FT245R chip and prepare the USB

physical connection.

Step 3: Writing the necessary VHDL codes to achieve the proposed solution to get

Microcontroller with USB interface

Step 4: Testing the overall circuit by establishing a serial communication connection with

the USB interface of any computer host using familiar communication package like Hyper

Terminal under windows [26].

48

4.4.1 Hardware verification of PicoBlaze testing code

In section 3.3.5 one basic program to read switched and update LED’s accordingly for

PicoBlaze Microcontroller core was simulated using Aldec tool, now we need to test this

program in real signal environment. Since Xilinx FPGA will be used here, another tool

from Xilinx (ISE 9.1) [11] is recommended for programming and downloading. This

version was used during this study.

By synthesizing the codes in section 3.3.5 and downloading this code into the target FPGA

on board NEXYSII the circuit may be experimentally tested .figure 4.5 shows that the code

given in section 3.3.5 is verified experimentally and it is clear that the LEDs are reflecting

the status of the switches

Figure 4.5: Hardware verification for PicoBlaze code

4.4.2 Integrating the FPGA board (NEXYSII) with (FT245R) USB Chip

Integration of the Microcontroller PicoBlaze core downloaded on the FPGA with the USB

Chip (FT245R) needs the following steps:

1- Doing a correct assignment for the FPGA pins to handle the input output ports and

other control pins, in this board version some pins assigned only for serial

inputs/outputs, the proper pins should be used.

49

2- The pins which have been assigned are already connected to the extended board

FX2BB connector, since NEXYSII is a new board and its datasheet is still under

preparation, the schematic of the board and the layout should be used to trace the

connection.

3- Wiring the connections of the extended board FX2BB to the USB chip FT245R.

Figure 4.6 shows on board connection of the system.

Figure 4.3: Microcontroller with USB on board

Figure 4.6: Microcontroller with USB on board

4.4.3 Assembly and VHDL codes for Microcontroller with USB

As can be seen in figure 4.5 the Hardware is completed and need to be tested, so the next

step is to write an assembly code for PicoBlaze Microcontroller and VHDL code for all the

system.

4.4.3.1 PicoBlaze assembly program for Microcontroller with USB

This program reads the status value of 8 switches in hex format. This value is then

transferred to the attached PC through the built USB interface and displayed using the

Hyper Terminal under windows as the ASCII equivalent of read HEX value. On the same

time any character entered by the key board of the PC through the Hyper Terminal window

will be displayed on the 8 LED display of the NEXYSII board. A reset function of all LED

is also available.

50

This assembly program contains the following parts:

1- the definition of all constants in addition to the ASCII table

2- USB communication routines

This routines is the main part of the assembly program since it will handle the reading

and writing from/to the USB chip.

a- Sending to USB

Microcontroller will transmit data to USB chip using this routine and at the beginning of

this routine the program will read the control port then test the transmit buffer is it empty or

full if empty the data port will be loaded by the data and the write to USB chip bit in the

control port should be set send data to the USB chip and finally the control port should be

rest to be ready.

51

b- Read from USB

In this routine the Microcontroller will read from the USB chip and this will be done by

testing if there is a data in data buffer of the chip or not and read it if existing then reset

the Zero flag to use it again in other process

3- the main program

This part will contain the sending menu text and waiting the input of the user to choose

reading switches and update LED’s or reset the LED’s

52

4- reading Switches routine

To read switches value and send it to the USB chip to show it in the terminal program

5- Updating LED’s routines

To Update LED’s with the Value which the user interred

6- Text messages

These routines will send the text messages to the terminal such as menus and it will be

done by sending character by character

For all the program (See appendix E)and this program will be converted to ROM VHDL

code using PicoBlaze assembler which was provided by Xilinx and will be added to the

VHDL code in next section to complete all VHDL codes that are needed to test the

proposed solution

53

4.4.3.2 VHDL code for testing Microcontroller with USB interface

The next step is to complete the system VHDL code (see appendix F) and download it to on

board FPGA

Figure 4.7 gives the block diagram of VHDL code

Figure 4.7: Block diagram of VHDL code

The top level code is contains of the following parts:

1- the tope level entity that representing the black block in figure 4.7 and assigning the

input and output of the system as following

54

2- declaration of (KCPSM3) the PicoBlaze Microcontroller (see appendix J for the

VHDL code for it )

3- declaration of the ROM

4- Signals used to connect KCPSM3 to program ROM and I/O logic

55

5- Signals used to connect KCPSM3 to USB/FIFO interface and LED’s/Switches

6- Switches, and LEDs connections and USB/FIFO control register connections

7- KCPSM3 input ports

56

8- KCPSM3 output ports

9- The FPGA will drive USB data bus all the time and need to be released when

reading from USB chip

All these codes (the assembly code in ROM which explained in section 4.4.3.1 and the

above Top VHDL code) are synthesized and downloaded to the FPGA on NEXYSII board

57

4.4.4 Testing the overall circuit

In previous sections the Overall circuit is built on board and the assembly program was also

written. The all VHDL codes are the downloaded on the FPGA, now the circuit is ready to

be tested.

On power starting, the Microcontroller sends the menu shown in Figure 4.8 to the terminal

program in the PC (Hyper Terminal for example), and keep waiting for user response. The

user responds by either input 1 or 2 or 3.

Figure 4.8: Hyper Terminal showing the program Menu

By pressing 1 the program will read the switch value which is in this example 30HEX and

showing character 0 as the ASCII code equivalent to 30 HEX.

By pressing 2 the program will ask user to enter any character by pressing a key in the

keyboard. The HEX value equivalent to the ASCII code of the pressed key will be

displayed on the led display. In this example key corresponds to Num 1 was pressed and

the LED display is showing 31 HEX which is the equivalent ASCII code.

58

Figure 4.9: Hyper Terminal window program execution

Typical real time run results are given in Figs 4.9 which gives the Hyper Terminal

window during program execution. Figure 4.10 shows the status of the 8 switches read by

the program and the resulted LED display after program execution.

Figure 4.10: Status of Switches and LED display while program execution

59

From previous results the proposed circuit was designed and implemented and gave

expected results and this circuit achieved a design of Microcontroller with USB interface.

Most of the M2M Mobile modules available in the market are still having serial interface

type RS232; while Modern PC’s and laptops are going to use high speed USB interfaces

rather than RS232 (Most of the Laptops available now in the market do not have any

RS232). So, in next chapter the M2M Mobile modules available in the Ericsson Lab [1]

will be integrated with the above described Microcontroller system to provide users with a

complete M2M Mobile modules having USB interface.

60

Chapter 5

GSM Module with USB Interface

5.1 Introduction

This chapter introduces one application for the system described in chapter 4. The

developed Microcontroller circuit was used to equip the available GSM module GM47/48

with a USB serial interface. The modified version of the GSM module was tested and

showed more flexible performance as it is now ready to be attached to any laptop.

5.2 Hardware of the GSM Module with USB

The circuit that has been completed and tested in chapter 4 will be used now with the GSM

module. Since the only possible way to communicate with the available GSM module

(GM47/48) is through its own built in UART, another UART circuit is needed to

established connection from our circuit to the available GSM . This is explained in Fig.5.1

which represent the system used to test the overall performance of the GSM module with

USB interface. This UART (of Microcontroller) to UART (of GSM module) connection is

a dummy and may be eliminated if the designer can access the parallel interface of the

GSM module.

As hardware the testing board (NEXYSII) has a build in connection as RS232 interface and

the designer need to assign correct pins to be used for RS232 connection.

Figure 5.1: Final System blocks

61

5.3 VHDL code of the GSM Module with USB

A UART VHDL code should be added to the assembly code that developed in chapter 4, to

enable serial communication with Microcontroller. In our case the only way to access the

GSM functions is by sending AT commands through the UART circuit. [3] Appendix H

has the full VHDL code

5.3.1 UART Implementation Using FPGA

The used UART core consists of two macros which have been highly optimized for Vertex,

Spartan families from Xilinx. It is a simple UART transmitter and UART receiver with the

fixed following characteristic:

- One start bit

- 8 data bits

- No parity

- 1 stop bit

Each macro also contains an embedded 16 byte buffer also Baud rate from 9600 to 115200

baud/s can be supported

5.3.1.1 Start bit

An asynchronous type of communication means that sending of a data word can start at any

moment. This is acknowledged by starting each data word with an attention bit. This

attention bit, also known as the start bit, is always identified by the low logic level.

Because the line is in high logic state when idle, the start bit is easily recognized by the

receiver.

5.3.1.2 Data bits

Directly following the start bit, the data bits are sent. A bit value 1 causes the line to go in

logic high state; the bit value 0 is represented by a logic low. The least significant bit is

always the first bit sent

.

62

5.3.1.3 Parity bit

For error detecting purposes, it is possible to add an extra bit to the data word

automatically. The transmitter calculates the value of the bit depending on the information

sent. The receiver performs the same calculation and checks if the actual parity bit value

corresponds to the calculated value

5.3.1.4 Stop bits

Suppose that the receiver has missed the start bit because of noise on the transmission line.

It started on the first following data bit with a logic low value. This causes garbled date to

reach the receiver. A mechanism must be present to resynchronize the communication. To

do this, framing is introduced. Framing means, that all the data bits and parity bit are

contained in a frame of start and stop bits. The period of time lying between the start and

stop bit is a constant defined by the baud rate and number of data and parity bits. The start

bit has always low logic value, the stop bit always high logic value. If the receiver detects a

value other than high logic when the stop bit should be present on the line, it knows that

there is a synchronization failure. This causes a framing error condition in the receiving

UART. The device then tries to resynchronize on new incoming bits.

For re-synchronizing, the receiver scans the incoming data for valid start and stop bit pairs.

This works, as long as there is enough variation in the bit patterns of the data words. If data

value zero is sent repeatedly, resynchronization is not possible for example.

The stop bit identifying the end of a data frame can have different lengths. Actually, it is

not a real bit but a minimum period of time the line must be idle (logic high) at the end of

each word. On PC's and through any communication package (Hyper Terminal for

example), this period may be equivalent to 1, 1.5 or 2 bits. 1.5 bits is only used with data

words of 5 bits length and 2 only for longer words. A stop bit length of 1 bit is possible for

all data word sizes.

63

5.4 Assembly code of the GSM Module with USB

in addition to the assemble code that can handle the connection between Microcontroller

(PicoBlaze) and the USB chip (FT245R) the code that can be able to connect the

Microcontroller to the additional VHDL code for UART should be added

This program allows the communication between the UART circuit of the GSM module

and a UART circuit developed as VHDL code. This later converts data into parallel format,

where it can be transferred to the FT245R chip that impalements the USB protocol. The

FT245R chip is connected to a laptop through a standard USB jack. In the other direction,

data stream from the attached laptop is transferred through the USB interface to the

FT245R chip, converted to parallel format, processed by the Microcontroller and finally

coupled to the GSM module using the UART to UART connection. . .See appendix G for

the assembly code

5.5 Testing the overall circuit

Figure 5.2 shows the final circuit and it is clear that this circuit has a RS232 connection

from one side and USB connection from other side

Figure 5.2: On Board Final circuit

The system hardware is consists of:

1- GSM module with built-in UART.

2- FPGA Chip mounted on NEXYSII development board contains all VHDL and assembly

codes

64

3- FT245R chip

4- USB B jack

5-PC or laptop having USB interface

The system was tested first for data transfer between two PC,s one of them has RS232

interface and the other one is a laptop with standard USB interface. Using Hyper Terminal

under windows a communication link was established between the two terminals and data

was transferred successfully.

Figure 5.3 shows that result on Hyper Terminal in the PC side which has received the

message “final system working” sent by the laptop

Figure 5.3: Final System working

The PC with the RS232 interface is then replaced by the GSM module. Now the

communication can be established using Hyper Terminal and AT commands can be sent

from the laptop through the USB connection. The GSM responded successfully to the

received commands where all GSM facilities like dialing, answering, sending SMS…etc

were available.

65

Conclusions The M2M is a new and growing technology available in the market for designing and

implementing fully automated systems. Using the USB interface instead of the RS232 will

improve the M2M system performance because of its advantages and flexibility. Most of

Laptops are not equipped with RS232 interface. 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

Microcontroller acts like the brain of M2M so it provides and supervises all the system

functions. In telecommunications and computer science, serial communications is preferred

due to its advantages over parallel communications. Serial computer buses are becoming

more common as improved technology enables them to transfer data at higher speeds. A

Universal Asynchronous Receiver/Transmitter (UART) is used to implement serial

communication and provide all necessary signals to build standard RS232 interface.

Most of the Microcontrollers available in the market are equipped with built in UART

circuit. USB is a highly growing technology applied for implementing high speed serial

data transfer. The availability of a Microcontroller with a USB interface is limited. Several

techniques may be used to build a microcontroller circuit with USB. The circuit designers

of systems containing Microcontroller can impalement their system. In two ways: Using

off-shelf Microcontroller chips or builds exactly the optimized configuration that

impalement their system using FPGA.

One of the available free cores for an 8-bits Microcontroller is the PicoBlaze

Microcontroller core which had been used effectively throughout this work. Integrating the

built Microcontroller with the FT245R IC Chip provides an optimized solution for our

application. The built circuit had been used successfully to establish USB serial

communication with the laptop as a host computer where data can be transferred. Using the

developed circuit with the GM 47/48 GSM module to provide a complete M2M system

with USB interface was successfully demonstrated. The experimental work confirms

exactly the work objectives.

66

Future Work

The future work may be oriented towards two directions:

1- Develop a USB core that may be integrated with any microcontroller core , like this

we will be able to build our applications on a single chip .

2- Going through the internal design of the RF section within the GSM module in

order to communicate in parallel internally while supplying the user of this GSM

module with USB standard interface.

67

References

[1] www.sonyEricsson.com/m2m

[2] Nebojsa Matic, “PIC microcontrollers, for beginners too” ebook

[3] Paul H. Young ,”Electronic communication techniques” 1990

[4] www.usb.org

[5] Compaq, Intel, Microsoft, NEC, “Universal Serial Bus Specification Revision 1.1“

September 23, 1998

[6] www.usb.org.org/developers/usb_20.zip

[7] Steven McDowell & Martin D.Seyer, “USB Explained”, 1999.

[8] www.keil.com/

[9] http://cygwin.com/

[10] www.aldec.com

[11] www.xilinx.com

[12] for DTE

[13] http://www.maxim-ic.com/

[14] http://www.nxp.com/acrobat_download/datasheets/PDIUSBD12_9.pdf

[15] http://www.ftdichip.com/Documents/DataSheets/DS_FT245R.pdf

[16] http://digilentinc.com/

[17] M. Abou Elela ,” Programmable Logic Remote Controller Using GSM Network

“Proceeding of MMS 2003 , 6-9 May 2003, Ain Shams University , Cairo, Egypt.

[18] Richard C. Dorf, H. Bishop , “Modern control System”, 1997.

[19] M. Abou Elela, “GSM Network Based PLC Systems ", Proceedings of the 2nd IIEC-

2004, December 19-21, 2004, Riyadh, Kingdom of Saudi Arabia.

[20] Kevin Skahill “VHDL for Programmable Logic “, Addison-Wesley Publishing.,

Menlo Park, CA, 1996.

[21] Julio C G Pimentel Hoang Le –Huy “A VHDL Library of IP Cores for Power Drive

and Motion Control Applications” IEEE Press, 2000.

68

[22] Alheraish, A” Design and Implementation of Home Automation System” Consumer

Electronics, IEEE Transactions, Volume 50, Issue 4, Nov. 2004 pp 1087 – 1092

[23] Peter J. Ashenden , “The VHDL Cookbook“, Dept. Computer Science, University of

Adelaide ,South Australia ,July 1990

[24] Wikipedia, the free encyclopedia

[25] Ahmed Ramadan, Amany Mohammed, Esraa Mohammed, Mohammed Mahmoud

,Mohammed talaat “FPGA based IP for USB interface” Ain Shams University, EE

department ,July 2005

[26] http://www.hilgraeve.com/index.html

Appendix A

Sony Ericsson GM47/GM48

GM 47/GM 48Technical Description

GM47/48 Technical description

BA/SEM/MS 02:0004 Rev B 6

1.2 Features

The module performs a set of telecom services (TS) according toGSM standard phase 2+, ETSI and ITU-T. The functions of themodule are implemented by issuing AT commands over the serialinterface. Supported AT commands are listed in section 5, these aredefined further in GSM 7.05.

1.2.1 Type of Mobile Station

The GM 4X family are normal dual band type of MS with thefollowing characteristics.

GM 47 GSM 900 E-GSM 900 GSM 1800

Frequency Range(MHz)

TX: 890-915

RX: 935-960

TX: 880-890

RX: 925-935

TX: 1710-1785

RX: 1805-1880

Channel spacing 200 kHz 200 kHz

Number of channels 173 Carriers *8 (TDMA)

GSM: Channels 1 to 124

E-GSM: Channels 975 to 1023

374 Carriers *8 (TDMA)

DCS: Channels 512 to 885

Modulation GMSK GMSK

TX Phase Accuracy < 5º RMS Phase error (burst) < 5º RMS Phase error (burst)

Duplex spacing 45 MHz 95 MHz

Receiver sensitivity atantenna connector

< - 102 dBm < - 102 dBm

Transmitter outputpower at antennaconnector

Class 4

2W (33 dBm)

Class 1

1W (30 dBm)

Automatic hand-over between GSM 900 and GSM 1800

GM 48 GSM 850 GSM 1900

Frequency Range (MHz) TX: 824-849

RX: 869-894

TX: 1850-1910

RX: 1930-1990

Channel spacing 200 kHz 200 kHz

Number of channels 123 carriers *8 (TDMA)

GSM: Channels 128 to 251

298 Carriers *8 (TDMA)

PCS: Channels 512 to 810

Modulation GMSK GMSK

TX Phase Accuracy < 5º RMS Phase error (burst) < 5º RMS Phase error (burst)

Duplex spacing 45 MHz 80 MHz

Receiver sensitivity at antennaconnector

< - 102 dBm < - 102 dBm

Transmitter output power atantenna connector

Class 5

0.8 W (29 dBm)

Class 1

1W (30 dBm)

GM47/48 Technical description

BA/SEM/MS 02:0004 Rev B 7

Automatic hand-over between GSM 850 and GSM 1900

1.2.2 SMSThe module supports the following SMS services:

• Sending: MO, both PDU and Text mode supported.• Receiving: MT, both PDU and Text mode supported.

• CBM is a service, in which a message is sent to all subscriberslocated in one or more specific cell(s) in the GSM network, forexample, cell location information.

• SMS STATUS REPORT according to GSM 03.40.• SMS COMMAND according to GSM 03.40.

The maximum length of an SMS message is 160 characters whenusing 7-bit encoding. For 8-bit data, the maximum length is 140 bytes.

The module does support upto 6 concatenated messages to extend thisfunction.

1.2.3 Voice callsThe GM47/48 offers the capability of MO and MT voice calls, as wellas supporting emergency calls. In addition to this multiparty, callwaiting and call deflection features are available. Some of thesefeatures are operator specific.

The module offers normal analogue input/output lines, analogue audioinput/ output lines in differential modes, and digital audio interface,with the possibility of accessing internal points within the digitalaudio lines. Moreover, the GM 47/GM48 has embedded echocanceller and noise suppresser, which provides high quality audio.

The module supports both HR, FR and EFR voice coding, providedthat EFR is available in the network.

1.2.4 DataThe module supports the following data protocols:

• General Packet Radio Service (GPRS). The modules are Class BTerminals, which provides simultaneous activation and attach ofGPRS and GSM services. The GM47/48 modules are GPRS 3+1devices, which are capable of transmitting in one timeslot perframe (uplink), and receiving in a maximum of three timeslots perframe (downlink).

• Circuit Switched Data (CSD). GM47/48 modules are capable tostablish a circuit switch data communication at 9.6 kbps, V42biscompression is not supported.

GM47/48 Technical description

BA/SEM/MS 02:0004 Rev B 8

• High Speed Circuit Switched Data (HSCSD). GM47/48 supportHSCSD communication, with one timeslot per frame capacity inthe uplink and two timeslots per frame capacity in the downlink(2+1).

1.2.5 SIM Card

The module supports the connection of an external SIM Card with 3Vand 5 V technology, via the 60-pin system connector. The moduledoes not have an internal SIM holder.

1.2.6 Power consumption

Stand-by1 Transmit/Operation

GSM 850 & 900 MHz 20 mA 275 mA (2A peak)

GSM 1800 & 1900 MHz 20 mA 250 mA (1.75A peak)

Note! The power consumption during transmission is measured atmaximum transmit power.

1.2.7 Other features

• Internet Ready Module

• 07.10 Multiplexing

• Bluetooth interoperability

• GPS interoperability

• SIM application toolkit, class 2 release 96 compliant

1.2.8 Development Kit

Sony Ericsson Mobile Communications provides the opportunity totest the module in a limited scale, before ordering a large quantity.With the development kit you can quickly get started with the module.The kit includes necessary accessories (software and hardware) thatyou will need for your test purposes. It also includes the following:

• GSM module GM 47 or GM 48

• Integrator’s Manual

• Warranty Sheet

1 This figures are tentative data, subject to change.

GM47/48 Technical description

BA/SEM/MS 02:0004 Rev B 14

Pin Signal Name Dir Signal Type Description

1. VCC - Supply Power Supply

2. DGND - - Digital Ground

3. VCC - Supply Power Supply

4. DGND - - Digital Ground

5. VCC - Supply Power Supply

6. DGND - - Digital Ground

7. VCC - Supply Power Supply

8. DGND - - Digital Ground

9. VCC - Supply Power Supply

10. DGND - - Digital Ground

11. VCC - Supply Power Supply

12. DGND - - Digital Ground

13. Reserved for future use

14. ON/OFF I Internal pull up,open drain

Turns the module on/off

Former WAKE_B

15. SIMVCC - Dig. 3/5 V SIM card power supply

Power output for SIM Card from module

16. SIMPRESENCE I Internal pull up,open drain

SIM Presence

A "1" shall indicate that the SIM is missing;a "0" that it is inserted.

17. SIMRST O Dig. 3/5 V SIM card reset

18. SIMDATA I/O Dig. 3/5 V SIM card data

19. SIMCLK O Dig. 3/5 V SIM card clock

20. DAC O Analogue Digital to Analogue converter

21. IO1 I/O Digital, 2.75 General purpose input/output 1

22. IO2 I/O Digital, 2.75 General purpose input/output 2

23. IO3 I/O Digital, 2.75 General purpose input/output 3

24. IO4 I/O Digital, 2.75 General purpose input/output 4

25. VRTC I Supply 1.8 V Voltage for real time clock

26. ADC1 I Analogue Analogue to Digital converter 1

27. ADC2 I Analogue Analogue to Digital converter 2

28. ADC3 I Analogue Analogue to Digital converter 3

29. SDA I/O 2.75, internalpullup

I2C Data

30. SCL O 2.75, internalpullup

I2C Clock

31. BUZZER O Dig. 2.75 Buzzer output from module

32. TIMESTAMP O Dig. 2.75 Timestamp

Timestamp is reserved for future use, if A-GPS is implemented on network side.

GM47/48 Technical description

BA/SEM/MS 02:0004 Rev B 15

33. LED O Dig. 2.75 Flashing LED

34. VIO O Power Out 2.75 Module powered indication.

The VIO is a 2.75 V output that couldpower external devices to transmit datatowards the GSM device to a 75mA max.

35. TX_ON O Dig 2.75 This output shall indicate when the GSMmodule is going to transmit the burst.

36. RI O Dig. 2.75 Ring Indicator

37. DTR I Dig. 2.75 Data Terminal Ready

38. DCD O Dig. 2.75 Data Carrier Detect

39. RTS I Dig. 2.75 Request To Send

40. CTS O Dig. 2.75 Clear To Send

41. TD I Dig. 2.75 Transmitted Data

Data from DTE (host) to DCE (module).[former DTMS]

42. RD O Dig. 2.75 Received Data

Data from DCE (module) to DTE (host).[former DFMS]

43. TD3 I Dig. 2.75 UART3 Transmission

Data from DTE (host) to DCE (module).[former DTMS]

44. RD3 O Dig. 2.75 UART3 Reception

Data from DTE (host) to DCE (module).[former DTMS]

Data from DCE (module) to DTE (host).[former DFMS]

45. TD2 I Dig. 2.75 UART2 Reception

Former CTMS. Used for flashing

46. RD2 O Dig. 2.75 UART2 Transmission

Data from DCE (module) to DTE (host).[former DFMS]

Former CFMS. Used for flashing

47. PCMULD I Dig. 2.75 DSP PCM digital audio input

48. PCMDLD O Dig. 2.75 DSP PCM digital audio output

49. PCMO O Dig. 2.75 Codec PCM digital audio output

50. PCMI I Dig. 2.75 Codec PCM digital audio input

51. PCMSYNC O Dig. 2.75 DSP PCM frame sync

52. PCMCLK O Dig. 2.75 DSP PCM clock output

53. MICP I Analogue Microphone input positive

54. MICN I Analogue Microphone input negative

55. BEARP O Analogue Speaker output positive

56. BEARN O Analogue Speaker output negative

57. AFMS O Analogue Audio output from module

GM47/48 Technical description

BA/SEM/MS 02:0004 Rev B 16

58. SERVICE I 12V/2.7V Flash programming voltage for the MS.Enable logger information if no flashing

Former VPPFLASH

59. ATMS I Analogue Audio input to module

60. AGND - - Analogue ground

3.2 General Electrical and Logical Characteristics

Many of the signals present in the interface are high-speed CMOSlogic inputs or outputs powered from 2.75 V ± 5 %. Whenever asignal is defined as Dig. 2.75 V, the following electricalcharacteristics shall apply.

Parameter Min. Typ. Max. Output

current Io

Units

High Level Output Voltage (VOH) 2.2 2.75 - 2 mA Volts

Low Level Output Voltage (VOL) 0 0.6 2 mA Volts

High Level Input Voltage (VIH) 1.93 2.75 Volts

Low Level Input voltage (VIL) 0 0.5 Volts

3.2.1 General Protection Requirements

All 2.75V digital inputs shall continuously withstand any voltage from-0.5V up to 3.47V (3.3V + 5%) in the power-on or power-offcondition with no damage. All 2.75V digital outputs shallcontinuously withstand a short circuit to any voltage within the rangefrom 0V to 3V.

The SIM output signals and the SIMVCC supply shall continuouslywithstand a short circuit to any voltage within the range from 0V to4.1V.

3.3 Grounds

Pins Name Description

2, 4, 6, 8, 10, 12 DGND Digital Ground

60 AGND Analogue Ground

GM47/48 Technical description

BA/SEM/MS 02:0004 Rev B 23

Parameter LimitCCO 2.0 - 2.5 V

3.8 Speaker Signals

Pin Speaker signals Dir Function

55 BEARP O Microphone Positive Output

56 BEARN O Microphone Negative Output

BEARP and BEARN are the speakers output pins. These outputs arein differential mode.

3.9 Digital Audio

Pin PCM signal Dir Function

52 PCMCLK O PCM clock

51 PCMSYNC O PCM frame sync

47 PCMULD I PCM audio input to DSP

48 PCMDLD O PCM audio output to DSP

50 PCMI I PCM audio input to Codec

49 PCMO O PCM audio output to Codec

The digital PCM audio signals allow the connection of a digital audiosource / receiver, bypassing the analogue audio CODEC processingfunctions performed within the module.

Figure 3.4 Pin connections to digital audio

GM47/48 Technical description

BA/SEM/MS 02:0004 Rev B 24

In case no external audio processing is performed, then it is needed toconnect

PCMDLD and PCMIPCMULD and PCMO

Electrical characteristicsThe Dig. 2.75 V CMOS Output / Input electrical characteristics shallapply, with DGND as the reference.

PCM interface formatThe PCM format (for PCMULD and PCMDLD) shall follow a linearPCM data I/O format of an industry standard Texas Instrument DSP.It is the same format as the one used between the CODEC and theDSP. The DSP is the source of the bit clock PCMCLK and the framesynchronisation PCMSYNC. The data bits in PCMULD andPCMDLD shall be aligned so that the MSB in each word occurs onthe same clock edge.

3.10 Serial Data

Pin Name Dir Description RS232 CCITTNº

41 TD I Serial data to module 103

42 RD O Serial data from module 104

39 RTS I Request To Send 105

40 CTS O Clear To Send 106

37 DTR I Data Terminal Ready 108.2

38 DCD O Data Carrier Detect 109

36 RI O Ring Indicator 125

45 TD2 I UART 2 Data Transmission

46 RD2 O UART 2 Data Reception

43 TD3 O UART 3 Data Transmission

44 RD3 I UART 3 Data Reception

GM47/48 Technical description

BA/SEM/MS 02:0004 Rev B 26

3.10.1 UART 1 (RS232) - RD, TD, RTS, CTS, DTR, DCD and RI

The UART1 signals form a 9 pin RS-232 (V.24) serial port, apartfrom the DSR (CCITT Nº 107) signal. DSR signal has been removedas it is usually connected to DTR in most systems.

The signal levels do not match the standard RS-232 (V.28) levels. Therelationship between the levels is shown in the table below

RS - 232 Level RD, TD RTS, CTS, DTR, DCD, RI 2.75 V CMOS Level

< - 3 V 1 OFF > 1.93

> + 3 V 0 ON < 0.80 V

Conversion between the 2.75V CMOS levels and the RS232 levelscan be achieved using a standard interface IC, such as the MaximIntegrated Products MAX3237.

3.10.2 Serial Data Signals - RD, TD

The default baud rate is 9.6 kbit/s, however higher bit rates up to 460kbit/s shall be supported, and set by an AT command. The UART 1starts at a rate of 9.6 kbit/s in standard AT mode or binary mode (Firstreceived data AT or binary will determine the operation mode).The GSM 07.10 multiplexing protocol is supported and shall bestarted on command. In this case bit rates up to 460 kbits/s shall besupported.

Serial Data From Module (RD)RD is an output used to send data on the UART 1 to the applicationsystem. This is a Dig. 2.75 CMOS Output and general characteristicsare applicable.

Parameter Limit

Application load resistance < 100 kΩ

Application load capacitance < 500 pF

Serial Data To Module (TD)TD is input (to the module) used by the application system to senddata on the UART 1 to the module. This is a Dig. 2.75 CMOS Inputand general characteristics are applicable.

Parameter Limit

Application driving impedance < 100 Ω

Input capacitance 1 nF

Input resistance (pull-up) 100 kΩ to 2.75 V

GM47/48 Technical description

BA/SEM/MS 02:0004 Rev B 27

3.10.3 Control Signals - RTS, CTS, DTR, DCD, RI

The control signals are active low, and hence when a standardinterface IC is used (such as MAX3237), then standard RS-232 levelsare obtained.

These signals together with DGND, RD and TD form a 9-pin RS-232data port (with the exception of the voltage levels and DSR).RTS and CTS shall be capable of transmitting at 1/10 of the datatransmission speed for data rates, up to 460 kbit/s. (Byte oriented flowcontrol mechanism).

Switching times for RTS and CTS

Parameter Limit

Time from Low to High level < 2 µs

Time from High to Low level < 2 µs

Request to Send (RTS)RTS is an input to the module. The signals on this circuit shall be usedto condition the DCE (the module when used for data transmissionpurposes) for data transmission. Default level is OFF, by internal pullup.

The exact behaviour of RTS shall be defined by an AT command.Software or hardware flow control can be selected. Hardware flowcontrol is the default.

This is a Dig. 2.75 CMOS Input and general characteristics areapplicable.

It is the duty of the application to pull RTS low (logic levels) torequest communications with the module. The module will respond byasserting CTS low and as such may be used as a notification as amodule status ready for communication.

Parameter Limit

Application driving impedance < 100 Ω

Input capacitance < 2 nF

Input resistance (pull-down) 100 kΩ to DGND

GM47/48 Technical description

BA/SEM/MS 02:0004 Rev B 28

Clear To Send (CTS)CTS is an output from the module. The signals on this circuit shall beused to indicate that the DCE (the module when used for datatransmission purposes) is ready to transmit data. Default level is high.The exact behaviour of CTS shall be defined by an AT command.Software or hardware flow control can be selected.

This is a Dig. 2.75 CMOS Output and general characteristics areapplicable.

Tip: if only software flow control is to be used it becomes necessaryto assert RTS low or to connect RTS to CTS at the module.

Parameter Limit

Application load capacitance < 500 pF

Application load resistance > 1 MΩ

Data Terminal Ready (DTR)DTR is an input to the module. Signals from the DTE on this circuitindicate the DTE is ready to transmit and receive data. DTR also actsas a hardware 'hang-up' so that calls are terminated if DTR is OFF(high).

Default level is ON (low). The exact behaviour of DTR shall bedefined by AT commands.

This is a Dig. 2.75 CMOS Input and general characteristics areapplicable.

Data Carrier Detect (DCD)DCD is an output from the module. An ON (low) signal shall indicatethat a valid carrier (data signal) is being received by the DCE(module). The exact behaviour of DCD shall be defined by an ATcommand.

This is a Dig. 2.75 CMOS Output and general characteristics areapplicable.

Ring Indicator (RI)RI is an output from the module. An ON (low) signal shall indicate aringing signal is being received by the DCE (module).

The functionality shall be selected by an AT command.

This is a Dig. 2.75 CMOS Output and general characteristics areapplicable.

GM47/48 Technical description

BA/SEM/MS 02:0004 Rev B 29

Note: DSR is considered permanently ready for a module, thereforeany DGND connection may be taken as DSR functionality.

3.10.4 UART 2 - TD2, RD2

The UART 2 consists of a full duplex serial communication. Thisinvolves the transmission and reception lines.

The communication port shall work in one mode: Operation andMaintenance mode.

Operation and Maintenance mode shall work in addition withSERVICE signal. On switching the module on, if SERVICE signal isactive then two events can happen. If no data is sent to the module,then the logger is activated. Otherwise, the module shall be ready tobe reprogrammed.

Timing and Electrical signals characteristics equal to UART 1 TD andRD, except for maximum baud rate that could be increased to 921KBPS.

Transmitted Data 2 (TD2)TD2 is input (to the module) used by the application system to senddata on the UART 2 to the module.

The electrical characteristics shall be the same as TD.

Received Data 2 (RD2)RD2 is an output used to send data on the UART 2 to the applicationsystem.

The electrical characteristics shall be the same as RD.

3.10.5 UART 3 - TD3, RD3

The UART 3 consists of a full duplex serial communication. Thisinvolves the transmission and reception lines.

Timing and electrical signals characteristics equal to UART 1 TD andRD.

Transmitted Data 3 (TD3)TD3 is input (to the module) used by the application system to senddata on the UART 3 to the module.

The electrical characteristics shall be the same as TD.

GM47/48 Technical description

BA/SEM/MS 02:0004 Rev B 30

Received Data 3 (RD3)RD is an output used to send data on the UART 3 to the applicationsystem.

The electrical characteristics shall be the same as RD.

3.11 SIM Card related signals

Parameter Mode Signal Min. Typ. Max. Unit

SIM supply Voltage 3 V SIMVCC 2.7 3.0 3.3 V

5 V 4.5 5.0 5.5 V

High Level Input Voltage(VIH)

3 V SIMDAT 2.1 3.0 V

5 V 3.5 5.0 V

Low Level Input Voltage(VIL)

3 V SIMDAT 0 0.9 V

5 V 0 1.5 V

High Level Output Voltage(VOH)

3 V SIMDAT 2.7 3.0 V

5 V 4.7 5.0 V

Low Level Output Voltage(VOL)

3 V SIMDAT 0 0.2 V

5 V 0 0.2 V

High Level Output Voltage(VOH)

3 V SIMCLK

SIMRST

2.4 3.0 V

5 V 4.4 5.0 V

Low Level Output Voltage(VOL)

3 V SIMCLK

SIMRST

0 0.35 V

5 V 0 0.3 V

GM47/48 Technical description

BA/SEM/MS 02:0004 Rev B 35

4 Antenna Connector

The Antenna Connector is a hub for transmission of the RadioFrequency (RF) signals from the module to the external customer-supplied antenna. It is a microminiature coaxial MMCX connectorthat is mounted on the surface of the module. One provider ofAntenna Connectors is IMS.

This table provides the electrical characteristics at the antennainterface.

Parameter Limit Description

Nominal impedance 50 Ω= (SWR < 2:1) ==

Output Power 2 Watt peak (Class 4) Extended GSM 900

1 Watt peak (Class 1) GSM 1800

Static Sensitivity Better than - 102 dBm Extended GSM 900

Better than - 102 dBm GSM 1800

GM47/48 Technical description

BA/SEM/MS 02:0004 Rev B 36

5 AT Command Summary

The AT standard is a line-oriented command language. "AT" is anabbreviation of ATtention and it is always used to start sending acommand line from a TE to the TA. TE stands for TerminalEquipment which is a computer of any size and TA stands forTerminal Adapter which is the modem part of the module.

The command line consists of a string of alphanumeric characters. It issent to the modem to instruct it to perform the commands specified bythe characters.

Functionality AT commands

CONTROL AND IDENTIFICATION

Subscriber Information AT+CNUM, AT+CIMI, AT*ESNU

Product & Release info AT+CGMI, AT+CGMM, AT+CGMR,AT+CGSN, AT*ESIR

Generic information & Settings AT, AT*, AT+CLAC, AT+GCAP, ATI,AT+CSCS, AT&F, AT&W, ATZ, AT+WS46

CALL CONTROL ATA, ATD, ATL, ATH, ATO, ATP, ATT,AT+CHUP, AT+CMOD, AT+VTS, AT+CVHU,AT+CR, AT+CRC, AT+CRLP

AUDIO CONTROL AT*EALR, AT*EAMS, AT*EARS, AT*ELAM,AT*EMIR, AT*EMIC, AT*EXVC

NETWORK SERVICES

Alternate Line Service (ALS) AT*EALS, AT*ELIN, AT*ESLN

Customer Service Profile AT*ECSP

Call forwarding AT+CCFC, AT*EDIF, AT*EDIS

Calling/called number identification AT+CLIP, AT+CLIR, AT*EIPS

Preferred networks AT*EPNR, AT*EPNW

Advice of Charge AT+CACM, AT+CAMM, AT+CAOC,AT+CPUC

Calling cards AT*ESCN

Call hold, waiting & multiparty AT+CCWA, AT+CHLD

Operator selection AT+COPS

Network registration AT+CREG

USSD AT+CUSD, AT+ CSSN

Security & Locks AT+CLCK, AT+ CPWD, AT+CPIN, AT*EPEE

SETTINGS AT*EMAR, AT*ERIL, AT*ERIN, AT*ERIP,AT*ESIL, AT*ESMA, AT*ESMM, AT*ESOM,

GM47/48 Technical description

BA/SEM/MS 02:0004 Rev B 37

AT*ECPI

ME STATUS INFORMATION AT*ECAM, AT+CSQ, AT+CBC, AT+CIND,AT+CPAS, AT+CMER

ERROR CONTROL AT+CMEE, AT+CEER

SMS & CB

Settings AT*ESTL, AT+CPMS, AT+CRES, AT+CSAS,AT+CSCA, AT+CSMS, AT+CNMI, AT+CSDH,AT+CSMP, AT+CGSMS

SMS-Command AT+CMGC

Read / write SMS AT+CMGD, AT+CMGW, AT+CMGL,AT+CMGR

Send SMS AT+CMGS, AT+CMSS

PHONEBOOK

Read / write / find AT+CPBS, AT+CPBR, AT+CPBW, AT+CPBF

Call screening AT*ECAR, AT*ECAS, AT*ECAW

Groups AT*EGIR, AT*ESAC, AT*ESCG, AT*ESDG,AT*ESDI, AT*ESGR

Personal Rings AT*EPRR, AT*EPRW

Settings AT*EPBM, AT*ESIA, AT*E2PCS

CLOCK

Alarm AT+CALA, AT+CALD, AT+CAPD

Time & Date AT+CCLK, AT+CTZU, AT*EDST

WAP

Bookmarks AT*EWBA, AT*EWBR

Settings AT*EWCG, AT*EWCT, AT*EWDT,AT*EWHP, AT*EWIL, AT*EWLI, AT*EWPB,AT*ENAD, AT*EWSA, AT*EWSG

Profiles AT*EWPN, AT*EWPR

INTERFACE COMMANDS AT&C, AT&D, AT+ICF, AT+IFC, AT+ILRR,AT+IPR, ATE, AETM, ATQ, ATS0, ATS10,ATS2, ATS3, ATS4, ATS5, ATS6, ATS7,ATS8, ATV, ATX, AT+CSCS

DATA COMPRESSION V42bis AT+DR, AT+DS

07.10 MULTIPLEXING AT+CMUX

GM47/48 Technical description

BA/SEM/MS 02:0004 Rev B 38

HSCSD AT+CHSR, AT+CHSU

GPRS

PDP Context Activation AT+CGACT

Manual PDP Context Activation AT+CGANS

GPRS Attachment AT+CGATT

Enter Data State AT+CGDATA

Define PDP Context AT+CGDCONT

GPRS Event Reporting AT+CGEREP

Show PDP Address AT+CGPADDR

Quality of Service Profile (MINIMUMACCEPTABLE)

AT+CGQMIN

Quality of Service Profile (REQUESTED) AT+CGQREQ

GPRS Network registration Status AT+CGREG

Extension of ATD for GPRS ATD*

NETWORK INFORMATION

Cell information AT*E2CD

Engineering Mode AT*E2EMM

SIM APPLICATION TOOLKIT

Set Up Call AT*E2STKC

Display Text AT*E2STKD

Get Inkey AT*E2STKG

Get Input AT*E2STKI

Select Item AT*E2STKL

Set Up Menu AT*E2STKM

Envelope (Menu Selection) AT*E2STKN

Application Toolkit Settings AT*E2STKS

88

Appendix B VHDL Top level code for Verification of

PicoBlaze code

89

----------------------------------------------------------------------- library IEEE; use IEEE.STD_LOGIC_1164.ALL; use IEEE.STD_LOGIC_ARITH.ALL; use IEEE.STD_LOGIC_UNSIGNED.ALL; entity PICOBLAZE_simulate is PORT ( RST : in std_logic; SWS : in std_logic_vector(7 downto 0); LEDS : out std_logic_vector(7 downto 0); CLK : in std_logic ); end PICOBLAZE_simulate ; architecture Behavioral of PICOBLAZE_simulate is ----------------------------------------------------------------------- -------------- declaration of KCPSM ----------------------------------------------------------------------- component kcpsm3 is Port ( address : out std_logic_vector(9 downto 0); instruction : in std_logic_vector(17 downto 0); port_id : out std_logic_vector(7 downto 0); write_strobe : out std_logic; out_port : out std_logic_vector(7 downto 0); read_strobe : out std_logic; in_port : in std_logic_vector(7 downto 0); interrupt : in std_logic; interrupt_ack : out std_logic; reset : in std_logic; clk : in std_logic); end component; ----------------------------------------------------------------------- -- declaration of program ROM ----------------------------------------------------------------------- component rom_0 is Port ( address : in std_logic_vector(9 downto 0); instruction : out std_logic_vector(17 downto 0); clk : in std_logic); end component;

90

----------------------------------------------------------------------- -- Signals used to connect KCPSM3 to program ROM and I/O logic ----------------------------------------------------------------------- signal address : std_logic_vector(9 downto 0); signal instruction : std_logic_vector(17 downto 0); signal port_id : std_logic_vector(7 downto 0); signal out_port : std_logic_vector(7 downto 0); signal in_port : std_logic_vector(7 downto 0); signal write_strobe : std_logic; signal read_strobe : std_logic; signal interrupt : std_logic :='0'; signal interrupt_ack : std_logic; ----------------------------------------------------------------------- -- internal signals ----------------------------------------------------------------------- signal sws_int: std_logic_vector(7 downto 0); signal leds_int: std_logic_vector(7 downto 0):= (others=>'0'); signal reset_kcpsm3: std_logic:= '0'; ----------------------------------------------------------------------- begin PICOBLAZE: kcpsm3 port map( address => address, instruction => instruction, port_id => port_id, write_strobe => write_strobe, out_port => out_port, read_strobe => read_strobe, in_port => in_port, interrupt => interrupt, interrupt_ack => interrupt_ack, reset => reset_kcpsm3, clk => clk); program_rom: rom_0 port map( address => address, instruction => instruction, clk => clk); reset_kcpsm3 <= RST; -----------------------------------------------------------------------

91

-- Switches, and LEDs connections ----------------------------------------------------------------------- sws_int <= SWS; LEDS <= leds_int; ----------------------------------------------------------------------- -- KCPSM3 input ports ----------------------------------------------------------------------- input_ports: process(clk) begin if clk'event and clk='1' then case port_id is -- read Switches at address 02 hex when "00000010" => in_port <= sws_int; when others => in_port <= "XXXXXXXX"; end case; end if; end process input_ports; ---------------------------------------------------------------------- -- KCPSM3 output ports --------------------------------------------------------------------- output_ports: process(clk) begin if clk'event and clk='1' then if write_strobe='1' then -- Update LEDs at address 08 hex if port_id="00001000" then leds_int <= out_port; end if; end if; end if; end process output_ports; end Behavioral;

92

Appendix C FT245R (Parallel to USB chip data sheet)

FT245R USB UART I.C. Datasheet Version 1.05 © Future Technology Devices International Ltd. 2005

Page 5

3. Block Diagram 3.1 Block Diagram (Simplified)

Figure 1 - FT245R Block Diagram

3.2 Functional Block Descriptions

3.3V LDO Regulator - The 3.3V LDO Regulator generates the 3.3V reference voltage for driving the USB transceiver cell output buffers. It requires an external decoupling capacitor to be attached to the 3V3OUT regulator output pin. It also provides 3.3V power to the 1.5kΩ internal pull up resistor on USBDP. The main function of this block is to power the USB Transceiver and the Reset Generator Cells, rather than to power external logic. However, external circuitry requiring 3.3V nominal at a current of around 50mA could also draw its power from the 3V3OUT pin if required.

USB Transceiver - The USB Transceiver Cell provides the USB 1.1 / USB 2.0 full-speed physical interface to the USB cable. The output drivers provide 3.3V level slew rate control signalling, whilst a differential receiver and two single ended receivers provide USB data in, SEO and USB Reset condition detection. This Cell also incorporates internal USB series resistors on the USB data lines, and a 1.5kΩ pull up resistor on USBDP.

USB DPLL - The USB DPLL cell locks on to the incoming NRZI USB data and provides separate recovered clock and data signals to the SIE block.

Internal 12MHz Oscillator - The Internal 12MHz Oscillator cell generates a 12MHz reference clock input to the x4 Clock multiplier. The 12MHz Oscillator is also used as the reference clock for the SIE, USB Protocol Engine and FIFO controller blocks

Clock Multiplier - The Clock Multiplier takes the 12MHz input from the Oscillator Cell and generates the 48MHz clock reference used for the USB DPLL block.

Serial Interface Engine (SIE) - The Serial Interface Engine (SIE) block performs the Parallel to Serial and Serial to Parallel conversion of the USB data. In accordance to the USB 2.0 specification, it performs bit stuffing / un-stuffing and CRC5 / CRC16 generation / checking on the USB data stream.

ClockMultiplier

Serial InterfaceEngine( SIE )

USBProtocol Engine

3.3 VoltLDO

Regulator

USBTransceiver

withIntegrated

SeriesResistorsand 1.5KPull-up

USB DPLL

Internal12MHz

Oscillator

48MHz

OCSI(optional)

OSCO(optional)

USBDP

USBDM

3V3OUT

VCC

D0D1D2D3D4D5D6D7

RD#

RXF#TXE#

RESET#

TESTGND

RESETGENERATOR

3V3OUT

WR

FIFO TX Buffer128 bytes

FIFO RX Buffer256 bytes

InternalEEPROM

To USB Transceiver Cell

PWREN#

To USBTransceiver

Cell

VCCIO

FIFO Controllerwith

ProgrammableHigh Drive

FT245R USB UART I.C. Datasheet Version 1.05 © Future Technology Devices International Ltd. 2005

Page 7

4. Device Pin Out and Signal Descriptions 4.1 28-LD SSOP Package

USBDP

USBDM

3V3OUT

GND

RESET#

VCC

GND

NC

AGND

TEST

OSCI

OSCO

TXE#

RXF#

D0

D2

D1

D4

VCCIO

D7

GND

NC

D5

D6

D3

PWREN#

RD#

WR

FT

245RL

YY

XX

-A

1

14 15

28

FT

DI

Figure 2 - 28 Pin SSOP Package Pin Out

Figure 3 - 28 Pin SSOP Package Pin Out (Schematic Symbol)

FT245RL

AGND

GND

GND

GND

TEST

25 7 18 21 26

3V3OUT

VCCIO4

17

NC

RESET#

NC

24

19

8

D0

D1

D2

D3

D4

D5

D6

D7

1

5

3

11

2

9

10

6

RXF#

WR

RD#

TXE#

23

22

13

14

20

16

15USBDP

USBDM

VCC

OSCI27

OSCO28

PWREN# 12

FT245R USB UART I.C. Datasheet Version 1.05 © Future Technology Devices International Ltd. 2005

Page 8

4.2 SSOP-28 Package Signal Descriptions

Table 1 - SSOP Package Pin Out Description

Pin No. Name Type DescriptionUSB Interface Group15 USBDP I/O USB Data Signal Plus, incorporating internal series resistor and 1.5kΩ pull up resistor to 3.3V

16 USBDM I/O USB Data Signal Minus, incorporating internal series resistor.

Power and Ground Group4 VCCIO PWR +1.8V to +5.25V supply to the FIFO Interface and Control group pins (1...3, 5, 6, 9...14, 22, 23). In USB bus

powered designs connect to 3V3OUT to drive out at 3.3V levels, or connect to VCC to drive out at 5V CMOS level. This pin can also be supplied with an external 1.8V - 2.8V supply in order to drive out at lower levels. It should be noted that in this case this supply should originate from the same source as the supply to Vcc. This means that in bus powered designs a regulator which is supplied by the 5V on the USB bus should be used.

7, 18, 21 GND PWR Device ground supply pins

17 3V3OUT Output 3.3V output from integrated L.D.O. regulator. This pin should be decoupled to ground using a 100nF capacitor. The prime purpose of this pin is to provide the internal 3.3V supply to the USB transceiver cell and the internal 1.5kΩ pull up resistor on USBDP. Up to 50mA can be drawn from this pin to power external logic if required. This pin can also be used to supply the FT245R’s VCCIO pin.

20 VCC PWR 3.3V to 5.25V supply to the device core.

25 AGND PWR Device analog ground supply for internal clock multiplier

Miscellaneous Signal Group8, 24 NC NC No internal connection.

19 RESET# Input Can be used by an external device to reset the FT245R. If not required can be left unconnected or pulled up to VCCIO.

26 TEST Input Puts the device into I.C. test mode. Must be grounded for normal operation.

27 OSCI Input Input to 12MHz Oscillator Cell. Optional - Can be left unconnected for normal operation. *

28 OSCO Output Output from 12MHz Oscillator Cell. Optional - Can be left unconnected for normal operation if internal oscilla-tor is used.*

FIFO Interface and Control Group1 D0 I/O FIFO Data Bus Bit 0**

2 D4 I/O FIFO Data Bus Bit 4**

3 D2 I/O FIFO Data Bus Bit 2**

5 D1 I/O FIFO Data Bus Bit 1**

6 D7 I/O FIFO Data Bus Bit 7**

9 D5 I/O FIFO Data Bus Bit 5**

10 D6 I/O FIFO Data Bus Bit 6**

11 D3 I/O FIFO Data Bus Bit 3**

12 PWREN# Output Goes low after the device is configured by USB, then high during USB suspend. Can be used to control power to external logic P-Channel logic level MOSFET switch. Enable the interface pull-down option when using the PWREN# pin in this way.

13 RD# Input Enables the current FIFO data byte on D0...D7 when low. Fetched the next FIFO data byte (if available) from the receive FIFO buffer when RD# goes from high to low. See Section 4.5 for timing diagram. **

14 WR Input Writes the data byte on the D0...D7 pins into the transmit FIFO buffer when WR goes from high to low. See Section 4.5 for timing diagram. **

22 TXE# Output When high, do not write data into the FIFO. When low, data can be written into the FIFO by strobing WR high, then low. During reset this signal pin is tri-state, but pulled up to VCCIO via an internal 200kΩ resistor. See Section 4.5 for timing diagram.

23 RXF# Output When high, do not read data from the FIFO. When low, there is data available in the FIFO which can be read by strobing RD# low, then high again. During reset this signal pin is tri-state, but pulled up to VCCIO via an internal 200kΩ resistor. See Section 4.5 for timing diagram.If the Remote Wakeup option is enabled in the internal EEPROM, during USB suspend mode (PWREN# = 1) RXF# becomes an input which can be used to wake up the USB host from suspend mode. Strobing the pin low will cause the device to request a resume on the USB bus.

*Contact FTDI Support for details of how to use an external crystal, ceramic resonator, or oscillator with the FT245R.

** When used in Input Mode, these pins are pulled to VCCIO via internal 200kΩ resistors. These can be programmed to gently pull low during USB suspend ( PWREN# = “1” ) by setting this option in the internal EEPROM.

FT245R USB UART I.C. Datasheet Version 1.05 © Future Technology Devices International Ltd. 2005

Page 9

4.3 QFN-32 Package

Figure 4 - QFN-32 Package Pin Out

FT245RQ

AGND

GND

GND

GND

TEST

24 4 17 20 26

3V3OUT

VCCIO1

16

NC

RESET#

NC

23

18

13

D0

D1

D2

D3

D4

D5

D6

D6

30

2

32

8

31

6

7

3

RXF#

WR

RD#

TXE#

22

21

10

11

19

15

14USBDP

USBDM

VCC

OSCI27

OSCO28

PWREN# 9

NC12NC5

NC29NC25

Figure 5 - QFN-32 Package Pin Out (Schematic Symbol)

FT245RQ

32 25

24

17

169

8

1

YYXX-A

18

9

1

2

3

4

5

6

7

8

10111213141516

17

19

20

21

22

23

24

25 26 27 28 29 30 31 32

US

BD

P

US

BD

M

3V3O

UT

RESET#

VCC

NC

AGND

TE

ST

OS

CI

OS

CO

TXE#

RXF#

D0

D2

D1

D4

VCCIO

D7

GND

NC

D5

D6

D3

PW

RE

N#

RD

#

WR

GND

GND

NC

NC

NC

NC

FTDITOP

BOTTOM

FT245R USB UART I.C. Datasheet Version 1.05 © Future Technology Devices International Ltd. 2005

Page 10

4.4 QFN-32 Package Signal Descriptions

Table 2 - QFN Package Pin Out Description

Pin No. Name Type DescriptionUSB Interface Group14 USBDP I/O USB Data Signal Plus, incorporating internal series resistor and 1.5kΩ pull up resistor to 3.3V

15 USBDM I/O USB Data Signal Minus, incorporating internal series resistor.

Power and Ground Group1 VCCIO PWR +1.8V to +5.25V supply to FIFO Interface and Control group pins (2,3, 6, ...,11, 21, 22, 30,..32). In USB bus

powered designs connect to 3V3OUT to drive out at 3.3V levels, or connect to VCC to drive out at 5V CMOS level. This pin can also be supplied with an external 1.8V - 2.8V supply in order to drive out at lower levels. It should be noted that in this case this supply should originate from the same source as the supply to Vcc. This means that in bus powered designs a regulator which is supplied by the 5V on the USB bus should be used.

4, 17, 20 GND PWR Device ground supply pins

16 3V3OUT Output 3.3V output from integrated L.D.O. regulator. This pin should be decoupled to ground using a 100nF capacitor. The prime purpose of this pin is to provide the internal 3.3V supply to the USB transceiver cell and the internal 1.5kΩ pull up resistor on USBDP. Up to 50mA can be drawn from this pin to power external logic if required. This pin can also be used to supply the FT245R’s VCCIO pin.

19 VCC PWR 3.3V to 5.25V supply to the device core.

24 AGND PWR Device analog ground supply for internal clock multiplier

Miscellaneous Signal Group5, 12, 13, 23, 25, 29

NC NC No internal connection.

18 RESET# Input Can be used by an external device to reset the FT245R. If not required can be left unconnected or pulled up to VCCIO.

26 TEST Input Puts the device into I.C. test mode. Must be grounded for normal operation.

27 OSCI Input Input to 12MHz Oscillator Cell. Optional - Can be left unconnected for normal operation. *

28 OSCO Output Output from 12MHz Oscillator Cell. Optional - Can be left unconnected for normal operation if internal oscilla-tor is used. *

FIFO Interface and Control Group30 D0 I/O FIFO Data Bus Bit 0**

31 D4 I/O FIFO Data Bus Bit 4**

32 D2 I/O FIFO Data Bus Bit 2**

2 D1 I/O FIFO Data Bus Bit 1**

3 D7 I/O FIFO Data Bus Bit 7**

6 D5 I/O FIFO Data Bus Bit 5**

7 D6 I/O FIFO Data Bus Bit 6**

8 D3 I/O FIFO Data Bus Bit 3**

9 PWREN# Output Goes low after the device is configured by USB, then high during USB suspend. Can be used to control power to external logic P-Channel logic level MOSFET switch. Enable the interface pull-down option when using the PWREN# pin in this way.

10 RD# Input Enables the current FIFO data byte on D0...D7 when low. Fetched the next FIFO data byte (if available) from the receive FIFO buffer when RD# goes from high to low. See Section 4.5 for timing diagram. **

11 WR Input Writes the data byte on the D0...D7 pins into the transmit FIFO buffer when WR goes from high to low. See Section 4.5 for timing diagram. **

21 TXE# Output When high, do not write data into the FIFO. When low, data can be written into the FIFO by strobing WR high, then low. During reset this signal pin is tri-state, but pulled up to VCCIO via an internal 200kΩ resistor. See Section 4.5 for timing diagram.

22 RXF# Output When high, do not read data from the FIFO. When low, there is data available in the FIFO which can be read by strobing RD# low, then high again. During reset this signal pin is tri-state, but pulled up to VCCIO via an internal 200kΩ resistor. See Section 4.5 for timing diagram.If the Remote Wakeup option is enabled in the internal EEPROM, during USB suspend mode (PWREN# = 1) RXF# becomes an input which can be used to wake up the host from suspend mode. Strobing the pin low will cause the device to request a resume on the USB bus.

*Contact FTDI Support for details of how to use an external crystal, ceramic resonator, or oscillator with the FT245R.

** When used in Input Mode, these pins are pulled to VCCIO via internal 200kΩ resistors. These can be programmed to gently pull low during USB suspend ( PWREN# = “1” ) by setting this option in the internal EEPROM.

FT245R USB UART I.C. Datasheet Version 1.05 © Future Technology Devices International Ltd. 2005

Page 11

4.5 FT245R FIFO Timing Diagrams

Figure 6 - FIFO Read Cycle

RXF#

RD#

D[7...0]

T3

T1

T5

T6

T2

T4

Valid Data

Table 3 - FIFO Read Cycle Timings

Time Description Min Max UnitT1 RD Active Pulse Width 50 ns

T2 RD to RD Pre-Charge Time 50 + T6 ns

T3 RD Active to Valid Data* 20 50 ns

T4 Valid Data Hold Time from RD Inactive* 0 ns

T5 RD Inactive to RXF# 0 25 ns

T6 RXF Inactive After RD Cycle 80 ns

* Load = 30pF

Figure 7 - FIFO Write Cycle

Valid DataD[7...0]

WR

TXE#T7

T12T11

T8

T9 T10

Table 4 - FIFO Write Cycle Timings

Time Description Min Max UnitT7 WR Active Pulse Width 50 ns

T8 WR to RD Pre-Charge Time 50 ns

T9 Data Setup Time before WR Inactive 20 ns

T10 Data Hold Time from WR Inactive 0 ns

T11 WR Inactive to TXE# 5 25 ns

T12 TXE Inactive After WR Cycle 80 ns

FT245R USB UART I.C. Datasheet Version 1.05 © Future Technology Devices International Ltd. 2005

Page 19

7. Device ConfigurationsPlease note that pin numbers on the FT245R chip in this section have deliberately been left out as they vary between the FT245RL and FT245RQ versions of the device. All of these configurations apply to both package options for the FT245R device. Please refer to Section 4 for the package option pin-out and signal descriptions.

7.1 Bus Powered Configuration

Figure 13 - Bus Powered Configuration

Figure 13 illustrates the FT245R in a typical USB bus powered design configuration. A USB Bus Powered device gets its power from the USB bus. Basic rules for USB Bus power devices are as follows –

i) On plug-in to USB, the device must draw no more than 100mA.ii) On USB Suspend the device must draw no more than 500μA.iii) A Bus Powered High Power USB Device (one that draws more than 100mA) should use the PWREN# pin to keep

the current below 100mA on plug-in and 500μA on USB suspend.iv) A device that consumes more than 100mA can not be plugged into a USB Bus Powered Hubv) No device can draw more that 500mA from the USB Bus.

The power descriptor in the internal EEPROM should be programmed to match the current draw of the device.A Ferrite Bead is connected in series with USB power to prevent noise from the device and associated circuitry (EMI) being radiated down the USB cable to the Host. The value of the Ferrite Bead depends on the total current required by the circuit – a suitable range of Ferrite Beads is available from Steward (www.steward.com) for example Steward Part # MI0805K400R-00.

FT245R

AGND

GND

GND

GND

TEST100nF

3V3OUT

VCCIO

NC

RESET#

NC

+100nF

10nF

Vcc

D0

D1

D2

D3

D4

D5

D6

D7

RXF#

WR#

RD#

TXE#

USBDP

USBDM

VCC1

2

3

4

5

OSCI

OSCO

PWREN#

FerriteBead

+

4.7uF

SHIELD

GND

GND

GND

GND

Vcc

FT245R USB UART I.C. Datasheet Version 1.05 © Future Technology Devices International Ltd. 2005

Page 20

7.2 Self Powered Configuration

Figure 14 Self Powered Configuration

Figure 14 illustrates the FT245R in a typical USB self powered configuration. A USB Self Powered device gets its power from its own power supply and does not draw current from the USB bus. The basic rules for USB Self power devices are as follows –

i) A Self Powered device should not force current down the USB bus when the USB Host or Hub Controller is powered down.

ii) A Self Powered Device can use as much current as it likes during normal operation and USB suspend as it has its own power supply.

iii) A Self Powered Device can be used with any USB Host and both Bus and Self Powered USB Hubs

The power descriptor in the internal EEPROM should be programmed to a value of zero (self powered).

In order to meet requirement (i) the USB Bus Power is used to control the RESET# Pin of the FT245R device. When the USB Host or Hub is powered up the internal 1.5kΩ resistor on USBDP is pulled up to 3.3V, thus identifying the device as a full speed device to USB. When the USB Host or Hub power is off, RESET# will go low and the device will be held in reset. As RESET# is low, the internal 1.5kΩ resistor will not be pulled up to 3.3V, so no current will be forced down USBDP via the 1.5kΩ pull-up resistor when the host or hub is powered down. Failure to do this may cause some USB host or hub controllers to power up erratically.

Figure 10 illustrates a self powered design which has a 3.3V - 5V supply. A design which is interfacing to 2.8V - 1.8V logic would have a 2.8V - 1.8V supply to VCCIO, and a 3.3V - 5V supply to VCC

Note : When the FT245R is in reset, the FIFO interface and control pins all go tri-state. These pins have internal 200kΩ pull-up resistors to VCCIO, so they will gently pull high unless driven by some external logic.

FT245R

AGND

GND

GND

GND

TEST100nF

3V3OUT

VCCIO

NC

RESET#

NC

+100nF

VCC

D0

D1

D2

D3

D4

D5

D6

D7

RXF#

WR#

RD#

TXE#

USBDP

USBDM

VCC1

2

3

4

5

OSCI

OSCO

PWREN#

4.7uF

SHIELD

GND GND

GND

GND

VCC = 3.3V - 5V

GND

10k

4k7

100nF

FT245R USB UART I.C. Datasheet Version 1.05 © Future Technology Devices International Ltd. 2005

Page 21

7.3 USB Bus Powered with Power Switching Configuration

Figure 15 - Bus Powered with Power Switching Configuration

USB Bus powered circuits need to be able to power down in USB suspend mode in order to meet the <= 500μA total USB suspend current requirement (including external logic). Some external logic can power itself down into a low current state by monitoring the PWREN# signal. For external logic that cannot power itself down in this way, the FT245R provides a simple but effective way of turning off power to external circuitry during USB suspend.

Figure 15 shows how to use a discrete P-Channel Logic Level MOSFET to control the power to external logic circuits. A suitable device would be an International Rectifier (www.irf.com) IRLML6402, or equivalent. It is recommended that a “soft start” circuit consisting of a 1kΩ series resistor and a 0.1μF capacitor are used to limit the current surge when the MOSFET turns on. Without the soft start circuit there is a danger that the transient power surge of the MOSFET turning on will reset the FT245R, or the USB host / hub controller. The values used here allow attached circuitry to power up with a slew rate of ~12.5V per millisecond, in other words the output voltage will transition from GND to 5V in approximately 400 microseconds.

Alternatively, a dedicated power switch I.C. with inbuilt “soft-start” can be used instead of a MOSFET. A suitable power switch I.C. for such an application would be a Micrel (www.micrel.com) MIC2025-2BM or equivalent.

Please note the following points in connection with power controlled designs –

i) The logic to be controlled must have its own reset circuitry so that it will automatically reset itself when power is re-applied on coming out of suspend.

ii) Set the Pull-down on Suspend option in the internal EEPROM.iii) The PWREN# pin should be used to switch the power to the external circuitry.iv) For USB high-power bus powered device (one that consumes greater than 100mA, and up to 500mA of current

from the USB bus), the power consumption of the device should be set in the max power field in the internal EEPROM. A high-power bus powered device must use this descriptor in the internal EEPROM to inform the system of its power requirements.

v) For 3.3V power controlled circuits the VCCIO pin must not be powered down with the external circuitry (the PWREN# signal gets its VCC supply from VCCIO). Either connect the power switch between the output of the 3.3V regulator and the external 3.3V logic or power VCCIO from the 3V3OUT pin of the FT245R.

FT245R

AGND

GND

GND

GND

TEST100nF

3V3OUT

VCCIO

NC

RESET#

NC

+100nF

10nF

5V VCC

D0

D1

D2

D3

D4

D5

D6

D7

TXE#

WR#

RD#

RXF#

USBDP

USBDM

VCC1

2

3

4

5

OSCI

OSCO

PWREN#

FerriteBead

+

4.7uF

SHIELD

GND

GND

GND

GND

0.1uF 0.1uF

1k

Soft StartCircuit

d

g

s Switched 5V Powerto External Logic

5V VCC

P-Channel PowerMOSFET

FT245R USB UART I.C. Datasheet Version 1.05 © Future Technology Devices International Ltd. 2005

Page 22

7.4 USB Bus Powered with 3.3V / 5V Supply and Logic Drive / IO Supply Voltage

Figure 16 - Bus Powered with 3.3V / 5V Supply and Logic Drive

Figure 16 shows a configuration where a jumper switch is used to allow the FT245R to be interfaced with a 3.3V or 5V logic devices. The VCCIO pin is either supplied with 5V from the USB bus, or with 3.3V from the 3V3OUT pin. The supply to VCCIO is also used to supply external logic.

Please note the following in relation to bus powered designs of this type -

i) The PWREN# signal should be used to power down external logic during USB suspend mode, in order to comply with the limit of 500μA. If this is not possible, use the configuration shown in Section 7.3.

ii) The maximum current source from USB Bus during normal operation should not exceed 100mA, otherwise a bus powered design with power switching (Section 7.3) should be used.

Another possible configuration would be to use a discrete low dropout regulator which is supplied by the 5V on the USB bus to supply 2.8V - 1.8V to the VCCIO pin and to the external logic. VCC would be supplied with the 5V from the USB bus. With VCCIO connected to the output of the low dropout regulator, would in turn will cause the FT245R I/O pins to drive out at 2.8V - 1.8V logic levels.

For USB bus powered circuits some considerations have to be taken into account when selecting the regulator –

iii) The regulator must be capable of sustaining its output voltage with an input voltage of 4.35V. A Low Drop Out (L.D.O.) regulator must be selected.

iv) The quiescent current of the regulator must be low in order to meet the USB suspend total current requirement of <= 500μA during USB suspend.

An example of a regulator family that meets these requirements is the MicroChip / Telcom TC55 Series of devices (www.microchip.com). These devices can supply up to 250mA current and have a quiescent current of under 1μA.

FT245R

AGND

GND

GND

GND

TEST100nF

3V3OUT

VCCIO

NC

RESET#

NC

10nF

D0

D1

D2

D3

D4

D5

D6

D7

TXE#

WR#

RD#

RXF#

USBDP

USBDM

VCC1

2

3

4

5

OSCI

OSCO

PWREN#

FerriteBead

+

SHIELD

GND

GND

GND

3.3V or 5V Supplyto External Logic

100nF

+100nF

Vcc

4.7uF

GND

1

Jumper

2

3

Vcc

FT245R USB UART I.C. Datasheet Version 1.05 © Future Technology Devices International Ltd. 2005

Page 23

8. Example Interface Configurations

8.1 USB to MCU FIFO Interface Example

Figure 17 -Example USB to MCU FIFO Interface

Figure 17 illustrates a typical interfacing between the FT245R and a Microcontroller (MCU) FIFO interface. This example uses two I/O ports: one port (8 bits) to transfer data, and the other port (4 or 5 bits) to monitor the TXE# and RXF# status bits and generate the RD# and WR strobes to the FT245R, as required. Using PWREN# for this function is optional.

If the Remote Wakeup option is enabled in the internal EEPROM, during USB suspend mode RXF# becomes an input which can be used to wake up the USB host controller by strobing the pin low.

FT245R

AGND

GND

GND

GND

TEST100nF

3V3OUT

VCCIO

NC

RESET#

NC

+100nF 4.7uF

Vcc

D0

D1

D2

D3

D4

D5

D6

D7

RXF#

WR#

RD#

TXE#

USBDP

USBDM

VCC1

2

3

4

5

OSCI

OSCO

PWREN#

Micro

con

troller

I/O10

I/O11

I/O12

I/O13

FerriteBead

GND

GND

GND

+

GND

10nF

Vcc

Vcc

I/O14

I/O15

I/O16

I/O17

I/O20

I/O21

I/O22

I/O23

I/O24

104

Appendix D Digilent NEXYS II Board schematic

105

106

107

108

109

110

111

112

113

114

115

116

Appendix E PicoBlaze assembly program for testing

Microcontroller with USB

117

; ; ;Port definitions ; CONSTANT USB_FIFO_port, 10 ; CONSTANT USB_FIFO_ctrl, 20 CONSTANT USB_rd_ena, 01 CONSTANT USB_RD, 02 CONSTANT USB_WR, 04 CONSTANT USB_TXE, 40 CONSTANT USB_RXF, 80 ; ; CONSTANT sws_port, 02 ; ; CONSTANT leds_port, 08 ; ;Special Register usage ; NAMEREG sF, DATA_IN_OUT ; ;Useful constants ;---------------------------------------------------------------------------------------------------------- ;ASCII table ;-------------------------------------------------------------------------------------------------------- CONSTANT character_a, 61 CONSTANT character_b, 62 CONSTANT character_c, 63 CONSTANT character_d, 64 CONSTANT character_e, 65 CONSTANT character_f, 66 CONSTANT character_g, 67 CONSTANT character_h, 68 CONSTANT character_i, 69 CONSTANT character_j, 6A CONSTANT character_k, 6B CONSTANT character_l, 6C CONSTANT character_m, 6D CONSTANT character_n, 6E

118

CONSTANT character_o, 6F CONSTANT character_p, 70 CONSTANT character_q, 71 CONSTANT character_r, 72 CONSTANT character_s, 73 CONSTANT character_t, 74 CONSTANT character_u, 75 CONSTANT character_v, 76 CONSTANT character_w, 77 CONSTANT character_x, 78 CONSTANT character_y, 79 CONSTANT character_z, 7A CONSTANT character_A, 41 CONSTANT character_B, 42 CONSTANT character_C, 43 CONSTANT character_D, 44 CONSTANT character_E, 45 CONSTANT character_F, 46 CONSTANT character_G, 47 CONSTANT character_H, 48 CONSTANT character_I, 49 CONSTANT character_J, 4A CONSTANT character_K, 4B CONSTANT character_L, 4C CONSTANT character_M, 4D CONSTANT character_N, 4E CONSTANT character_O, 4F CONSTANT character_P, 50 CONSTANT character_Q, 51 CONSTANT character_R, 52 CONSTANT character_S, 53 CONSTANT character_T, 54 CONSTANT character_U, 55 CONSTANT character_V, 56 CONSTANT character_W, 57 CONSTANT character_X, 58 CONSTANT character_Y, 59 CONSTANT character_Z, 5A CONSTANT character_0, 30 CONSTANT character_1, 31 CONSTANT character_2, 32 CONSTANT character_3, 33 CONSTANT character_4, 34 CONSTANT character_5, 35 CONSTANT character_6, 36 CONSTANT character_7, 37

119

CONSTANT character_8, 38 CONSTANT character_9, 39 CONSTANT character_colon, 3A CONSTANT character_fullstop, 2E CONSTANT character_semi_colon, 3B CONSTANT character_minus, 2D CONSTANT character_plus, 2B CONSTANT character_comma, 2C CONSTANT character_less_than, 3C ;'<' CONSTANT character_greater_than, 3E ;'>' CONSTANT character_open, 28 ;'(' CONSTANT character_close, 29 ;')' CONSTANT character_divide, 2F ;'/' CONSTANT character_equals, 3D CONSTANT character_space, 20 CONSTANT character_CR, 0D ;carriage return CONSTANT character_LF, 0A ;line feed CONSTANT character_question, 3F ;'?' CONSTANT character_dollar, 24 CONSTANT character_exclaim, 21 ;'!' CONSTANT character_BS, 08 ;Back Space command character CONSTANT character_XON, 11 ;Flow control ON CONSTANT character_XOFF, 13 ;Flow control OFF ; ;--------------------------------------------------------------------------------------------------------; ; the main program ;--------------------------------------------------------------------------------------------------------; warm_start: CALL send_Menu CALL send_CR CALL send_CR prompt: LOAD DATA_IN_OUT, character_greater_than CALL send_to_USB read_in_menue: CALL read_from_USB JUMP Z, read_in_menue CALL send_to_USB COMPARE DATA_IN_OUT, character_1 JUMP Z, read_sws_command COMPARE DATA_IN_OUT, character_2 JUMP Z, update_leds COMPARE DATA_IN_OUT, character_3 JUMP Z, reset_leds CALL send_CR ;no valid command input

120

JUMP warm_start ;Try again! ; ;*********************************************************************** ;Read Slide Switches and Echo Thier Status to USB ;*********************************************************************** ; read_sws_command: CALL sws_value INPUT DATA_IN_OUT, sws_port CALL send_to_USB CALL send_CR JUMP prompt ; ;*********************************************************************** ; UPDATE LEDS *********************************************************************** ; update_leds: CALL enter_key wait: CALL read_from_USB JUMP Z, wait CALL send_to_USB OUTPUT DATA_IN_OUT, leds_port CALL send_CR JUMP prompt ; ;*********************************************************************** ;reset_leds ;*********************************************************************** reset_leds: LOAD DATA_IN_OUT,00 OUTPUT DATA_IN_OUT, leds_port CALL send_CR JUMP prompt ;*********************************************************************** ;USB communication routines ;*********************************************************************** send_to_USB: INPUT s0, USB_FIFO_ctrl TEST s0, USB_TXE JUMP Z, send_to_USB

121

OUTPUT DATA_IN_OUT, USB_FIFO_port LOAD s0, USB_WR OUTPUT s0, USB_FIFO_ctrl LOAD s0, 00 OUTPUT s0, USB_FIFO_ctrl RETURN read_from_USB: INPUT s0, USB_FIFO_ctrl TEST s0, USB_RXF RETURN Z LOAD s0, USB_rd_ena OUTPUT s0, USB_FIFO_ctrl OR s0, USB_RD OUTPUT s0, USB_FIFO_ctrl LOAD s0, s0 INPUT DATA_IN_OUT, U SB_FIFO_port LOAD s0, 00 OUTPUT s0, USB_FIFO_ctrl OR s0, FF ; Clear ZERO flag RETURN ;*********************************************************************** ; Text messages *********************************************************************** send_CR: LOAD DATA_IN_OUT, character_CR CALL send_to_USB RETURN ; ;Send a space to the USB ; send_space: LOAD DATA_IN_OUT, character_space CALL send_to_USB RETURN ; sws_value: CALL send_CR LOAD DATA_IN_OUT, character_S CALL send_to_USB LOAD DATA_IN_OUT, character_W CALL send_to_USB LOAD DATA_IN_OUT, character_S CALL send_to_USB CALL send_space

122

LOAD DATA_IN_OUT, character_V CALL send_to_USB LOAD DATA_IN_OUT, character_A CALL send_to_USB LOAD DATA_IN_OUT, character_L CALL send_to_USB LOAD DATA_IN_OUT, character_U CALL send_to_USB LOAD DATA_IN_OUT, character_E CALL send_to_USB LOAD DATA_IN_OUT, character_equals CALL send_to_USB RETURN enter_key: CALL send_CR LOAD DATA_IN_OUT, character_E CALL send_to_USB LOAD DATA_IN_OUT, character_N CALL send_to_USB LOAD DATA_IN_OUT, character_T CALL send_to_USB LOAD DATA_IN_OUT, character_E CALL send_to_USB LOAD DATA_IN_OUT, character_R CALL send_to_USB CALL send_space LOAD DATA_IN_OUT, character_K CALL send_to_USB LOAD DATA_IN_OUT, character_E CALL send_to_USB LOAD DATA_IN_OUT, character_Y CALL send_to_USB CALL send_CR LOAD DATA_IN_OUT, character_greater_than CALL send_to_USB RETURN send_Menu: CALL send_CR LOAD DATA_IN_OUT, character_1 CALL send_to_USB LOAD DATA_IN_OUT, character_minus CALL send_to_USB LOAD DATA_IN_OUT, character_R

123

CALL send_to_USB LOAD DATA_IN_OUT, character_E CALL send_to_USB LOAD DATA_IN_OUT, character_A CALL send_to_USB LOAD DATA_IN_OUT, character_D CALL send_to_USB CALL send_space LOAD DATA_IN_OUT, character_S CALL send_to_USB LOAD DATA_IN_OUT, character_W CALL send_to_USB LOAD DATA_IN_OUT, character_S CALL send_to_USB CALL send_CR LOAD DATA_IN_OUT, character_2 CALL send_to_USB LOAD DATA_IN_OUT, character_minus CALL send_to_USB LOAD DATA_IN_OUT, character_U CALL send_to_USB LOAD DATA_IN_OUT, character_P CALL send_to_USB LOAD DATA_IN_OUT, character_D CALL send_to_USB LOAD DATA_IN_OUT, character_A CALL send_to_USB LOAD DATA_IN_OUT, character_T CALL send_to_USB LOAD DATA_IN_OUT, character_E CALL send_to_USB CALL send_space LOAD DATA_IN_OUT, character_L CALL send_to_USB LOAD DATA_IN_OUT, character_E CALL send_to_USB LOAD DATA_IN_OUT, character_D CALL send_to_USB CALL send_CR LOAD DATA_IN_OUT, character_3 CALL send_to_USB

124

LOAD DATA_IN_OUT, character_minus CALL send_to_USB LOAD DATA_IN_OUT, character_R CALL send_to_USB LOAD DATA_IN_OUT, character_E CALL send_to_USB LOAD DATA_IN_OUT, character_S CALL send_to_USB LOAD DATA_IN_OUT, character_E CALL send_to_USB LOAD DATA_IN_OUT, character_T CALL send_to_USB CALL send_space LOAD DATA_IN_OUT, character_L CALL send_to_USB LOAD DATA_IN_OUT, character_E CALL send_to_USB LOAD DATA_IN_OUT, character_D CALL send_to_USB CALL send_to_USB CALL send_CR RETURN ;

125

Appendix F VHDL code for testing Microcontroller with

USB interface

126

---------------------------------------------------------------------------------- library IEEE; use IEEE.STD_LOGIC_1164.ALL; use IEEE.STD_LOGIC_ARITH.ALL; use IEEE.STD_LOGIC_UNSIGNED.ALL; ---------------------------------------------------------------------------------- entity PICOBLAZE_WITH_USB is PORT ( RST : in std_logic; USB_D : inout std_logic_vector(7 downto 0); USB_RXF : in std_logic; USB_TXE : in std_logic; USB_RD : out std_logic; USB_WR : out std_logic; SWS : in std_logic_vector(7 downto 0); LEDS : out std_logic_vector(7 downto 0); CLK : in std_logic ); end PICOBLAZE_WITH_USB; architecture Behavioral of PICOBLAZE_WITH_USB is ---------------------------------------------------------------------------------- -- declaration of KCPSM3 ---------------------------------------------------------------------------------- component kcpsm3 is Port ( address : out std_logic_vector(9 downto 0); instruction : in std_logic_vector(17 downto 0); port_id : out std_logic_vector(7 downto 0); write_strobe : out std_logic; out_port : out std_logic_vector(7 downto 0); read_strobe : out std_logic; in_port : in std_logic_vector(7 downto 0); interrupt : in std_logic; interrupt_ack : out std_logic; reset : in std_logic; clk : in std_logic); end component; ----------------------------------------------------------------------------------

127

-- declaration of program ROM ---------------------------------------------------------------------------------- component rom_0 is Port ( address : in std_logic_vector(9 downto 0); instruction : out std_logic_vector(17 downto 0); clk : in std_logic); end component; -- -- Signals used to connect KCPSM3 to program ROM and I/O logic -- signal address : std_logic_vector(9 downto 0); signal instruction : std_logic_vector(17 downto 0); signal port_id : std_logic_vector(7 downto 0); signal out_port : std_logic_vector(7 downto 0); signal in_port : std_logic_vector(7 downto 0); signal write_strobe : std_logic; signal read_strobe : std_logic; signal interrupt : std_logic :='0'; signal interrupt_ack : std_logic; -- ---------------------------------------------------------------------------------- -- Signals used to connect KCPSM3 to USB/FIFO interface ---------------------------------------------------------------------------------- signal usb_data: std_logic_vector(7 downto 0):= (others=> 'Z'); signal usb_ctrl: std_logic_vector(7 downto 0):= (others=> '0'); signal usb_rd_ena : std_logic; signal sws_int: std_logic_vector(7 downto 0); signal leds_int: std_logic_vector(7 downto 0):= (others=>'0'); -- -- signal reset_kcpsm3: std_logic:= '0'; -- begin PICOBLAZE: kcpsm3 port map( address => address, instruction => instruction, port_id => port_id,

128

write_strobe => write_strobe, out_port => out_port, read_strobe => read_strobe, in_port => in_port, interrupt => interrupt, interrupt_ack => interrupt_ack, reset => reset_kcpsm3, clk => clk); program_rom: rom_0 port map( address => address, instruction => instruction, clk => clk); -- -- reset_kcpsm3 <= RST; ----------------------------------------------------------------------------------- -- Switches, and LEDs connections and USB/FIFO control register connections ---------------------------------------------------------------------------------- sws_int <= SWS; LEDS <= leds_int; usb_rd_ena<= usb_ctrl(0); USB_RD <= not(usb_ctrl(1)); USB_WR <= usb_ctrl(2); usb_ctrl(7) <= not(USB_RXF); usb_ctrl(6) <= not(USB_TXE); -- ---------------------------------------------------------------------------------------------------------- -- KCPSM3 input ports ---------------------------------------------------------------------------------------------------------- input_ports: process(clk) begin if clk'event and clk='1' then case port_id is -- read Switches at address 02 hex when "00000010" => in_port <= sws_int; -- read USB FIFO data at address 10 hex

129

when "00010000" => in_port <= USB_D; -- read USB FIFO control register at address 20 hex when "00100000" => in_port <= usb_ctrl; when others => in_port <= "XXXXXXXX"; end case; end if; end process input_ports; -- ---------------------------------------------------------------------------------------------------------- -- KCPSM3 output ports ---------------------------------------------------------------------------------------------------------- -- -- adding the output registers to the processor output_ports: process(clk) begin if clk'event and clk='1' then if write_strobe='1' then -- Update LEDs at address 08 hex if port_id="00001000" then leds_int <= out_port; end if; -- Update USB FIFO data register at address 10 hex if port_id="00010000" then usb_data <= out_port; end if;

130

-- Update USB FIFO control register at address 20 hex if port_id="00100000" then usb_ctrl(0) <= out_port(0); usb_ctrl(1) <= out_port(1); usb_ctrl(2) <= out_port(2); end if; end if; end if; end process output_ports; -- -- FPGA drive USB data bus all the time and only relase it when (usb_rd_ena) signal high -- USB_D <= (others=>'Z') when (usb_rd_ena='1') else usb_data; -- end Behavioral;

131

Appendix G PicoBlaze assembly program for GSM Module

with USB

; ;Port definitions ;

132

CONSTANT status_port, 00 CONSTANT tx_data_present, 01 CONSTANT tx_half_full, 02 CONSTANT tx_full, 04 CONSTANT rx_data_present, 08 CONSTANT rx_half_full, 10 CONSTANT rx_full, 20 ; CONSTANT UART_read_port, 01 ; CONSTANT UART_write_port, 01 ; ; CONSTANT USB_FIFO_port, 10 ; CONSTANT USB_FIFO_ctrl, 20 CONSTANT USB_rd_ena, 01 CONSTANT USB_RD, 02 CONSTANT USB_WR, 04 CONSTANT USB_TXE, 40 CONSTANT USB_RXF, 80 ; ; ;Special Register usage ; NAMEREG sF, DATA_IN_OUT ; ; ;Useful constants ; ; ;ASCII table ; CONSTANT character_a, 61 CONSTANT character_b, 62 CONSTANT character_c, 63 CONSTANT character_d, 64 CONSTANT character_e, 65 CONSTANT character_f, 66 CONSTANT character_g, 67 CONSTANT character_h, 68 CONSTANT character_i, 69 CONSTANT character_j, 6A CONSTANT character_k, 6B CONSTANT character_l, 6C CONSTANT character_m, 6D

133

CONSTANT character_n, 6E CONSTANT character_o, 6F CONSTANT character_p, 70 CONSTANT character_q, 71 CONSTANT character_r, 72 CONSTANT character_s, 73 CONSTANT character_t, 74 CONSTANT character_u, 75 CONSTANT character_v, 76 CONSTANT character_w, 77 CONSTANT character_x, 78 CONSTANT character_y, 79 CONSTANT character_z, 7A CONSTANT character_A, 41 CONSTANT character_B, 42 CONSTANT character_C, 43 CONSTANT character_D, 44 CONSTANT character_E, 45 CONSTANT character_F, 46 CONSTANT character_G, 47 CONSTANT character_H, 48 CONSTANT character_I, 49 CONSTANT character_J, 4A CONSTANT character_K, 4B CONSTANT character_L, 4C CONSTANT character_M, 4D CONSTANT character_N, 4E CONSTANT character_O, 4F CONSTANT character_P, 50 CONSTANT character_Q, 51 CONSTANT character_R, 52 CONSTANT character_S, 53 CONSTANT character_T, 54 CONSTANT character_U, 55 CONSTANT character_V, 56 CONSTANT character_W, 57 CONSTANT character_X, 58 CONSTANT character_Y, 59 CONSTANT character_Z, 5A CONSTANT character_0, 30 CONSTANT character_1, 31 CONSTANT character_2, 32 CONSTANT character_3, 33 CONSTANT character_4, 34 CONSTANT character_5, 35 CONSTANT character_6, 36

134

CONSTANT character_7, 37 CONSTANT character_8, 38 CONSTANT character_9, 39 CONSTANT character_colon, 3A CONSTANT character_fullstop, 2E CONSTANT character_semi_colon, 3B CONSTANT character_minus, 2D CONSTANT character_plus, 2B CONSTANT character_comma, 2C CONSTANT character_less_than, 3C ;'<' CONSTANT character_greater_than, 3E ;'>' CONSTANT character_open, 28 ;'(' CONSTANT character_close, 29 ;')' CONSTANT character_divide, 2F ;'/' CONSTANT character_equals, 3D CONSTANT character_space, 20 CONSTANT character_CR, 0D ;carriage return CONSTANT character_LF, 0A ;line feed CONSTANT character_question, 3F ;'?' CONSTANT character_dollar, 24 CONSTANT character_exclaim, 21 ;'!' CONSTANT character_BS, 08 ;Back Space command character CONSTANT character_XON, 11 ;Flow control ON CONSTANT character_XOFF, 13 ;Flow control OFF ; ; ; ; loop: CALL read_from_UART CALL NZ, write_USB_FIFO CALL read_USB_FIFO CALL NZ, send_to_UART JUMP loop ; ; ;*********************************************************************** ;USB communication routines ;*********************************************************************** ;Registers used s0 and DATA_IN_OUT ; read_from_UART: INPUT s0, status_port TEST s0, rx_data_present RETURN Z INPUT DATA_IN_OUT, UART_read_port

135

OR s0, FF RETURN ; ; read_USB_FIFO: INPUT s0, USB_FIFO_ctrl TEST s0, USB_RXF RETURN Z LOAD s0, USB_rd_ena OUTPUT s0, USB_FIFO_ctrl OR s0, USB_RD OUTPUT s0, USB_FIFO_ctrl LOAD s0, s0 INPUT DATA_IN_OUT, USB_FIFO_port LOAD s0, 00 OUTPUT s0, USB_FIFO_ctrl OR s0, FF RETURN ; ;Transmit one character to the UART send_to_UART: INPUT s0, status_port TEST s0, tx_full JUMP NZ, send_to_UART OUTPUT DATA_IN_OUT, UART_write_port RETURN ; write_USB_FIFO: INPUT s0, USB_FIFO_ctrl TEST s0, USB_TXE JUMP Z, write_USB_FIFO OUTPUT DATA_IN_OUT, USB_FIFO_port LOAD s0, USB_WR OUTPUT s0, USB_FIFO_ctrl LOAD s0, 00 OUTPUT s0, USB_FIFO_ctrl RETURN ;

136

Appendix H VHDL code of the GSM Module with USB

137

---------------------------------------------------------------------------------- library IEEE; use IEEE.STD_LOGIC_1164.ALL; use IEEE.STD_LOGIC_ARITH.ALL; use IEEE.STD_LOGIC_UNSIGNED.ALL; ---------------------------------------------------------------------------------------------------------- entity PICOBLAZE_WITH_USB is generic ( C_CLK_FREQ : integer := 50_000_000; -- Core clock frequency C_BAUDRATE : integer := 9600 -- Requested baud rates in bits per second ); PORT ( RST : in std_logic; RXD : in std_logic; TXD : out std_logic; USB_D : inout std_logic_vector(7 downto 0); USB_RXF : in std_logic; USB_TXE : in std_logic; USB_RD : out std_logic; USB_WR : out std_logic; CLK : in std_logic ); end PICOBLAZE_WITH_USB; architecture Behavioral of PICOBLAZE_WITH_USB is -- -- declaration of KCPSM3 -- component kcpsm3 is Port ( address : out std_logic_vector(9 downto 0); instruction : in std_logic_vector(17 downto 0); port_id : out std_logic_vector(7 downto 0); write_strobe : out std_logic; out_port : out std_logic_vector(7 downto 0); read_strobe : out std_logic; in_port : in std_logic_vector(7 downto 0); interrupt : in std_logic; interrupt_ack : out std_logic; reset : in std_logic;

138

clk : in std_logic); end component; ------------------------------------------------------------------------------------------------------------ -- declaration of program ROM ------------------------------------------------------------------------------------------------------------ component rom_0 is Port ( address : in std_logic_vector(9 downto 0); instruction : out std_logic_vector(17 downto 0); clk : in std_logic); end component; -- -- component uart_tx_plus Port ( data_in : in std_logic_vector(7 downto 0); write_buffer : in std_logic; reset_buffer : in std_logic; en_16_x_baud : in std_logic; serial_out : out std_logic; buffer_data_present : out std_logic; buffer_full : out std_logic; buffer_half_full : out std_logic; clk : in std_logic); end component; ------------------------------------------------------------------------------------------------------------ -- declaration of UART Receiver with integral 16 byte FIFO buffer ------------------------------------------------------------------------------------------------------------ component uart_rx Port ( serial_in : in std_logic; data_out : out std_logic_vector(7 downto 0); read_buffer : in std_logic; reset_buffer : in std_logic; en_16_x_baud : in std_logic; buffer_data_present : out std_logic; buffer_full : out std_logic; buffer_half_full : out std_logic; clk : in std_logic); end component; -- ------------------------------------------------------------------------------------------------------------ -- Signals/Constants for UART baud rate generation ------------------------------------------------------------------------------------------------------------ constant ratio: integer := C_CLK_FREQ/(16*C_BAUDRATE); signal baud_count : integer range 0 to (ratio-1) :=0; signal en_16_x_baud : std_logic:='0';

139

-- ------------------------------------------------------------------------------------------------------------ -- Signals used to connect KCPSM3 to program ROM and I/O logic ------------------------------------------------------------------------------------------------------------ signal address : std_logic_vector(9 downto 0); signal instruction : std_logic_vector(17 downto 0); signal port_id : std_logic_vector(7 downto 0); signal out_port : std_logic_vector(7 downto 0); signal in_port : std_logic_vector(7 downto 0); signal write_strobe : std_logic; signal read_strobe : std_logic; signal interrupt : std_logic :='0'; signal interrupt_ack : std_logic; ------------------------------------------------------------------------------------------------------------ -- Signals used to connect KCPSM3 to USB/FIFO interface ------------------------------------------------------------------------------------------------------------ signal usb_data: std_logic_vector(7 downto 0):= (others=> 'Z'); signal usb_ctrl: std_logic_vector(7 downto 0):= (others=> '0'); signal usb_rd_ena : std_logic; ------------------------------------------------------------------------------------------------------------ -- Signals used to connect KCPSM3 and Watch Dog timer ------------------------------------------------------------------------------------------------------------ signal reset_kcpsm3: std_logic:= '0'; -- ------------------------------------------------------------------------------------------------------------ -- Signals for UART connectionss ------------------------------------------------------------------------------------------------------------ signal uart_status: std_logic_vector(7 downto 0):= (OTHERS=>'0'); signal write_to_uart : std_logic; signal tx_data_present : std_logic; signal tx_full : std_logic; signal tx_half_full : std_logic; signal read_from_uart : std_logic; signal rx_data : std_logic_vector(7 downto 0); signal tx_data : std_logic_vector(7 downto 0); signal rx_data_present : std_logic; signal rx_full : std_logic; signal rx_half_full : std_logic; signal rst_uart : std_logic; -- begin PICOBLAZE: kcpsm3

140

port map( address => address, instruction => instruction, port_id => port_id, write_strobe => write_strobe, out_port => out_port, read_strobe => read_strobe, in_port => in_port, interrupt => interrupt, interrupt_ack => interrupt_ack, reset => reset_kcpsm3, clk => clk); program_rom: rom_0 port map( address => address, instruction => instruction, clk => clk); -- -- uart_transmit: uart_tx_plus port map ( data_in => out_port, write_buffer => write_to_uart, reset_buffer => rst_uart, en_16_x_baud => en_16_x_baud, serial_out => TXD, buffer_data_present => tx_data_present, buffer_full => tx_full, buffer_half_full => tx_half_full, clk => clk ); uart_receive: uart_rx port map ( serial_in => RXD, data_out => rx_data, read_buffer => read_from_uart, reset_buffer => rst_uart, en_16_x_baud => en_16_x_baud, buffer_data_present => rx_data_present, buffer_full => rx_full, buffer_half_full => rx_half_full, clk => clk ); --

141

-- reset_kcpsm3 <= RST; ------------------------------------------------------------------------------------------------------------ -- UART status register connections ------------------------------------------------------------------------------------------------------------ uart_status(0) <= tx_data_present; uart_status(1) <= tx_half_full; uart_status(2) <= tx_full; uart_status(3) <= rx_data_present; uart_status(4) <= rx_half_full; uart_status(5) <= rx_full; rst_uart <= uart_status(7) or reset_kcpsm3; ------------------------------------------------------------------------------------------------------------ -- USB/FIFO control register connections ------------------------------------------------------------------------------------------------------------ usb_rd_ena<= usb_ctrl(0); USB_RD <= not(usb_ctrl(1)); USB_WR <= usb_ctrl(2); usb_ctrl(7) <= not(USB_RXF); usb_ctrl(6) <= not(USB_TXE); -- ---------------------------------------------------------------------------------------------------------- -- KCPSM3 input ports ---------------------------------------------------------------------------------------------------------- -- -- -- The inputs connect via a pipelined multiplexer -- input_ports: process(clk) begin if clk'event and clk='1' then case port_id is -- read UART status register at address 00 hex when "00000000" => in_port <= uart_status; -- read UART receive data at address 01 hex when "00000001" => in_port <= rx_data;

142

-- read USB FIFO data at address 10 hex when "00010000" => in_port <= USB_D; -- read USB FIFO control register at address 20 hex when "00100000" => in_port <= usb_ctrl; when others => in_port <= "XXXXXXXX"; end case; if (read_strobe='1' and port_id(0)='1') then read_from_uart <= '1'; else read_from_uart <= '0'; end if; end if; end process input_ports; ---------------------------------------------------------------------------------------------------------- -- KCPSM3 output ports ---------------------------------------------------------------------------------------------------------- -- adding the output registers to the processor output_ports: process(clk) begin if clk'event and clk='1' then if write_strobe='1' then -- Write UART status/control register at address 00 hex if port_id="00000000" then uart_status(7) <= out_port(7); end if; -- Update USB FIFO data register at address 10 hex

143

if port_id="00010000" then usb_data <= out_port; end if; -- Update USB FIFO control register at address 20 hex if port_id="00100000" then usb_ctrl(0) <= out_port(0); usb_ctrl(1) <= out_port(1); usb_ctrl(2) <= out_port(2); end if; end if; end if; end process output_ports; -- -- write_to_uart <= '1' when (write_strobe='1' and port_id(0)='1') else '0'; USB_D <= usb_data when (usb_rd_ena='0') else (others=>'Z'); baud_timer: process(clk) begin if clk'event and clk='1' then if baud_count=(ratio-1) then baud_count <= 0; en_16_x_baud <= '1'; else baud_count <= baud_count + 1; en_16_x_baud <= '0'; end if; end if; end process baud_timer; end Behavioral;

144

Appendix I PicoBlaze Instruction Set

145

146

147

148

149

Appendix J

PicoBlaze VHDL Code

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

150

-- Library declarations -- -- Standard IEEE libraries -- library IEEE; use IEEE.STD_LOGIC_1164.ALL; use IEEE.STD_LOGIC_ARITH.ALL; use IEEE.STD_LOGIC_UNSIGNED.ALL; library unisim; use unisim.vcomponents.all; -- ------------------------------------------------------------------------------------ -- -- Main Entity for KCPSM3 -- entity kcpsm3 is Port ( address : out std_logic_vector(9 downto 0); instruction : in std_logic_vector(17 downto 0); port_id : out std_logic_vector(7 downto 0); write_strobe : out std_logic; out_port : out std_logic_vector(7 downto 0); read_strobe : out std_logic; in_port : in std_logic_vector(7 downto 0); interrupt : in std_logic; interrupt_ack : out std_logic; reset : in std_logic; clk : in std_logic); end kcpsm3; -- ------------------------------------------------------------------------------------ -- -- Start of Main Architecture for KCPSM3 -- architecture low_level_definition of kcpsm3 is -- ------------------------------------------------------------------------------------ -- -- Signals used in KCPSM3 -- ------------------------------------------------------------------------------------ -- -- Fundamental control and decode signals -- signal t_state : std_logic; signal not_t_state : std_logic; signal internal_reset : std_logic; signal reset_delay : std_logic; signal move_group : std_logic; signal condition_met : std_logic; signal normal_count : std_logic; signal call_type : std_logic; signal push_or_pop_type : std_logic; signal valid_to_move : std_logic; -- -- Flag signals -- signal flag_type : std_logic; signal flag_write : std_logic; signal flag_enable : std_logic; signal zero_flag : std_logic; signal sel_shadow_zero : std_logic; signal low_zero : std_logic; signal high_zero : std_logic; signal low_zero_carry : std_logic; signal high_zero_carry : std_logic; signal zero_carry : std_logic; signal zero_fast_route : std_logic; signal low_parity : std_logic; signal high_parity : std_logic; signal parity_carry : std_logic; signal parity : std_logic; signal carry_flag : std_logic; signal sel_parity : std_logic; signal sel_arith_carry : std_logic; signal sel_shift_carry : std_logic; signal sel_shadow_carry : std_logic; signal sel_carry : std_logic_vector(3 downto 0); signal carry_fast_route : std_logic; -- -- Interrupt signals -- signal active_interrupt : std_logic; signal int_pulse : std_logic; signal clean_int : std_logic; signal shadow_carry : std_logic; signal shadow_zero : std_logic; signal int_enable : std_logic; signal int_update_enable : std_logic; signal int_enable_value : std_logic; signal interrupt_ack_internal : std_logic; -- -- Program Counter signals --

151

signal pc : std_logic_vector(9 downto 0); signal pc_vector : std_logic_vector(9 downto 0); signal pc_vector_carry : std_logic_vector(8 downto 0); signal inc_pc_vector : std_logic_vector(9 downto 0); signal pc_value : std_logic_vector(9 downto 0); signal pc_value_carry : std_logic_vector(8 downto 0); signal inc_pc_value : std_logic_vector(9 downto 0); signal pc_enable : std_logic; -- -- Data Register signals -- signal sx : std_logic_vector(7 downto 0); signal sy : std_logic_vector(7 downto 0); signal register_type : std_logic; signal register_write : std_logic; signal register_enable : std_logic; signal second_operand : std_logic_vector(7 downto 0); -- -- Scratch Pad Memory signals -- signal memory_data : std_logic_vector(7 downto 0); signal store_data : std_logic_vector(7 downto 0); signal memory_type : std_logic; signal memory_write : std_logic; signal memory_enable : std_logic; -- -- Stack signals -- signal stack_pop_data : std_logic_vector(9 downto 0); signal stack_ram_data : std_logic_vector(9 downto 0); signal stack_address : std_logic_vector(4 downto 0); signal half_stack_address : std_logic_vector(4 downto 0); signal stack_address_carry : std_logic_vector(3 downto 0); signal next_stack_address : std_logic_vector(4 downto 0); signal stack_write_enable : std_logic; signal not_active_interrupt : std_logic; -- -- ALU signals -- signal logical_result : std_logic_vector(7 downto 0); signal logical_value : std_logic_vector(7 downto 0); signal sel_logical : std_logic; signal shift_result : std_logic_vector(7 downto 0); signal shift_value : std_logic_vector(7 downto 0); signal sel_shift : std_logic; signal high_shift_in : std_logic; signal low_shift_in : std_logic; signal shift_in : std_logic; signal shift_carry : std_logic; signal shift_carry_value : std_logic; signal arith_result : std_logic_vector(7 downto 0); signal arith_value : std_logic_vector(7 downto 0); signal half_arith : std_logic_vector(7 downto 0); signal arith_internal_carry : std_logic_vector(7 downto 0); signal sel_arith_carry_in : std_logic; signal arith_carry_in : std_logic; signal invert_arith_carry : std_logic; signal arith_carry_out : std_logic; signal sel_arith : std_logic; signal arith_carry : std_logic; -- -- ALU multiplexer signals -- signal input_fetch_type : std_logic; signal sel_group : std_logic; signal alu_group : std_logic_vector(7 downto 0); signal input_group : std_logic_vector(7 downto 0); signal alu_result : std_logic_vector(7 downto 0); -- -- read and write strobes -- signal io_initial_decode : std_logic; signal write_active : std_logic; signal read_active : std_logic; -- -- ------------------------------------------------------------------------------------ -- -- Attributes to define LUT contents during implementation for primitives not -- contained within generate loops. In each case the information is repeated -- in the generic map for functional simulation -- attribute INIT : string; attribute INIT of t_state_lut : label is "1"; attribute INIT of int_pulse_lut : label is "0080"; attribute INIT of int_update_lut : label is "EAAA"; attribute INIT of int_value_lut : label is "04"; attribute INIT of move_group_lut : label is "7400"; attribute INIT of condition_met_lut : label is "5A3C"; attribute INIT of normal_count_lut : label is "2F"; attribute INIT of call_type_lut : label is "1000"; attribute INIT of push_pop_lut : label is "5400"; attribute INIT of valid_move_lut : label is "D";

152

attribute INIT of flag_type_lut : label is "41FC"; attribute INIT of flag_enable_lut : label is "8"; attribute INIT of low_zero_lut : label is "0001"; attribute INIT of high_zero_lut : label is "0001"; attribute INIT of sel_shadow_zero_lut : label is "3F"; attribute INIT of low_parity_lut : label is "6996"; attribute INIT of high_parity_lut : label is "6996"; attribute INIT of sel_parity_lut : label is "F3FF"; attribute INIT of sel_arith_carry_lut : label is "F3"; attribute INIT of sel_shift_carry_lut : label is "C"; attribute INIT of sel_shadow_carry_lut : label is "3"; attribute INIT of register_type_lut : label is "0145"; attribute INIT of register_enable_lut : label is "8"; attribute INIT of memory_type_lut : label is "0400"; attribute INIT of memory_enable_lut : label is "8000"; attribute INIT of sel_logical_lut : label is "FFE2"; attribute INIT of low_shift_in_lut : label is "E4"; attribute INIT of high_shift_in_lut : label is "E4"; attribute INIT of shift_carry_lut : label is "E4"; attribute INIT of sel_arith_lut : label is "1F"; attribute INIT of input_fetch_type_lut : label is "0002"; attribute INIT of io_decode_lut : label is "0010"; attribute INIT of write_active_lut : label is "4000"; attribute INIT of read_active_lut : label is "0100"; -- ------------------------------------------------------------------------------------ -- -- Start of KCPSM3 circuit description -- ------------------------------------------------------------------------------------ -- begin -- ------------------------------------------------------------------------------------ -- -- Fundamental Control -- -- Definition of T-state and internal reset -- ------------------------------------------------------------------------------------ -- t_state_lut: LUT1 --synthesis translate_off generic map (INIT => X"1") --synthesis translate_on port map( I0 => t_state, O => not_t_state ); toggle_flop: FDR port map ( D => not_t_state, Q => t_state, R => internal_reset, C => clk); reset_flop1: FDS port map ( D => '0', Q => reset_delay, S => reset, C => clk); reset_flop2: FDS port map ( D => reset_delay, Q => internal_reset, S => reset, C => clk); -- ------------------------------------------------------------------------------------ -- -- Interrupt input logic, Interrupt enable and shadow Flags. -- -- Captures interrupt input and enables the shadow flags. -- Decodes instructions which set and reset the interrupt enable flip-flop. -- ------------------------------------------------------------------------------------ -- -- Interrupt capture int_capture_flop: FDR port map ( D => interrupt, Q => clean_int, R => internal_reset, C => clk); int_pulse_lut: LUT4 --synthesis translate_off generic map (INIT => X"0080") --synthesis translate_on port map( I0 => t_state, I1 => clean_int, I2 => int_enable, I3 => active_interrupt, O => int_pulse );

153

int_flop: FDR port map ( D => int_pulse, Q => active_interrupt, R => internal_reset, C => clk); ack_flop: FD port map ( D => active_interrupt, Q => interrupt_ack_internal, C => clk); interrupt_ack <= interrupt_ack_internal; -- Shadow flags shadow_carry_flop: FDE port map ( D => carry_flag, Q => shadow_carry, CE => active_interrupt, C => clk); shadow_zero_flop: FDE port map ( D => zero_flag, Q => shadow_zero, CE => active_interrupt, C => clk); -- Decode instructions that set or reset interrupt enable int_update_lut: LUT4 --synthesis translate_off generic map (INIT => X"EAAA") --synthesis translate_on port map( I0 => active_interrupt, I1 => instruction(15), I2 => instruction(16), I3 => instruction(17), O => int_update_enable ); int_value_lut: LUT3 --synthesis translate_off generic map (INIT => X"04") --synthesis translate_on port map( I0 => active_interrupt, I1 => instruction(0), I2 => interrupt_ack_internal, O => int_enable_value ); int_enable_flop: FDRE port map ( D => int_enable_value, Q => int_enable, CE => int_update_enable, R => internal_reset, C => clk); -- ------------------------------------------------------------------------------------ -- -- Decodes for the control of the program counter and CALL/RETURN stack -- ------------------------------------------------------------------------------------ -- move_group_lut: LUT4 --synthesis translate_off generic map (INIT => X"7400") --synthesis translate_on port map( I0 => instruction(14), I1 => instruction(15), I2 => instruction(16), I3 => instruction(17), O => move_group ); condition_met_lut: LUT4 --synthesis translate_off generic map (INIT => X"5A3C") --synthesis translate_on port map( I0 => carry_flag, I1 => zero_flag, I2 => instruction(10), I3 => instruction(11), O => condition_met ); normal_count_lut: LUT3 --synthesis translate_off generic map (INIT => X"2F") --synthesis translate_on port map( I0 => instruction(12), I1 => condition_met, I2 => move_group, O => normal_count ); call_type_lut: LUT4 --synthesis translate_off

154

generic map (INIT => X"1000") --synthesis translate_on port map( I0 => instruction(14), I1 => instruction(15), I2 => instruction(16), I3 => instruction(17), O => call_type ); push_pop_lut: LUT4 --synthesis translate_off generic map (INIT => X"5400") --synthesis translate_on port map( I0 => instruction(14), I1 => instruction(15), I2 => instruction(16), I3 => instruction(17), O => push_or_pop_type ); valid_move_lut: LUT2 --synthesis translate_off generic map (INIT => X"D") --synthesis translate_on port map( I0 => instruction(12), I1 => condition_met, O => valid_to_move ); -- ------------------------------------------------------------------------------------ -- -- The ZERO and CARRY Flags -- ------------------------------------------------------------------------------------ -- -- Enable for flags flag_type_lut: LUT4 --synthesis translate_off generic map (INIT => X"41FC") --synthesis translate_on port map( I0 => instruction(14), I1 => instruction(15), I2 => instruction(16), I3 => instruction(17), O => flag_type ); flag_write_flop: FD port map ( D => flag_type, Q => flag_write, C => clk); flag_enable_lut: LUT2 --synthesis translate_off generic map (INIT => X"8") --synthesis translate_on port map( I0 => t_state, I1 => flag_write, O => flag_enable ); -- Zero Flag low_zero_lut: LUT4 --synthesis translate_off generic map (INIT => X"0001") --synthesis translate_on port map( I0 => alu_result(0), I1 => alu_result(1), I2 => alu_result(2), I3 => alu_result(3), O => low_zero ); high_zero_lut: LUT4 --synthesis translate_off generic map (INIT => X"0001") --synthesis translate_on port map( I0 => alu_result(4), I1 => alu_result(5), I2 => alu_result(6), I3 => alu_result(7), O => high_zero ); low_zero_muxcy: MUXCY port map( DI => '0', CI => '1', S => low_zero, O => low_zero_carry ); high_zero_cymux: MUXCY port map( DI => '0', CI => low_zero_carry, S => high_zero, O => high_zero_carry ); sel_shadow_zero_lut: LUT3 --synthesis translate_off

155

generic map (INIT => X"3F") --synthesis translate_on port map( I0 => shadow_zero, I1 => instruction(16), I2 => instruction(17), O => sel_shadow_zero ); zero_cymux: MUXCY port map( DI => shadow_zero, CI => high_zero_carry, S => sel_shadow_zero, O => zero_carry ); zero_xor: XORCY port map( LI => '0', CI => zero_carry, O => zero_fast_route); zero_flag_flop: FDRE port map ( D => zero_fast_route, Q => zero_flag, CE => flag_enable, R => internal_reset, C => clk); -- Parity detection low_parity_lut: LUT4 --synthesis translate_off generic map (INIT => X"6996") --synthesis translate_on port map( I0 => logical_result(0), I1 => logical_result(1), I2 => logical_result(2), I3 => logical_result(3), O => low_parity ); high_parity_lut: LUT4 --synthesis translate_off generic map (INIT => X"6996") --synthesis translate_on port map( I0 => logical_result(4), I1 => logical_result(5), I2 => logical_result(6), I3 => logical_result(7), O => high_parity ); parity_muxcy: MUXCY port map( DI => '0', CI => '1', S => low_parity, O => parity_carry ); parity_xor: XORCY port map( LI => high_parity, CI => parity_carry, O => parity); -- CARRY flag selection sel_parity_lut: LUT4 --synthesis translate_off generic map (INIT => X"F3FF") --synthesis translate_on port map( I0 => parity, I1 => instruction(13), I2 => instruction(15), I3 => instruction(16), O => sel_parity ); sel_arith_carry_lut: LUT3 --synthesis translate_off generic map (INIT => X"F3") --synthesis translate_on port map( I0 => arith_carry, I1 => instruction(16), I2 => instruction(17), O => sel_arith_carry ); sel_shift_carry_lut: LUT2 --synthesis translate_off generic map (INIT => X"C") --synthesis translate_on port map( I0 => shift_carry, I1 => instruction(15), O => sel_shift_carry ); sel_shadow_carry_lut: LUT2 --synthesis translate_off generic map (INIT => X"3") --synthesis translate_on port map( I0 => shadow_carry, I1 => instruction(17),

156

O => sel_shadow_carry ); sel_shadow_muxcy: MUXCY port map( DI => shadow_carry, CI => '0', S => sel_shadow_carry, O => sel_carry(0) ); sel_shift_muxcy: MUXCY port map( DI => shift_carry, CI => sel_carry(0), S => sel_shift_carry, O => sel_carry(1) ); sel_arith_muxcy: MUXCY port map( DI => arith_carry, CI => sel_carry(1), S => sel_arith_carry, O => sel_carry(2) ); sel_parity_muxcy: MUXCY port map( DI => parity, CI => sel_carry(2), S => sel_parity, O => sel_carry(3) ); carry_xor: XORCY port map( LI => '0', CI => sel_carry(3), O => carry_fast_route); carry_flag_flop: FDRE port map ( D => carry_fast_route, Q => carry_flag, CE => flag_enable, R => internal_reset, C => clk); -- ------------------------------------------------------------------------------------ -- -- The Program Counter -- -- Definition of a 10-bit counter which can be loaded from two sources -- ------------------------------------------------------------------------------------ -- invert_enable: INV -- Inverter should be implemented in the CE to flip flops port map( I => t_state, O => pc_enable); pc_loop: for i in 0 to 9 generate -- -- Attribute to define LUT contents during implementation -- The information is repeated in the generic map for functional simulation -- attribute INIT : string; attribute INIT of vector_select_mux : label is "E4"; attribute INIT of value_select_mux : label is "E4"; -- begin vector_select_mux: LUT3 --synthesis translate_off generic map (INIT => X"E4") --synthesis translate_on port map( I0 => instruction(15), I1 => instruction(i), I2 => stack_pop_data(i), O => pc_vector(i) ); value_select_mux: LUT3 --synthesis translate_off generic map (INIT => X"E4") --synthesis translate_on port map( I0 => normal_count, I1 => inc_pc_vector(i), I2 => pc(i), O => pc_value(i) ); register_bit: FDRSE port map ( D => inc_pc_value(i), Q => pc(i), R => internal_reset, S => active_interrupt, CE => pc_enable, C => clk); pc_lsb_carry: if i=0 generate begin pc_vector_muxcy: MUXCY port map( DI => '0',

157

CI => instruction(13), S => pc_vector(i), O => pc_vector_carry(i)); pc_vector_xor: XORCY port map( LI => pc_vector(i), CI => instruction(13), O => inc_pc_vector(i)); pc_value_muxcy: MUXCY port map( DI => '0', CI => normal_count, S => pc_value(i), O => pc_value_carry(i)); pc_value_xor: XORCY port map( LI => pc_value(i), CI => normal_count, O => inc_pc_value(i)); end generate pc_lsb_carry; pc_mid_carry: if i>0 and i<9 generate begin pc_vector_muxcy: MUXCY port map( DI => '0', CI => pc_vector_carry(i-1), S => pc_vector(i), O => pc_vector_carry(i)); pc_vector_xor: XORCY port map( LI => pc_vector(i), CI => pc_vector_carry(i-1), O => inc_pc_vector(i)); pc_value_muxcy: MUXCY port map( DI => '0', CI => pc_value_carry(i-1), S => pc_value(i), O => pc_value_carry(i)); pc_value_xor: XORCY port map( LI => pc_value(i), CI => pc_value_carry(i-1), O => inc_pc_value(i)); end generate pc_mid_carry; pc_msb_carry: if i=9 generate begin pc_vector_xor: XORCY port map( LI => pc_vector(i), CI => pc_vector_carry(i-1), O => inc_pc_vector(i)); pc_value_xor: XORCY port map( LI => pc_value(i), CI => pc_value_carry(i-1), O => inc_pc_value(i)); end generate pc_msb_carry; end generate pc_loop; address <= pc; -- ------------------------------------------------------------------------------------ -- -- Register Bank and second operand selection. -- -- Definition of an 8-bit dual port RAM with 16 locations -- including write enable decode. -- -- Outputs are assigned to PORT_ID and OUT_PORT. -- ------------------------------------------------------------------------------------ -- -- Forming decode signal register_type_lut: LUT4 --synthesis translate_off generic map (INIT => X"0145") --synthesis translate_on port map( I0 => active_interrupt, I1 => instruction(15), I2 => instruction(16), I3 => instruction(17), O => register_type ); register_write_flop: FD port map ( D => register_type,

158

Q => register_write, C => clk); register_enable_lut: LUT2 --synthesis translate_off generic map (INIT => X"8") --synthesis translate_on port map( I0 => t_state, I1 => register_write, O => register_enable ); reg_loop: for i in 0 to 7 generate -- -- Attribute to define RAM contents during implementation -- The information is repeated in the generic map for functional simulation -- attribute INIT : string; attribute INIT of register_bit : label is "0000"; attribute INIT of operand_select_mux : label is "E4"; -- begin register_bit: RAM16X1D --synthesis translate_off generic map(INIT => X"0000") --synthesis translate_on port map ( D => alu_result(i), WE => register_enable, WCLK => clk, A0 => instruction(8), A1 => instruction(9), A2 => instruction(10), A3 => instruction(11), DPRA0 => instruction(4), DPRA1 => instruction(5), DPRA2 => instruction(6), DPRA3 => instruction(7), SPO => sx(i), DPO => sy(i)); operand_select_mux: LUT3 --synthesis translate_off generic map (INIT => X"E4") --synthesis translate_on port map( I0 => instruction(12), I1 => instruction(i), I2 => sy(i), O => second_operand(i) ); end generate reg_loop; out_port <= sx; port_id <= second_operand; -- ------------------------------------------------------------------------------------ -- -- Store Memory -- -- Definition of an 8-bit single port RAM with 64 locations -- including write enable decode. -- ------------------------------------------------------------------------------------ -- -- Forming decode signal memory_type_lut: LUT4 --synthesis translate_off generic map (INIT => X"0400") --synthesis translate_on port map( I0 => active_interrupt, I1 => instruction(15), I2 => instruction(16), I3 => instruction(17), O => memory_type ); memory_write_flop: FD port map ( D => memory_type, Q => memory_write, C => clk); memory_enable_lut: LUT4 --synthesis translate_off generic map (INIT => X"8000") --synthesis translate_on port map( I0 => t_state, I1 => instruction(13), I2 => instruction(14), I3 => memory_write, O => memory_enable ); store_loop: for i in 0 to 7 generate -- -- Attribute to define RAM contents during implementation

159

-- The information is repeated in the generic map for functional simulation -- attribute INIT : string; attribute INIT of memory_bit : label is "0000000000000000"; -- begin memory_bit: RAM64X1S --synthesis translate_off generic map(INIT => X"0000000000000000") --synthesis translate_on port map ( D => sx(i), WE => memory_enable, WCLK => clk, A0 => second_operand(0), A1 => second_operand(1), A2 => second_operand(2), A3 => second_operand(3), A4 => second_operand(4), A5 => second_operand(5), O => memory_data(i)); store_flop: FD port map ( D => memory_data(i), Q => store_data(i), C => clk); end generate store_loop; -- ------------------------------------------------------------------------------------ -- -- Logical operations -- -- Definition of AND, OR, XOR and LOAD functions which also provides TEST. -- Includes pipeline stage used to form ALU multiplexer including decode. -- ------------------------------------------------------------------------------------ -- sel_logical_lut: LUT4 --synthesis translate_off generic map (INIT => X"FFE2") --synthesis translate_on port map( I0 => instruction(14), I1 => instruction(15), I2 => instruction(16), I3 => instruction(17), O => sel_logical ); logical_loop: for i in 0 to 7 generate -- -- Attribute to define LUT contents during implementation -- The information is repeated in the generic map for functional simulation attribute INIT : string; attribute INIT of logical_lut : label is "6E8A"; -- begin logical_lut: LUT4 --synthesis translate_off generic map (INIT => X"6E8A") --synthesis translate_on port map( I0 => second_operand(i), I1 => sx(i), I2 => instruction(13), I3 => instruction(14), O => logical_value(i)); logical_flop: FDR port map ( D => logical_value(i), Q => logical_result(i), R => sel_logical, C => clk); end generate logical_loop; -- -- ------------------------------------------------------------------------------------ -- -- Shift and Rotate operations -- -- Includes pipeline stage used to form ALU multiplexer including decode. -- ------------------------------------------------------------------------------------ -- sel_shift_inv: INV -- Inverter should be implemented in the reset to flip flops port map( I => instruction(17), O => sel_shift); -- Bit to input to shift register high_shift_in_lut: LUT3 --synthesis translate_off generic map (INIT => X"E4")

160

--synthesis translate_on port map( I0 => instruction(1), I1 => sx(0), I2 => instruction(0), O => high_shift_in ); low_shift_in_lut: LUT3 --synthesis translate_off generic map (INIT => X"E4") --synthesis translate_on port map( I0 => instruction(1), I1 => carry_flag, I2 => sx(7), O => low_shift_in ); shift_in_muxf5: MUXF5 port map( I1 => high_shift_in, I0 => low_shift_in, S => instruction(2), O => shift_in ); -- Forming shift carry signal shift_carry_lut: LUT3 --synthesis translate_off generic map (INIT => X"E4") --synthesis translate_on port map( I0 => instruction(3), I1 => sx(7), I2 => sx(0), O => shift_carry_value ); pipeline_bit: FD port map ( D => shift_carry_value, Q => shift_carry, C => clk); shift_loop: for i in 0 to 7 generate begin lsb_shift: if i=0 generate -- -- Attribute to define LUT contents during implementation -- The information is repeated in the generic map for functional simulation attribute INIT : string; attribute INIT of shift_mux_lut : label is "E4"; -- begin shift_mux_lut: LUT3 --synthesis translate_off generic map (INIT => X"E4") --synthesis translate_on port map( I0 => instruction(3), I1 => shift_in, I2 => sx(i+1), O => shift_value(i) ); end generate lsb_shift; mid_shift: if i>0 and i<7 generate -- -- Attribute to define LUT contents during implementation -- The information is repeated in the generic map for functional simulation attribute INIT : string; attribute INIT of shift_mux_lut : label is "E4"; -- begin shift_mux_lut: LUT3 --synthesis translate_off generic map (INIT => X"E4") --synthesis translate_on port map( I0 => instruction(3), I1 => sx(i-1), I2 => sx(i+1), O => shift_value(i) ); end generate mid_shift; msb_shift: if i=7 generate -- -- Attribute to define LUT contents during implementation -- The information is repeated in the generic map for functional simulation attribute INIT : string; attribute INIT of shift_mux_lut : label is "E4"; -- begin shift_mux_lut: LUT3 --synthesis translate_off generic map (INIT => X"E4") --synthesis translate_on

161

port map( I0 => instruction(3), I1 => sx(i-1), I2 => shift_in, O => shift_value(i) ); end generate msb_shift; shift_flop: FDR port map ( D => shift_value(i), Q => shift_result(i), R => sel_shift, C => clk); end generate shift_loop; -- ------------------------------------------------------------------------------------ -- -- Arithmetic operations -- -- Definition of ADD, ADDCY, SUB and SUBCY functions which also provides COMPARE. -- Includes pipeline stage used to form ALU multiplexer including decode. -- ------------------------------------------------------------------------------------ -- sel_arith_lut: LUT3 --synthesis translate_off generic map (INIT => X"1F") --synthesis translate_on port map( I0 => instruction(14), I1 => instruction(15), I2 => instruction(16), O => sel_arith ); arith_loop: for i in 0 to 7 generate -- -- Attribute to define LUT contents during implementation -- The information is repeated in the generic map for functional simulation attribute INIT : string; attribute INIT of arith_lut : label is "96"; -- begin lsb_arith: if i=0 generate -- -- Attribute to define LUT contents during implementation -- The information is repeated in the generic map for functional simulation attribute INIT : string; attribute INIT of arith_carry_in_lut : label is "6C"; -- begin arith_carry_in_lut: LUT3 --synthesis translate_off generic map (INIT => X"6C") --synthesis translate_on port map( I0 => instruction(13), I1 => instruction(14), I2 => carry_flag, O => sel_arith_carry_in ); arith_carry_in_muxcy: MUXCY port map( DI => '0', CI => '1', S => sel_arith_carry_in, O => arith_carry_in); arith_muxcy: MUXCY port map( DI => sx(i), CI => arith_carry_in, S => half_arith(i), O => arith_internal_carry(i)); arith_xor: XORCY port map( LI => half_arith(i), CI => arith_carry_in, O => arith_value(i)); end generate lsb_arith; mid_arith: if i>0 and i<7 generate begin arith_muxcy: MUXCY port map( DI => sx(i), CI => arith_internal_carry(i-1), S => half_arith(i), O => arith_internal_carry(i)); arith_xor: XORCY port map( LI => half_arith(i), CI => arith_internal_carry(i-1), O => arith_value(i));

162

end generate mid_arith; msb_arith: if i=7 generate -- -- Attribute to define LUT contents during implementation -- The information is repeated in the generic map for functional simulation attribute INIT : string; attribute INIT of arith_carry_out_lut : label is "2"; -- begin arith_muxcy: MUXCY port map( DI => sx(i), CI => arith_internal_carry(i-1), S => half_arith(i), O => arith_internal_carry(i)); arith_xor: XORCY port map( LI => half_arith(i), CI => arith_internal_carry(i-1), O => arith_value(i)); arith_carry_out_lut: LUT1 --synthesis translate_off generic map (INIT => X"2") --synthesis translate_on port map( I0 => instruction(14), O => invert_arith_carry ); arith_carry_out_xor: XORCY port map( LI => invert_arith_carry, CI => arith_internal_carry(i), O => arith_carry_out); arith_carry_flop: FDR port map ( D => arith_carry_out, Q => arith_carry, R => sel_arith, C => clk); end generate msb_arith; arith_lut: LUT3 --synthesis translate_off generic map (INIT => X"96") --synthesis translate_on port map( I0 => sx(i), I1 => second_operand(i), I2 => instruction(14), O => half_arith(i)); arith_flop: FDR port map ( D => arith_value(i), Q => arith_result(i), R => sel_arith, C => clk); end generate arith_loop; -- -- ------------------------------------------------------------------------------------ -- -- ALU multiplexer -- ------------------------------------------------------------------------------------ -- input_fetch_type_lut: LUT4 --synthesis translate_off generic map (INIT => X"0002") --synthesis translate_on port map( I0 => instruction(14), I1 => instruction(15), I2 => instruction(16), I3 => instruction(17), O => input_fetch_type ); sel_group_flop: FD port map ( D => input_fetch_type, Q => sel_group, C => clk); alu_mux_loop: for i in 0 to 7 generate -- -- Attribute to define LUT contents during implementation -- The information is repeated in the generic map for functional simulation attribute INIT : string; attribute INIT of or_lut : label is "FE"; attribute INIT of mux_lut : label is "E4"; -- begin or_lut: LUT3 --synthesis translate_off

163

generic map (INIT => X"FE") --synthesis translate_on port map( I0 => logical_result(i), I1 => arith_result(i), I2 => shift_result(i), O => alu_group(i)); mux_lut: LUT3 --synthesis translate_off generic map (INIT => X"E4") --synthesis translate_on port map( I0 => instruction(13), I1 => in_port(i), I2 => store_data(i), O => input_group(i)); shift_in_muxf5: MUXF5 port map( I1 => input_group(i), I0 => alu_group(i), S => sel_group, O => alu_result(i) ); end generate alu_mux_loop; -- ------------------------------------------------------------------------------------ -- -- Read and Write Strobes -- ------------------------------------------------------------------------------------ -- io_decode_lut: LUT4 --synthesis translate_off generic map (INIT => X"0010") --synthesis translate_on port map( I0 => active_interrupt, I1 => instruction(13), I2 => instruction(14), I3 => instruction(16), O => io_initial_decode ); write_active_lut: LUT4 --synthesis translate_off generic map (INIT => X"4000") --synthesis translate_on port map( I0 => t_state, I1 => instruction(15), I2 => instruction(17), I3 => io_initial_decode, O => write_active ); write_strobe_flop: FDR port map ( D => write_active, Q => write_strobe, R => internal_reset, C => clk); read_active_lut: LUT4 --synthesis translate_off generic map (INIT => X"0100") --synthesis translate_on port map( I0 => t_state, I1 => instruction(15), I2 => instruction(17), I3 => io_initial_decode, O => read_active ); read_strobe_flop: FDR port map ( D => read_active, Q => read_strobe, R => internal_reset, C => clk); -- ------------------------------------------------------------------------------------ -- -- Program CALL/RETURN stack -- -- Provided the counter and memory for a 32 deep stack supporting nested -- subroutine calls to a depth of 31 levels. -- ------------------------------------------------------------------------------------ -- -- Stack memory is 32 locations of 10-bit single port. stack_ram_inv: INV -- Inverter should be implemented in the WE to RAM port map( I => t_state, O => stack_write_enable); stack_ram_loop: for i in 0 to 9 generate -- -- Attribute to define RAM contents during implementation -- The information is repeated in the generic map for functional simulation -- attribute INIT : string;

164

attribute INIT of stack_bit : label is "00000000"; -- begin stack_bit: RAM32X1S --synthesis translate_off generic map(INIT => X"00000000") --synthesis translate_on port map ( D => pc(i), WE => stack_write_enable, WCLK => clk, A0 => stack_address(0), A1 => stack_address(1), A2 => stack_address(2), A3 => stack_address(3), A4 => stack_address(4), O => stack_ram_data(i)); stack_flop: FD port map ( D => stack_ram_data(i), Q => stack_pop_data(i), C => clk); end generate stack_ram_loop; -- Stack address pointer is a 5-bit counter stack_count_inv: INV -- Inverter should be implemented in the CE to the flip-flops port map( I => active_interrupt, O => not_active_interrupt); stack_count_loop: for i in 0 to 4 generate begin register_bit: FDRE port map ( D => next_stack_address(i), Q => stack_address(i), R => internal_reset, CE => not_active_interrupt, C => clk); lsb_stack_count: if i=0 generate -- -- Attribute to define LUT contents during implementation -- The information is repeated in the generic map for functional simulation -- attribute INIT : string; attribute INIT of count_lut : label is "6555"; -- begin count_lut: LUT4 --synthesis translate_off generic map (INIT => X"6555") --synthesis translate_on port map( I0 => stack_address(i), I1 => t_state, I2 => valid_to_move, I3 => push_or_pop_type, O => half_stack_address(i) ); count_muxcy: MUXCY port map( DI => stack_address(i), CI => '0', S => half_stack_address(i), O => stack_address_carry(i)); count_xor: XORCY port map( LI => half_stack_address(i), CI => '0', O => next_stack_address(i)); end generate lsb_stack_count; mid_stack_count: if i>0 and i<4 generate -- -- Attribute to define LUT contents during implementation -- The information is repeated in the generic map for functional simulation -- attribute INIT : string; attribute INIT of count_lut : label is "A999"; -- begin count_lut: LUT4 --synthesis translate_off generic map (INIT => X"A999") --synthesis translate_on port map( I0 => stack_address(i), I1 => t_state, I2 => valid_to_move, I3 => call_type, O => half_stack_address(i) );

165

count_muxcy: MUXCY port map( DI => stack_address(i), CI => stack_address_carry(i-1), S => half_stack_address(i), O => stack_address_carry(i)); count_xor: XORCY port map( LI => half_stack_address(i), CI => stack_address_carry(i-1), O => next_stack_address(i)); end generate mid_stack_count; msb_stack_count: if i=4 generate -- -- Attribute to define LUT contents during implementation -- The information is repeated in the generic map for functional simulation -- attribute INIT : string; attribute INIT of count_lut : label is "A999"; -- begin count_lut: LUT4 --synthesis translate_off generic map (INIT => X"A999") --synthesis translate_on port map( I0 => stack_address(i), I1 => t_state, I2 => valid_to_move, I3 => call_type, O => half_stack_address(i) ); count_xor: XORCY port map( LI => half_stack_address(i), CI => stack_address_carry(i-1), O => next_stack_address(i)); end generate msb_stack_count; end generate stack_count_loop; -- ------------------------------------------------------------------------------------ -- -- End of description for KCPSM3 macro. -- ------------------------------------------------------------------------------------ -- --********************************************************************************** -- Code for simulation purposes only after this line --********************************************************************************** -- ------------------------------------------------------------------------------------ -- -- Code for simulation. -- -- Disassemble the instruction codes to form a text string variable for display. -- Determine status of reset and flags and present in the form of a text string. -- Provide a local variables to simulate the contents of each register and scratch -- pad memory location. -- ------------------------------------------------------------------------------------ -- --All of this section is ignored during synthesis. --synthesis translate off simulation: process (clk, instruction) -- --complete instruction decode -- variable kcpsm3_opcode : string(1 to 19); -- --Status of flags and processor -- variable kcpsm3_status : string(1 to 13):= "NZ, NC, Reset"; -- --contents of each register -- variable s0_contents : std_logic_vector(7 downto 0):=X"00"; variable s1_contents : std_logic_vector(7 downto 0):=X"00"; variable s2_contents : std_logic_vector(7 downto 0):=X"00"; variable s3_contents : std_logic_vector(7 downto 0):=X"00"; variable s4_contents : std_logic_vector(7 downto 0):=X"00"; variable s5_contents : std_logic_vector(7 downto 0):=X"00"; variable s6_contents : std_logic_vector(7 downto 0):=X"00"; variable s7_contents : std_logic_vector(7 downto 0):=X"00"; variable s8_contents : std_logic_vector(7 downto 0):=X"00"; variable s9_contents : std_logic_vector(7 downto 0):=X"00"; variable sa_contents : std_logic_vector(7 downto 0):=X"00";

166

variable sb_contents : std_logic_vector(7 downto 0):=X"00"; variable sc_contents : std_logic_vector(7 downto 0):=X"00"; variable sd_contents : std_logic_vector(7 downto 0):=X"00"; variable se_contents : std_logic_vector(7 downto 0):=X"00"; variable sf_contents : std_logic_vector(7 downto 0):=X"00"; -- --contents of each scratch pad memory location -- variable spm00_contents : std_logic_vector(7 downto 0):=X"00"; variable spm01_contents : std_logic_vector(7 downto 0):=X"00"; variable spm02_contents : std_logic_vector(7 downto 0):=X"00"; variable spm03_contents : std_logic_vector(7 downto 0):=X"00"; variable spm04_contents : std_logic_vector(7 downto 0):=X"00"; variable spm05_contents : std_logic_vector(7 downto 0):=X"00"; variable spm06_contents : std_logic_vector(7 downto 0):=X"00"; variable spm07_contents : std_logic_vector(7 downto 0):=X"00"; variable spm08_contents : std_logic_vector(7 downto 0):=X"00"; variable spm09_contents : std_logic_vector(7 downto 0):=X"00"; variable spm0a_contents : std_logic_vector(7 downto 0):=X"00"; variable spm0b_contents : std_logic_vector(7 downto 0):=X"00"; variable spm0c_contents : std_logic_vector(7 downto 0):=X"00"; variable spm0d_contents : std_logic_vector(7 downto 0):=X"00"; variable spm0e_contents : std_logic_vector(7 downto 0):=X"00"; variable spm0f_contents : std_logic_vector(7 downto 0):=X"00"; variable spm10_contents : std_logic_vector(7 downto 0):=X"00"; variable spm11_contents : std_logic_vector(7 downto 0):=X"00"; variable spm12_contents : std_logic_vector(7 downto 0):=X"00"; variable spm13_contents : std_logic_vector(7 downto 0):=X"00"; variable spm14_contents : std_logic_vector(7 downto 0):=X"00"; variable spm15_contents : std_logic_vector(7 downto 0):=X"00"; variable spm16_contents : std_logic_vector(7 downto 0):=X"00"; variable spm17_contents : std_logic_vector(7 downto 0):=X"00"; variable spm18_contents : std_logic_vector(7 downto 0):=X"00"; variable spm19_contents : std_logic_vector(7 downto 0):=X"00"; variable spm1a_contents : std_logic_vector(7 downto 0):=X"00"; variable spm1b_contents : std_logic_vector(7 downto 0):=X"00"; variable spm1c_contents : std_logic_vector(7 downto 0):=X"00"; variable spm1d_contents : std_logic_vector(7 downto 0):=X"00"; variable spm1e_contents : std_logic_vector(7 downto 0):=X"00"; variable spm1f_contents : std_logic_vector(7 downto 0):=X"00"; variable spm20_contents : std_logic_vector(7 downto 0):=X"00"; variable spm21_contents : std_logic_vector(7 downto 0):=X"00"; variable spm22_contents : std_logic_vector(7 downto 0):=X"00"; variable spm23_contents : std_logic_vector(7 downto 0):=X"00"; variable spm24_contents : std_logic_vector(7 downto 0):=X"00"; variable spm25_contents : std_logic_vector(7 downto 0):=X"00"; variable spm26_contents : std_logic_vector(7 downto 0):=X"00"; variable spm27_contents : std_logic_vector(7 downto 0):=X"00"; variable spm28_contents : std_logic_vector(7 downto 0):=X"00"; variable spm29_contents : std_logic_vector(7 downto 0):=X"00"; variable spm2a_contents : std_logic_vector(7 downto 0):=X"00"; variable spm2b_contents : std_logic_vector(7 downto 0):=X"00"; variable spm2c_contents : std_logic_vector(7 downto 0):=X"00"; variable spm2d_contents : std_logic_vector(7 downto 0):=X"00"; variable spm2e_contents : std_logic_vector(7 downto 0):=X"00"; variable spm2f_contents : std_logic_vector(7 downto 0):=X"00"; variable spm30_contents : std_logic_vector(7 downto 0):=X"00"; variable spm31_contents : std_logic_vector(7 downto 0):=X"00"; variable spm32_contents : std_logic_vector(7 downto 0):=X"00"; variable spm33_contents : std_logic_vector(7 downto 0):=X"00"; variable spm34_contents : std_logic_vector(7 downto 0):=X"00"; variable spm35_contents : std_logic_vector(7 downto 0):=X"00"; variable spm36_contents : std_logic_vector(7 downto 0):=X"00"; variable spm37_contents : std_logic_vector(7 downto 0):=X"00"; variable spm38_contents : std_logic_vector(7 downto 0):=X"00"; variable spm39_contents : std_logic_vector(7 downto 0):=X"00"; variable spm3a_contents : std_logic_vector(7 downto 0):=X"00"; variable spm3b_contents : std_logic_vector(7 downto 0):=X"00"; variable spm3c_contents : std_logic_vector(7 downto 0):=X"00"; variable spm3d_contents : std_logic_vector(7 downto 0):=X"00"; variable spm3e_contents : std_logic_vector(7 downto 0):=X"00"; variable spm3f_contents : std_logic_vector(7 downto 0):=X"00"; -- --temporary variables -- variable sx_decode : string(1 to 2); --sX register specification variable sy_decode : string(1 to 2); --sY register specification variable kk_decode : string(1 to 2); --constant value specification variable aaa_decode : string(1 to 3); --address specification -- -------------------------------------------------------------------------------- -- -- Function to convert 4-bit binary nibble to hexadecimal character -- -------------------------------------------------------------------------------- -- function hexcharacter (nibble: std_logic_vector(3 downto 0)) return character is variable hex: character; begin case nibble is when "0000" => hex := '0'; when "0001" => hex := '1';

167

when "0010" => hex := '2'; when "0011" => hex := '3'; when "0100" => hex := '4'; when "0101" => hex := '5'; when "0110" => hex := '6'; when "0111" => hex := '7'; when "1000" => hex := '8'; when "1001" => hex := '9'; when "1010" => hex := 'A'; when "1011" => hex := 'B'; when "1100" => hex := 'C'; when "1101" => hex := 'D'; when "1110" => hex := 'E'; when "1111" => hex := 'F'; when others => hex := 'x'; end case; return hex; end hexcharacter; -- -------------------------------------------------------------------------------- -- begin -- decode first register sx_decode(1) := 's'; sx_decode(2) := hexcharacter(instruction(11 downto 8)); -- decode second register sy_decode(1) := 's'; sy_decode(2) := hexcharacter(instruction(7 downto 4)); -- decode constant value kk_decode(1) := hexcharacter(instruction(7 downto 4)); kk_decode(2) := hexcharacter(instruction(3 downto 0)); -- address value aaa_decode(1) := hexcharacter("00" & instruction(9 downto 8)); aaa_decode(2) := hexcharacter(instruction(7 downto 4)); aaa_decode(3) := hexcharacter(instruction(3 downto 0)); -- decode instruction case instruction(17 downto 12) is when "000000" => kcpsm3_opcode := "LOAD " & sx_decode & ',' & kk_decode & " "; when "000001" => kcpsm3_opcode := "LOAD " & sx_decode & ',' & sy_decode & " "; when "001010" => kcpsm3_opcode := "AND " & sx_decode & ',' & kk_decode & " "; when "001011" => kcpsm3_opcode := "AND " & sx_decode & ',' & sy_decode & " "; when "001100" => kcpsm3_opcode := "OR " & sx_decode & ',' & kk_decode & " "; when "001101" => kcpsm3_opcode := "OR " & sx_decode & ',' & sy_decode & " "; when "001110" => kcpsm3_opcode := "XOR " & sx_decode & ',' & kk_decode & " "; when "001111" => kcpsm3_opcode := "XOR " & sx_decode & ',' & sy_decode & " "; when "010010" => kcpsm3_opcode := "TEST " & sx_decode & ',' & kk_decode & " "; when "010011" => kcpsm3_opcode := "TEST " & sx_decode & ',' & sy_decode & " "; when "011000" => kcpsm3_opcode := "ADD " & sx_decode & ',' & kk_decode & " "; when "011001" => kcpsm3_opcode := "ADD " & sx_decode & ',' & sy_decode & " "; when "011010" => kcpsm3_opcode := "ADDCY " & sx_decode & ',' & kk_decode & " "; when "011011" => kcpsm3_opcode := "ADDCY " & sx_decode & ',' & sy_decode & " "; when "011100" => kcpsm3_opcode := "SUB " & sx_decode & ',' & kk_decode & " "; when "011101" => kcpsm3_opcode := "SUB " & sx_decode & ',' & sy_decode & " "; when "011110" => kcpsm3_opcode := "SUBCY " & sx_decode & ',' & kk_decode & " "; when "011111" => kcpsm3_opcode := "SUBCY " & sx_decode & ',' & sy_decode & " "; when "010100" => kcpsm3_opcode := "COMPARE " & sx_decode & ',' & kk_decode & " "; when "010101" => kcpsm3_opcode := "COMPARE " & sx_decode & ',' & sy_decode & " "; when "100000" => case instruction(3 downto 0) is when "0110" => kcpsm3_opcode := "SL0 " & sx_decode & " "; when "0111" => kcpsm3_opcode := "SL1 " & sx_decode & " "; when "0100" => kcpsm3_opcode := "SLX " & sx_decode & " "; when "0000" => kcpsm3_opcode := "SLA " & sx_decode & " "; when "0010" => kcpsm3_opcode := "RL " & sx_decode & " "; when "1110" => kcpsm3_opcode := "SR0 " & sx_decode & " "; when "1111" => kcpsm3_opcode := "SR1 " & sx_decode & " "; when "1010" => kcpsm3_opcode := "SRX " & sx_decode & " "; when "1000" => kcpsm3_opcode := "SRA " & sx_decode & " "; when "1100" => kcpsm3_opcode := "RR " & sx_decode & " "; when others => kcpsm3_opcode := "Invalid Instruction"; end case; when "101100" => kcpsm3_opcode := "OUTPUT " & sx_decode & ',' & kk_decode & " "; when "101101" => kcpsm3_opcode := "OUTPUT " & sx_decode & ",(" & sy_decode & ") "; when "000100" => kcpsm3_opcode := "INPUT " & sx_decode & ',' & kk_decode & " "; when "000101" => kcpsm3_opcode := "INPUT " & sx_decode & ",(" & sy_decode & ") "; when "101110" => kcpsm3_opcode := "STORE " & sx_decode & ',' & kk_decode & " "; when "101111" => kcpsm3_opcode := "STORE " & sx_decode & ",(" & sy_decode & ") "; when "000110" => kcpsm3_opcode := "FETCH " & sx_decode & ',' & kk_decode & " "; when "000111" => kcpsm3_opcode := "FETCH " & sx_decode & ",(" & sy_decode & ") "; when "110100" => kcpsm3_opcode := "JUMP " & aaa_decode & " "; when "110101" => case instruction(11 downto 10) is when "00" => kcpsm3_opcode := "JUMP Z," & aaa_decode & " "; when "01" => kcpsm3_opcode := "JUMP NZ," & aaa_decode & " "; when "10" => kcpsm3_opcode := "JUMP C," & aaa_decode & " "; when "11" => kcpsm3_opcode := "JUMP NC," & aaa_decode & " "; when others => kcpsm3_opcode := "Invalid Instruction"; end case;

168

when "110000" => kcpsm3_opcode := "CALL " & aaa_decode & " "; when "110001" => case instruction(11 downto 10) is when "00" => kcpsm3_opcode := "CALL Z," & aaa_decode & " "; when "01" => kcpsm3_opcode := "CALL NZ," & aaa_decode & " "; when "10" => kcpsm3_opcode := "CALL C," & aaa_decode & " "; when "11" => kcpsm3_opcode := "CALL NC," & aaa_decode & " "; when others => kcpsm3_opcode := "Invalid Instruction"; end case; when "101010" => kcpsm3_opcode := "RETURN "; when "101011" => case instruction(11 downto 10) is when "00" => kcpsm3_opcode := "RETURN Z "; when "01" => kcpsm3_opcode := "RETURN NZ "; when "10" => kcpsm3_opcode := "RETURN C "; when "11" => kcpsm3_opcode := "RETURN NC "; when others => kcpsm3_opcode := "Invalid Instruction"; end case; when "111000" => case instruction(0) is when '0' => kcpsm3_opcode := "RETURNI DISABLE "; when '1' => kcpsm3_opcode := "RETURNI ENABLE "; when others => kcpsm3_opcode := "Invalid Instruction"; end case; when "111100" => case instruction(0) is when '0' => kcpsm3_opcode := "DISABLE INTERRUPT "; when '1' => kcpsm3_opcode := "ENABLE INTERRUPT "; when others => kcpsm3_opcode := "Invalid Instruction"; end case; when others => kcpsm3_opcode := "Invalid Instruction"; end case; if clk'event and clk='1' then --reset and flag status information if reset='1' or reset_delay='1' then kcpsm3_status := "NZ, NC, Reset"; else kcpsm3_status(7 to 13) := " "; if flag_enable='1' then if zero_carry='1' then kcpsm3_status(1 to 4) := " Z, "; else kcpsm3_status(1 to 4) := "NZ, "; end if; if sel_carry(3)='1' then kcpsm3_status(5 to 6) := " C"; else kcpsm3_status(5 to 6) := "NC"; end if; end if; end if; --simulation of register contents if register_enable='1' then case instruction(11 downto 8) is when "0000" => s0_contents := alu_result; when "0001" => s1_contents := alu_result; when "0010" => s2_contents := alu_result; when "0011" => s3_contents := alu_result; when "0100" => s4_contents := alu_result; when "0101" => s5_contents := alu_result; when "0110" => s6_contents := alu_result; when "0111" => s7_contents := alu_result; when "1000" => s8_contents := alu_result; when "1001" => s9_contents := alu_result; when "1010" => sa_contents := alu_result; when "1011" => sb_contents := alu_result; when "1100" => sc_contents := alu_result; when "1101" => sd_contents := alu_result; when "1110" => se_contents := alu_result; when "1111" => sf_contents := alu_result; when others => null; end case; end if; --simulation of scratch pad memory contents if memory_enable='1' then case second_operand(5 downto 0) is when "000000" => spm00_contents := sx; when "000001" => spm01_contents := sx; when "000010" => spm02_contents := sx; when "000011" => spm03_contents := sx; when "000100" => spm04_contents := sx; when "000101" => spm05_contents := sx; when "000110" => spm06_contents := sx; when "000111" => spm07_contents := sx; when "001000" => spm08_contents := sx; when "001001" => spm09_contents := sx; when "001010" => spm0a_contents := sx; when "001011" => spm0b_contents := sx; when "001100" => spm0c_contents := sx;

169

when "001101" => spm0d_contents := sx; when "001110" => spm0e_contents := sx; when "001111" => spm0f_contents := sx; when "010000" => spm10_contents := sx; when "010001" => spm11_contents := sx; when "010010" => spm12_contents := sx; when "010011" => spm13_contents := sx; when "010100" => spm14_contents := sx; when "010101" => spm15_contents := sx; when "010110" => spm16_contents := sx; when "010111" => spm17_contents := sx; when "011000" => spm18_contents := sx; when "011001" => spm19_contents := sx; when "011010" => spm1a_contents := sx; when "011011" => spm1b_contents := sx; when "011100" => spm1c_contents := sx; when "011101" => spm1d_contents := sx; when "011110" => spm1e_contents := sx; when "011111" => spm1f_contents := sx; when "100000" => spm20_contents := sx; when "100001" => spm21_contents := sx; when "100010" => spm22_contents := sx; when "100011" => spm23_contents := sx; when "100100" => spm24_contents := sx; when "100101" => spm25_contents := sx; when "100110" => spm26_contents := sx; when "100111" => spm27_contents := sx; when "101000" => spm28_contents := sx; when "101001" => spm29_contents := sx; when "101010" => spm2a_contents := sx; when "101011" => spm2b_contents := sx; when "101100" => spm2c_contents := sx; when "101101" => spm2d_contents := sx; when "101110" => spm2e_contents := sx; when "101111" => spm2f_contents := sx; when "110000" => spm30_contents := sx; when "110001" => spm31_contents := sx; when "110010" => spm32_contents := sx; when "110011" => spm33_contents := sx; when "110100" => spm34_contents := sx; when "110101" => spm35_contents := sx; when "110110" => spm36_contents := sx; when "110111" => spm37_contents := sx; when "111000" => spm38_contents := sx; when "111001" => spm39_contents := sx; when "111010" => spm3a_contents := sx; when "111011" => spm3b_contents := sx; when "111100" => spm3c_contents := sx; when "111101" => spm3d_contents := sx; when "111110" => spm3e_contents := sx; when "111111" => spm3f_contents := sx; when others => null; end case; end if; end if; end process simulation; --synthesis translate on -- --********************************************************************************** -- End of simulation code. --********************************************************************************** -- -- end low_level_definition; -- ------------------------------------------------------------------------------------ -- -- END OF FILE KCPSM3.VHD -- ------------------------------------------------------------------------------------