Latest revision as of 10:29, 16 September 2015

We propose a communication protocol between FPGA device and host computer based on data packets. This protocol differentiate control packets, state packets and data packets in the communication. We developed a set of IPs to implement this protocol. The structure of a typical top level VHDL design is depicted in the figure below. The top level entity is composed of two basic blocks that can remain unchanged: cypress_if and sequencer. The cypress_if module acts as an interface between the cypress device of the motherboard and the rest of the design inside the FPGA. The sequencer is in charge of the communication protocol. It reads packets from the host computer and sends commands to the application in one way, and create packets from data to the host computer in the other way. The application controller (applic_ctrl) should be adapted to the given application as well as one or more optional blocks of the application with their wrapper (applic_wrp). In this page, we will explain the role of basic hardware modules in the Evariste III system.

USB controller interface module – cypress_if

The cypress_if module controls access to the Cypress EZ USB controller’s input/output FIFOs via a synchronous 16-bit data bus and it writes and reads 16-bit data words to the depacketizer and from the packetizer (both are included in the sequencer module). If the USB controller’s input FIFO is not empty (data are available) AND the depacketizer is ready to receive new data, the cypress_if module reads one 16-bit data word from the input FIFO and writes it to the depacketizer. If the output FIFO is not full (data can be written) AND the packetizer has prepared new data word, the cypress_if sends one 16-bit data word from the packetizer to the output FIFO. Note that the cypress_if is responsible for inserting one turn-around clock cycle when changing the direction of the transfer on the bidirectional bus. One of the most important tasks of the cypress_if module is to manage the ends of transactions. In order to finish correctly the transactions (and to avoid that the last data will remain in the output FIFO), the application must assert the “end of packet” signal sent to the Cypress EZ USB interface. The end of transaction is usually defined by the host PC by sending the “end of packet” control flag as a part of the control packet and the application responds by counting the amount of data that must be written to the output FIFO before the “end of packet” output bit should be asserted. The module cypress_if asserts the “end_of_packet” signal also when the time-out occurs. The time-out delay is not programmable and it is defined in the cypress_if entity VHDL code.

Sequencer module - sequencer

As mentioned above, the current Evariste III system communicates with the host PC using packets. Three types of packets are used:

• control packets
• state packets
• data packets

The control packets and state packets are 128 bits long. The length of the data packets is a multiple of 128 bits. The payload of the data packet can contain 1 to 65536 blocks of 128 bits. The role of the sequencer is to analyze packets coming from the USB bus in a so-called depacketizer and to create packets that should be sent to the host PC in a so-called packetizer. Both depacketizer and packetizer will next be explained in more details. According to the payload size given in the data packet header, the sequencer controls the number of 128-bit blocks sent/received to/by the application.

Depacketizer

The depacketizer is a part of the sequencer module. It receives 16-bit words from the USB controller FIFO via the USB controller interface module and searches for the packet header (a 16-bit word 0x1337). Once the packet header is detected, the packet type prefix is expected to arrive in order to confirm one of the two kinds of packets that can come from the host PC: the control packet or the data packet. The control packet has a packet prefix 0xc0de and the data packet has a packet prefix 0xda7a. The packet headers and prefixes are followed by predefined control bits. The structure of the control and data packets is presented in the following figure.

When the control packet is received, the sequencer waits until the application is ready to receive the command, then it sends the 64-bit control word to the application controller and confirms this transfer by asserting the wr_ctrl2appl signal for exactly one period of the clk_ctrl clock signal.

Packetizer

The packetizer is a part of the sequencer module. It reads 128-bit data words and 96-bit state words from the application controller, creates data and state packets and sends them to the USB controller FIFO via the cypress_if module. The state packets are created in response to control packets sent by the host PC. The data packets are created in response to the demand from the host PC expressed by a non-zero value MMMM from previous figure. The packetizer decrements this value automatically when sending data blocs to the host PC. The state packet and data packet headers are identical 16-bit words having the value 0x1337. The packet header must be followed by the packet type prefix: the state packet has the prefix 0x57a7 and the data packet has the prefix 0xda7a (the same as the data packets sent by the host PC). The packet headers and prefixes are followed by predefined bits. The structure of the state and data packets is presented in the following figure.

Application controller module - applic_ctrl

The application is controlled by the sequencer using a 64-bit control word bus, 128-bit data bus and few control signals. It is clocked by the same clock as the sequencer (clk_ctrl). The transmission of control words and data words is possible only if the application is ready to receive commands or data. The sequencer reads the signal busy2state generated by the application and if this signal is not asserted (the application is ready), the sequencer can put the received command/data onto the internal bus (ctrl2appl or data2appl, respectively) and validate them by asserting the signal wr_ctrl2appl or wr_data2appl, respectively, during one clock period clk_ctrl. Once the command/data has been received, the application controller asserts the busy2state signal and processes the received command/data, while updating the state bits at its output. After processing the data, the controller puts the new data onto the internal bus appl2bus and it deasserts the busy2state signal.

Application module and its wrapper - applic_wrp

The user is free to make his application module and its wrapper. The structure of the application module will depend on the application controller (the part of the controller designed by the user) and on the application itself. It is thus very difficult to propose some structure for this module. Nevertheless, the user can start to design his module by using examples given as a part of the Evariste III system.

The top level entity

The top level entity instantiates the basic modules (cypress_if, sequencer, applic_ctrl and applic_wrp) and optional modules. It determines also the use of bits of the 96-bit state word state2bus (depending on the application) and of the 64-bit control word ctrl2appl (although the sequencer generates 64-bit control words transmitted in control packets and reads 96 state bits in the response to a command transmission not all control and state bits are always used). In our examples, bits 80 to 95 of the state word (16 bits) are used for transmission of the hardware version to the PC. Note also, that the control word bits 57 and 58 are reserved for generation of two levels of reset signals by the software: application reset and mode reset. This way, the software can reset hardware on three levels:

• the system reset (signal system_rst in the top level entity generated in the Cypress device by the call of the Cypress EZ USB reset function in the PC) will reset both USB controller and reconfigurable hardware (controller interface, sequencer, application controller and application itself)
• the application reset (signal appl_rst in the top level entity associated with the bit 57 of the control word) can be used for resetting the application, without resetting the USB controller interface
• the mode reset (signal mode_rst in the top level entity associated with the bit 58 of the control word) can be used for changing the mode of the application, for example by putting it into an idle state.

We propose two examples: a simple counter and a random number generator. In the first example, the mode is used to switch from “count up” mode to “count down” mode, and in the random generator mode enables to switch between two types of generator (with or without post-processing). According to Cypress EZ USB device documentation, we should provide a clock to latch data (clk_if) that is in advance compared to the data bus fd. This clock should have a frequency in a range between 3 to 48 MHz (see Cypress EZ USB device documentation for details). In our examples, we used a pll that generates two clocks: the control clock clk_ctrl and the Cypress USB interface controller clock clk_if. Both clocks must have the same frequency, but the clk_if clock must be advanced by about 60 degrees. In order to speed up the data transfer, we recommend setting the frequency to its maximum value defined by Cypress – 48 MHz. If some other clock signals are necessary in the application module, we recommend setting their frequency to a multiple of the clk_ctrl clock signal frequency.