Summary
The main aim of the project is to test the viability of using a cypress EZ-USB FX2 board containing a cy686 chip to interface with a FPGA Xilinx board to pass visualisation data to a PC. First objectives were to get any data passed to the PC by the two devices independently. Then to get the FPGA to display a coloured screen via VGA connection. Then to interface between the two devices. The final stages of the project were to display an image using a camera module on the FPGA interfacing with the FX2 board and get it displayed on the PC. A bonus would be to get the image fully rendered in colour as grayscale is relatively easier. Due to the project being heavily based on software the chips and components were already inbuilt.
Table of Contents
1.1 What is a FPGA? 2
1.2 What is an usb?
1.2.1 Control Transfers
1.2.2 Interrupt Transfers
1.2.3Isohronous Transfers
1.2.4Bulk Transfers
1.3 Similar Projects
1.3 Proposed Deliverables 3
2.1 Breakdown of the Nexys 3 Board
2.1.1 Hardware
2.1.2 Clock Design
2.1.3 Pmod Design
2.2 Breakdown of the Cypress EZ-USB FX2 Board
2.2.1 8051 Processor
2.2.2 General Programmable Interface (GPIF)
2.2.3 EZ-USB Endpoint Buffers
3.1 Software Development
3.1.1 FPGA CODING (ModelSim, ISE Design, Stream In, Stream Out, Loop Back)
3.1.2 Cypress EZ-USB FX2 coding
3.2 Cypress to FPGA interconnections
4.1 PC to FPGA
4.1.1 7 Segment Display
4.2 FPGA to PC
4.2.1 VGA display
4.2.2 USB HID Keyboard Controller
4.3 PC to FX2
4.3.1 FX2 Counter program description
4.4 FX2 to PC
4.4.1 USB HID Control
4.5 FPGA to FX2
4.5.1 Stream
4.6 FX2 to FPGA
4.6.1 Stream Out
4.7 Discussion
“[1] A major challenge of using digital circuits built on Xilinx FPGA boards is to import/export data to/from a PC for visualisation. The aim of this project is to review the viability of using a device such as the CY3674 EZ-USB FX1 (or FX2 or FX3). The main challenge of this project is to interface in a sensible way data streamed from the FPGA onto the PC via one of these devices. Another challenge would be to see how this could be used to program and/or configure the FPGA as well. “
For this project to be achievable I must first understand; how each device operates, the various protocols associated with each device, each device respective coding language etc. Here I will analyse the purpose of each device and the important operations or protocols each one uses to send data.
1.1 What is a FPGA?
Figure 1 FPGA layout [2]
FPGA stands for field-programmable gate array, semiconductor devices that are based around a matrix of logic blocks (LB as seen in figure 1) connected via programmable interconnects. Created by Xilinx in 1984, it’s a chip only limited by your imagination as it can be programmed to match your desired application requirements. It works based on developing a digital computing task in its required software language, compiling it down to a configuration file or bitstream that contains information on how the FPGA should behave. Unlike a microcontroller, the FPGA is not preloaded with anything, making it just a reprogrammable silicon chip at face value. This works to its advantage as it can be programmed and re-programmed to fit the users’ needs as many times as required. A microcontroller on the other hand, can only go by the CPU architecture and operates in a sequential manner while FPGAs’ run things in a parallel manner meaning different processing operations do not have to compete for the same resources. The one downfall of the FPGA would be that they are RAM based devices, so once the power is removed it loses all data and will need to be reprogrammed when turned back on.
1.2 What is a USB?
USB stands for Universal Serial Bus. Its purpose has become to standardise the connection between a PC and its peripheral devices such as keyboards, printers, external hard drives etc, and in some cases the PC can even power the peripheral device. The device first debuted in 1996 and only suited for devices like keyboards and mice as it only transferred at a rate of 1.5 Mbit/s (Low Bandwidth or Low Speed) and 12 Mbit/s (Full Speed). 2012 saw the release of the USB 2.0, with an improved data transfer speed of 480 Mbit/s (High Speed or High Bandwidth) to suite a wider variety of peripheral devices like memory sticks, external hardrives, webcams, CD hubs etc. Its then been upgraded to 3.0. Released in 2008, its considered to have super transmission speed with speeds up to 5Gbps which is a major upgrade from the 2.0. However, majority of products are still using the 2.0 version. Port to port connections vary from USB A to B which usually used for devices such as printers and scanners. USB A to C which is usually used for smaller devices like a phones charger.
This project will mainly focus data transfer which will involves 4 different types/ endpoints:
1.2.1 Control Transfers
[3] Control transfers configure and send commands to a device. Because they are so important, they employ the most extensive USB error checking. The host reserves a portion of each USB frame for Control transfers. Control transfers consist of two or three stages.
• The setup stage contains eight bytes of USB control data.
• An optional data stage contains more data, if required.
• The status (or handshake) stage allows the device to indicate successful completion of a control operation.
1.2.2 Interrupt Transfers
[3] Interrupt data is like bulk data; it can have packet sizes of 1 through 64 bytes at full speed or up to 1024 bytes at high-speed. Interrupt endpoints have an associated polling interval that ensures they will be polled (receive an IN token) by the host on a regular basis. The data has guaranteed latency, and unidirectional stream pipe and error detection. Figure illustrate the data transactions for data in transfers from the token packet to the data packet to the handshake packet.
1.2.3 Isochronous Transfers
[3] Isochronous data is time-critical and used to stream data like audio and video. An isochronous packet may contain up to 1023 bytes at full speed, or up to 1024 bytes at high speed. Time of delivery is the most important requirement for isochronous data. In every USB frame, a certain amount of USB bandwidth is allocated to isochronous transfers. To lighten the overhead, isochronous transfers have no handshake (ACK/NAK/STALL/NYET), and no retries; error detection is limited to a 16 bit CRC.
Isochronous transfers do not use the data-toggle mechanism. In full-speed mode, only one isochronous packet can be transferred per endpoint, per frame. In high-speed mode, up to three isochronous packets can be transferred per endpoint, per micro-frame.
1.2.4 Bulk Transfers
[3] Bulk data transfers in ‘bursts,’ travelling in packets of 8, 16, 32, or 64 bytes at full speed or 512 bytes at high speed. Bulk data has guaranteed accuracy due to an automatic retry mechanism for erroneous data, however, they have no guaranteed minimum bandwidth. The host schedules bulk packets when there is available bus time. Bulk transfers are typically used for printer, scanner, or modem data. Bulk data has built-in flow control provided by handshake packets. Figures illustrate the data transactions for both data in and out transfers from the token packet to the data packet to the handshake packet.
The FPGA to USB integration is very common within the industry and can be used for a wide range applications.
USB Oscilloscope – This project uses a form of imagine processing but focuses more on speeding up the data transfers between PC and oscilloscope. The data collected from the oscilloscope will be converted from analogue to digital. This data is then extracted by FPGA which passes through the USB peripheral controller which in this case is a Cypress EZ-USB FX3 and uses General Purpose Interfaces as well. This project however, just implements the ability for the USB peripheral controller to receive data and display rather than the ability to send data back.
http://ecesd.engr.uconn.edu/ecesd174/files/2012/10/Fall-Final-Report-Team-174.pdf
An alternative to using a Cypress EZ-USB to integrate with an FPGA would be to use a FTDI USB. FTDI devices use USB bulk transfers to transport data.
Image detection – This projects focus is on image detection. Although it does not use a USB peripheral controller as a medium for the FPGA to communicate to the PC it is able to achieve image detection through image processing.
https://www.cc.gatech.edu/~ksubrama/files/FPGA_Report.pdf
1.4 Proposed deliverables:
This project is heavily software based, so the majority of the hardware has already been implemented by the cypress and diligent manufactures on the respective boards. Below show the block diagrams of the various main components of the boards.
Figure 3 Nexys 3 Basic Block Diagram [4]
The Nexys3 is a complete, ready-to-use digital circuit development platform based on the Xilinx Spartan-6 LX16 FPGA. The Spartan-6 is optimized for high performance logic, and offers more than 50% higher capacity, higher performance, and more resources as compared to the Nexys2’s Spartan-3 500E FPGA. One of the most relevant features of the device will be its General-purpose input/output components (GPIO) i.e. its LEDs and 4-digit-seven-segment display and its input/output expansion connectors. There’s a fourth instalment to the Nexys series with the Nexys 4 board but its basis differs from the Nexys 2 and Nexy 3 as its based off the Artix-7 FPGA from Xilinx rather containing a Spartan chip like its predecessors.
Programming files are stored in SRAM-based memory cells within the FPGA. This data defines the FPGA’s logic functions and circuit connections, and it remains valid until it is erased by removing board power, by pressing the reset button attached to the PROG input, or by writing a new configuration file using the JTAG port.
The Nexys3 board includes eight slide switches, five push buttons, eight individual LEDs, and a four digit seven-segment display. The pushbuttons and slide switches are connected to the FPGA via series resistors to prevent damage from inadvertent short circuits (a short circuit could occur if an FPGA pin assigned to a pushbutton or slide switch was inadvertently defined as an output).
2.1.2 Clock Designs
[5] The Nexys 3 board includes a single 100MHz CMOS oscillator. The input clock can drive any or all four clock management tiles in the Spartan-6. Each tile includes two Digital Clock Managers (DCMs) and four Phase-Locked Loops (PLLs).
DCMs provide the four phases of the input frequency (0º, 90º, 180º, and 270º), a divided clock that can be the input clock divided by any integer from 2 to 16 or half numbers from 1.5 to 7.5, two antiphase clock outputs that can be multiplied by any integer from 2 to 32 and simultaneously divided by any integer from 1 to 32.
PLLs use Voltage Controlled Oscillators (VCOs) that can be programmed to generate frequencies from 400MHz to 1080MHz range by setting three sets of programmable dividers during FPAG configuration. VCO outputs have eight equally-spaced outputs (0º, 45º, 90º, 135º, 180º, 225º, 270º, and 315º) that can be divided by any integer between 1 and 128.
2.1.3 Pmod design
[5] The Pmods on the Nexys 3 board will be very essential within this project as they will be the gateway in which data is passed to and from the Nexys 3 board for communication.
Figure 4 Spartan 6 to Pmod Block Diagram [5]
The suggested EZ-USB to FPGA connection would translate to the Nexys 3 board by connecting each input or output to the 4 Pmod. Each pmod section has 8 data signal pins, 2 voltage pins and 2 ground pins as seen above in figure. To accommodate the 16-bit data bus from port B and Port D on the FX2, Pmod B and C will be used. Pmod A will be used for the FX2 inputs and Pmod D will be used for the outputs.
The Cypress EZ-USB FX2LP is a flexible USB 2.0 peripheral controller designed to handle maximum USB 2.0 bandwidth. To take full advantage of the USB 2.0 480 Mbps signalling rate, FX2LP contains specialized hardware to buffer the USB data and connect seamlessly to a variety of high-bandwidth external devices such as MCUs, ASICs, and FPGAs. The FX2 has a fully configurable General Programmable Interface (GPIF™) and master/slave endpoint FIFO (8-bit or 16-bit data bus).
Figure 2 Cypress EZ-USB FX2 Hardware Block Diagram [5]
2.2.1 8051 Processor
FX2LP has an 8051 core with two USARTs, three counter/timers, and an enhanced interrupt system. The core can use a 48 MHz, 24 MHz, or 12 MHz clock. The CPU is supported by 16KB of on-chip code/data RAM. In addition, the 8051 has random access to the endpoint FIFOs for applications that require interpreting or modifying the data that is moving between the USB and peripheral interfaces. The 8051 selects the interface mode using an internal register. Single-chip mode is the power-on default configuration. Early versions of the 8051 (such as the 8031) only had external memory. Most applications used an external 64 KB ROM (or EPROM) chip (enabled by the 8051’s PSEN# signal) for program memory and an external 64 KB RAM chip (enabled by the 8051’s read and write signals) for data memory.
A software called Keil is used to program the 8051 processor through its internal RAM which will communicate with the whole board. The USB 2.0 specification and generous FX2LP buffering take care of transporting of bytes in and out of endpoint FIFOs at high speed over the USB interface, but that is only half of the job. The other end of the pipe must transport the FIFO data on/off chip at speeds matching USB transfer rates. FX2 contains two hardware interfaces specifically designed for this purpose: Slave FIFO and General Programmable Interface (GPIF). In addition to the high-speed transfer logic, the FX2 8051 has random access to the endpoint FIFOs for applications that require interpreting or modifying the data that is moving between the USB and peripheral interfaces. The memory structure of the device is slightly complex as a standard 8051 has read only memory but the FX2 devices memory is reprogrammable.
2.2.2 General Programmable Interface (GPIF)
Not all external controllers are designed to connect to a FIFO. Therefore, FX2LP provides a high-speed interface, GPIF which provides direct connection to common interfaces, such as disk drives, FPGAs, and ASICs, without requiring additional glue logic. The GPIF’s core is a state machine—you must develop waveforms using GPIF Designer to control the state machine. The GPIF is driven by one of the four Waveform Descriptors, which are data structures containing all the waveform information. GPIF Designer relieves the designer of understanding the descriptor formats. It uses the graphical waveform entry to create a C-language source file, which can be included in an FX2LP project. Provides six control (CTL) and ready (RDY) signals. Six control outputs are also programmable on a clock-by- clock basis. As a simple example, RD# and WR# strobes can be created with programmable durations and polarities using these control signals. Six ready inputs can be tested in a GPIF state machine to read status and perform interface synchronization. Three state outputs indicate the GPIF state, useful for debugging with a logic analyser.
2.2.3 EZ-USB Endpoint Buffers
Endpoint buffers are defined to be like a source of data. From the EZ-USB’s point of view, an endpoint is a buffer full of bytes received or held for transmission over the bus. Since USB is a serial bus, a device endpoint is an actual FIFO which sequentially empties or fills with USB data bytes. The host selects a device endpoint by sending a 4-bit address and a direction bit. Therefore, USB can uniquely address 32 endpoints, 16 of them being In endpoints, In0-15 and 16 of them being Out endpoints, Out0-15. The EZ-USB reads host data from an out endpoint buffer, and writes data for transmission to the host to an IN endpoint buffer.
EZ-USB contains three 64-byte endpoint buffers, plus 4 KB of buffer space that can be configured 12 ways. They all have common configurations.
Endpoints 2, 4, 6 and 8 are the large, high bandwidth, data moving endpoints. They can be configured in various ways to suit bandwidth requirements. Figure above demonstrates how these endpoints are used in the process of data transfers from the USB to an external peripheral device and the GPIF associated with them. The double, triple, or quad buffering abilities of the endpoints are demonstrated below in figure. Double buffering means that one packet of data can be filling or emptying with USB data while another packet (from the same endpoint) is being serviced by external interface logic. Triple buffering adds a third packet buffer to the pool, which can be used by either side (USB or inter- face) as needed. Quad buffering adds a fourth packet buffer. Multiple buffering can significantly improve USB bandwidth performance when the data supplying and consuming rates are similar, but bursty; it smooths out the bursts, reducing or eliminating the need for one side to wait for the other.
3.1 Software Development Environment
3.1.1 FPGA coding (ModelSim, ISE Design, Stream In, Stream Out, Loop Back)
ModelSim is a multi-language HDL simulation environment operating in Verilog, VHDL and System C languages. This project will use VHDL coding relating to the Nexys 3 board where ModelSim will be used to create and compile the necessary .bit file to identify any flaws within it. The file will then be tested through simulation, this process imitates each component within the .bit file as waveforms to ensure the code is working correctly.
ISE Design Suite is where the code will be prepared for transfer onto the Nexys 3 board…
Both applications were already installed on the PCs at the university and were easily accessible.
The main objectives for the FPGA will be to firstly provide an interface clock which will be shifted 180 degrees to match the requirements of the FX2 Slave FIFO. Secondly it will monitor the Full (Flag D, endpoint 6 In FIFO) and Empty (Flag A, endpoint 2 Out FIFO) and depending on which flag is activated the FPGA will respond by either reading or writing into the FIFOs accordingly, which gives the foundation on how to begin coding for the FPGA. The codes Stream In & Stream Out were created to monitor each flag separately.
Stream In
This codes purpose is to monitors the Full flag of EP6 (Flag D) in 2 states, write and idle. The FPGA continuously writes incrementing data into the FIFO while both Flag D and Sync (PC0 of FX2) signals are high. While writing data into the EP6 FIFO, the FPGA pauses the writing as soon as the Full flag gets asserted, this is when it is in an idle state. The FPGA then resumes the writing when the flag gets de-asserted, this is when it is in a write state.
Figure shows the two distinct states and the affected endpoints and demonstrates how if the EP6 Full flag (Flag D) stays low (asserted), the state machine remains in an idle state. After the Full flag and Sync signal goes high, there is a transition from state the idle state to the write state.
Stream Out
This codes purpose is to monitor the Empty flag EP2 (Flag A) in 2 states, read and idle. The FPGA continuously reads the incrementing data coming from the FX2 while Flag A is high. If Flag A should go low while the FPGA is reading then it will pause and go into its idle state. Here the FPGA will wait for Flag A to once again be high before it continues in the read state.
Figure shows the two distinct states and the affected endpoints in this state machine: Idle state and Read State. Idle state is where SLRD and SLOE stays high. As long as the EP2 Empty flag (FLAGA) stays low (asserted), the state machine remains in an idle state. After the EP2 Empty flag goes high, there is a transition from state the idle state to read state. Read state is where the FPGA continuously reads data from EP2 FIFO. The state machine goes back to the idle state when FLAG A becomes low. SLRD and SLOE signals are de-asserted during this transition.
Figure below illustrates the workings of the flags and components behaviour through a timings simulation. The code created should produce a similar outcome.
Loop Back
This code is a made up of a combination of the Stream In & Stream Out codes. This way the FPGA to FX2 connection created can both read, write and wait in one program without having to reprogram the FPGA with different codes every time the systems functionality needs to change. Here any data written into the EP2 FIFO of FX2LP is read by the FPGA, and written into the EP6 FIFO.
3.1.2 Cypress EZ-USB FX2 coding
Keil as a software allows for commands to be given to the 8051 processor within the cypress EZ-USB FX2. The software’s communication includes C/C++ compilers, debuggers, integrated development and simulation environments, RTOS and middleware libraries, and evaluation boards for ARM, Cortex-M, Cortex-R4, 8051, C166, and 251 processor families. The 8051 based architecture within the program has a standard programming format for all projects:
fw.c – The Cypress USB Firmware Frameworks.
bulkloop.c – Your application, also referred to as code module peripheral.c; it is a good idea to rename it for your specific project name.
dscr.a51 – is an assembly language file containing the data necessary to enumerate the USB device. The file comprises table data in the form of .db (define byte) statements. You edit this file to customize items such as VID/PID and descriptive strings for your design.
USBJmpTb.OBJ – is a jump table required by the FX2LP architecture, never requiring modification.
EZUSB.LIB – contains a library of useful FX2LP functions, mostly dealing with I2C communication. The source code is included with the FX2LP DVK in the TargetLibLP subfolder.
GPIF Designer
GPIF Designer is a graphical user interface (GUI) which allows a user to create or modify the waveforms associated to configure the GPIF function on the FX2 board.
Cypress Control Centre
Cypress Control Centre comes in Cypress Suite USB 3.4.7 downloaded as part of the development kit. It can be used to upload and test the firmware on the FX2 board. The USB Control Centre application allows you to upload code on the FX2LP RAM, Small EEPROM and 64KB EEPROM. It also has the feature which allows to transfer hex data onto different Endpoints.
The software for the FX2 proved to be more difficult to use as the programs were not originally installed on the PCs within the university. The available program for Keil was Keil µVision 5, only supporting arm based devices like Mbed and not 8051 processor devices which is needed for this project. The only resolution for this problem was for the FX2 firmware code to be developed using Keil uVision 2.0 which is a much older version of the software. The FX2 board itself gave problems as it required drivers to be installed on the PC before any interaction was possible which caused major setbacks to the progress of the project as at the time testing was supposed to take place, only drivers for windows 7 were available. It wasn’t until xyz date that the drivers for windows 10 was made available and installed on the computers for use.
Figure 6 displays the necessary connection between the FX2 device and a Xilinx FPGA board in order to transfer data successfully, illustrating in block diagram form how the GPIF and GPIOs from the FX2 and the Pmod ports from the FPGA will be utilised. The FX2 functions in synchronous Slave FIFO mode and the FPGA acts as the master.
Each signal is explained below.
Interface Clock – For this project an external clock source from the FPGA is used to generate the clock for the slave FIFO interface at 48MHz. However, this can be configured at any frequency between 5-48MHz or can be generated internally.
FIFO Flag pins – Flag pins feedback the status of the FX2’s FIFOs. A flag can either be used to show the FIFO is full, empty and programmable. The external source, in this case the FPGA, will usually monitor the ‘empty’ flag (EF) of OUT endpoints and the full flag (FF) of IN endpoints, the programmable level flag (PF) is equally useful for either type of endpoint. For the sake of this project, only FLAGA and FLAGD are being used to report when the status is empty and monitor when the status is full respectively.
FIFO Data Bus – These pins are located on ports B & D on the FX2 board, are used to show the ‘FIFO full’, ‘FIFO empty’ and ‘FIFO Programmable’. They can be configured to be either an 8-bit or 16-bit bus. The 16-bit configuration has been chosen for this project.
Control Pins (SLOE, SLRD, SLWR, PACKET END, FIFOADR [1:0])
The Slave FIFO ‘control’ pins are SLOE (Slave Output Enable), SLRD (Slave Read), SLWR (Slave Write), FIFOADR [1:0] (FIFO Select) and Packet End. ‘Read’ and ‘Write’ are from the external mater’s point of view, the external master reads from OUT endpoints and writes to IN endpoints. The SLOE pin enables the FD outputs. In synchronous mode, when SLOE is asserted, this causes the FD bus to be driven with the data that the FIFO pointer is currently pointing to. The data is pre-fetched and is output only when SLOE is asserted. By default, SLOE and SLRD are active-low, their polarities can be changed via the FIFOPINPOLAR register. The Slave write allows data to be written on the FIFO Data Bus either on the rising edge of the Interface Clock or on each asserted to deasserted transition of SLWR depending on if it’s in synchronous mode or asynchronous mode respectively.
FIFOADR [1:0]
The FIFOADR [1:0] pins select which of the four FIFOs is connected to the FD bus (and, if the FIFO flags are operating in indexed mode, they select which FIFO’s flags are presented on the respective FLAG pins):
The aim of these mini projects was to help gain a better understanding of each induvial device. Each project involved data transference of either; PC to device, Device to PC or Device to Device.
4.1.1 7 Segment Display
This is a basic project designed to use case statements to increment numbers and letters by 1 and assigning them to the 7-segment display. In this project, the 7-segment display is being configured to display the numbers 0 to 9 and the letter A to F. This was used to understand how to make use of the data acquired and assign it somewhere, in this case the incrementing in numbers during the case statement causes a change in numerical value on the segment display. For the project the segment display is used to show how many times the Empty and Full flags have been asserted. At first when the Full flag is asserted the second to last anode will increment and when the Empty flag is asserted the last anode will increment. But to shorten the code when the Full flag is asserted the display value on the last anode will increment, and when the Empty flag is asserted the display value will decrement.
4.2.1 VGA display
In this project the Nexys 3 board is used to control the PC screen. While being connected via a USB there is also a VGA connection between the Nexys 3 board and the PC. The mechanisms of this project are fairly similar to that of the main project as everything is based off timings, but instead of shifting the master clock, in this case the clock is divided. Figure shows how the clock is divided amongst the program to create an image.
| Description | Time | Width/Freq |
| Pixel Clock | 39.7 ns (± 0.5%) | 25.175MHz |
| Hor Sync Time | 3.813 μs | 96 Pixels |
| Hor Back Porch | 1.907 μs | 48 Pixels |
| Hor Front Porch | 0.636 μs | 16 Pixels |
| Hor Addr Video Time | 25.422 μs | 640 Pixels |
| Hor L/R Border | 0 μs | 0 Pixels |
| V Sync Time | 0.064 ms | 2 Lines |
| V Back Porch | 1.048 ms | 33 Lines |
| V Front Porch | 0.318 ms | 10 Lines |
| V Addr Video Time | 15.253 ms | 480 Lines |
| V T/B Border | 0 ms | 0 Lines |
Figure shows the code in block diagram form. This highlights the techniques that will be used later for the main project such as the clock division, loops within states and image display. The code example can be found in the appendix.
This project was used to gain an understanding on how imitate the FX2 to image sensor example found on the cypress website with the FPGA being the medium between the FX2 and the image sensor. As seen in figure below, the image sensor has a HSYNC and VSYNC pin out exactly like the VGA pin outs on the Nexys 3 board and so this would make displaying the image captured a lot easier. The ability to display colour also gives an insight on how to change the grayscale image into a coloured one.
4.2.2 USB HID Keyboard Controller
This aim of this project was to study how the keyboard is able to communicate with the Nexys 3 board and then relay that information to the PC. The keyboard can send data to the host only when both the data and clock lines are high (or idle). This process imitates the write state within the Stream In function needed to write data from the Nexys 3 to the FX2, as data is written when both Flag D and the Sync pulse are both high, and so the coding for the data transfer of the keyboard will give an understanding on how to code for the writing data transference from the Nexys 3 to the FX2.
Since the host is the bus master, the keyboard must check to see whether the host is sending data before driving the bus. To facilitate this, the clock line is used as a “clear to send” signal. If the host pulls the clock line low, the keyboard must not send any data until the clock is released. Here we have an imitation of the idle state of either Stream In or Out functions. Pulling the clock lines low will be the equivalent of pulling either of the Flags low causing the read or write state to go into idle state where the devices will do nothing until the flags are raised high. Code can be found in Appendix. Figure below gives an example.
This was the very first code example used on the FX2 board, found on the cypress website, to gain an understanding on how data transfers work as prior to this project there was no knowledge on the project. The code is programmed to control how fast the segment displays a 0-9 count. This is achieved by writing a certain number of bytes to EP2 (ranging from 0x01 to 0xFF), and each value will be passed into the timer function. The number of bytes written to EP2 will determine the delay between displaying each digit of 0-9 count. Performing an IN transfer afterwards will give the timer tick counts on EP6.
This code helped gained a better understanding on how the bulk transference of data impacts the behaviour of the FX2 board especially the roles that endpoints 2 and 6 play.
4.4.1 USB HID Control
The aim of this program was to see an example of how the FX2 board communicates and transfers data to a PC. The basis of the project is to use the four push buttons available on the FX2 board to demonstrate keyboard functionality. As discovered during research, the ability for a keyboard to function under a USB 1.0 specification due to its low data requirement, the large endpoints 2, 4, 6 or 8 will not be required for use the same way they would be in the main project, however the same data transference protocols remain the same and whatever is learnt can be adapted to meet the overall project’s needs.
4.5.1 Stream In
As explained in the software development under the system design section, the Stream In code is used to write data to the from the Nexys 3 board to the FX2. An excerpt of the code can be found in the appendix. Figures shows a simulation representation of the code.
Figure shows the state being idle as a result of Flag D being low. No data is being written during this period until Flag D goes high. The data begins to increment and will continue to do so until the flag is pulled low
4.6.1 Stream Out
As explained in the software development under the system design section, the Stream Out code is used to read incoming data from the FX2 board by the Nexys 3 board. An excerpt of the code can be found in the appendix. Figures shows a simulation representation of the code.
Figure shows the incrementing data being read by the FPGA while in a read state while Flag A is asserted. Figure is also proved to be correct as both SLRD (Slave Read) and SLOE (Slave Output Enable) are both low while in the read state, with the FIFOADR being 00.
Figure shows the last value of the data that was read before Flag A went low by the FPGA remains the same for the duration of the idle state. Figure is also proven to be true as both SLRD and SLOE are both asserted during the idle state.
The Stream Out code was further edited to give a real-time confirmation of the working code. For the FX2, both endpoints 2 & 6 are configured using the EP2CFG and EP6CFG registers. Both endpoints are set for double-buffering, using two 1024-byte FIFOS. The IFCONFIG register is not written, so it uses the default 8051 PORTS mode. The OUT endpoints, once configured, need to be armed to accept packets from the host. Since they are double buffered, they need to be armed by writing their byte count twice.
The 7 segment displays on both devices were used to demonstrate the transference of data, just as described in segment display project. Here, the Nexys 3 board will display the number of bytes being read and the FX2 would either increment or decrement based on whether Flags A or D were being asserted. Because the Stream Out code is activated when Flag D is pulled high the Nexys 3 will not do anything as it has not been programmed to respond to Flag D.
Figures below show an example of what happens when 0 bytes are sent twice to the Nexys 3 board from the FX2. Figure shows the data being sent over by the FX2 from the Cypress Control Centre.
As seen above the bulk data transfers take place on the empty flag, endpoint 2 (EP2), Flag A corresponding to the requirements needed to stream out data to the Nexys 3 board. 2 bulk transfers of 0 bytes are displayed in the text above. Figure below shows the resulting numbers on each segment display.
Project Budget
Graphs
Appendix:
Figure 1: Google Search
Figure 2: Google Search
Figure 3: Cypress website
Figure 4: NKC Electronics site: http://www.nkcelectronics.com/Nexys3-Spartan-6-FPGA-Board_p_232.html
FPGA Keyboard USB HID Control code excerpt
case state_reg is
when idle =>
tx_idle <= ‘1’;
if wr_ps2=‘1’ then
b_next <= par & din;
c_next <= (others=>‘1’); — 2^13-1
state_next <= rts;
end if;
when rts => — request to send
ps2c_out <= ‘0’;
tri_c <= ‘1’;
c_next <= c_reg – 1;
if (c_reg=0) then
state_next <= start;
end if;
when start => — assert start bit
ps2d_out <= ‘0’;
tri_d <= ‘1’;
if fall_edge=‘1’ then
n_next <= “1000”;
state_next <= data;
end if;
when data => — 8 data + 1 pairty
ps2d_out <= b_reg(0);
tri_d <= ‘1’;
if fall_edge=‘1’ then
b_next <= ‘0’ & b_reg(8 downto 1);
if n_reg = 0 then
state_next <= stop;
else
n_next <= n_reg – 1;
end if;
end if;
VGA Display code excerpts
constant HD: integer:= 640; –horizontal display area
constant HF: integer:= 16 ; –h. front porch
constant HB: integer:= 48 ; –h. back porch
constant HPW: integer:= 96 ; –h. pusle width
constant VD: integer:= 480; –vertical display area
constant VF: integer:= 10; –v. front porch
constant VB: integer:= 29; –v. back porch
constant VPW: integer:= 2; –v. pusle width
h_sync_next <=
‘1’ when (h_count_reg>=(HD+HF)) –656
and (h_count_reg<=(HD+HF+HPW–1)) else –751
‘0’;
v_sync_next <=
‘1’ when (v_count_reg>=(VD+VF)) –490
and (v_count_reg<=(VD+VF+VPW–1)) else –491
vgaRed <= “111” when video_on =‘1’;
vgaGreen<= “111”;
vgaBlue<=“11”;
Cypress segment display
BYTE xdata Digit[] = { 0xc0, 0xf9, 0xa4, 0xb0, 0x99, 0x92, 0x82, 0xf8,
0x80, 0x98, 0x88, 0x83, 0xc6, 0xa1, 0x86, 0x8e };
for(j=0;j<10;j++) // loop counts from 0–9
Stream In code
–write control signal generation
process(Now_State, FLAGD)begin
if((Now_State = In_WR) and (FLAGD = ‘1’))then
SLWR_i <= ‘0’;
else
SLWR_i <= ‘1’;
end if;
end process;
–streamIN mode state machine
streamIN_mode_fsm_f : process(IFCLK, Reset) begin
if(Reset = ‘0’)then
Now_State <= In_Idle;
elsif(IFCLK’event and IFCLK = ‘1’)then
Now_State <= Nxt_State;
end if;
end process;
–LoopBack mode state machine combo
streamIN_mode_fsm : process(FLAGD, Now_State) begin
Nxt_State <= Now_State;
case Now_State is
when In_Idle =>
if((FLAGD = ‘1’) and (sync = ‘1’))then
Nxt_State <= In_WR;
else
Nxt_State <= In_Idle;
end if;
when In_WR =>
if(FLAGD = ‘0’)then
Nxt_State <= In_Idle;
else
Nxt_State <= In_WR;
end if;
when others =>
Nxt_State <= In_Idle;
end case;
end process;
Stream Out code
—read control signal generation
process(NOW_State, FLAGA)begin
if((NOW_State = OUT_Rd) and (FLAGA = ‘1’))then
SLRD_i <= ‘0’;
SLOE_i <= ‘0’;
else
SLRD_i <= ‘1’;
SLOE_i <= ‘1’;
end if;
end process;
–streamOUT mode state machine
FSM : process(IFCLK, Reset_i) begin
if(Reset_i = ‘0’)then
NOW_State <= OUT_Idle;
elsif(IFCLK’event and IFCLK = ‘1’)then
NOW_State <= NXT_State;
end if;
end process;
–streamOUT mode state machine combo
process(FLAGA, NOW_State) begin
NXT_State <= NOW_State;
case NOW_State is
when OUT_Idle =>
if(FLAGA = ‘1’)then
NXT_State <= OUT_Rd;
else
NXT_State <= OUT_Idle;
end if;
when OUT_Rd =>
if(FLAGA = ‘0’)then
NXT_State <= OUT_Idle;
else
NXT_State <= OUT_Rd;
end if;
when others =>
NXT_State <= OUT_Idle;
end case;
end process;
Cypress keyboard
if( !(EP1INCS & bmEPBUSY) ) // Is the IN1BUF available,
{
EZUSB_ReadI2C(BTN_ADDR,0x01,&buttons); // Read button states
buttons &= 0x0F;
if ((oldbuttons – buttons) != 0) //Change in button state
{
if (buttons & 1) //Shift
EP1INBUF[0] = 0;
else
EP1INBUF[0] = 2;
if (buttons & 2) //a
EP1INBUF[2] = 0;
else
EP1INBUF[2] = 4;
if (buttons & 4) //b
EP1INBUF[3] = 0;
else
EP1INBUF[3] = 5;
if (buttons & 8) //c
EP1INBUF[4] = 0;
else
EP1INBUF[4] = 6;
EP1INBUF[1] = 0;
EP1INBC = 5;
}
oldbuttons = buttons;
}
project management
conclusion
references
You have to be 100% sure of the quality of your product to give a money-back guarantee. This describes us perfectly. Make sure that this guarantee is totally transparent.
Read moreEach paper is composed from scratch, according to your instructions. It is then checked by our plagiarism-detection software. There is no gap where plagiarism could squeeze in.
Read moreThanks to our free revisions, there is no way for you to be unsatisfied. We will work on your paper until you are completely happy with the result.
Read moreYour email is safe, as we store it according to international data protection rules. Your bank details are secure, as we use only reliable payment systems.
Read moreBy sending us your money, you buy the service we provide. Check out our terms and conditions if you prefer business talks to be laid out in official language.
Read more