Latest revision as of 22:50, 4 April 2013

The structure of a typical top level VHDL design is depicted in the following figure. The top level entity is composed of three basic blocks that should remain unchanged (modules cypress_if, sequencer and pll1), the application controller (applic_ctrl) that should be adapted to the given application and one or more optional blocks of the application with their wrapper (applic_wrp). One or more plls can be used if required. Next, we will explain the role of basic hardware modules in the Evariste II system.

The top level entity

The top level entity instantiates the basic modules (cypress_if, sequencer, pll1, applic_ctrl and applic_wrp) and optional modules (e.g. pll2). 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). Bits 80 to 95 of the state word (16 bits) are usually 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

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 module is responsible for inserting one turn-around clock cycle when changing the direction of the transfer on the bidirectional bus.

Another important task of the cypress_if module is to manage the ends of transactions. In order to finish transactions correctly (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

The Evariste II 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 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 depacketizer and to create packets that should be sent to the host PC in a packetizer. According to the payload size given in the data packet header, the sequencer controls the number of 128-bit blocks sent/received 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 packet prefix 0xc0de and the data packet has packet prefix 0cda7a. The packet headers and prefixes are followed by predefined control bits. The structure of the control and data packets is presented in the next figure.

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

Phase locked loops and clock generation

In the case of the Cypress USB controller application, the phase locked loop pll1 must generate at least 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 (delay - 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.

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 II system.

File structure of simulation and synthesis projects

The file structure for hardware simulation and synthesis projects depends on the design tool used. For Altera Quartus II and Xilinx ISE tools, we recommend to place the design files into three directories (this strategy is applied in all examples at this web page):

• Shared: this directory contains all files that are shared by the simulation and synthesis tools (VHDL files, hex files, etc.)
• Simul: this directory contains the ModelSim project, all simulation-specific VHDL files and two directories containing input and output scripts (scripts_in and scripts_out, respectively)
• Synth: this directory contains the reconfigurable hardware project and all synthesis-specific VHDL files

In the context of the Microsemi Libero design tools, the shared files are placed in the hdl directory (user defined files) and in the smartgen directory, the simulation files and directories are placed in the simulation directory and the synthesis files are placed in the synthesis directory. Note that the structure of the project and thus the names of the project directories are imposed by the Libero tool.

VHDL testbench and simulation

The VHDL testbench uses VHDL files and script input and output files. There are three testbench-related VHDL files:

• The testbench VHDL file itself
• The FIFO module (simulating the behavior of the Cypress EZ USB input/output FIFOs)
• The VHDL package txt_util for the text output.

The top level VHDL testbench file instantiates the top level entity of the design under test (DUT), it opens and interprets the input script file, creates packets accordingly and sends them to the Cypress controller input FIFO model. It also polls continuously the Cypress controller output FIFO model for packets sent by the DUT. If the output FIFO is not empty, the testbench reads the FIFO data, analyzes packets and creates the log file accordingly.

The ModelSim project should include all the VHDL files from the shared and simul directories. If some hex files are used (e.g. for embedded memory initialization), they should be placed in the simul directory.

Example projects (reference designs) include two more ModelSim *.do files: one for launching the simulation (the tb.do file) and the second one for defining the waveform window format. The user should just launch ModelSim, change the working directory inside ModelSim (File -> Change directory…) and type “do tb.do” in the Transcript window. The simulator will then compile the project, open the waveform window, open the script files and write waveforms to the waveform windows and the log file to the output log file in the Scripts_out directory.

VHDL synthesis and device configuration

The synthesis project file should include all the VHDL files from the shared and synth directories. If some hex files are used (e.g. for embedded memory initialization), they should be placed in the synth directory.

The project creation depends on device vendor and its design tool. The first example includes five projects for five available families and modules: Altera Cyclone III, Altera Arria II, Xilinx Spartan 3, Xilinx Virtex 5 and Microsemi Fusion. Other application projects can be created accordingly.

All FPGA modules contain small configuration connectors. Connectors on Altera and Xilins FPGA modules contain interface for both device SRAM configuration and for configuration memory programming. Small adapter cards are available for connecting standard configuration cables such as Altera USB Blaster, Xilinx Platform Cable USB II and Microsemi FlashPro3 (or compatible) with FPGA modules. Altera and Xilins adapter cards contain both JTAG interface for device configuration and proprietary interface for configuration memory programming.

Once the design of the application hardware is finished, the device configuration bitstream can be programmed into the configuration memory and the application is directly available once the card is plugged into the USB connector via standard USB cable. Note that before programming or configuring the card, the Evariste II motherboard must by powered from the USB bus or from some external power supply (by default, the card is powered from the USB bus). If the card is powered from the USB bus (the most frequent case), two USB cables are needed: one for powering the card and the other for configuring the device or programming the configuration memory.