Upload
bharathgrandhi
View
272
Download
0
Embed Size (px)
Citation preview
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 -- ------------------------------------------------------------------------------------