USB2.0 Device Controller SDK- Compiler

Transcription

1 Bar Ilan University School of Engineering VLSI Lab USB2.0 Device Controller SDK- Compiler Alon Fital Chen Hajaj Final Project Forth Year Computer Engineering Project Leader: Mr. Moshe Doron Academic Supervisor: Prof. Wimer October 2010

2 Contents MAIN PROJECT GOALS...5 THE COMPILER APPLICATION:...5 SDK APPLICATION:...5 THE DRIVER WINUSB:...6 THE DEMO APPLICATION:...7 THE NEW DEMO:...7 ALTERNATIVE SOLUTIONS...8 COMPILER...8 THE SDK APPLICATION...8 USB DRIVER...8 SYSTEM ARCHITECTURE AND INTEGRATION:...ERROR! BOOKMARK NOT DEFINED. DIAGRAM OF THE SYSTEM HARDWARE AND SOFTWARE...10 SYSTEM INTEGRATION...11 USB INTRODUCTION...12 THE MAIN ARCHITECTURE IDEAS:...12 IN DEPTH SPECIFICATIONS:...13 USB'S DESCRIPTOR TABLES:...14 Device Descriptor Table:...15 Configuration Descriptor Table...15 Interface Descriptor Table...16 End-Point Descriptor Table...16 USB DATA TRANSFER SPEEDS:...17 DRIVERS AND USB:...18 DEVICE ENUMERATION PROCESS...18 END POINT TRANSFER TYPES:...19 WINDOWS DRIVERS...21 INTRODUCTION:...21 WINUSB INTRODUCTION:...22 CREATING A WINUSB DRIVER:...22 THE WINUSB API:...24 Communicating with a USB device using WinUSB API:...24 SOFTWARE AND TOOLS FOUNDATION FOR THE PROJECT:...25 THE SDK CLASSES:...27 THE CSDKDLG CLASS (MAIN CLASS):...27 The OnInitDialog function:...28 The OnTvnSelchangedUsbSelectTree function:...28 The ChangeTableView Function:...28 The save/load method:...28 THE COMPILE PROCESS...29 The Compile algorithm:...29 THE MAIN DATA CLASSES:...30 The Table row Class CUsbTableRow...30 The Table Class CUsbTable...30 The Descriptor Tables Classes:...31 The Device descriptor Class CUsbDevice...31 The Config descriptor Class CUsbConfig...32 The Interface descriptor Class CusbInter /88

3 The Endpoint descriptor Class CusbEndPoint...32 THE µcontroller COMPILER CLASSES:...33 OVERVIEW:...33 THE REGISTERS CLASS CREGISTER, CREGISTERS (ARRAY)...34 THE INPUTS CLASS - CINPUTS...35 A correct input Example Movb R1, An incorrect input Example Movb R1, THE COMMANDS CLASS CCOMMAND, CCOMMANDS (ARRAY)...36 THE LINE CLASS CLINE, CLINES (ARRAY)...37 THE LABELS CLASS CLABEL, CLABELS (ARRAY)...38 THE PROGRAM CLASS CPROGRAM...39 THE MAIN DIALOG - CCOMPILERDLG...40 PROBLEMS AND SOLUTIONS WHICH AROUSED DURING THE PROJECT...41 THE COMPILER:...41 THE USB DRIVER: JUNGO, WINUSB, WDK AND BACK AGAIN:...43 THE DEMO APPLICATION:...44 ANALYZING SIMULATION RESULTS:...45 SELF-CHECKING:...45 µcontroller TB:...45 Shortcuts:...45 THE TB CODE:...46 TB Analyze:...49 THE DEMO CODE FOR THE FPGA PRESENTATION:...50 Demo Analyze:...58 SUGGESTIONS FOR FUTURE PROJECTS...59 A PROGRAMMERS GUIDE:...61 MFC MICROSOFT FOUNDATION CLASS LIBRARY...61 MFC HISTORY:...61 MFC OVERVIEW:...63 EXAMPLE - THE SDK AND ITS USE OF MFC CONTROLS:...65 NAMING CONVENTIONS IN WIN32 AND MFC:...65 COLLECTION CLASSES:...66 CONFIGURING THE SDK AND COMPILER...68 THE COMPILER:...68 The commands file - Mandatory:...68 Command Format:...68 Example:...68 Explanation:...68 User Macro Format:...69 Example 1 A Simple Example:...69 Example 2 More complex example:...69 Explanation:...69 The registers file (Registers.txt) - Mandatory:...70 Register Format:...70 Example 1 Regular Register:...70 Example 2 Multiple Aliases:...70 The constants file (Constants.txt) - Optional:...70 Constant Format:...70 Example:...70 The input file (input.txt)...70 Comments: /88

4 Comment Format 1:...70 Comment Format 2:...71 Input command Format:...71 Example 1 Regular command:...71 Example 2 User Macro (Exactly the same):...71 Example 3 Another User Macro:...71 Label Usage Format:...71 Absolute address Format:...71 The output files (Output.txt and Output.chk.txt):...71 The Output.txt file:...72 The Output.chk.txt file:...72 Example:...72 THE SDK:...72 Format:...72 Explanation:...73 Field Example:...73 Explanation...73 The INI files:...73 A sample INI file (EndPointDesc.ini)...75 APPENDIXES:...76 THE INF FILE...76 A SIMPLE.SU2 FILE EXAMPLE...77 AN SDK COMPILE EXAMPLE...78 THE SDK UML DIAGRAM:...79 Overview:...79 THE AGE.SU2 FILE...80 COMPILER FLOW CHARTS (ABSTRACT)...82 Assembly input line parsing...82 Data reading process...83 Smart NOP insert process...84 SDK FLOW CHARTS (ABSTRACT)...85 Generic Operation of program:...85 Saving Process:...86 Interface save example:...86 Store Information in field:...87 Compile Process:...87 BIBLIOGRAPHY /88

5 Main Project goals The USB2.0 Device Controller SDK and Compiler come to serve the hardware user and engineer of the entire USB2.0 system which is developed in the VLSI lab in the university. The main purpose was to simplify the gap between the software and hardware for the engineer, making it easy for him to focus on the hardware part he constructs. It was decided that the project will be divided into four elements: i. A Compiler for the µcontroller team, which will be used to both create interrupts and (later on) can be used to write assembly programs to run. ii. iii. iv. The SDK Application, which will be used by all teams in order to configure the USB2.0 specification and burn into the hardware (using the Quartus program). A windows Driver for the entire project, which was supposed to be used in order to provide both Isochronous and bulk data transfers. A demo application, which will show the operation of the USB2.0 Device controller while it will be used to transfer data between the computer and the AGE project from last year. The Compiler Application: The Compiler was built in order to give the end user a simpler, higher level assembly language to program the µcontroller. The compiler's main objectives were the following: i. Fast and seamless translation of the user inputted commands into machine code. ii. Create easy to use user-macros, in order to simplify the work with the µcontroller. iii. Allow labels and absolute addresses to help simplify the coding process. iv. Produce a readable output file which indicates errors, NOPs, Cycles count and more. v. Produce a binary output of the machine code for direct burning. vi. Provide configurable data hazard detection support as it is not implemented in the µcontroller. 5/88

6 SDK Application: As a new USB2.0 device is created, the hardware engineer must configure many parameters which allow the USB protocol to communicate with it, such as power requirements, end point addresses and more. The SDK application is a simple and intuitive UI which allow every user, even without any programming knowledge to set all the required data fields in order to allow the system to recognize his new device, provide feedback over errors and brief explanations of each field. More than that, it is also fully customizable, allowing very easy transition into USB3.0 specification if needed (or for that manner, any other hardware spec) based on simple configuration files which are provided with the software (separately). We also wanted to give the user the option to save and load his data, making it easy to create templates for different systems. The Driver WinUSB: Although the hardware configuration part is done with the Compiler and SDK application, windows still requires more data in order to allow new devices to be recognized and worked with, this is the device driver. In the original project definition, we wanted to create a fully capable driver which will support isochronous transfers. But, as the project advanced, we understood that the steep level of knowledge needed to write a complete Kernel driver is far beyond the scope of the project. After consulting with Prof. Wimer and Mr. Moshe Doron (and a few others from outside the university) we reached the conclusion that if we will drop the support for isochronous transfer, we will be able to create a much simpler (non kernel) driver which can be used with the WinUSB kit, allowing us to complete the driver. The WinUSB solution provides a simple driver and API which can be used to communicate with any USB device. By Using the WinUSB kit, all the programmer needs to provide is some configuration files, DLLs and a SYS file and the hardware can be connected without worries to any windows system (Vista and above, for XP a small prior install is needed). 6/88

7 The Demo application: The original plan was to create a program which will display the output of the AGE Project from last year. Meaning, it would display a 640 X 48024bit images at 24 FPS, while refreshing it with the data from the AGE. We also wanted to allow the user to insert data to the AGE via the program allowing him to change the vertices list, transformation matrixes, colors and more, thus showing the real-time changes in the AGE and in its display. Unfortunately, in the vicinity of July, we already understood that the hardware side of the project, mainly the final integration will not be done in time, and after consulting with Mr. Moshe Doron we came to a conclusion there is no need to begin the Demo application, mainly because we couldn't check it at all. This part was researched, but not written at all in the end. The new Demo: As the original Demo application got canceled, and because we wanted to have a "hands-on" experience with the software and hardware, it was decided to create a small joint operation between the µcontroller team and us, making a live demonstration of the µcontroller while running commands written by our compiler. The demo will utilize the FPGAs I/O to allow user to input HEX numbers, perform ALU operations on them and see the results on the FPGAs 7Seg displays. This part of the project is completely done from the software side and is awaiting the final state of the µcontroller which should be done in the near month. 7/88

8 Alternative Solutions Compiler In order to create a baseline compiler, which will support both the current µcontroller and other future hardware projects which will be made in the university, we decided to create a fully customizable compiler, with no obligation to: register size, command set and more. Our compiler supports: Any Command set (Including user defined macros) Any amount of registers (And Aliases if needed) Any bit size (8bit, 16bit, etc) for the CPU and ALU subsystem Smart Data hazard support (if needed) External Constants from file There are no other solutions in the market, which supports the amount of customizability requirements, as compilers are usually dedicated and optimized to specific sets. The SDK Application The SDK Application was made in order to help the process of configuring the Protocol Engine without resorting to low level (binary) coding. Again, as we wanted to create a baseline, we decided to make the program fully customized (Which can support USB1.0, USB2.0 and USB3.0 if needed). Although the configuration of the program is customizable, its output is dedicated to be used with the PE and µcontroller, thus, no other solution can be found. USB driver Although it was decided to drop the isochronous transfers from the project in order to avoid Kernel-Level development, there is a major cooperation which allows for easy driver programming. The Jungo cooperation is a specialized group for hardware communication via different means, including USB, PCI, PCIE and more, their USB suite, WinDriver USB, allows for user to create kernel-level drivers without the need for kernel-level programming knowledge. 8/88

9 WinDriver allows automatic code generation (for many languages) from a simplified wizard for existing chips and vendor-specific ones, driver debugging and hardware testing, all from the WinDriver USB suite. Unfortunately, no education-license was given per request from Mr. Moshe Doron and its licensing is very expensive. System Architecture and Integration: The project main purpose was to create a system on chip, which will be connected to the AGE project from last year. The concept was to create a portable graphic solution, which will connect to a small controlling unit, and from it to a PC (or any other USB device). This will create a small System-On-Key, similar to a Disk-On-Key which will have a USB connection for Data, Display and more. Furthermore, by creating a good baseline USB controller, we will be giving a boost to any other device which can be created in the university, as the USB connection is very easy to work with and is available on almost every device. This will allow for the VLSI lab to produce many other controllers and projects, such as a Disk- On-Key, Audio Chipsets, Video chipsets and more, broadening the options the VLSI lab have. 9/88

10 Diagram of the system Hardware and software 10/88

11 System integration With the hardware fully integrated, the software kit comes to package the rest. Windows Device Driver: It was decided to use the WinUSB kit in order to create the windows driver, the files and explanation needed for it is included in the appendixes (the INF file). The SDK program: The SDK will be used by the Hardware engineer in order to create the entire descriptor tables needed for the normal operation of the system, allowing for communication with the USB protocol. The SDK will output its data as a µcontroller compiler input, allowing for quick compilation for the µcontroller. The µcontroller Compiler: The Compiler will be responsible for any high-level assembly language to machine-code conversions. It will be used both to program the PE, DMAC and µcontroller itself. The FPGA: The FPGA will be used for its I/O, allowing a hand on Demo which will allow users to interact with the system. Direct Coding Windows Device Driver PHY USB hardware connector PHY USB hardware connector Protocol Engine µcontroller µcontroller Compiler USB 2.0 SDK Coding VIA µcontroller Memory maps From SDK Output to FPGA Iinputs and Outputs DMA Controller 11/88

12 USB Introduction The Universal Serial Bus (USB) is a specification to establish communication between various devices and a host controller (usually a PC), developed and invented by Ajay Bhatt while working for Intel. USB was intended to replace the many varieties of PC connectivity (such as serial, parallel and ps/2 ports) in one global connection which will fit all applications and peripherals. The port can be used to connect computer peripherals such as mice, keyboards, digital cameras, printers, personal media players, flash drives, external HDDs and more. It can also be used to power the devices, resulting in less cable clutter for PCs. For many of those devices, USB has become the standard connection method. USB was designed for personal computers, but it has become commonplace on other devices such as smart-phones, PDAs and game consoles, TVs and more. As of 2008, there are about 2 billion USB devices sold per year, and approximately 6 billion devices sold to date. The main architecture ideas: The following criteria were applied in defining the architecture for the USB: Ease-of-use for PC peripheral expansion. Low-cost solution that supports transfer rates up to 480 Mb/s (12 Mb/s for the original USB 1.0). Support simultaneous operation of many devices. Full support for real-time data for voice, audio and video applications. Protocol flexibility for mixed-mode isochronous data transfers and asynchronous messaging allowing both bulk data transfer and real-time work simultaneous. Built-in error handling mechanism and dynamic insertion and removal of devices without any delay. 12/88

13 Integration in commodity device technology. Comprehension of various PC configurations, form factors and port sizes. Provision of a standard interface capable of quick diffusion into product. Built-in power management. Enabling new classes of devices that augment the PC s capability. In depth specifications: In order to provide the selection of attributes that can achieve multiple price/performance integration points and can enable functionality for both the system and component level the following guide lines were set: Easy to use for end user: Single model for cabling and connectors, per form factor (USB, miniusb, µusb). Electrical details isolated from end user (e.g., bus terminations) Self-identifying peripherals (Plug-andplay support), automatic mapping of function to driver and configuration. Dynamic attach/detach and on the fly reconfigurations. Isochronous transfers: Guaranteed bandwidth and low latencies appropriate for telephony, audio, video, etc. Bulk transfers: Appropriate for massive data movement, such as external HDDs, DiskOnKeys and more. Wide range of workloads and applications: Suitable for device bandwidths ranging from a few Kb/s to several hundred Mb/s. Supports isochronous as well as asynchronous transfer types over the same set of wires. Supports concurrent operation of many devices (multiple connections). Supports up to 127 physical devices. Support Hubs for less cable clutter. Supports transfer of multiple data and message streams between the host and devices. Allows compound devices (i.e., peripherals composed of many functions). Low protocol overhead, resulting in high bus utilization. Flow control for buffer handling is built into the protocol. Flexibility: Support a wide range of packet sizes, which allows a wide range of device buffering options. Allow a wide range of device data rates by accommodating packet buffer size and latencies. Robustness: Error handling/fault recovery mechanism is built into the protocol. Dynamic insertion and removal of devices is identified in user-perceived real-time. Supports identification of faulty devices. 13/88

14 Upgrade path: Architecture upgradeable to support multiple USB Host Controllers in a system. Synergy with PC industry: Protocol is simple to implement and integrate. Consistent with the PC plug-and-play architecture. Leverages existing operating system. Low-cost implementation: Low-cost sub channel at 1.5 Mb/s. Optimized for integration in peripheral and host hardware. Suitable for development of low-cost peripherals. Low-cost cables and connectors. Uses commodity technologies. USB's Descriptor tables: In order to configure an USB device, the hardware manufacture must include a set of information called Descriptor tables so that the device may communicate with the USB protocol. There are four kinds of tables needed for each device: Device Descriptor Table Configuration Descriptor Table Interface Descriptor Table End-Point Descriptor Table Please note that a single Device can have multiple configurations, each having multiple interfaces, each having multiple endpoints. 14/88

15 Device Descriptor Table: USB devices can have only one device descriptor. The device descriptor includes information such as what USB revision the device complies with, the Product and Vendor IDs used to load the appropriate drivers and the number of possible configurations the device can have. The number of configurations indicates how many configuration descriptors branches are to follow. Offset Field Size Value Description 0 blength 1 Number Size of the Descriptor in Bytes (18 bytes) 1 bdescriptortype 1 Constant Device Descriptor (0x01) 2 bcdusb 2 BCD USB Specification Number which device complies too. 4 bdeviceclass 1 Class Class Code (Assigned by USB Org) 5 bdevicesubclass 1 SubClass Subclass Code (Assigned by USB Org) 6 bdeviceprotocol 1 Protocol Protocol Code (Assigned by USB Org) 7 bmaxpacketsize 1 Number Maximum Packet Size for Zero Endpoint. Valid Sizes are 8, 16, 32, 64 8 idvendor 2 ID Vendor ID (Assigned by USB Org) 10 idproduct 2 ID Product ID (Assigned by Manufacturer) 12 bcddevice 2 BCD Device Release Number 14 imanufacturer 1 Index Index of Manufacturer String Descriptor 15 iproduct 1 Index Index of Product String Descriptor 16 iserialnumber 1 Index Index of Serial Number String Descriptor 17 bnumconfigurations 1 Integer Number of Possible Configurations Configuration Descriptor Table Each device can have a number of configuration descriptors that the device is designed to work with, but at each given time the device can only have one configuration active. The difference between the configurations could be in the amount of power to use, its number of interfaces and more, for example, a device can have a normal operation mode and a low-level mode. Offset Field Size Value Description 15/88

16 0 blength 1 Number Size of Descriptor in Bytes 1 bdescriptortype 1 Constant Configuration Descriptor (0x02) 2 wtotallength 2 Number Total length in bytes of data returned 4 bnuminterfaces 1 Number Number of Interfaces 5 bconfigurationvalue 1 Number Value to use as an argument to select this configuration 6 iconfiguration 1 Index Index of String Descriptor describing this configuration 7 bmattributes 1 Bitmap Bit 7 Reserved, set to 1 Bit 6 Self Powered Bit 5 Remote Wakeup Bits 4..0 Reserved, set to 0 8 bmaxpower 1 ma Maximum Power Consumption in 2mA Interface Descriptor Table The interfaces descriptors cluster endpoints into functional groups for the different features of the device. For example you could have a multi-function fax/scanner/printer device. One Interface descriptor can describe the endpoints of the fax function, while the other scanner functionality. Unlike the configuration descriptor, there is no limitation as to having only one interface enabled at a time. A device could have one or many interface descriptors enabled at once. Each interface can have up to 15 in and 15 out endpoints associated to it. Offset Field Size Value Description 1 bdescriptortype 1 Constant Interface Descriptor (0x04) 2 binterfacenumber 1 Number Number of Interface 3 balternatesetting 1 Number Value used to select alternative setting 4 bnumendpoints 1 Number Number of Endpoints used for this interface 5 binterfaceclass 1 Class Class Code (Assigned by USB Org) 6 binterfacesubclass 1 SubClass Subclass Code (Assigned by USB Org) 7 binterfaceprotocol 1 Protocol Protocol Code (Assigned by USB Org) 8 iinterface 1 Index Index of String Descriptor Describing this interface End-Point Descriptor Table 16/88

17 Endpoint descriptors are used to specify the type of transfer, direction, polling interval and maximum packet size for each endpoint, basically creating a pipe between the host and the device. Endpoint zero, the default control endpoint is always assumed to be a control endpoint and as such don t need a descriptor. Offset Field Size Value Description 0 blength 1 Number Size of Descriptor in Bytes (7 bytes) 1 bdescriptortype 1 Constant Endpoint Descriptor (0x05) 2 bendpointaddress 1 Endpoint 3 bmattributes* 1 Bitmap Bits 0..3 Endpoint Number Bits 4..6 Reserved Set to Zero Bit 7 Direction 0 Out 1 In Bits 0..1 Transfer 00 Control Type 01 Isochronous 10 Bulk 11 Interrupt Bits 2..3 Sync 00 No Sync Type 01 Async 10 Adaptive 11 Synchronous Bits 4..5 Usage 00 Data Type 01 Feedback 10 - Explicit Feedback Bits 6..7 Reserved 4 wmaxpacketsize 2 Number Maximum Packet Size this endpoint is capable of sending or receiving 6 binterval 1 Number Interval for polling endpoint data transfers. Value in frame counts. Ignored for Bulk & Control Endpoints. Isochronous must equal 1 and field may range from 1 to 255 for interrupt endpoints. *bmattributes When in any mode which is not Isochronous, bits 2..7 are all reserved. USB data transfer speeds: 17/88

18 The transfer speed capabilities the USB connection allows are rising at each version of the specification and will probably continue to rise. In 1996, USB 1.0 was introduced with two speeds, a full speed mode of 12Mbits/s and a low speed mode of 1.5Mbits/s. In 2000, USB 2.0 was introduced, rising the speed to 480Mbits/s calling it High Speed mode. In 2008, the USB 3.0 specification was first introduced and like his previous specs it also raised the transfer speed to a level called "Super Speed" with a rate of 5.0 Gbit/s. Just for reference, A normal modern DVD Drive can read up to a speed of 20Mbit/s (making it X250 faster) while comparing to an old Floppy drive which had a peak transfer rate of around 1000 Kbit/s (making it X5,000,00 faster). Drivers and USB: The USB protocol supports plug and play with dynamically loadable and unloadable drivers. The user simply plugs the device into the bus. The host detects this addition, interrogate the newly inserted device and load the appropriate driver. This entire process can finish in time for the hourglass to blink on your screen (provided a driver was already installed for your device). The end-user doesn t needs to worry about terminations, terms such as IRQs or port addresses, rebooting the computer (or even finding the drives most of the time). Once the user is finished with the device, all it needs to do is unplug the cable; the host will detect its absence and automatically unload the driver. The loading of the appropriate driver is done using a PID/VID (Product ID/Vendor ID) combination. Device enumeration process 18/88

19 When a USB device is first connected to a USB host, the USB device enumeration process is started. The enumeration starts by sending a reset signal to the USB device. The data rate of the USB device is determined during the reset signaling. After reset, the USB device's information is read by the host and the device is assigned a unique 7-bit address. If the device is supported by the host, the device drivers needed for communicating with the device are loaded and the device is set to a configured state. If the USB host is restarted, the enumeration process is repeated for all connected devices. End Point Transfer types: USB supports four transfer types: Control transfer: Control transfers are typically used for command and status operations. They are essential to set up a USB device with all enumeration functions being performed using control transfers. They are typically bursty, random packets which are initiated by the host and use best effort delivery. Interrupt transfer: Unlike normal interrupt request known from controllers/cpus, in the USB protocol, even after an interrupt is requested it must still wait until the host polls it. What it does guarantee is: o Latency. o Stream Pipe Unidirectional. o Error detection and next period retry. Bulk transfer: Bulk transfers can be used for large bursty data. Such as a print-job, image from a scanner, data transfer to HDD and more. Bulk transfers provide error correction in the form of a CRC16 field on the data payload and error detection/re-transmission mechanisms ensuring data is transmitted and received without error. 19/88

20 Bulk transfer guarantee: o Error detection via CRC, with guarantee of delivery. o No guarantee of bandwidth or minimum latency. o Stream Pipe - Unidirectional Isochronous transfer: Isochronous transfers occur continuously and periodically. They typically contain time sensitive information, such as an audio or video stream. If a packet is lost or delayed, it is just dropped. Isochronous transfer guarantee: o Guaranteed access to USB bandwidth. o Bounded latency. o Stream Pipe - Unidirectional o Error detection via CRC, but no retry or guarantee of delivery. 20/88

21 Windows Drivers Introduction: When Creating a USB Device, the hardware manufacturer must provide methods for the applications to access the device's features. Historically, this was done via the Windows Driver Model (WDM) which places the driver in the device stack above the system supplied protocol. The functional driver creates a small layer which allows applications to communicate with the device using the same regular Win32 API functions using the same pipetransfer methods. Creating such a driver was a significant development effort which usually required a specialized driver team even for simple devices which needed very simple drivers. In 2004, with window's XP SP2, WinUSB was introduced. Its main purpose was to provide a simpler alternative to fully custom driver writing, which allows usage of simple devices. As the main purpose of the API was to create simple drivers, there are some features which were removed in order to allow the simple creation: Multiple application access to the device is not allowed. Isochronous transfer type is not allowed. No Cross Platform support (Windows XP and Above only) 21/88

22 WinUSB Introduction: As part of the original plan of our project, we reviewed the WinUSB API in order to create an USB 2.0 vendor specific driver for the Protocol Engine. The WinUSB architecture consists of two primary components: The WinUsb.sys which is a kernel-mode driver which can be used as a function driver above the device's driver stack. WinUsb.dll which is a User-mode DLL which exposes the WinUSB API. With the API, applications can access the WinUsb.sys when it is used. For simple drivers, the programmer can use the DLL and driver in order to perform a set of device I/O control request, basically filling the gap for non-custom driver programming. All the programmer needs to do is call the WinUSB APIs functions, which then internally process and forward the request to the WinUsb.Sys which communicates with the device itself. Creating a WinUSB Driver: In order to create a Function Driver using the WinUsb.sys we must create a package which includes: The WinUSB co-installer, which installs WinUSB on the target machine (if needed). The KDMF co-installer, which installs the correct version of the KDMF (if needed). An INF file which installs the WinUsb.sys as the device's functional driver (Basically, the configuration of the device). Optional: If the target machine is x64 based, then a Signed catalog file of the package must be supplied as well for security reasons. (Via Microsoft testing). After setting the WinUsb.sys as the function driver, all which is left is an application to use it with. 22/88

23 In order to use the WinUSB API in an application we need to: Include the WinUsb.h file (supplied with the WDK package). Add the WinUsb.lib file (for the functions themselves). Include the Usb100.h file, which have many useful macros. To access the device, the application then need to: Use the device interface GUID (which we inputted to both the INF and the device's descriptor table) to obtain a handle to the device. Use the handle to initialize WinUSB. Use the WinUSB API to configure the device. Use the WinUSB API to communicate with the endpoints. 23/88

24 The WinUSB API: After creating the drivers, the programmer can use basic windows I/O functions mixed with some of the WinUSB API in order to transfer data and configure the device. For instance, in order to communicate with the devices, all that is needed is to use the WinUSB's function WinUsb_WritePipe or WinUsb_ReadPipe with the buffer which we want to send/receive. Communicating with a USB device using WinUSB API: 1. Prerequisites: 1.1. Include Windows and WinUSB header files Link the application to the needed WinUSB library files Declare the GUID which was written in supplement INF file. 2. Get information about all the configurations of the device with the given GUID Enumerate the device interfaces Get the interface information Create a device path for pipe operations 2.2. Open the handle Get a WinUSB interface handle Query the device for its Descriptor tables Open the needed pipelines (and query them if needed) 2.3. Send a control transfer to the designated endpoint 2.4. Issue an I/O request 3. Close all open handles 24/88

25 Software and tools foundation for the project: When approaching a new software program, you need to decide three main characteristics: 1. Architecture Which Operating System (OS), CPU, Memory limitation (If Any), ETC. It was decided that the program will need to run on Microsoft Windows XP (and above) for 32bit, 64bit CPUs (32bit native), also, there is no need for Cross- Platform work (Meaning we can use Windows XP and above libraries). 2. Language C, C++, C#, Java and many more. In our experience, when facing complex application, mainly those which need Graphical User Interface (GUI) it is easier to write in C++, C# or Java and not C. Java and C# can be pretty slow (though it matters less for our needs), and as we only worked with C++, we decided that we will use it as our programming language. 3. API and Environment Win32 API,.Net, MFC As we picked a Windows, C++ based language; we had three options to work with: Win32 API - The very basic core of window's API, allows for almost anything, but with the expense of great complexity and high learning curve..net Although a very "easy to learn" API, with many built in features, this language is more suitable for C#, and although we can write C++ in it, it was not meant for it. MFC An older (but not out-dated) library, which is a thin wrapper for the Win32 API and is a bit more programmer friendly. Picking an API was the hardest part for us (as we lack any "real" experience in programming); we eliminated the "raw" Win32 API for its learning curve, and 25/88

26 later on also the.net - As we preferred staying on plain C++ which we already know (although no windows interface work was ever done). Therefore, MFC was chosen. And as MFC is Microsoft proprietary, we choose the Microsoft Visual Studio 2005 Which is also available at the university as our programming environment. 26/88

27 The SDK Classes: The CSDKDlg class (main class): #m_hicon: HICON -m_chomebutton: CButtonToolTip -m_csavebutton: CButtonToolTip -m_ccompilebutton: CButtonToolTip -m_cnexterrbutton: CButtonToolTip -m_cpreverrbutton: CButtonToolTip -m_coptionbutton: CButtonToolTip -m_hcompileicon: HICON -m_hsaveicon: HICON -m_hhomeicon: HICON -m_hnexterr: HICON -m_hpreverr: HICON -m_hoptionicon: HICON -m_hundoicon: HICON -m_cbuttongroup: CStatic -m_cvaluegroup: CStatic -m_cvaluedectext: CStatic -m_cvaluehextext: CStatic -m_ceditvaluedec: CEdit -m_ceditvaluehex: CEdit -m_ceditdesc: CEdit -m_cselecttree: CContextTreeCtrl -m_ctablelist: CContextListCtrl -m_usbdevice: CUsbDevice -m_hseltreeitem: HTREEITEM -m_strtablename: CString -m_bnotsaved: bool -m_bfirstrun: bool -m_ncurtabsel: int -m_nstartadd: int CSDKDlg <<create>>-csdkdlg(pparent: CWnd) <<destroy>>-csdkdlg() #DoDataExchange(pDX: CDataExchange): void #OnOK(): void #OnCancel(): void #OnInitDialog(): BOOL #OnSysCommand(nID: UINT, lparam: LPARAM): void #OnPaint(): void #OnQueryDragIcon(): HCURSOR <<CppMacro>>-DECLARE_MESSAGE_MAP() -ChangeTableView(strTableName: CString, bsave: bool): void -SaveTableValues(): void -SaveTableToINI(pArrUsbTableRows: CUsbTableRowArray, strsectionname: CString, strfilename: CString): void -LoadTableFromInI(pArrUsbTableRows: CUsbTableRowArray, strsectionname: CString, strfilename: CString): void -ChangeTable(strName: CString): void -CheckTableValidity(pArrUsbTableRows: CUsbTableRowArray): bool -CalcAddress(strTableName: CString, pfile: CStdioFile): CString -SaveTableToAssembly(strCurrTable: CString, pfile: CStdioFile): void +OnBnClickedButtonMainHome(): void +OnCtlColor(pDC: CDC, pwnd: CWnd, nctlcolor: UINT): HBRUSH +OnSize(nType: UINT, cx: int, cy: int): void +OnGetMinMaxInfo(lpMMI: MINMAXINFO): void +OnBnClickedButtonMainCompile(): void +OnTvnSelchangedUsbSelectTree(pNMHDR: NMHDR, presult: LRESULT): void +OnBnClickedButtonMainSave(): void +OnLvnItemchangingUsbTableList(pNMHDR: NMHDR, presult: LRESULT): void +OnBnClickedButtonMainLoad(): void +OnBnClickedButtonMainOptions(): void +ChangeValues(wParam: WPARAM, lparam: LPARAM): LRESULT The Entire GUI is located inside the CSDKDlg, it is responsible to transfer the data from the list class (the user s inputted data) to the tables themselves, to select the 27/88

28 correct table after choosing from the tree class (Device, Config, Interface or Endpoint) and to start the Compile, Save and Load processes. The main project data sits inside the dialog which only holds the CUSBDevice class, which contains the rest of the data, In order to reach the Device, Config, Interface or Endpoint, the Dialog sends a request to the CUSBDevice specifying the wanted data. The OnInitDialog function: The OnInitDialog function is responsible for the automatic load for the entire descriptors table's data. It is also responsible of the initial settings of the GUI, such as the tooltip initialization, the buttons icons and more. When the function is finished, the entire data set is already loaded into the application, and the user can start inputting his data or loading it. The OnTvnSelchangedUsbSelectTree function: This function is called whenever the user presses any button on the Tree class. It checks whether the active table needs to be changed, if so, it converts the point the user pressed to the appropriate table name and calls the ChangeTableView function. The ChangeTableView Function: This function is responsible to save the current table data if needed and to switch to the new requested table. It first loads the table from the given the table name and then loads its data into the list class for the user to work on. The save/load method: One of the useful functions of the SDK is its inner save/load mechanism. In any point, the user may save the program, allowing him to save multiple templates (with data) for different types of devices, the file is saved with the suffix.su2(sdk USB2.0). This allows the user to transfer all the data structure of his device to other users that 28/88

29 may have the required data or just easily transfer the data in a very convenient way between computers. The Compile Process In our application, we programmed the compile button to output an Assembly file that will be used with the compiler to program the PE using the µcontroller. The Compile algorithm: We must first save the current table s vales into the DB, as the user can press the Compile button at any point. After the DB is up to date, we turn to check the validity of the filled tables; this is done by loading all the different tables in a hierarchic way and checking that all of their values are filled. For each table, we check whether all the fields are full, or empty, if a certain table has invalid fields, an error message is outputted to the user indicating the name of the problematic field and the compile process is terminated. If the entire DB is valid, we begin outputting the DB into an assembly file for the compiler. In order to output the data, we traverse the DB in a hierarchal path, starting with the Device seeping deeper until the endpoint. In each phase, we calculate the address of the current table (using the CalcAddress Function) and output a simple MOV command to the compiler with the current value. When the compilation is done, the output file is opened to the user, allowing him to send it to the compiler, thus, finishing the process. 29/88

30 The main Data classes: The Table row Class CUsbTableRow +m_noffset: int +m_nsize: int +m_strfieldname: CString +m_strvalue: CString +m_strdesc: CString +m_strtype: CString +m_strdefault: CString CUsbTableRow <<create>>-cusbtablerow(strfilename: CString, nfieldind: int) The CUsbTableRow class is used to hold the data for each line in each descriptor table whether it is the Device, Configuration, Interface or Endpoint. Its fields, except the value are field automatically filled with the by a programs configuration (INI) file. The Value field holds the data which the user inputs in the program or loads from an external.su2 file. The Table Class CUsbTable CUsbTable #m_arrtablerow: CUsbTableRowArray #m_strfilename: CString <<create>>-cusbtable(strfilename: CString) <<create>>-cusbtable() <<destroy>>-cusbtable() +GetName(): CString +GetTableRows(): CUsbTableRowArray +Create(strFileName: CString): void +Save(): void +Load(strFileName: CString): void The CUsbTable class is the general class who is responsible for each of the descriptors table data. Each table contains an array of rows (CUsbTableRow) holding the information relevant. Device, configuration, interface and endpoint tables all inherit from the CUsbTable class, therefore, allowing them to share the Save, Load, Create (and more) procedures. 30/88

31 CUsbTable #m_arrtablerow: CUsbTableRowArray #m_strfilename: CString <<create>>-cusbtable(strfilename: CString) <<create>>-cusbtable() <<destroy>>-cusbtable() +GetName(): CString +GetTableRows(): CUsbTableRowArray +Create(strFileName: CString): void +Save(): void +Load(strFileName: CString): void CUsbConfig -m_arrinter: CUsbInterArray <<destroy>>-cusbconfig() +CreateConfig(strFilePath: CString): void +GetTable(strTableName: CString): CUsbTableRowArray -m_usbconfig: CUsbConfig CUsbDevice <<create>>-cusbdevice() +CreateDevice(strFileName: CString): void +GetTable(strTableName: CString): CUsbTableRowArray CUsbEndPoint <<create>>-cusbendpoint(strpathname: CString) CUsbInter -m_arrendpointsin: CUsbEndPointArray -m_arrendpointsout: CUsbEndPointArray <<create>>-cusbinter(strpathname: CString) <<destroy>>-cusbinter() +GetTable(nInOut: UINT, nindex: UINT): CUsbTableRowArray The Descriptor Tables Classes: The Device descriptor Class CUsbDevice -m_usbconfig: CUsbConfig CUsbDevice <<create>>-cusbdevice() +CreateDevice(strFileName: CString): void +GetTable(strTableName: CString): CUsbTableRowArray The CUsbDevice class represent the USB device descriptor, this class holds the entire DB of the tables, and allows the CSdkDlg to access them via the GetTable method. 31/88

32 The Config descriptor Class CUsbConfig CUsbConfig -m_arrinter: CUsbInterArray <<destroy>>-cusbconfig() +CreateConfig(strFilePath: CString): void +GetTable(strTableName: CString): CUsbTableRowArray The CUsbConfig class represnts the USB configuration descripor, this class holds all the interfaces and allow access to them via the GetTable method. The Interface descriptor Class CusbInter CUsbInter -m_arrendpointsin: CUsbEndPointArray -m_arrendpointsout: CUsbEndPointArray <<create>>-cusbinter(strpathname: CString) <<destroy>>-cusbinter() +GetTable(nInOut: UINT, nindex: UINT): CUsbTableRowArray The CUsbInter class represnts the USB interface descripor, this class holds all the endpoints and allow access to them via the GetTable method. The Endpoint descriptor Class CusbEndPoint CUsbEndPoint <<create>>-cusbendpoint(strpathname: CString) The CUsbEndPoint class represnts the USB endpoint descripor, this is the lowermost device data. 32/88

33 The µcontroller Compiler classes: Overview: The program was organized in the same manner we perceived the compiler: The Dialog (GUI) of the application, which holds all the needed files. Within it, the program itself (the user's program), which is a collection of lines, each holding a command, its registers and labels. In the following pages, we will go in depth over each class and its purpose, starting from the bottom, and rising to the dialog itself. 33/88

34 The Registers class CRegister, CRegisters (array) The register class is used to hold the needed data over a single/multiple registers, including its OP-Code and Alias (E.G. RC is R14 is 1110) and fast transaction between the two. This is the only connection between the program and the sub layer of the individual register, as the program request an OP-Code via supplying an Alias, the CRegisters class finds the correct one and retrieves its OP-Code. Important note, there can be more than one Alias for the same OP-Code if needed. The main dialog is the only holder of the CRegisters array and forwards it whenever needed to the individual inner classes. 34/88

35 The Inputs class - CInputs The inputs class holds the list of inputs each line has, meaning, each command's actual input types and values including conversions two's compliments. This is the output generator for each individual line as it holds the command and its inputs. A correct input Example Movb R1, 53 As the line process, the command will be translated from Movb into its OP-Code Its output register will be set to R1; its inputs will be set to be of type Immediate from the commands.txt (for Movb) and then checked if 53 can fit inside an 8bit number and will be padded to 8bit. After the input check, a new line is created: Thus creating a complete 16bit command. An incorrect input Example Movb R1, 5353 When the input class parses the line and reaches the number 5353, it checks whether the number fits an 8bit two's compliment size ( ) and 35/88

36 then outputs the error: "Not 8Bit, index: 2/2", allowing the user to immediately understand the error and correct it. The Commands class CCommand, CCommands (array) The command class is responsible of holding each command's definitions (from commands.txt file) and the actual representation of each line in the program (in binary) It defines the amount and type of inputs the command has (in the CInputs class), whether it requires NOPs smart NOPs or no NOPs at all and is in charge of expending User-Macros into their intended purpose. The main function which is needed is the GetOutput function, which calls the CInputs GetOutput function, resulting in a formatted output line. 36/88

37 The Line class CLine, CLines (array) The line class holds the entire data a single line needs, including: The register list, the command list and the final output (after compilation). Each line basically holds its command and its inputs and is the middleman for the program to each created line's formatted output or error. The Clines a self-deleting array of the Cline class, it is the only middleman between the program and each individual line (which is accessed via an integer key, [n]). Only the Dialog holds the Clines class, which then forwards it to the CProgram for manipulation. 37/88

38 The Labels Class CLabel, CLabels (array) The label class is in charge of holding the label names and absolute offset; it is also in charge of creating additional offset as we insert smart/non-smart NOPs in the application and to output the final actual location of the label. In order to improve performance, contiguous NOPs do not move the line each time, but are saved, and only after shifted in the entire needed size. Also, it is only required to offset a label if the data which was inserted was before it, resulting in fewer operations. The CLabels holds all the labels in the system and is in charge of updating them all if a change to the label offset is required. Also, in order to minimize workload, the program counts the amount of lines needed to be offset and sends them all together, resulting in one change per label and not one change per line, per label. 38/88

39 The Program Class CProgram The program class holds the entire data needed to compile and create the outputted binary file. It holds the entire list of Commands, Registers and Labels and the list of lines the user inputted waiting for compile. The entire compiling process is done via the program class which calls the sub layers of the CLine class for each line, thus creating an outputted binary file, an error file, and a user-formatted output file for easy understanding of the compiling process. The CProgram class also counts all the inserted NOPs for statistical information over the compile process. 39/88

40 The Main Dialog - CCompilerDlg This class holds the entire GUI of the compiler and entire set of data for the compiling process. It includes handling for all the Buttons, the List, Tree and the GUI resizing algorithm. When the user presses the Compile button, the OnOK function is called which handles the file opening and reading, starting the compile process and the outputting. 40/88

41 Problems and solutions which aroused during the project The original project plan was to provide a software package for the Protocol engine in order to configure it and allow it to communicate with windows. It was decided to provide a single application, dubbed, the SDK and create a Windows driver. As the system began to come together, we understood that we had three major shortcomings in both the system design and with Drivers in general. The Compiler: Although the µcontrollers main objective is to provide a boot-up and initialization of the system, it will still need a method to copy all the needed data (in our case, the entire USB2.0 Descriptor tables) from the µcontroller data segment to the P.E data segment, also, in order to create interrupts, we would be forced to resort to lowlevel machine code for the µcontroller, which is not feasible. More than that, Mr. Moshe Doron and Prof. Wimer wanted the µcontroller to be a part of a small standalone chip, which will be used in future applications that will probably require more in depth application programming. Therefore, in February 2010, it was decided to update and shift the focus of the project to create a compiler. The compiler will be used for both our project and future projects if needed and will be created to support multiple hardware choices. As there is only little programming knowledge in the departments, we were forced to start the project blindly, with no knowledge of its timelines and depth. As we began to program the Compiler, we saw that the µcontrollers specification, command list, registers are constantly changing, which made us rethink (and restart) the project, this time, allowing it to be fully customizable for the hardware team. 41/88

42 Now, the compiler can be set to create assembly language to any device with a simple change to its configuration (which can be made by the hardware creator), allowing easy to make assembly language compiler to any device; More than that, the configuration files are easy to understand, and require no intervention with the programmer to change, even allowing the user to create special macros for any set of command he/she constantly use. Another main issue which we faced with the Compiler was the fact that Data hazard prevention and data forwarding were not inserted into the µcontroller due to their complexity. Data hazard means that the ALU began changing a register, and in the next clock, performed an operation with it as the input. Because of the pipeline architecture which the µcontroller team choose, when the operation starts, the value is still not the new one (it can be anything), resulting in an error. This new requirement, made us change the way we compiled each line, as it required us to have prior knowledge of each register, at each input line and have a mechanism which pushes NOPs only when needed (in order not to waste cycles). Besides reorganizing the way each line is read, we also had to change other bits of data, mainly labels which are found in the original input code and need to retain the correct address location and Absolute addresses, which need to maintain their original location. We decided to implement a mechanism which will keep track of the entire register list, while keeping in check each register which is in use (meaning, requires a NOP if used again) against the list of current registers used in each line. Therefore, inserting NOPs only whenever they are needed thus not bloating the cycle count. Although the idea is good, with no data forwarding from the hardware point, there are still many wasted cycles (A detailed comparison can be found in later chapters). 42/88

43 The USB Driver: Jungo, WinUSB, WDK and back again: As we began the project, we decided that the first thing to be done is the driver as it required a lot of studying and understanding. In the beginning, we sat with Mr. Moshe Doron and decided to try and use Jungo's WinDriver suite, which allows user without extensive programming background to create User-mode drivers. When we acquired a trial copy of the application, we understood it is fully commercial and although Mr. Moshe Doron tried to receive an educational copy, it was denied. Therefore, it was decided to follow the route of WinUSB, which is a simple kit Microsoft supplies to allow users to create drivers. We read the WinUSB materiel and the USB2.0 Specification in the same time, while making sure we can implement everything we wanted from it with the WinUSB kit. As we reached the transfer types the USB2.0 allow, we discovered that although the WinUSB is extensive, it lacks support for any isochronous transfers as they require Kernel level drivers. After a meeting with Prof. Wimer and Mr. Moshe Doron, it was decided that we do want the isochronous transfer, resulting in abandoning the WinUSB and shifting our focus into the Windows driver Kit suite (WDK). Again, we began researching the WDK, and we found out two major problems: 1. The WDK is meant for experienced Kernel driver programmers and its learning curve is very high. 2. There is no way of debugging or testing the driver as long as the hardware components are not finished. More than that, in order to debug them, special hardware must be bought. After lengthy discussions and after receiving input from another team which created a similar project, we understood that venturing into the Kernel mode driver is not possible and we were forced to revert back to the WinUSB kit while retaining as much as we can. 43/88

44 Therefore, in February 2010, it was decided to leave the WDK and re-focus on the WinUSB kit in order to have at least basic driver functionality where only bulk transfer will be allowed, hoping that it will retain pseudo-real-time performance with some buffer management on the software side. The Demo Application: As we progressed our discussions about the entire system integration, we understood that another key element of the system is missing, an application which will allow for direct operation against the AGE as it needs a way to display its data (images) via the computer while setting various settings for the hardware. Although creating a driver is enough for Windows to recognize the device, it doesn't perform any operations with it unless instructed to. The main idea of the Demo application was to use the WinUSBs API to create a simple application, which will show the data from the AGE, though, as we only support Bulk transfers, and not isochronous, we couldn't tell when the data will arrive (to any end). Also, there was no proper way for create the triangle lists for the AGE, as no program was supplied last year. It was decided to leave this application to the end mainly because the amount of code for it isn't large (The API allows for simple reading and writing buffers from/to the device, which was all we needed) and because we couldn't test it against anything until the system integration is done. As we mentioned before, this application is canceled and is replaced with a new FPGA Demo which will provide some tactical feedback over the system as the system integration is cancled. 44/88

45 Analyzing Simulation Results: In order to check the correct operation of our compiler, we used two approaches: Self-Checking: We created a debugging file which is attached to the binary output, outlaying the methods the compiler took, its NOPs, LABELs, ETC. By checking the debug file, we can compare it to the initial purpose of each line and make sure we don't have mistakes in the programming logic. µcontroller TB: We created an extensive test bench, which will be run on the µcontroller, this will help us and the µcontrollers team to check for correct operation of both the hardware and the code. Shortcuts: µc = µcontroller, DMAC = DMA Controller, UM = User Macro PC = Program counter & = Bitwise AND, = Bitwise OR, ^ = Bitwise XOR,!= Not Equal 45/88

46 The TB Code: Assembly Code Explanation Registers changes Registers same Smart NOPs Force NOP mov2b R1,%MAIN When the µc starts, it loads the PC to address 0; we 3 3 JMP R1 need to jump to the main function. 2 2 ;Cycle Count: No Change 5 5 %CHECK_ALU This procedure checks the µcs ALU operations mov2b R1,0 Zero out R1 R1=0 3 3 ADDI R1,3 MOVW R2,R1 ADDI R1,-3 ADD R3,R1,R2 Check for simple Add immediate Check copy between registers Check negative operation and 2's compliment Check ADD registers R1=3 1 1 R2=3 R1=3 0 1 R1=0 R2=3 1 1 R3=3 R1=0,R2=3 1 1 DEC R3 Check UM DEC R3=2 0 1 INC R2 Check UM INC R2=4 R1=0,R3=2 1 1 OR R2,R2,R3 Check OR Command R2=6 R1=0,R3=2 1 1 Check AND AND R1,R2,R3 Command XOR R1,R1,R2 Check XOR R1=4 R1=2 R2=6,R3=2 1 1 R2=6,R3=2 1 1 XOR R1,R1,R1 Null R1, Check XOR 1 1 RETP End procedure 2 2 ;Cycle Count: 15% improvement %CHECK_LOOP Check the µcs Loop command mov2b R1,0 Zero out R1 R1=0 2 3 mov2b RC,3 Count loop to 3 RC=3 R1=0 2 3 mov2b R2,%INNER_LOOP Load label loop R1=0,RC= /88

47 %INNER_LOOP Inner loop for check, Shift R1 by 4 and then INC it R1=0 RC=3 Sht R1,5 Shift R1,5 R1=32 R1=544 RC=2 RC=1 1 1 R1=8736 RC=0 R1=0 RC=3 Sht R1,-1 Shift R1,-1 R1=16 R1=272 RC=2 RC=1 1 1 R1=4368 RC=0 R1=1 RC=3 INC R1 INC R1 R1=17 R1=273 RC=2 RC=1 0 1 R1=4369 RC=0 Loop RC,R2,RC Loop to R2 if RC!=0 2 2 Sht R1,4 Check carry flag R1=4368 Carry=1 0 1 ;Cycle Count: 36% improvement FJC R10,%CORRECT_JC Fast jump UM 2 2 Movb R1,0 Zero out R1, Error R1=0 0 1 RETP End procedure 2 2 ;Cycle Count: 20% improvement 4 5 %CORRECT_JC The Jump Carry should arrive here, as Carry should be 1 Sht R1,-1 Shift right R1=2184 Carry=0 0 1 FJC R10,%INCORRECT_NJC Fast jump UM 2 2 Movb R1,1 Insert 1, Correct R1=1 0 1 RETP End Procedure 2 2 ;Cycle Count: 33% improvement 4 6 %INCORRECT_NJC The Jump should NOT arrive here, As Carry should be 0 Movb R1,0 Zero out R1, Error R1=0 0 1 RETP End procedure 2 2 ;Cycle Count: 33% improvement 2 3 Total Cycle Count (for Correct route): 19% improvement /88

48 %CHECK_LOD_STR The function checks the memory access functionality Load R1 address mov2b R1, R1= mov2b R2,0 Zero out R2 R2=0 R1= str R2,R1 Store 0 into memory [R1] [R1]=0 R1=16000,R2= Inc R2 R2=1 R1= Lod R2,R1 Load from memory [R1] [R1]=0,R2=0 R1= OR R2,R2,R2 Check if R2 is 0 R2=0 R1= FJZ R10,%CORRECT_JZ Fast jump UM 2 2 Movb R1,0 Zero out R1, Error R1=0 0 1 RETP End Procedure 2 3 ;Cycle Count: 35% improvement 9 14 %CORRECT_JZ The Jump Carry should arrive here, as Zero should be 1 Movb R1,1 Insert 1, Correct 0 1 RETP End Procedure 2 2 ;Cycle Count: 25% improvement %CHECK_SMART_NOP The Function checks the NOP amount inserting with/without smart NOPs, simulating a simple copy to memory mov2b R1,32000 Load R1 address R1= mov2b R2,0 Zero out R2 R2=0 R1= mov2b RC,20000 Count loop to 100 RC=100 R1=32000,R2= %SMART_LOOP Inner loop for NOP compares [R1]=0 Str R2,R1 Store [R1]=R2 0 0 [R1+100]=100 R1=32001 RC=100 Inc R1 Inc R1 0 1 R1=32100 RC=0 R2=1 Inc R2 Inc R2 0 1 R2=100 48/88

49 FLOOP R3,%SMART_LOOP Loop to R3 if RC!=0 2 2 ;Cycle Count: ~51% improvement :1000 Goto address 1000, insert NOPs until it %MAIN Main Function, runs all the other functions in turn And insert ~1000 NOPs between each run Fjmp R10,%CHECK_ALU 0 0 :2000 Goto address 2000, insert NOPs until it Fjmp R10,%CHECK_LOOP 0 0 :3000 Goto address 3000, insert NOPs until it Fjmp R10,%CHECK_LOD_STR 0 0 :4000 Goto address 4000, insert NOPs until it Fjmp R10,%CHECK_SMART_N OP Total Cycle Count (for Correct route): 0 0 ~41% improvement TB Analyze: As we can see, the total cycle count for the TB was reduced in almost half when using the Smart-NOP interface, reducing the cycle count to only 293. As we suspected, the main advantage of the Smart-NOP will be shown in loops, where each NOP inserting is multiplied, but even without counting the loop, there is about 30% improvement for regular operations. 49/88

50 The Demo code for the FPGA presentation: Assembly Code Explanation Smart NOPs Force NOP %Main FJMP R10,%MAIN %Wait1Sec Zero address, main function Be in a constant jumping loop The function will NOP for 1 second (320*5)*32,767=52,427,200 cycles / 50Mhz 1 second MOVW R11,RC Save RC 0 1 MOV2B RC,320 RC= %LOOP_BIG_CLOCK Outer loop, runs 320 times MOVW R12,RC Save RC 0 1 MOV2B RC,0x7FFF RC=32, %LOOP_SMALL_CLOCK Inner loop, runs 32,767 times FLOOP R10,%LOOP_SMALL_CLOCK Fast loop, R10= LOOP_SMALL_CLOCK, RC=32, MOVW RC,R11 Reload RC to outer loop value 0 1 FLOOP R10,%LOOP_BIG_CLOCK Fast loop, R10= LOOP_BIG_CLOCK, RC= MOVW RC,R11 Reload original RC 0 1 RETP Return 2 2 ;Cycle Count: ~0% improvement %Display7Seg Loads into selected 7Seg (By R4) the representation of a letter (By R5) OR R4,R4,R4 Check what R4 is, and jump to that 0 1 FJZ R10,%LOAD_7SEG_0 label 5 5 DEC R4 1 1 OR R4,R4,R4 0 1 FJZ R10,%LOAD_7SEG_1 5 5 DEC R4 1 1 OR R4,R4,R4 0 1 FJZ R10,%LOAD_7SEG_3 5 5 DEC R4 1 1 OR R4,R4,R4 0 1 FJZ R10,%LOAD_7SEG_ /88

51 DEC R4 1 1 OR R4,R4,R4 0 1 FJZ R10,%LOAD_7SEG_5 5 5 DEC R4 1 1 OR R4,R4,R4 0 1 FJZ R10,%LOAD_7SEG_6 5 5 ;%LOAD_7SEG_7 R4 was 7 MOV2B R6,#Add7Seg7 R6=Address of 7Seg number STR R6,R5 [R6]=R5 0 0 RETP Return from procedure 2 2 %LOAD_7SEG_6 R4 was 6 MOV2B R6, #Add7Seg6 R6=Address of 7Seg number STR R6,R5 [R6]=R5 0 0 RETP Return from procedure 2 2 %LOAD_7SEG_5 R4 was 5 MOV2B R6,#Add7Seg5 R6=Address of 7Seg number STR R6,R5 [R6]=R5 0 0 RETP Return from procedure 2 2 %LOAD_7SEG_4 R4 was 4 MOV2B R6, #Add7Seg4 R6=Address of 7Seg number STR R6,R5 [R6]=R5 0 0 RETP Return from procedure 2 2 %LOAD_7SEG_3 R4 was 3 MOV2B R6, #Add7Seg3 R6=Address of 7Seg number STR R6,R5 [R6]=R5 0 0 RETP Return from procedure 2 2 %LOAD_7SEG_2 R4 was 2 MOV2B R6, #Add7Seg2 R6=Address of 7Seg number STR R6,R5 [R6]=R5 0 0 RETP Return from procedure 2 2 %LOAD_7SEG_1 R4 was 1 MOV2B R6, #Add7Seg1 R6=Address of 7Seg number STR R6,R5 [R6]=R5 0 0 RETP Return from procedure 2 2 %LOAD_7SEG_0 R4 was 0 MOV2B R6, #Add7Seg0 R6=Address of 7Seg number /88

52 STR R6,R5 [R6]=R5 0 0 RETP Return from procedure 2 2 ;Cycle Count (Worse case): 15% Improvement %Calc7Seg Receives a 4bit number on R3 to display, and the 7Seg number on R4 (0-3 Input 7Seg, 4-7 Output 7Seg) OR R3,R3,R3 Check what R3 is, and jump to that 0 1 FJZ R10,%LOAD_0 label 5 5 DEC R3 1 1 OR R3,R3,R3 0 1 FJZ R10,%LOAD_1 5 5 DEC R3 1 1 OR R3,R3,R3 0 1 FJZ R10,%LOAD_2 5 5 DEC R3 1 1 OR R3,R3,R3 0 1 FJZ R10,%LOAD_3 5 5 DEC R3 1 1 OR R3,R3,R3 0 1 FJZ R10,%LOAD_4 5 5 DEC R3 1 1 OR R3,R3,R3 0 1 FJZ R10,%LOAD_5 5 5 DEC R3 1 1 OR R3,R3,R3 0 1 FJZ R10,%LOAD_6 5 5 DEC R3 1 1 OR R3,R3,R3 0 1 FJZ R10,%LOAD_7 5 5 DEC R3 1 1 OR R3,R3,R3 0 1 FJZ R10,%LOAD_8 5 5 DEC R3 1 1 OR R3,R3,R3 0 1 FJZ R10,%LOAD_9 5 5 DEC R3 1 1 OR R3,R3,R /88

53 FJZ R10,%LOAD_A 5 5 DEC R3 1 1 OR R3,R3,R3 0 1 FJZ R10,%LOAD_B 5 5 DEC R3 1 1 OR R3,R3,R3 0 1 FJZ R10,%LOAD_C 5 5 DEC R3 1 1 OR R3,R3,R3 0 1 FJZ R10,%LOAD_D 5 5 DEC R3 1 1 OR R3,R3,R3 0 1 FJZ R10,%LOAD_E 5 5 ;%LOAD_F R3 was 15 MOV2B R5,0x0E R5=Representation of data for 7Seg 2 3 FJMP R10,%Display7Seg Data is ready, Display on 7Seg 5 5 RETP Return from Procedure 2 2 %LOAD_E R3 was 14 MOV2B R5,0x06 R5=Representation of data for 7Seg 2 3 FJMP R10,%Display7Seg Data is ready, Display on 7Seg 5 5 RETP Return from Procedure 2 2 %LOAD_D R3 was 13 MOV2B R5,0x21 R5=Representation of data for 7Seg 2 3 FJMP R10,%Display7Seg Data is ready, Display on 7Seg 5 5 RETP Return from Procedure 2 2 %LOAD_C R3 was 12 MOV2B R5,0x46 R5=Representation of data for 7Seg 2 3 FJMP R10,%Display7Seg Data is ready, Display on 7Seg 5 5 RETP Return from Procedure 2 2 %LOAD_B R3 was 11 MOV2B R5,0x03 R5=Representation of data for 7Seg 2 3 FJMP R10,%Display7Seg Data is ready, Display on 7Seg 5 5 RETP Return from Procedure 2 2 %LOAD_A R3 was 10 MOV2B R5,0x08 R5=Representation of data for 7Seg 2 3 FJMP R10,%Display7Seg Data is ready, Display on 7Seg /88

54 RETP Return from Procedure 2 2 %LOAD_9 R3 was 9 MOV2B R5,0x10 R5=Representation of data for 7Seg 2 3 FJMP R10,%Display7Seg Data is ready, Display on 7Seg 5 5 RETP Return from Procedure 2 2 %LOAD_8 R3 was 8 MOV2B R5,0x00 R5=Representation of data for 7Seg 2 3 FJMP R10,%Display7Seg Data is ready, Display on 7Seg 5 5 RETP Return from Procedure 2 2 %LOAD_7 R3 was 7 MOV2B R5,0x78 R5=Representation of data for 7Seg 2 3 FJMP R10,%Display7Seg Data is ready, Display on 7Seg 5 5 RETP Return from Procedure 2 2 %LOAD_6 R3 was 6 MOV2B R5,0x02 R5=Representation of data for 7Seg 2 3 FJMP R10,%Display7Seg Data is ready, Display on 7Seg 5 5 RETP Return from Procedure 2 2 %LOAD_5 R3 was 5 MOV2B R5,0x12 R5=Representation of data for 7Seg 2 3 FJMP R10,%Display7Seg Data is ready, Display on 7Seg 5 5 RETP Return from Procedure 2 2 %LOAD_4 R3 was 4 MOV2B R5,0x19 R5=Representation of data for 7Seg 2 3 FJMP R10,%Display7Seg Data is ready, Display on 7Seg 5 5 RETP Return from Procedure 2 2 %LOAD_3 R3 was 3 MOV2B R5,0x30 R5=Representation of data for 7Seg 2 3 FJMP R10,%Display7Seg Data is ready, Display on 7Seg 5 5 RETP Return from Procedure 2 2 %LOAD_2 R3 was 2 MOV2B R5,0x24 R5=Representation of data for 7Seg 2 3 FJMP R10,%Display7Seg Data is ready, Display on 7Seg 5 5 RETP Return from Procedure 2 2 %LOAD_1 R3 was 1 MOV2B R5,0x49 R5=Representation of data for 7Seg 2 3 FJMP R10,%Display7Seg Data is ready, Display on 7Seg /88

55 RETP Return from Procedure 2 2 %LOAD_0 R3 was 0 MOV2B R5,0x40 R5=Representation of data for 7Seg 2 3 FJMP R10,%Display7Seg Data is ready, Display on 7Seg 5 5 RETP Return from Procedure 2 2 ;Cycle Count (Worse case): 25% Improvement %BreakNumberTo7Seg Break R2 into 4 segments (4bit each), each loaded into a different 7Seg (input/output decided by R7) MOVB R3,0x000f R3= AND R3,R2,R3 R3=R2&R3=4 Lower bits 0 1 MOVW R4,R7 R4=R7=Which 7Seg to use 0 1 FJMP R10,%Calc7Seg Calculate 7Seg data from R3's data 5 5 MOV2B R3,0x00f0 R3= AND R3,R2,R3 R3=R2&R3=2 nd 4 Lower bits 0 1 INC R4 R3+=1, Use next 7Seg 0 1 FJMP R10,%Calc7Seg Calculate 7Seg data from R3's data 5 5 MOV2B R3,0x0f00 R3= AND R3,R2,R3 R3=R2&R3=2 nd 4 Upper bits 0 1 INC R4 R3+=1, Use next 7Seg 0 1 FJMP R10,%Calc7Seg Calculate 7Seg data from R3's data 5 5 MOV2B R3,0xf000 R3= AND R3,R2,R3 R3=R2&R3=4 Upper bits 0 1 INC R4 R3+=1, Use next 7Seg 0 1 FJMP R10,%Calc7Seg Calculate 7Seg data from R3's data 5 5 ;Cycle Count: 25% Improvement %SetDataFor7Seg Load the correct input into R2, the input for the 7Seg MOVB R7,0 Load R7 to 0, in order to show data on input 7Seg 0 1 MOV2B R2,#AddSwitchSelect R2=Address of the selection switch 3 3 LOD R3,R2 R3=[R2]=Value of selection switch 1 1 OR R3,R3,R3 R3=R3 R3=0 Only if originally was FJZ R10,%SWITCH_LOAD_0 0 SWITCH_LOAD_0 5 5 ;%SWITCH_LOAD_1 Means the value of the switch was 1 MOVW R2,R1 R2=R1=Input FJMP R10,%BreakNumberTo7Seg Select which 7Seg to output too /88

56 RETP Return from procedure 2 2 %SWITCH_LOAD_0 Means the value of the switch was 0 MOVW R2,R0 R2=R0=Input0 0 1 FJMP R10,%BreakNumberTo7Seg Select which 7Seg to output too 5 5 RETP Return from procedure 2 2 ;Cycle Count: 15% Improvement ;Interrupts Begin: ;R0 = Input 0, R1 = Input 1 ;R2 = Selected Input, R3 = ;R4 = Selected 7Seg, R5 = :61440 Int0, Load Input based on Switch #0 FJMP R10,%SetDataFor7Seg Fast jump to the function 5 5 RETI Return 2 2 ;Cycle Count: 0% Improvement 7 7 :61952 Int1, Store input based on Switch #0 MOV2B R2,#AddSwitchSelect R2=Address of the selection switch 3 3 LOD R3,R2 R3=[R2] 1 1 OR R3,R3,R3 Check the switches value 0 1 FJZ R10,%SWITCH_STR_0 0 SWITCH_STR_0 5 5 ;%SWITCH_STR_1 Means the value of the switch was 1 MOV2B R2,#AddInput R2=Address of input data 3 3 LOD R1,R2 R1=[R2]=Input data 0 1 FJMP R2,%SetDataFor7Seg Reload data into 7Seg 5 5 %SWITCH_STR_0 Means the value of the switch was 0 LOD R0,R2 R0=[R2]=Input data 0 1 FJMP R2,%SetDataFor7Seg Reload data into 7Seg 5 5 RETI Return from Interrupt 2 2 ;Cycle Count: 14.5% Improvement 7 8 :62464 Int2, Perform AND on R0,R1 and output to output 7Seg AND R2,R0,R1 R2=R0&R1 0 1 MOVB R7,4 Load R7 to 4, in order to show data on output 7Seg 0 1 FJMP R10,%BreakNumberTo7Seg Reload data into output 7Seg 5 5 RETI Return from Interrupt /88

57 ;Cycle Count: 22% Improvement 7 9 :62976 Int3, Perform OR on R0,R1 and output to output 7Seg OR R2,R0,R1 R2=R0 R1 0 1 MOVB R7,4 Load R7 to 4, in order to show data on output 7Seg 0 1 FJMP R10,%BreakNumberTo7Seg Reload data into output 7Seg 5 5 RETI Return from Interrupt 2 2 ;Cycle Count: 22% Improvement 7 9 :63488 Int4, Perform Shift 4 on R0 and output 7Seg MOVW R2,R0 R2=R0 1 1 SHT R2,4 Shift R2 by 4 places, R2=R2*2^4 0 1 MOVB R7,4 Load R7 to 4, in order to show data on output 7Seg 0 1 FJMP R10,%BreakNumberTo7Seg Reload data into output 7Seg 5 5 RETI Return from Interrupt 2 2 ;Cycle Count: 20% Improvement 8 10 :64000 Int5, Perform XOR on R0,R1 and output to output 7Seg XOR R2,R0,R1 R2=R0^R1 0 1 MOVB R7,4 Load R7 to 4, in order to show data on output 7Seg 0 1 FJMP R10,%BreakNumberTo7Seg Reload data into output 7Seg 5 5 RETI Return from Interrupt 2 2 ;Cycle Count: 22% Improvement 7 9 :64512 Int6, Toggle mask register (RF) MOV2B R10,0xFFFF Set R10 to all XOR RF,RF,R10 RF = RF^R10 = Toggle all bits 0 1 RETI Return from Interrupt 2 2 ;Cycle Count: 25% Improvement 3 4 :65024 Int7, Simply Count for 5 seconds, Non maskable INT MOVB R7,4 Load R7 to 4, in order to show data on output 7Seg 0 1 MOVB R2,0 Set R2 (the output data) to start with MOVB RC,5 Load loop counted to /88

58 %LOOP_COUNT_TO_5 Load data into the output 7Seg, hold for 1 second, inc it and repeat INC R2 INC R2 0 1 FJMP R10,%BreakNumberTo7Seg Change output 5 5 FJMP R10,%Wait1Sec Wait for 1 second 5 5 FLOOP R11,%LOOP_COUNT_TO_5 Loop 5 5 RETI Return from Interrupt 2 2 ;Cycle Count: 10% Improvement Demo Analyze: For a regular use, that performs: Storing two numbers, performing AND, SHIFT and OR. We can see that the total cycle count is reduced in about 20% (from 1179 to 936 cycles) when using the Smart-NOP interface. 58/88

59 Suggestions for future projects Our project was made in order to create a fully working portable system on chip which will connect via USB to any computer or other peripheral. By creating fully customizable development tools which are needed, we have created a good baseline for completing this task next year. Also, because there is no specific target to our current compiler, any other team in the university can take the compiler tool and use it to enjoy high-level assembly language writing, with error detection, labels, absolute addresses and more. Furthermore, because we implemented Data-Hazard detection avoidance, the compiler can be used on very simple controllers, which don t want to add the complexity of data forwarding and detection. Of course, our project and the other system s project require an integration project which will connect them together to a fully functioning system on chip. Such a project, will allow many other kinds of systems on chip, which can communicate very easily via the USB2.0 protocol, such as a Graphic on chip which can utilize last year s project, the AGE. By using our code for the SDK, Compiler and WinUSB communication example, a future team can take the finished components (DMAC, µcontroller, PE, SDK), integrate them and upload them onto an FPGA which will be connected via USB to a PC fairly easy, and also write complex programs for the compiler (see the Demo code). We suggest considering a WDK driver creation project to allow isochronous transfers, mainly for achieving real-time operations. We do feel obliged to say that such a project will require extensive knowledge in Kernel and driver programming, and will have to have a programmer in charge. If the required knowledge and personal can be acquired, it will give the engineering 59/88

60 school a big step in the driver development field and will allow different and advanced USB hardware projects to be connected to the host via USB and controlled by it. We believe that by creating these projects, the engineering school will get closer to the real systems in the industry. 60/88

61 A Programmers guide: MFC Microsoft Foundation Class Library MFC History: MFC was Microsoft's way of shifting programmers from C to C++, mainly shifting to object-oriented programming, one of the biggest concept breakthroughs of the 20 th century programming. In the early 1990, most programmers were Assembler or C programmers only. One of the main concept of programming was "we want control", meaning, no need for help nor limitation from outside; just raw writing, raw memory handling and more. In their eyes, C was only a way to create semi-assembler code faster in higher level programming and not a new concept. Create programs in the raw C code made them fast and lightweight, but it also made them unstable and very hard to maintain or understand by other programmers. In 1992 (in the old days of 16bit windows version 3.1), Microsoft introduced a new API with their latest compiler (Version 7.0), "Application Framework Extensions" (AFX) which name was later changed to MFC. Its purpose was to create an extremely thin object oriented C++ Wrapper for the Microsoft windows API; Making it easier for programmers to use the Win32 API while keeping it very close to C++. Starting the late 1990s, Microsoft began development on the Next Generation Windows Services (NGWS) which were late on called.net Framework in order to replace the MFC API. The purpose of the new API was to create easier coding and better productivity and maintenance, also, the new API included an inner Garbage Collector (which allows for less worry over memory handling). 61/88

62 Although.Net sounds terrific, and required a lot of less experience, it had shortcomings: i. Performance The new API gave a huge performance hit for the applications. Although this does not affect small applications, for Real-time/Server applications, this was not an option. ii. iii. Package Size The new.net's package size was huge (compared to MFC) resulting in more than 50Mb per package (Although this might seem small today, in the early 2000, this was a very problematic download). Supported OS Although MFC and.net are made for Windows only, MFC was basically a wrapper for the API, and was still C++,.Net moved to a completely new language which only it supported. Making it Cross Platformless and harder to learn for older programmers. Because of these reasons (and many more) and although MFC was getting "old", it was never abandoned by programmers, especially for time sensitive/high performance applications, and starting 2008, Microsoft began re-releasing updates and feature packs for MFC as well (MFC Version 9.0 and version 10.0 with the latest Visual studio 2010). 62/88

63 MFC Overview: In order to understand MFC, one must understand its basic class library. The main hierarchy is the following: i. CObject The Principal base class for the MFC Library, supports diagnostics, run-time information and serialization, all the classes in MFC inherit from it. ii. iii. iv. CCmdTarget - Provides message map architecture for dialogs, views and other controls. This class lets the programmer route events (such as button click) to a "physical" function, dialog, control or other program. CWnd The parent for all the window classes in MFC, it includes the window handle (HWND) which is used by Window's itself to maintain and preserve resources to the application and includes the basic functions for any GUI driven control, such as size handling, on-screen location, z-ordering and more. CDialog The most basic form of simplified GUI, this class holds all the needed functions to maintain a simple dialog (Window) and create inside it various controls such as: i. Edit boxes (CEdit) ii. Buttons (CButton) iii. List controls (CListCtrl) iv. Tree controls (CTreeCtrl) v. Plain text (CStatic) vi. Group boxes (Derived from CButton) 63/88

64 v. Doc/View architecture One of architecture ideas Microsoft had was to separate the envelope, the view and the data from each other. In order to accomplish that, they create the Doc/View architecture which includes three main classes: i. CFrame: The CFrame is the envelope for the Doc/View, it routes the messages, display a menu and provide the bounding between multiple projects. ii. CDocument: The CDocument basically contains data, it can be used to have multiple documents such as word and excel. iii. CView : This is the GUI of the application, which loads the data from the currently active document; it is also responsible for printing and other viewing methods needed. There are many prebuilt classes to simplify the work of the programmer, mostly in order to help the GUI development of the view: CFormView, a scrollable view that contains dialog-box controls and is based on a dialog template resource. CListView, a view that has list controls. CRecordView, a view that displays database records in dialog-box controls. CTreeView, a view that has tree controls. When facing the need to maintain multiple sets of data, and/or multiple sets of views for the same data, the Doc/View architecture makes the separation more coherent and visible, thus, making a simpler program. The CDialog class is basically the main structure for both of our programs (The SDK and the Compiler). 64/88

65 Most of our work was done on top of it while using modified controls such as the CTreeCtrl for fast selection of data in the SDK and a heavily modified CListCtrl for the data itself. One of our biggest challenges was digging into the CListCtrl in order to customize it to fit our needs. Example - The SDK and its use of MFC controls: Naming Conventions in Win32 and MFC: There are a couple of naming conventions every programmer must follow, in order to understand our code, these is a short list of the conventions used in MFC (and Win32 in general). Hungarian Notation Prefix b f c n h l Meaning Boolean, true/false Flag (Word, Byte) A single Character Short or Integer Handle (File, window, etc) Long s, str String sz Usually string, can be size 65/88

66 p Any pointer LPSTR Pointer to string Win32 Data Types LPTSTR LPCSTR BOOL (not bool) Pointer to Unicode String Pointer to a const string Window's Boolean, not be confused with bool, this is an integer, though used usually with the TRUE/FALSE constants UINT Unsigned integer Constants Win32 Always Upper case, in the following format: Class_Type LVS_REPORT LVS = list control REPORT = A report mode ns Conventio MFC m_ On C Class members Message Handler (OnButtonClk) Prefix for classes, CDialog, CListCtrl, etc m_ncurrentline m_ = Class member ncurrentline = Type integer Examples m_strlabel m_bmustnops m_ = Class Member strlabel = CString m_ = Class member bmustnops = bool/bool Collection Classes: Besides the basic classes for window handling, there are the collection classes: The collections are divided into three types: Arrays, Lists and Maps. It is easy to understand their differences by understanding how to choose them: Collection Ordered? Indexed? Insert an Search for Duplicate element specified element elements? List Yes No Fast Slow Yes Array Yes By integer Slow Slow Yes Map No By any key Fast Fast No (keys) 66/88

67 Yes (values) 1. Lists (CList, CPtrList, CStringList) These lists are basically wrappers for doubly linked lists, meaning, they hold a Head and Tail pointers and use it to traverse the list. Because there is no real structure for the list itself, it can be very useful in places which we need to add or delete a lot of objects. The biggest disadvantage of the list is the fact that it is not indexed, meaning, you cannot reach the N th location directly, but must traverse (from head or tail) to it. 2. Arrays (CArray, CPtrArray, CStringArray, CUIntArray) Arrays are basically a C/C++ array which was added with a dynamic resizing mechanism. Its biggest advantage is the "easy to retrieve" data method but it lacks in speed for either inserting or searching items. 3. Maps (CMap, CMapStringToString, CMapStrintToPtr) Maps are basically a hash table (or Dictionary) that holds a pair of <Key, Value>. The Key is being hashed (via a hash function) making it fast to find thus, making the retrieval of objects/values (of any size) very fast. Although a Map is very fast, it does not keep the original order of the data, meaning, in order to retrieve an object, you must know its Key and not only its location. In our code we mainly encountered the CStringArray (An array of strings), CTypedPtrArray (An array of a pointer to any object) and CMapStringToString (for fast transform from a string to another). 67/88

68 Configuring the SDK and Compiler Along with the development and implementation of our software, we decided to create them fully customizable for the sake of the different users who can use them. In the next sections, we will review each configuration (and input) files that the applications receive and explain how to build them. The Compiler: The compiler application receives several configuration files from the user and the input file to assemble: The commands file - Mandatory: The commands file holds the instruction set (IS) which the controller/cpu target handles. In the file, the user may write both commands and add user macros which can hold anything from simple functions to complete code segments. Command Format: Command Name (SPACE) Binary Machine Code (SPACE) NOP Count (SPACE) InputType1 (COMMA) InputType2 (COMMA) Example: AddI ,1 Explanation: AddI The command name for the instruction set (Not Case sensitive) The Machine OPCode for the command (Only in binary format). 1 The amount of NOPs the command requires after it. If an! is inserted before the number, Smart-NOPs is disabled, and the amount of NOPs will always be inserted (useful for JMPs) 3 Input Type 3, Register 1 Input Type 1, 8Bit immediate 68/88

69 User Macro Name (SPACE) Command from IS including inputs; Next command; To use one of the inputs (which the user includes in the command) first input from user), to user Upper or Lower (half from CPU bit Size) from an immediate, write Example 1 A Simple With the user writing (in the Input file): INC R1 will transform into AddI R1,1 Example 2 More complex movb RC,@0,RC With the user writing (in the Input file): FLoop R1, %Label Movb Sht Movb Loop Command name will be UPPER@1 R1, R1, LOWER(%Label) RC,@0,RC RC,R1,RC 69/88

70 The registers file (Registers.txt) - Mandatory: The registers file is contains the names of the different registers and their op codes, it also supports multiple aliases for a single OPCode. Register Format: Name1 (Comma) Name2 (Space)OPCode (Binary) Example 1 Regular Register: R Example 2 Multiple Aliases: R15,RF 1111 The constants file (Constants.txt) - Optional: This file can be used to store global constants which can later be used in the complier as Labels or Absolute addresses. Constant Format: #ConstantName (Space) Address (0x for Hex or Decimal) Example: #Add7Seg0 0x7fff The input file (input.txt) The input file is the assembly code which the user wants to assemble and convert to the machine code. The commands which are allowed in this file are those from the IS of the commands file (Including the User Macros). Comments: For documenting the code, we allowed the user to use C/C++ style commenting. Comment Format 1: Each line starting (and only starting) with // will be considered as a comment 70/88

71 Comment Format 2: Each block starting with /* will be a comment until a */ is found. Both /* and */ must be the start of the line. Input command Format: Name (SPACE) Input1 (COMMA) Input2 (COMMA) Example 1 Regular command: ADD R3,R1,R2 Example 2 User Macro (Exactly the same): INC R2 Example 3 Another User Macro: FJC R10,%CORRECT_JC Label Usage Format: Each label must be preceded with % followed by the name. The names are not case sensitive and may contain any character but spaces. Absolute address Format: In order to reach specific locations (for example, for interrupts) we gave the user the option to define absolute locations in the input file. When the user creates a line containing (for example) -:1000 It will tell the compiler to start inserting NOPs before the command, until it reached 999, and continue with the next command (resulting in next command being in address 1000). The output files (Output.txt and Output.chk.txt): The compiler creates two different output files: 71/88

72 The Output.txt file: This file contains the binary machine code which is the final output which is ready to be burned into the µcompiler. The Output.chk.txt file: This file is parsed from the output.txt file, including parsed binary lines and the original lines as well. It also indicates the operations of the Labels, Absolute Addresses, SmartNops and Hazards, allowing the programmer to make sure everything is correct and done according to his original program. Example: sht R10,8 Indicating the line number, machine code (divided into bytes) and original command. The SDK: Although The SDK application is dedicated to the USB 2.0 spec it can accommodate any module which has the same format. In order to configure the SDK with the correct descriptors types spec following the USB2.0 Spec, we created a number of INI files which contains the needed data. The INI files should be located in the folder names INI, which is place in the exe file folder. As any other Windows INI file, the INI is constructed from Sections and Entries. Format: [Section Name] Entry= Value [Next Section] 72/88

73 Explanation: Anything between each section and the next one is considered to be from the same data set, thus, allowing for easy access via calling for a read/write command over the Section and its entry. All of our INIs begin with the section [General] followed by the number of fields, Num_Of= #. Then, each field which we want to use is a different section with the naming convention of Field_#. Field Example: [Field_0] Offset=0 Field=bLength Size=1 Desc=Size of Descriptor in Bytes Type=Number Explanation This is the first field in the current INI, dubbed, Field_0. Its offset (as specified in the USB2.0 Spec) is 0. Its name is blength Its size is 1 byte Its description (which shows in the bottom of the screen) is " Size of Descriptor in Bytes" Its type is also shown in the table, for easier understanding of what input is expected. The INI files: The SDK expects to find four INI files: DeviceDesc.ini ConfigDesc.ini InterDesc.ini 73/88

74 EndPointDesc.ini All of the INI files are written exactly the same, where the relationship between them is 1 Device, 1 Config, 4 Interfaces and 16 (in/out) EndPoints for each interface. 74/88

75 A sample INI file (EndPointDesc.ini) [General] Num_Of=6 [Field_0] Offset=0 Field=bLength Size=1 Desc=Size of Descriptor in Bytes (7 bytes) Type=Number Endpoint 01 = Feedback Endpoint 00 = Data Endpoint Bits 5..4 = Usage Type (Iso 11 = Reserved Mode) 11 = Synchronous 10 = Adaptive 01 = Asynchronous = No Synchonisation3..2 = Synchronisation Type (Iso Mode)Isochronous endpoint, Type=Bitmap [Field_1] Offset=1 Field=bDescriptorType Size=1 Desc=Endpoint Descriptor (0x05) Type=Constant [Field_2] Offset=2 Field=bEndpointAddress Size=1 Desc=Endpoint Address Bits 0..3b Endpoint Number. Bits 4..6b Reserved. Set to Zero Bits 7 Direction 0 = Out, 1 = In (Ignored for Control Endpoints) Type=Endpoint [Field_3] Offset=3 Field=bmAttributes Size=1 Desc=Bits 0..1 Transfer Type 00 = Control 01 = Isochronous 10 = Bulk 11 = Interrupt Bits 2..7 are reserved. If Bits = Explicit Feedback Data [Field_4] Offset=4 Field=wMaxPacketSize Size=2 Desc=Maximum Packet Size this endpoint is capable of sending or receiving Type=Number [Field_5] Offset=6 Field=bInterval Size=1 Desc=Interval for polling endpoint data transfers. Type in frame counts. Ignored for Bulk & Control Endpoints. Isochronous must equal 1 and field may range from 1 to 255 for interrupt endpoints. Type=Number 75/88

76 Appendixes: The INF File This is the data the WinUSB Kit requires in order to work with device. Each line is commented with explanations, and it is pretty straightforward. [Version] Signature = "$Windows NT$" ; Device class name Class = VlsiLabContClass ; Device GUID (unique ID) ClassGuid={78A1C d3-B88D- 00C04FAD5171} Provider = %ProviderName% ; Catalog file, only needed for x64 OSes ;CatalogFile=MyCatFile.cat ; ================== Class section ================== [ClassInstall32] Addreg=VlsiLabContClassReg [VlsiLabContClassReg] HKR,,,0,%ClassName% HKR,,Icon,,-1 ; ========== Manufacturer/Models sections =========== [Manufacturer] %ProviderName% = VlsiLabCont_WinUSB,NTx86,NTamd64,NTia64 [VlsiLabCont_WinUSB.NTx86] %USB\VlsiLabCont.DeviceDesc% =USB_Install, USB\VID_0547&PID_1002 [VlsiLabCont_WinUSB.NTamd64] %USB\VlsiLabCont.DeviceDesc% =USB_Install, USB\VID_0547&PID_1002 [VlsiLabCont_WinUSB.NTia64] %USB\VlsiLabCont.DeviceDesc% =USB_Install, USB\VID_0547&PID_1002 ; =================== Installation =================== ;Include files and services [USB_Install] Include=winusb.inf Needs=WINUSB.NT [USB_Install.Services] Include=winusb.inf AddService=WinUSB,0x ,WinUSB_ServiceIn stall ;Create the driver as service [WinUSB_ServiceInstall] DisplayName = %WinUSB_SvcDesc% ServiceType = 1 StartType = 3 ErrorControl = 1 ServiceBinary = %12%\WinUSB.sys ;Define the WinUsb.sys as kernal-mode service [USB_Install.Wdf] KmdfService=WINUSB, WinUsb_Install [WinUSB_Install] KmdfLibraryVersion=1.5 ;Define the GUIS of the device and set it as a regisity value [USB_Install.HW] AddReg=Dev_AddReg [Dev_AddReg] HKR,,DeviceInterfaceGUIDs,0x10000,"{b35924d6-3e16-4a9e a4b79bac}" ;Defines the data insturcttions needed to installing the co-installers. [USB_Install.CoInstallers] AddReg=CoInstallers_AddReg CopyFiles=CoInstallers_CopyFiles [CoInstallers_AddReg] HKR,,CoInstallers32,0x ,"WdfCoInstalle r01005.dll,wdfcoinstaller","winusbcoinstaller.dll" [CoInstallers_CopyFiles] WinUSBCoInstaller.dll WdfCoInstaller01005.dll [DestinationDirs] CoInstallers_CopyFiles=11 ; ================= Source Media Section ===================== ; Define the different packages for x86, x64 OSes [SourceDisksNames] 1 = %DISK_NAME%,,,\i386 2 = %DISK_NAME%,,,\amd64 3 = %DISK_NAME%,,,\ia64 [SourceDisksFiles.x86] WinUSBCoInstaller.dll=1 WdfCoInstaller01005.dll=1 [SourceDisksFiles.amd64] WinUSBCoInstaller.dll=2 WdfCoInstaller01005.dll=2 [SourceDisksFiles.ia64] WinUSBCoInstaller.dll=3 WdfCoInstaller01005.dll=3 ; =================== Strings =================== [Strings] ProviderName="MyWinUsbTest" USB\VlsiLabCont.DeviceDesc="Test using WinUSB only" WinUSB_SvcDesc="WinUSB Test" DISK_NAME="My Install Disk" ClassName="VlsiLabContClass" 76/88

77 A simple.su2 file Example [0] ; Device Descriptor Table Num_Of=14 Value_0=1 Value_1=2 Value_2=1 Value_3=2 Value_4=3 Value_5=1 Value_6=2 Value_7=500 Value_8=739 Value_9=3249 Value_10=3 Value_11=1 Value_12=2 Value_13=3 [0_0] ; Config 0 Descriptor Table Num_Of=8 Value_0=3 Value_1=232 Value_2=1000 Value_3=23 Value_4=23 Value_5=10 Value_6=4 Value_7=2 [0_0_0] ; Interface 0, Config 0 Descriptor Table Num_Of=9 Value_0=1 Value_1=2 Value_2=3 Value_3=4 Value_4=1 Value_5=2 Value_6=3 Value_7=1 Value_8=23 [0_0_0_0_0] ; EndPoint IN 0, Interface 0, Config 0 Descriptor Table Num_Of=6 Value_0=0 Value_1=0 Value_2=0 Value_3=0 Value_4=0 Value_5=0 [0_0_0_1_0] ; EndPoint OUT 0, Interface 0, Config 0 Descriptor Table Num_Of=6 Value_0=1 Value_1=2 Value_2=3 Value_3=4 Value_4=5 Value_5=6 77/88

78 An SDK Compile Example ;Device Settings, Base Address: 0x0 MOV2B R1,0x0000 MOV2B R2,0x0001 STR R1,R2 MOV2B R1,0x0008 MOV2B R2,0x0002 STR R1,R2 MOV2B R1,0x0010 MOV2B R2,0x0001 STR R1,R2 MOV2B R1,0x0020 MOV2B R2,0x0002 STR R1,R2 MOV2B R1,0x0028 MOV2B R2,0x0003 STR R1,R2 MOV2B R1,0x0030 MOV2B R2,0x0001 STR R1,R2 MOV2B R1,0x0038 MOV2B R2,0x0002 STR R1,R2 MOV2B R1,0x0040 MOV2B R2,0x01f4 STR R1,R2 MOV2B R1,0x0050 MOV2B R2,0x02e3 STR R1,R2 MOV2B R1,0x0060 MOV2B R2,0x0cb1 STR R1,R2 MOV2B R1,0x0070 MOV2B R2,0x0003 STR R1,R2 MOV2B R1,0x0078 MOV2B R2,0x0001 STR R1,R2 MOV2B R1,0x0080 MOV2B R2,0x0002 STR R1,R2 MOV2B R1,0x0088 MOV2B R2,0x0003 STR R1,R2 ; ;Configuration Settings, Base Address: 0x9 MOV2B R1,0x0009 MOV2B R2,0x0003 STR R1,R2 MOV2B R1,0x0011 MOV2B R2,0x00e8 STR R1,R2 MOV2B R1,0x0019 MOV2B R2,0x03e8 STR R1,R2 MOV2B R1,0x0029 MOV2B R2,0x0017 STR R1,R2 MOV2B R1,0x0031 MOV2B R2,0x0017 STR R1,R2 MOV2B R1,0x0039 MOV2B R2,0x000a STR R1,R2 MOV2B R1,0x0041 MOV2B R2,0x0004 STR R1,R2 MOV2B R1,0x0049 MOV2B R2,0x0002 STR R1,R2 ; ;Interface [0] Settings, Base Address: 0xe ; ;Interface [0], EndPoint IN [0] Settings, Base Address: 0x22 MOV2B R1,0x0022 MOV2B R2,0x0000 STR R1,R2 MOV2B R1,0x002a MOV2B R2,0x0000 STR R1,R2 MOV2B R1,0x0032 MOV2B R2,0x0000 STR R1,R2 MOV2B R1,0x003a MOV2B R2,0x0000 STR R1,R2 MOV2B R1,0x0042 MOV2B R2,0x0000 STR R1,R2 MOV2B R1,0x0052 MOV2B R2,0x0000 STR R1,R2 ; ;Interface [0], EndPoint IN [1] Settings, Base Address: 0x26 MOV2B R1,0x0026 MOV2B R2,0x0001 STR R1,R2 MOV2B R1,0x002e MOV2B R2,0x0002 STR R1,R2 MOV2B R1,0x0036 MOV2B R2,0x0003 STR R1,R2 MOV2B R1,0x003e MOV2B R2,0x0004 STR R1,R2 MOV2B R1,0x0046 MOV2B R2,0x0005 STR R1,R2 MOV2B R1,0x0056 MOV2B R2,0x0006 STR R1,R2 78/88

79 The SDK UML diagram: Overview: 79/88

80 The AGE.SU2 File [0] // The Device - AGE Num_Of=14 Value_0=18 //Size of this descriptor, in bytes. Value_1=1 //DEVICE descriptor Type Value_2=512 //2.00 current rev of USB specification Value_3=239 Value_4=0 //No SubClass Value_5=0 //Device does not use class-specific protocols on a device basis. Value_6=64 Value_7=0 Value_8=0 Value_9=0 Value_10=0 Value_11=0 Value_12=0 Value_13=1 //One configuration [0_0] //Configuration Descriptor Num_Of=8 Value_0=9 // Size of this descriptor, in bytes. Value_1=2 // CONFIGURATION descriptor Value_2=109 // Length of the total configuration block, including this descriptor, in bytes Value_3=1 // This device has a single interface Value_4=1 // ID of this configuration Value_5=0 Value_6=128 // Bus-powered device, no remote wakeup capability Value_7=250 [0_0_0] // Interface Descriptor Num_Of=9 Value_0=9 // Size of this descriptor, in bytes. Value_1=4 // INTERFACE descriptor type Value_2=1 // Number of this (single) interface Value_3=0 // Default setting Value_4=14 // Number of endpoints (14) used by this interface (excluding endpoint 0) Value_5=0 Value_6=0 Value_7=250 // Device does not use class-specific protocols on a device basis Value_8=0 [0_0_0_0_0] // Frame Buffer (current) Num_Of=6 Value_0=7 // Size of this descriptor, in bytes Value_1=5 // ENDPOINT descriptor type (5- Endpoint) Value_2=17 // 1 = IN endpoint ; Address 1 (0x11 in hex) Value_3=1 // Transfer Type 01 = Isochronous, no sync, data endpoint Value_4=5120 // Maximum packet size = 1024 bytes, 3 transactions/µframe Value_5=3 // Interval for polling high BW endpoint for data transfers. // Expressed in µframe (125µSec) units [0_0_0_0_1] // Frame Buffer (upload) Num_Of=6 Value_0=7 // Size of this descriptor, in bytes Value_1=5 // ENDPOINT descriptor type (5- Endpoint) Value_2=18 // 1 = IN endpoint ; Address 1 (0x11 in hex) Value_3=2 // Transfer Type 01 = Isochronous, no sync, data endpoint Value_4=5120 // Maximum packet size = 1024 bytes, 3 transactions/µframe Value_5=3 // Interval for polling high BW endpoint for data transfers. // Expressed in µframe (125µSec) units [0_0_0_1_0] // Endpoint OUT #1 Descriptor RegFile TM Num_Of=6 Value_0=7 // Size of this descriptor, in bytes Value_1=5 // ENDPOINT descriptor type (5- Endpoint) Value_2=1 Value_3=3 // Transfer Type 10 = Bulk Value_4=512 Value_5=3 // 4 NAK/ACK per 1µFrame (125µSec) [0_0_0_1_1] // Endpoint OUT #2 Descriptor Descriptor RegFileSF Num_Of=6 Value_0=7 // Size of this descriptor, in bytes Value_1=5 // ENDPOINT descriptor type (5- Endpoint) Value_2=2 Value_3=3 // Transfer Type 10 = Bulk Value_4=12 Value_5=3 // 4 NAK/ACK per 1µFrame (125µSec) [0_0_0_1_2] // Endpoint OUT #3 Descriptor RegFileRSF Num_Of=6 Value_0=7 // Size of this descriptor, in bytes Value_1=5 // ENDPOINT descriptor type (5- Endpoint) Value_2=3 Value_3=3 // Transfer Type 10 = Bulk Value_4=12 Value_5=3 // 4 NAK/ACK per 1µFrame (125µSec) [0_0_0_1_3] // Endpoint OUT #4 Descriptor RegVn Num_Of=6 Value_0=7 // Size of this descriptor, in bytes 80/88

81 Value_1=5 // ENDPOINT descriptor type (5- Endpoint) Value_2=4 Value_3=3 // Transfer Type 10 = Bulk Value_4=2 Value_5=3 // 4 NAK/ACK per 1µFrame (125µSec) [0_0_0_1_4] // Endpoint OUT #5 Descriptor RegTn Num_Of=6 Value_0=7 // Size of this descriptor, in bytes Value_1=5 // ENDPOINT descriptor type (5- Endpoint) Value_2=5 Value_3=3 // Transfer Type 10 = Bulk Value_4=3 Value_5=3 // 4 NAK/ACK per 1µFrame (125µSec) [0_0_0_1_5] // Endpoint OUT #6 Descriptor RegFileSVP Num_Of=6 Value_0=7 // Size of this descriptor, in bytes Value_1=5 // ENDPOINT descriptor type (5- Endpoint) Value_2=6 Value_3=3 // Transfer Type 10 = Bulk Value_4=16 Value_5=3 // 4 NAK/ACK per 1µFrame (125µSec) [0_0_0_1_6] // Endpoint OUT #7 Descriptor RegBG Num_Of=6 Value_0=7 // Size of this descriptor, in bytes Value_1=5 // ENDPOINT descriptor type (5- Endpoint) Value_2=7 Value_3=3 // Transfer Type 10 = Bulk Value_4=3 Value_5=3 // 4 NAK/ACK per 1µFrame (125µSec) [0_0_0_1_7] // Endpoint OUT #8 Descriptor RegPPI Num_Of=6 Value_0=7 // Size of this descriptor, in bytes Value_1=5 // ENDPOINT descriptor type (5- Endpoint) Value_2=8 Value_3=3 // Transfer Type 10 = Bulk Value_4=1 Value_5=3 // 4 NAK/ACK per 1µFrame (125µSec) [0_0_0_1_8] // Endpoint OUT #9 Descriptor RegFileRWB Num_Of=6 Value_0=7 // Size of this descriptor, in bytes Value_1=5 // ENDPOINT descriptor type (5- Endpoint) Value_2=9 Value_3=3 // Transfer Type 10 = Bulk Value_4=24 Value_5=3 // 4 NAK/ACK per 1µFrame (125µSec) [0_0_0_1_9] // Endpoint OUT #10 Descriptor Vertices Memory Num_Of=6 Value_0=7 // Size of this descriptor, in bytes Value_1=5 // ENDPOINT descriptor type (5- Endpoint) Value_2=10 Value_3=2 // Transfer Type 10 = Bulk Value_4=512 Value_5=3 // 4 NAK/ACK per 1µFrame (125µSec) [0_0_0_1_10] // Endpoint OUT #11 Descriptor Triangles Memory Num_Of=6 Value_0=7 // Size of this descriptor, in bytes Value_1=5 // ENDPOINT descriptor type (5- Endpoint) Value_2=11 Value_3=2 Value_4=512 Value_5=3 [0_0_0_1_11] // Endpoint OUT #12 Descriptor Triangles Outward Normal Memory Num_Of=6 Value_0=7 // Size of this descriptor, in bytes Value_1=5 // ENDPOINT descriptor type (5- Endpoint) Value_2=12 Value_3=2 Value_4=512 Value_5=3 [0_0_0_1_12] // Endpoint OUT #13 Descriptor Triangles Color Memory Num_Of=6 Value_0=7 // Size of this descriptor, in bytes Value_1=5 // ENDPOINT descriptor type (5- Endpoint) Value_2=13 Value_3=2 Value_4=512 Value_5=3 [0_0_0_1_13] // Endpoint OUT #14 Descriptor RegFileLV Num_Of=6 Value_0=7 // Size of this descriptor, in bytes Value_1=5 // ENDPOINT descriptor type (5- Endpoint) Value_2=14 Value_3=3 Value_4=12 Value_5=3 [0_0_0_1_14] // Endpoint OUT #15 Descriptor RegSPn Num_Of=6 Value_0=7 // Size of this descriptor, in bytes Value_1=5 // ENDPOINT descriptor type (5- Endpoint) Value_2=15 Value_3=3 // Transfer Type 10 = Bulk Value_4=512 Value_5=3 // 4 NAK/ACK per 1µFrame (125µSec) 81/88

82 Compiler Flow charts (Abstract) Assembly input line parsing 82/88

83 Data reading process 83/88

84 Smart NOP insert process 84/88

85 SDK Flow charts (Abstract) Generic Operation of program: 85/88

86 Saving Process: Interface save example: 86/88

87 Store Information in field: Compile Process: 87/88