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

Transcription

1 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

2 II Arabic abstract ملخص الرسالة يعتبر المتحكم الدقيق من الدواي ر الا ساسية لبناء الا نظمة المتضمنة وهى أنظمة تعتمد على الحاسب آوحدة بناي ية ويتم ضمها داخل منظومة ما. وعلى عكس وظيفة الحاسوب الا لي الذي يقوم بوظاي ف عامة فا ن الا نظمة المتضمنة يكون لها وظاي ف سابقة التحديد. وعادة يتم تصميم البنية الداخلية لمتحكم دقيق بحيث تلبى احتياجات سابقة التحديد من قبل المستخدم بحيث تفي با غراض المنظومة الكلية التي تتضمنها. ويمكن للمصمم اختيار المتحكم الدقيق من مي ات الدواي ر القياسية المتاحة بالا سواق. أو يمكنه تصميم وحدة خاصة باستخدام تقنيات" نظام على رقيقة سليكون المتاحة حاليا من العديد من الشرآات. ومن التقنيات الواعدة المستخدمة في بناء ألا نظمة تامة الا تمتة تقنية اتصال ا له با له أو اتصال ا له با نسان باستخدام شبكة الجوال. ويقوم المتحكم الدقيق بدور العقل المدبر لهذه ألا نظمة حيث يمكن من خلال هذه التقنية نقل البيانات بين ا له وأخرى أو أله وإنسان أو العكس. ونظرا لتوفر شبكات الجوال وآفاءتها فى نقل البيانات الرقمية بدون تكلفة عملية فقد وفرت العديد من شرآات الجوال مثل اريكسون و نوآيا وعالم زد في الا سواق عدة وحدات لتطوير نماذج أولية لبعض التطبيقات في هذا المجال. وعادة ما يتم استخدام داي رة المواجهة المتوالية القياسية من نوع RS232 للاتصال بين جهاز الجوال الذي يعمل آمرسل و مستقبل للبيانات وبين داي رة التطبيقات التي تحتوى على المتحكم الدقيق والمتصل بالا لة. ونظرا لشيوع استخدام داي رة مواجهة متوالية جامعة USB) ( فى معظم الا جهزة ألا ن لتفوقها على داي رة المواجهة المتوالية القياسية من نوع RS232 فا ن تزويد داي رة المتحكم الدقيق بداي رة داي رة المواجهة المتوالية الجامعة من نوع USB سوف يحسن من أداء أنظمة ألتحكم عموما وأنظمة التحكم على شبكة الجوال على وجه الخصوص. الهدف الا ساسي من هذا البحث هو اقتراح وتصميم داي رة متحكم دقيق تحتوى على داي رة مواجهة جامعة ) ( USB ويلبى التصميم احتياجات التطوير الواجب توافرها في وحدات التصميم للنماذج الا ولية لتطبيقات أنظمة اتصال ا له با له أو اتصال ا له با نسان أو العكس وذلك باستخدام شبكة الجوال المحلية و العالمية. آما سيساعد البحث أيضا في دراسة وتعلم وممارسة التصميم باستخدام تقنيات و أدوات التصميم الحديثة للا نظمة الا لكترونية الرقمية وذلك من خلال محاآاة و نمذجة وتنفيذ الداي رة المقترحة للمتحكم الدقيق.

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

4 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

5 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 Introduction Basic components in Microcontroller Memory unit Central Processing Unit Bus Input-output unit Timer unit Analog to Digital Converter Serial communication Universal Asynchronous Receiver/Transmitter (UART) RS Universal Serial Bus (USB) CHAPTER 2 Universal Serial Bus (USB) Fundamentals Introduction... 13

6 VI 2.2 USB System Description USB interconnect USB Host USB Devices Hubs Functions Physical Interface Signaling Power USB Cable Protocol Bit Ordering Packet Field Formats SYNC Field Packet Identifier Field Address Fields Address Field Endpoint Field Frame Number Field Data Field Packet Formats Token Packets Start-of-Frame Packets Data Packets Handshake Packets Data Flow Types Transfer Types Control Transfers Isochronous Transfers Interrupt Transfers Bulk Transfers... 28

7 VII CHAPTER 3 Implementation of Microcontroller core in FPGA Introduction Synthesizable VHDL Model of 8051 (Dalton project) Block Diagram Verification Procedure of the 8051 model PicoBlaze core for Microcontroller Introduction PicoBlaze Microcontroller Features PicoBlaze Microcontroller Functional Blocks General-Purpose Registers (1,024)-Instruction Program Store Arithmetic Logic Unit (ALU) Flags (64)-Byte Scratchpad RAM Input/Output Program Counter (PC) Program Flow Control CALL/RETURN Stack Interrupts Reset Verification of PicoBlaze code CHAPTER 4 Microcontroller with USB interface Introduction Implementation of USB USB Cores for FPGA Physical Layer Protocol layer Serial Interfacing to Microcontroller Parallel Interfacing to Microcontroller controller Hardware verification of Microcontroller Core with USB interface... 46

8 VIII 4.4 Experimental Work Hardware verification of PicoBlaze testing code Integrating the FPGA board (NEXYSII) with (FT245R) USB Chip Assembly and VHDL codes for Microcontroller with USB PicoBlaze assembly program for Microcontroller with USB VHDL code for testing Microcontroller with USB interface Testing the overall circuit CHAPTER 5 GSM module with USB Introduction Hardware of the GSM Module with USB VHDL code of the GSM Module with USB UART Implementation Using FPGA Start bit Data bits Parity bit Stop bits Assembly code of the GSM Module with USB Testing the overall circuit Conclusion Future work Referances Appendix A: Sony Ericsson GM47/GM Appendix B: VHDL Top level code for Verification of PicoBlaze code Appendix C: FT245R (Parallel to USB chip data sheet) Appendix D: Digilent NEXYS II Board schematic Appendix E: PicoBlaze assembly program for Microcontroller with USB Appendix F: VHDL code for testing Microcontroller with USB interface Appendix G: PicoBlaze assembly program for GSM Module with USB Appendix H: VHDL code for GSM Module with USB Appendix I: PicoBlaze Instruction Set Appendix J: PicoBlaze VHDL code

9 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 Figure 2.1: Bus Topology Figure 2.2: A Typical Hub Figure 2.3: USB cable Figure 2.4: USB cable connector types Figure 2.5: PID Format Figure 2.6: ADDR Field Figure 2.7: Endpoint Field Figure 2.8: Data Field Format Figure 2.9: Token Format Figure 2.10: SOF Packet Figure 2.11: Data Packet Format Figure 2.12 : Handshake Packet Figure 3.1: Block Diagram of 8051 model Figure 3.2: Simulation result of testing 8051 model Figure 3.3: Block Diagram of PicoBlaze Figure 3.4: Simulation result of PicoBlaze Figure 4.1 :Maxim implementation for the USB to Microcontroller through UART Figure 4.2 :block diagram of the FT245R chip Figure 4.3 :NEXYSII board... 46

10 X Figure 4.4: proposed block diagram for Microcontroller with USB Figure 4.5: Hardware verification for PicoBlaze code Figure 4.6: Microcontroller with USB on board Figure 4.7: Block diagram of VHDL code Figure 4.8: Hyper Terminal showing the program Menu Figure 4.9: Test result in Hyper Terminal Figure 4.10: Switches and LEDs Values after using the program Figure 5.1: Final System blocks Figure 5.2: On Board Final circuit Figure 5.3: Final System working... 64

11 XI List of Tables Table 2.1: RS232 cable length according to Texas Instruments Table 3.1 Comparison between hard wired and FPGA implementation of Microcontroller 29 Table model blocks description... 30

12 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

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

14 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

15 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

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

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

18 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 Bus The way to connect blocks together is called "bus". Physically, it represents a group of 8, 16, or more wires. There are two types of buses: address and data bus. The first one consists of as many lines as the amount of memory we wish to address and the other one is as wide as data, in our case 8 bits or the connection line. First one serves to transmit address from CPU memory, and the second to connect all blocks inside the Microcontroller see Figure 1.4. As far as functionality, the situation has improved, but a new problem has also appeared: we have a unit that's capable of working by itself, but which does not have any contact with the outside world, or with us! In order to remove this deficiency, let's add a block which contains several memory locations whose one end is connected to the data bus, and the

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

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

21 9 Figure 1.7: A/D converter 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

22 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

23 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 opencircuit voltage of 25 volts; Because the voltage levels are higher than logic levels typically used by integrated circuits, special intervening driver circuits are required to translate logic levels. These also protect the device's internal circuitry from short circuits or transients that may appear on the RS- 232 interface, and provide sufficient current to comply with the slew rate (how fast the signal changes between levels) requirements for data transmission. The cable length mentioned in the standard allows maximum communication speed to occur. If speed is reduced by a factor 2 or 4, the maximum length increases dramatically. Texas Instruments has done some practical experiments years ago at different baud rates to test the maximum allowed cable lengths. Keep in mind, that the RS232 standard was

24 12 originally developed for 20 kbps. By halving the maximum communication speed, the allowed cable length increases a factor ten! RS232 cable length according to Texas Instruments Baud rate Maximum cable length (ft) Table 1.1: RS232 cable length according to Texas Instruments 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.

25 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 USB interconnect The USB interconnect is the manner in which USB devices are connected to and communicate with the host. This includes the following: - Bus Topology: Connection model between USB devices and the host. - Inter-layer Relationships: In terms of a capability stack, the USB tasks that are performed at each layer in the system. - Data Flow Models: The manner in which data moves in the system over the USB between producers and consumers. - USB Schedule: The USB provides a shared interconnect. Access to interconnect is scheduled in order to support isochronous data transfers and to eliminate arbitration overhead. The USB connects USB devices with the USB host. The USB physical interconnect is a tiered star topology. A hub is at the center of each star. Each wire segment is a point-to-point connection between the host and a hub or function,

26 14 or a hub connected to another hub or function. Figure 2.1 illustrates the topology of the USB. Figure 2.1: Bus Topology 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 USB Devices USB devices are divided into device classes such as hub, locator, or text device. The hub device class indicates a specially designated USB device that provides additional USB attachment points. USB devices are required to carry information for self-identification and generic configuration. They are also required at all times to display behavior consistent with defined USB device states. Two major divisions of device classes exist: hubs and functions.

27 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 Functions A function is a USB device that is able to transmit or receive data or control information over the bus. A function is typically implemented as a separate peripheral device with a cable that plugs into a port on a hub. However, a physical package may implement multiple functions and an embedded hub with a single USB cable. This is known as a compound device. A compound device appears to the host as a hub with one or more non-removable USB devices. Each function contains configuration information that describes its capabilities and resource requirements. Before a function can be used, it must be configured by the host. This configuration includes allocating USB bandwidth and selecting function-specific configuration options.

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

29 Power The USB supports a range of power sourcing and power consuming agents; these include the following: - Root port hubs: Are directly attached to the USB Host Controller. Hub power is derived from the same source as the Host Controller. Systems that obtain operating power externally, either AC or DC must supply at least five unit loads to each port. Such ports are called high-power ports. Battery powered systems may supply either one or five unit loads. Ports that can supply only one unit load are termed low-power ports. - Bus-powered hubs: Draw all of their power for any internal functions and downstream ports from VBUS on the hub s upstream port. Bus-powered hubs may only draw up to one unit load upon power up, and five unit loads after configuration. The configuration power is split between allocations to the hub, any non-removable functions and the external ports. External ports in a bus-powered hub can supply only one unit load per port regardless of the current draw on the other ports of that hub. The hub must be able to supply this port current when the hub is in the Active or Suspend state. - Self-powered hubs: Power for the internal functions and downstream ports does not come from VBUS. However, the USB interface of the hub may draw up to one unit load from its upstream VBUS to allow the interface to function when the remainder of the hub is powered down. Hubs that obtain operating power externally (from the USB) must supply five unit loads to each port. Battery-powered Hubs may supply either one or five unit loads per port. - Low-power bus-powered functions: All power to these devices comes from VBUS. They may draw no more than one unit load at any time.

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

31 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] 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 Packet Field Formats Before learning the different types of packets used by the protocol, let us view the different fields in the packets: 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 Packet Identifier Field A packet identifier (PID) immediately follows the SYNC field of every USB packet. A PID consists of a four-bit packet type field followed by a four-bit check field as shown in Figure 2.6. The PID indicates the type of packet and, by inference, the format of the packet and the type of error detection applied to the packet. The four-bit check field of the PID ensures reliable decoding of the PID so that the remainder of the packet is interpreted correctly. The PID check field is generated by performing a one s complement of the packet type field. A PID error exists if the four PID check bits are not complements of their respective packet identifier bits.

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

33 21 Function address zero is reserved as the default address and may not be assigned to any other use. Figure 2.6: ADDR Field 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

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

35 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 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 Figure 2.10: SOF Packet The SOF token comprises the token-only transaction that distributes an SOF marker and accompanying frame number at precisely timed intervals corresponding to the start of each frame. All full-speed functions, including hubs, receive the SOF packet. The SOF token does not cause any receiving function to generate a return packet; therefore, SOF delivery

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

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

38 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 Transfer Types The USB transports data through a pipe between a memory buffer associated with a software client on the host and an endpoint on the USB device. Data transported by message pipes is carried in a USB-defined structure, but the USB allows device-specific structured data to be transported within the USB-defined message data payload. The USB also defines that data moved over the bus is pocketsize for any pipe (stream or message), but ultimately the formatting and interpretation of the data transported in the data payload of a bus transaction is the responsibility of the client software and function using the pipe. However, the USB provides different transfer types that are optimized to more closely match the service requirements of the client software and function using the pipe. An IRP uses one or more bus transactions to move information between a software client and its function. The designers of a USB device choose the capabilities for the device s endpoints. When a pipe is established for an endpoint, most of the pipe s transfer characteristics are determined and remain fixed for the lifetime of the pipe. Transfer characteristics that can be modified are described for each transfer type.

39 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 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 Isochronous Transfers In non-usb environments, isochronous transfers have the general implication of constantrate, error tolerant transfers. In the USB environment, requesting an isochronous transfer type provides the requester with the following: - Guaranteed access to USB bandwidth with bounded latency - Guaranteed constant data rate through the pipe as long as data is provided to the pipe

40 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 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 Bulk Transfers The bulk transfer type is designed to support devices that need to communicate relatively large amounts of data at highly variable times where the transfer can use any available bandwidth. Requesting a pipe with a bulk transfer type provides the requester with the following: - Access to the USB on a bandwidth-available basis - Retry of transfers, in the case of occasional delivery failure due to errors on the bus - Guaranteed delivery of data, but no guarantee of bandwidth or latency. Bulk transfers occur only on a bandwidth-available basis. For a USB with large amounts of free bandwidth, bulk transfers may happen relatively quickly; for a USB with little bandwidth available, bulk transfers may trickle out over a relatively long period of time.

41 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 Power consumption Cost effective for small scale production Fixed as the circuit is hard wired Cost effective for mass production 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 Needs of adding additional analog circuits Added on board May be on chip according to configuration Added on chip Added on board

42 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 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 8051_ram Model of a decoder that decodes the non-uniform 8051 instructions into uniform representations. 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 _ctr 8051_dbg Model of the core 8051 processor. This model is described behaviorally as a sequential logic block. This entity is there for debugging only. Currently, it outputs a trace of each instruction that is executed.

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

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

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

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

47 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

48 PicoBlaze Microcontroller Functional Blocks 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 (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 Arithmetic Logic Unit (ALU) The byte-wide Arithmetic Logic Unit (ALU) performs all Microcontroller calculations, including: Basic arithmetic operations such as addition and subtraction Bitwise logic operations such as AND, OR, and XOR Arithmetic compare and bitwise test operations Comprehensive shift and rotate operations All operations are performed using an operand provided by any specified register (sx). The result is returned to the same specified register (sx). If an instruction requires a second operand, then the second operand is either a second register (sy) or an 8-bit immediate constant (kk).

49 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 (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 Input/Output The Input/Output ports extend the PicoBlaze microcontroller s capabilities and allow the Microcontroller to connect to a custom peripheral set or to other FPGA logic. The PicoBlaze Microcontroller supports up to 256 input ports and 256 output ports or a combination of input/output ports. The PORT_ID output provides the port address. During an INPUT operation, the PicoBlaze Microcontroller reads data from the IN_PORT port to a specified register, sx. During an OUTPUT operation, the PicoBlaze Microcontroller writes the contents of a specified register, sx, to the OUT_PORT port.

50 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 Program Flow Control The default execution sequence of the program can be modified using conditional and nonconditional 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) CALL/RETURN Stack The CALL/RETURN hardware stack stores up to 31 instruction addresses, Enabling nested CALL sequences up to 31 levels deep. Since the stack is also used during an interrupt operation, at least one of these levels should be reserved when interrupts are enabled. The stack is implemented as a separate cyclic buffer. When the stack is full, it overwrites the oldest value. Consequently, there are no instructions to control the stack or the stack pointer. No program memory is required for the stack.

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

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

53 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

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

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

56 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 Serial Interfacing to Microcontroller This technique is the commonly used by most of the designers. Most of the available offshelf 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

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

58 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

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

60 Hardware verification of PicoBlaze testing code In section 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 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 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 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.

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

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

63 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

64 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

65 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

66 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

67 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

68 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 and the above Top VHDL code) are synthesized and downloaded to the FPGA on NEXYSII board

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

70 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

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

72 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

73 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 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 baud/s can be supported 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 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.

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

75 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

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

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

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

79 67 References [1] [2] Nebojsa Matic, PIC microcontrollers, for beginners too ebook [3] Paul H. Young, Electronic communication techniques 1990 [4] [5] Compaq, Intel, Microsoft, NEC, Universal Serial Bus Specification Revision 1.1 September 23, 1998 [6] [7] Steven McDowell & Martin D.Seyer, USB Explained, [8] [9] [10] [11] [12] for DTE [13] [14] [15] [16] [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, [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, [21] Julio C G Pimentel Hoang Le Huy A VHDL Library of IP Cores for Power Drive and Motion Control Applications IEEE Press, 2000.

80 68 [22] Alheraish, A Design and Implementation of Home Automation System Consumer Electronics, IEEE Transactions, Volume 50, Issue 4, Nov pp [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]

81 Appendix A Sony Ericsson GM47/GM48

82 GM 47/GM 48 Technical Description

83 GM47/48 Technical description 1.2 Features Type of Mobile Station The module performs a set of telecom services (TS) according to GSM standard phase 2+, ETSI and ITU-T. The functions of the module are implemented by issuing AT commands over the serial interface. Supported AT commands are listed in section 5, these are defined further in GSM The GM 4X family are normal dual band type of MS with the following characteristics. GM 47 GSM 900 E-GSM 900 GSM 1800 Frequency Range (MHz) TX: RX: TX: RX: TX: RX: Channel spacing 200 khz 200 khz Number of channels 173 Carriers *8 (TDMA) GSM: Channels 1 to 124 E-GSM: Channels 975 to 1023 Modulation GMSK GMSK 374 Carriers *8 (TDMA) DCS: Channels 512 to 885 TX Phase Accuracy < 5º RMS Phase error (burst) < 5º RMS Phase error (burst) Duplex spacing 45 MHz 95 MHz Receiver sensitivity at < dbm < dbm antenna connector Transmitter output power at antenna connector Class 4 Class 1 2W (33 dbm) 1W (30 dbm) Automatic hand-over between GSM 900 and GSM 1800 GM 48 GSM 850 GSM 1900 Frequency Range (MHz) TX: RX: TX: RX: Channel spacing 200 khz 200 khz Number of channels 123 carriers *8 (TDMA) 298 Carriers *8 (TDMA) GSM: Channels 128 to 251 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 antenna < dbm < dbm connector Transmitter output power at Class 5 Class 1 antenna connector 0.8 W (29 dbm) 1W (30 dbm) BA/SEM/MS 02:0004 Rev B 6

84 GM47/48 Technical description Automatic hand-over between GSM 850 and GSM SMS The 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 subscribers located in one or more specific cell(s) in the GSM network, for example, cell location information. SMS STATUS REPORT according to GSM SMS COMMAND according to GSM The maximum length of an SMS message is 160 characters when using 7-bit encoding. For 8-bit data, the maximum length is 140 bytes. The module does support upto 6 concatenated messages to extend this function Voice calls The GM47/48 offers the capability of MO and MT voice calls, as well as supporting emergency calls. In addition to this multiparty, call waiting and call deflection features are available. Some of these features are operator specific. The module offers normal analogue input/output lines, analogue audio input/ output lines in differential modes, and digital audio interface, with the possibility of accessing internal points within the digital audio lines. Moreover, the GM 47/GM48 has embedded echo canceller and noise suppresser, which provides high quality audio. The module supports both HR, FR and EFR voice coding, provided that EFR is available in the network Data The module supports the following data protocols: General Packet Radio Service (GPRS). The modules are Class B Terminals, which provides simultaneous activation and attach of GPRS and GSM services. The GM47/48 modules are GPRS 3+1 devices, which are capable of transmitting in one timeslot per frame (uplink), and receiving in a maximum of three timeslots per frame (downlink). Circuit Switched Data (CSD). GM47/48 modules are capable to stablish a circuit switch data communication at 9.6 kbps, V42bis compression is not supported. BA/SEM/MS 02:0004 Rev B 7

85 GM47/48 Technical description High Speed Circuit Switched Data (HSCSD). GM47/48 support HSCSD communication, with one timeslot per frame capacity in the uplink and two timeslots per frame capacity in the downlink (2+1) SIM Card The module supports the connection of an external SIM Card with 3V and 5 V technology, via the 60-pin system connector. The module does not have an internal SIM holder Power consumption Stand-by 1 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 at maximum transmit power Other features Internet Ready Module Multiplexing Bluetooth interoperability GPS interoperability SIM application toolkit, class 2 release 96 compliant Development Kit Sony Ericsson Mobile Communications provides the opportunity to test 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) that you 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. BA/SEM/MS 02:0004 Rev B 8

86 GM47/48 Technical description 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 IO2 I/O Digital, 2.75 General purpose input/output IO3 I/O Digital, 2.75 General purpose input/output IO4 I/O Digital, 2.75 General purpose input/output VRTC I Supply 1.8 V Voltage for real time clock 26. ADC1 I Analogue Analogue to Digital converter ADC2 I Analogue Analogue to Digital converter ADC3 I Analogue Analogue to Digital converter SDA I/O 2.75, internal I 2 C Data pullup 30. SCL O 2.75, internal pullup I 2 C Clock 31. BUZZER O Dig Buzzer output from module 32. TIMESTAMP O Dig Timestamp Timestamp is reserved for future use, if A- GPS is implemented on network side. BA/SEM/MS 02:0004 Rev B 14

87 GM47/48 Technical description 33. LED O Dig Flashing LED 34. VIO O Power Out 2.75 Module powered indication. The VIO is a 2.75 V output that could power external devices to transmit data towards the GSM device to a 75mA max. 35. TX_ON O Dig 2.75 This output shall indicate when the GSM module is going to transmit the burst. 36. RI O Dig Ring Indicator 37. DTR I Dig Data Terminal Ready 38. DCD O Dig Data Carrier Detect 39. RTS I Dig Request To Send 40. CTS O Dig Clear To Send 41. TD I Dig Transmitted Data Data from DTE (host) to DCE (module). [former DTMS] 42. RD O Dig Received Data Data from DCE (module) to DTE (host). [former DFMS] 43. TD3 I Dig UART3 Transmission Data from DTE (host) to DCE (module). [former DTMS] 44. RD3 O Dig UART3 Reception Data from DTE (host) to DCE (module). [former DTMS] Data from DCE (module) to DTE (host). [former DFMS] 45. TD2 I Dig UART2 Reception Former CTMS. Used for flashing 46. RD2 O Dig UART2 Transmission Data from DCE (module) to DTE (host). [former DFMS] Former CFMS. Used for flashing 47. PCMULD I Dig DSP PCM digital audio input 48. PCMDLD O Dig DSP PCM digital audio output 49. PCMO O Dig Codec PCM digital audio output 50. PCMI I Dig Codec PCM digital audio input 51. PCMSYNC O Dig DSP PCM frame sync 52. PCMCLK O Dig 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 BA/SEM/MS 02:0004 Rev B 15

88 GM47/48 Technical description 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 CMOS logic inputs or outputs powered from 2.75 V ± 5 %. Whenever a signal is defined as Dig V, the following electrical characteristics shall apply. Parameter Min. Typ. Max. Output Units current I o High Level Output Voltage (V OH) ma Volts Low Level Output Voltage (V OL) ma Volts High Level Input Voltage (V IH) Volts Low Level Input voltage (V IL) Volts General Protection Requirements 3.3 Grounds 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-off condition with no damage. All 2.75V digital outputs shall continuously withstand a short circuit to any voltage within the range from 0V to 3V. The SIM output signals and the SIMVCC supply shall continuously withstand a short circuit to any voltage within the range from 0V to 4.1V. Pins Name Description 2, 4, 6, 8, 10, 12 DGND Digital Ground 60 AGND Analogue Ground BA/SEM/MS 02:0004 Rev B 16

89 GM47/48 Technical description Parameter CCO Limit 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 are in 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 audio source / receiver, bypassing the analogue audio CODEC processing functions performed within the module. Figure 3.4 Pin connections to digital audio BA/SEM/MS 02:0004 Rev B 23

90 GM47/48 Technical description In case no external audio processing is performed, then it is needed to connect PCMDLD and PCMI PCMULD and PCMO Electrical characteristics The Dig V CMOS Output / Input electrical characteristics shall apply, with DGND as the reference. PCM interface format The PCM format (for PCMULD and PCMDLD) shall follow a linear PCM data I/O format of an industry standard Texas Instrument DSP. It is the same format as the one used between the CODEC and the DSP. The DSP is the source of the bit clock PCMCLK and the frame synchronisation PCMSYNC. The data bits in PCMULD and PCMDLD shall be aligned so that the MSB in each word occurs on the same clock edge Serial Data Pin Name Dir Description RS232 CCITT Nº 41 TD I Serial data to module RD O Serial data from module RTS I Request To Send CTS O Clear To Send DTR I Data Terminal Ready DCD O Data Carrier Detect RI O Ring Indicator 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 BA/SEM/MS 02:0004 Rev B 24

91 GM47/48 Technical description UART 1 (RS232) - RD, TD, RTS, CTS, DTR, DCD and RI The UART1 signals form a 9 pin RS-232 (V.24) serial port, apart from the DSR (CCITT Nº 107) signal. DSR signal has been removed as it is usually connected to DTR in most systems. The signal levels do not match the standard RS-232 (V.28) levels. The relationship between the levels is shown in the table below RS 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 levels can be achieved using a standard interface IC, such as the Maxim Integrated Products MAX Serial Data Signals - RD, TD The default baud rate is 9.6 kbit/s, however higher bit rates up to 460 kbit/s shall be supported, and set by an AT command. The UART 1 starts at a rate of 9.6 kbit/s in standard AT mode or binary mode (First received data AT or binary will determine the operation mode). The GSM multiplexing protocol is supported and shall be started on command. In this case bit rates up to 460 kbits/s shall be supported. Serial Data From Module (RD) RD is an output used to send data on the UART 1 to the application system. This is a Dig CMOS Output and general characteristics are applicable. Parameter Application load resistance Application load capacitance Limit < 100 kω < 500 pf Serial Data To Module (TD) TD is input (to the module) used by the application system to send data on the UART 1 to the module. This is a Dig CMOS Input and general characteristics are applicable. Parameter Application driving impedance Input capacitance Input resistance (pull-up) Limit < 100 Ω 1 nf 100 kω to 2.75 V BA/SEM/MS 02:0004 Rev B 26

92 GM47/48 Technical description Control Signals - RTS, CTS, DTR, DCD, RI Parameter The control signals are active low, and hence when a standard interface IC is used (such as MAX3237), then standard RS-232 levels are obtained. These signals together with DGND, RD and TD form a 9-pin RS-232 data port (with the exception of the voltage levels and DSR). RTS and CTS shall be capable of transmitting at 1/10 of the data transmission speed for data rates, up to 460 kbit/s. (Byte oriented flow control mechanism). Switching times for RTS and CTS 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 used to condition the DCE (the module when used for data transmission purposes) for data transmission. Default level is OFF, by internal pull up. The exact behaviour of RTS shall be defined by an AT command. Software or hardware flow control can be selected. Hardware flow control is the default. This is a Dig CMOS Input and general characteristics are applicable. It is the duty of the application to pull RTS low (logic levels) to request communications with the module. The module will respond by asserting CTS low and as such may be used as a notification as a module status ready for communication. Parameter Application driving impedance Input capacitance Input resistance (pull-down) Limit < 100 Ω < 2 nf 100 kω to DGND BA/SEM/MS 02:0004 Rev B 27

93 GM47/48 Technical description Clear To Send (CTS) CTS is an output from the module. The signals on this circuit shall be used to indicate that the DCE (the module when used for data transmission 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 CMOS Output and general characteristics are applicable. Tip: if only software flow control is to be used it becomes necessary to assert RTS low or to connect RTS to CTS at the module. Parameter Application load capacitance Application load resistance Limit < 500 pf > 1 MΩ Data Terminal Ready (DTR) DTR is an input to the module. Signals from the DTE on this circuit indicate the DTE is ready to transmit and receive data. DTR also acts as 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 be defined by AT commands. This is a Dig CMOS Input and general characteristics are applicable. Data Carrier Detect (DCD) DCD is an output from the module. An ON (low) signal shall indicate that a valid carrier (data signal) is being received by the DCE (module). The exact behaviour of DCD shall be defined by an AT command. This is a Dig CMOS Output and general characteristics are applicable. Ring Indicator (RI) RI is an output from the module. An ON (low) signal shall indicate a ringing signal is being received by the DCE (module). The functionality shall be selected by an AT command. This is a Dig CMOS Output and general characteristics are applicable. BA/SEM/MS 02:0004 Rev B 28

94 GM47/48 Technical description Note: DSR is considered permanently ready for a module, therefore any DGND connection may be taken as DSR functionality UART 2 - TD2, RD2 The UART 2 consists of a full duplex serial communication. This involves the transmission and reception lines. The communication port shall work in one mode: Operation and Maintenance mode. Operation and Maintenance mode shall work in addition with SERVICE signal. On switching the module on, if SERVICE signal is active then two events can happen. If no data is sent to the module, then the logger is activated. Otherwise, the module shall be ready to be reprogrammed. Timing and Electrical signals characteristics equal to UART 1 TD and RD, except for maximum baud rate that could be increased to 921 KBPS. Transmitted Data 2 (TD2) TD2 is input (to the module) used by the application system to send data 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 application system. The electrical characteristics shall be the same as RD UART 3 - TD3, RD3 The UART 3 consists of a full duplex serial communication. This involves the transmission and reception lines. Timing and electrical signals characteristics equal to UART 1 TD and RD. Transmitted Data 3 (TD3) TD3 is input (to the module) used by the application system to send data on the UART 3 to the module. The electrical characteristics shall be the same as TD. BA/SEM/MS 02:0004 Rev B 29

95 GM47/48 Technical description Received Data 3 (RD3) RD is an output used to send data on the UART 3 to the application system. The electrical characteristics shall be the same as RD SIM Card related signals Parameter Mode Signal Min. Typ. Max. Unit SIM supply Voltage 3 V SIMVCC V 5 V V High Level Input Voltage 3 V SIMDAT V (V IH) 5 V V Low Level Input Voltage 3 V SIMDAT V (V IL) 5 V V High Level Output Voltage 3 V SIMDAT V (V OH) 5 V V Low Level Output Voltage 3 V SIMDAT V (V OL) 5 V V High Level Output Voltage 3 V SIMCLK V (V OH) SIMRST 5 V V Low Level Output Voltage 3 V SIMCLK V (V OL) SIMRST 5 V V BA/SEM/MS 02:0004 Rev B 30

96 GM47/48 Technical description 4 Antenna Connector The Antenna Connector is a hub for transmission of the Radio Frequency (RF) signals from the module to the external customersupplied antenna. It is a microminiature coaxial MMCX connector that is mounted on the surface of the module. One provider of Antenna Connectors is IMS. This table provides the electrical characteristics at the antenna interface. Parameter Limit Description Nominal impedance 50 Ω= (SWR < 2:1) == Output Power 2 Watt peak (Class 4) Extended GSM Watt peak (Class 1) GSM 1800 Static Sensitivity Better than dbm Extended GSM 900 Better than dbm GSM 1800 BA/SEM/MS 02:0004 Rev B 35

97 GM47/48 Technical description 5 AT Command Summary The AT standard is a line-oriented command language. "AT" is an abbreviation of ATtention and it is always used to start sending a command line from a TE to the TA. TE stands for Terminal Equipment which is a computer of any size and TA stands for Terminal Adapter which is the modem part of the module. The command line consists of a string of alphanumeric characters. It is sent to the modem to instruct it to perform the commands specified by the characters. Functionality CONTROL AND IDENTIFICATION Subscriber Information Product & Release info Generic information & Settings AT commands AT+CNUM, AT+CIMI, AT*ESNU AT+CGMI, AT+CGMM, AT+CGMR, AT+CGSN, AT*ESIR 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) Customer Service Profile Call forwarding Calling/called number identification Preferred networks Advice of Charge Calling cards Call hold, waiting & multiparty Operator selection Network registration USSD Security & Locks AT*EALS, AT*ELIN, AT*ESLN AT*ECSP AT+CCFC, AT*EDIF, AT*EDIS AT+CLIP, AT+CLIR, AT*EIPS AT*EPNR, AT*EPNW AT+CACM, AT+CAMM, AT+CAOC, AT+CPUC AT*ESCN AT+CCWA, AT+CHLD AT+COPS AT+CREG AT+CUSD, AT+ CSSN 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, BA/SEM/MS 02:0004 Rev B 36

98 GM47/48 Technical description 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 SMS-Command Read / write SMS Send SMS AT*ESTL, AT+CPMS, AT+CRES, AT+CSAS, AT+CSCA, AT+CSMS, AT+CNMI, AT+CSDH, AT+CSMP, AT+CGSMS AT+CMGC AT+CMGD, AT+CMGW, AT+CMGL, AT+CMGR AT+CMGS, AT+CMSS PHONEBOOK Read / write / find Call screening Groups Personal Rings Settings AT+CPBS, AT+CPBR, AT+CPBW, AT+CPBF AT*ECAR, AT*ECAS, AT*ECAW AT*EGIR, AT*ESAC, AT*ESCG, AT*ESDG, AT*ESDI, AT*ESGR AT*EPRR, AT*EPRW AT*EPBM, AT*ESIA, AT*E2PCS CLOCK Alarm Time & Date AT+CALA, AT+CALD, AT+CAPD AT+CCLK, AT+CTZU, AT*EDST WAP Bookmarks Settings Profiles AT*EWBA, AT*EWBR AT*EWCG, AT*EWCT, AT*EWDT, AT*EWHP, AT*EWIL, AT*EWLI, AT*EWPB, AT*ENAD, AT*EWSA, AT*EWSG 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 MULTIPLEXING AT+CMUX BA/SEM/MS 02:0004 Rev B 37

99 GM47/48 Technical description HSCSD AT+CHSR, AT+CHSU GPRS PDP Context Activation Manual PDP Context Activation GPRS Attachment Enter Data State Define PDP Context GPRS Event Reporting Show PDP Address Quality of Service Profile (MINIMUM ACCEPTABLE) Quality of Service Profile (REQUESTED) GPRS Network registration Status Extension of ATD for GPRS AT+CGACT AT+CGANS AT+CGATT AT+CGDATA AT+CGDCONT AT+CGEREP AT+CGPADDR AT+CGQMIN AT+CGQREQ AT+CGREG ATD* NETWORK INFORMATION Cell information Engineering Mode AT*E2CD AT*E2EMM SIM APPLICATION TOOLKIT Set Up Call Display Text Get Inkey Get Input Select Item Set Up Menu Envelope (Menu Selection) Application Toolkit Settings AT*E2STKC AT*E2STKD AT*E2STKG AT*E2STKI AT*E2STKL AT*E2STKM AT*E2STKN AT*E2STKS BA/SEM/MS 02:0004 Rev B 38

100 88 Appendix B VHDL Top level code for Verification of PicoBlaze code

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

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

103 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 " " => 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=" " then leds_int <= out_port; end if; end if; end if; end process output_ports; end Behavioral;

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

105 3. Block Diagram Page Block Diagram (Simplified) VCC PWREN# 3V3OUT USBDP USBDM 3.3 Volt LDO Regulator USB Transceiver with Integrated Series Resistors and 1.5K Pull-up Serial Interface Engine ( SIE ) To USB Transceiver Cell FIFO TX Buffer 128 bytes USB Protocol Engine Internal EEPROM VCCIO FIFO Controller with Programmable High Drive D0 D1 D2 D3 D4 D5 D6 D7 RD# WR RXF# TXE# USB DPLL 3V3OUT OSCO (optional) OCSI (optional) Internal 12MHz Oscillator Clock Multiplier 48MHz FIFO RX Buffer 256 bytes RESET# To USB Transceiver Cell RESET GENERATOR TEST GND 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. FT245R USB UART I.C. Datasheet Version 1.05 Future Technology Devices International Ltd. 2005

106 4. Device Pin Out and Signal Descriptions LD SSOP Package Page 7 D OSCO D4 OSCI D2 TEST VCCIO D1 D7 GND NC D5 D6 D3 PWREN# RD# YYXX-A FT245RL FTDI AGND NC RXF# TXE# GND VCC RESET# GND 3V3OUT USBDM WR USBDP Figure 2-28 Pin SSOP Package Pin Out VCCIO VCC USBDM USBDP D0 D1 D2 D NC RESET# NC OSCI OSCO FT245RL D4 D5 D6 D RXF# V3OUT A G N D G N D G N D G N D T E S T TXE# RD# WR PWREN# Figure 3-28 Pin SSOP Package Pin Out (Schematic Symbol) FT245R USB UART I.C. Datasheet Version 1.05 Future Technology Devices International Ltd. 2005

107 4.2 SSOP-28 Package Signal Descriptions Page 8 Table 1 - SSOP Package Pin Out Description Pin No. Name Type Description USB Interface Group 15 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 Group 4 VCCIO PWR +1.8V to +5.25V supply to the FIFO Interface and Control group pins (1...3, 5, 6, , 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 Group 8, 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 oscillator is used.* FIFO Interface and Control Group 1 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

108 4.3 QFN-32 Package TOP Page FTDI YYXX-A FT245RQ BOTTOM NC OSCO OSCI TEST NC D2 D4 D AGND 24 NC 23 RXF# 22 TXE# 21 GND 20 VCC 19 RESET# 18 GND 17 1 VCCIO 2 D1 3 D7 4 GND 5 NC 6 D5 7 D6 8 D Figure 4 - QFN-32 Package Pin Out 3V3OUT USBDM USBDP NC NC WR RD# PWREN# VCCIO VCC USBDM USBDP NC NC NC NC NC FT245RQ D0 D1 D2 D3 D4 D5 D RESET# NC OSCI OSCO 3V3OUT A G N D G N D G N D G N D T E S T D6 RXF# TXE# RD# WR PWREN# Figure 5 - QFN-32 Package Pin Out (Schematic Symbol) FT245R USB UART I.C. Datasheet Version 1.05 Future Technology Devices International Ltd. 2005

109 4.4 QFN-32 Package Signal Descriptions Page 10 Table 2 - QFN Package Pin Out Description Pin No. Name Type Description USB Interface Group 14 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 Group 1 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 Group 5, 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 oscillator is used. * FIFO Interface and Control Group 30 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

110 Page FT245R FIFO Timing Diagrams Figure 6 - FIFO Read Cycle RXF# T5 T6 RD# T1 T2 D[7...0] T3 Valid Data T4 Table 3 - FIFO Read Cycle Timings Time Description Min Max Unit T1 RD Active Pulse Width 50 ns T2 RD to RD Pre-Charge Time 50 + T6 ns T3 RD Active to Valid Data* 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 T11 T12 TXE# T7 T8 WR T9 T10 D[7...0] Valid Data Table 4 - FIFO Write Cycle Timings Time Description Min Max Unit T7 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

111 7. Device Configurations Page 19 Please 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 5 SHIELD nF + GND Ferrite Bead Vcc VCC USBDM USBDP VCCIO NC RESET# NC OSCI OSCO FT245R D0 D1 D2 D3 D4 D5 D6 D7 Vcc RXF# TXE# 100nF 4.7uF + 100nF 3V3OUT A G N D G N D G N D G N D T E S T RD# WR# PWREN# GND GND Figure 13 - Bus Powered Configuration GND 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 Hub v) 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 ( for example Steward Part # MI0805K400R-00. FT245R USB UART I.C. Datasheet Version 1.05 Future Technology Devices International Ltd. 2005

112 7.2 Self Powered Configuration Page 20 5 SHIELD GND VCC = 3.3V - 5V 4k7 10k VCC USBDM USBDP VCCIO NC RESET# NC OSCI OSCO FT245R D0 D1 D2 D3 D4 D5 D6 D7 GND RXF# VCC TXE# 100nF 100nF 4.7uF + 100nF 3V3OUT A G N D G N D G N D G N D T E S T RD# WR# PWREN# GND GND Figure 14 Self Powered Configuration GND 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 USB UART I.C. Datasheet Version 1.05 Future Technology Devices International Ltd. 2005

113 7.3 USB Bus Powered with Power Switching Configuration P-Channel Power MOSFET s d Switched 5V Power to External Logic Page 21 g 0.1uF 0.1uF Soft Start Circuit 5 SHIELD nF + GND Ferrite Bead 5V VCC 1k VCC USBDM USBDP VCCIO NC RESET# NC OSCI OSCO FT245R D0 D1 D2 D3 D4 D5 D6 D7 5V VCC TXE# RXF# 100nF 4.7uF + 100nF 3V3OUT A G N D G N D G N D G N D T RD# E S WR# T PWREN# GND GND Figure 15 - Bus Powered with Power Switching Configuration GND 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 ( 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 ( 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 reapplied 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 USB UART I.C. Datasheet Version 1.05 Future Technology Devices International Ltd. 2005

114 Page USB Bus Powered with 3.3V / 5V Supply and Logic Drive / IO Supply Voltage 3.3V or 5V Supply to External Logic Vcc 100nF 5 SHIELD nF + GND Ferrite Bead Jumper Vcc VCC USBDM USBDP VCCIO NC RESET# NC OSCI OSCO FT245R D0 D1 D2 D3 D4 D5 D6 D7 TXE# 100nF 4.7uF GND + 100nF GND 3V3OUT A G N D G N D G N D G N D T E S T RXF# RD# WR# PWREN# Figure 16 - Bus Powered with 3.3V / 5V Supply and Logic Drive GND 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 ( These devices can supply up to 250mA current and have a quiescent current of under 1μA. FT245R USB UART I.C. Datasheet Version 1.05 Future Technology Devices International Ltd. 2005

115 8. Example Interface Configurations Page USB to MCU FIFO Interface Example Vcc Vcc 5 Vcc GND Ferrite Bead 10nF VCC USBDM USBDP VCCIO NC RESET# NC OSCI OSCO FT245R D0 D1 D2 D3 D4 D5 D6 D7 I/O10 I/O11 I/O12 I/O13 I/O14 I/O15 I/O16 I/O17 Microcontroller 100nF 4.7uF + RXF# I/O20 TXE# I/O21 GND 100nF 3V3OUT A G N D G N D G N D G N D T E S T RD# WR# PWREN# I/O22 I/O23 I/O24 GND GND 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 USB UART I.C. Datasheet Version 1.05 Future Technology Devices International Ltd. 2005

116 104 Appendix D Digilent NEXYS II Board schematic

117 105

118 106

119 107

120 108

121 109

122 110

123 111

124 112

125 113

126 114

127 115

128 116 Appendix E PicoBlaze assembly program for testing Microcontroller with USB

129 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

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

131 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

132 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

133 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

134 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

135 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

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

137 125 Appendix F VHDL code for testing Microcontroller with USB interface

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

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

140 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 " " => in_port <= sws_int; read USB FIFO data at address 10 hex

141 129 when " " => in_port <= USB_D; read USB FIFO control register at address 20 hex when " " => 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=" " then leds_int <= out_port; end if; Update USB FIFO data register at address 10 hex if port_id=" " then usb_data <= out_port; end if;

142 130 Update USB FIFO control register at address 20 hex if port_id=" " 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;

143 131 Appendix G PicoBlaze assembly program for GSM Module with USB ; ;Port definitions ;

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

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

146 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

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

148 136 Appendix H VHDL code of the GSM Module with USB

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

150 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';

151 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

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

153 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 " " => in_port <= uart_status; read UART receive data at address 01 hex when " " => in_port <= rx_data;

154 142 read USB FIFO data at address 10 hex when " " => in_port <= USB_D; read USB FIFO control register at address 20 hex when " " => 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=" " then uart_status(7) <= out_port(7); end if; Update USB FIFO data register at address 10 hex

155 143 if port_id=" " then usb_data <= out_port; end if; Update USB FIFO control register at address 20 hex if port_id=" " 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;

156 Appendix I PicoBlaze Instruction Set 144

157 145

158 146

159 147

160 148

161 149 Appendix J PicoBlaze VHDL Code

162 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

163 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";

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

165 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

166 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

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

168 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',

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

170 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

171 159 The information is repeated in the generic map for functional simulation attribute INIT : string; attribute INIT of memory_bit : label is " "; begin memory_bit: RAM64X1S synthesis translate_off generic map(init => X" ") 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")

172 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

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

174 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

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

176 164 attribute INIT of stack_bit : label is " "; begin stack_bit: RAM32X1S synthesis translate_off generic map(init => X" ") 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) );

177 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";

178 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';

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

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

181 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