USB Test Environment ATUSBTEST- SS7400. Summary

Transcription

1 Features Simple Command-driven Host Model Comprehensive Reports by Monitor Protocol Validation by Monitor Comprehensive Test Suite Fully Compliant with USB Forum Checklist Generates and Monitors Packets NRZI, Bit-stuffed, CRC Encoded Packets Error Packets Can Be Generated to Test for Robustness Provides Commands Set to Generate Different Transactions Interfaces with Atmel s USB Cores ATUSBHUB-SSU8040 ATUSBFUNC-SS7211 Overview The ATUSBTEST-SS7400 is a USB simulation environment designed to simulate and verify the application and USB functionality during the initial phases of the design and to verify the complete application in the final stages of the design. A typical USB environment consists of these functional blocks: host bus functional model to generate USB traffic; monitor model to monitor USB traffic; target device core such as the ATUSBFUNC-SS7211 (full-speed core) or the ATUSBHUB- SSU8040 (hub); and an application model to emulate the end application. The ATUSBTEST-SS7400 includes a host bus functional model with a command file interface and a simple integrated monitor model. The ATUSBTEST-SS7400 also includes an application model. This model can handle control transfers, interrupt transfers, bulk/iso in and bulk/iso out transfers. It has a simple command file interface to transfer the required data and simple controls to generate STALL and NO RESPONSE from the application. This model, in the course of the design, can be easily replaced by the end application s synthesized logic. This test environment supports both low- and full-speed implementations, although the ATUSBFUNC-SS7211 only allows full speed. USB Test Environment ATUSBTEST- SS7400 Summary Simple Simulation Environment Report File: hst_log Monitor Model Command File: hst_cmds Host Bus Functional Model USB Device Core Application Model Command File: app_cmds Rev. 1669AS 07/01 Note: This is a summary document. A complete document is available under NDA. For more information, please contact your local Atmel sales office. 1

2 Test Environment Guidelines Setting Up the Test Bench Users need to make sure that the ATUSBTEST-SS7400 is installed using the detailed instructions in the installation document. Upon successful installation of the ATUS- BTEST-SS7400, the following design steps need to be taken for proper simulation and verification of the USB device under test (DUT). 1. Instantiate the host model (from ATUSBTEST- SS7400) in a testbench module. 2. Instantiate two instances of transceiver model (provided): One transceiver to connect to the host model. One transceiver to connect to the DUT. 3. Instantiate the DUT and make appropriate connections to the transceiver model as suggested in the sample testbench. 4. If the application portion of the design is not yet developed, the user needs to instantiate the ATUSBFUNC-SS7211 device core and the sample application model provided with it to simulate the application interface. 5. Upon having an instance of the ATUSBTEST- SS7400, two transceivers, the ATUSBFUNC- SS7211 and application model, the testbench module is complete for use. 6. Along with the testbench module, the necessary design modules needed to generate USB traffic are the hst_mdl.v (for ATUSBTEST- SS7400), all the modules related to the ATUSB- FUNC-SS7211, xvr.v (for the transceiver) and app_mdl.v (for the application model). 7. To generate USB traffic, the ATUSBTEST- SS7400 requires the command file hst_cmds, which is explained in detail in the next section. hst_cmds file is a user-friendly, customizable USB traffic generator. This file is translated into a format that can be understood by hst_mdl by using an executable script called hst_mdl. This script, when run on the hst_cmds file, generates intermediate files that are compliant with requirements of the host model. hst_mdl also flags any format errors in the hst_cmds file. 8. If the sample application model is being used to generate traffic and communicate with the USB device core, the test directory needs to have three files for data transfers from the device EPs to the host. ep0_data is the file that contains the data for EP0 transfers from application to host; ep1_data contains the data for EP1 transfers from application to host; and ep2_data contains the data for EP2 transfers from application to host. The format of these files is explained in the section The Application Model. The application model requires another file, app_cmds, which is used by the application model to generate no response to interrupts and stall to different device endpoints. 9. Once the preceding files are available, the user is ready to simulate the USB device core using the ATUSBTEST-SS7400. Running Simulations 1. Run the executable hst_mdl on hst_cmds file to generate the intermediate files required for the host model and monitor model. 2. Compile all device core-related modules, application model, host model and the transceivers. 3. Run for a specific amount of time or until the host model reaches the end of the hst_cmds file. The host model is designed to automatically exit upon completion of the last executable command in the hst_cmds file. Logs and Reports Pre-simulation Logs hst_cmd.out When hst_mdl is executed on the hst_cmds file, a log file named hst_cmd.out is generated. This generates a log of possible errors in the hst_cmds files. A few such logs are: Include file not found Data files not found Incorrect number of bytes in a transfer (if the user defines data that does not end on byte boundary) Incorrect data format (such as a character g through z in hex data) Number of commands found in the hst_cmds files. (User may check to see if all commands intended were processed.) 2 ATUSBTEST-SS7400

3 ATUSBTEST-SS7400 Post-simulation Logs Host Side ep0_rcvd_app EP0 from the device. It also specifies the transaction number for which the data was received. ep1_rcvd_app EP1 from the device. It also specifies the transaction number for which the data was received. ep2_rcvd_app EP2 from the device. It also specifies the transaction number for which the data was received. hst_log This file logs all the data transmitted/received on the USB line with summary of errors, recommendation and log of every USB transaction. It also specifies the transaction number for which the data was received. This is explained in detail in the section on the monitor reports. Device Side ep0_rcvd_host This file logs all the data received on the USB line to endpoint EP0 from the host for the setup, data portion of the control transfer. ep3_rcvd_host EP3 from the host. app_log This file stores the interrupts received, action performed, count value and interrupt status register value for the complete simulation. Verification for Correctness Correctness of the simulation may be checked in two phases: Correctness of protocol Correctness of data Correctness of Protocol This may be checked by looking for ***ERROR in the hst_log. This tells the user whether the DUT performed any protocol violation such as transmitting an incorrect CRC, invalid handshake, etc. The user is also recommended to check for ***WARNING to see if the user has unintentionally introduced errors in the hst_cmds file such as illegal packet sizes, incorrect addresses, incorrect endpoints, etc. Correctness of Data This may be checked by comparing the data transferred from the application and the data received by the host, and vice versa. Atmel provides a simple script to process the received and transmitted data at the end of the simulation. This script is tailor-made for specific applications, primarily due to variable data formats. Check with your Atmel Support Engineer for details on this script. Installing the Design Install the complete design in a common place. Run the following commands as root. Later releases will be installed in this directory. < PROMPT> cd /installation_dir/ < PROMPT> unzip ss7211.zip Running Simulation 1. Compile all Verilog files (SS7211/core) in the directory SS7211/SS7400/ 2. Compile all Verilog files (SS7211/SS7400) in the directory SS7211/SS7400/ the compile_mti file has the script for the compilation in Model Tech environment. 3. Run the simulator or run the batch file run??.bat for DOS environment in SS7211/SS7400/ or run_mti <Test Case No.> for UNIX environment is SS7211/SS The batch file: Compiles the host commands files to bit pattern for Verilog; Runs the Verilog simulation; and Scans the simulation and reports the simulation status. 3

4 Installation Directory Structure CORE Verilog Files for Core SS7211 TEST TEST1 TEST12 Command and Data Files Command and Data Files DOC SS7211 Document SS7400 Document Test Environment Document SS7400 Host model exe file, ram_data, batch files host, application, xvr, ram models and testbench SCRIPTS SYNTHESIS SCRIPTS run_mti (script to run test cases) compile_mti (compile script for Model Tech tool) TEST1 hst_log and monitor.log RSLT TEST12 hst_log and monitor. log Host Model The host functional model has a simple, user-friendly, configurable and comprehensive command file interface. Based on the commands initiated by the user, the host model generates a bit-stuffed, NRZI data on the USB line. It also maintains the necessary frequency and signaling based on full-speed and low-speed signaling. It generates CRC5 for token and CRC16 for data. It generates SYNC pattern, SOP and EOP to maintain packet integrity. Through the command line interface, the user can generate error conditions that help in checking the correctness of design and protocol integrity of the device under test. In the receiver mode, the host model detects SYNC pattern, SOP and EOP. It performs NRZI encode and bit unstuffing and checks for the correctness of the CRC. The host model is also capable of detecting time-out conditions, ACK, NAK and STALL conditions. The host model is also capable of performing a retry on a NAKed packet. The host model generates the necessary USB packets such as SETUP, OUT, IN and SOF from a command file, which is described in detail in the following sections. Command File The host bus functional model uses a file named hst_cmds to generate necessary USB traffic on the line. This file is generated by the user/designer based on the format described in the next section. This file needs to be available in the current directory where the simulation is run. 4 ATUSBTEST-SS7400

5 ATUSBTEST-SS7400 Appendix A: Functional Block Diagrams Host Model Pin Name Direction Comments vpo Output Goes to the transceiver to generate a differential signal on the USB line vmo Output Goes to the transceiver to generate a differential signal on the USB line oe_n Output Enables the transceiver transmitter clk Input USB clk clk_4x Input 4x clk suspend Input Used from the device to detect suspend by monitor fsen Output Indicates the current speed of the transfer iso Input Indicates from the device whether the current transfer is isochronous vp Input Digital data corresponding to the differential data in the USB line (from the transceiver) vm Input Digital data corresponding to the differential data in the USB line (from the transceiver) line_rcv Input Data received from the USB line (from the transceiver) Host Model I/O vpo vmo oe_n clk clk_4x suspend fsen iso vp vm line_rcv 5

6 Transceiver Model Pin Name Direction Comments fsen Input Determines the signaling from the transceiver. This is generated by the host model. vmo Input Data from the host model to generate differential data on the USB line vpo Input Data from the host model to generate differential data on the USB line oe_n Input Generated by the host model to enable the transmitter vp Output Generated by the transceiver to indicate idle, SE0 and line status vm Output Generated by the transceiver to indicate idle, SE0 and line status rcv Output Generated by the transceiver in the receive mode to indicate the received data from the line Note: This table shows the pinout of the transceiver model used in the building of the testbench. Transceiver Model I/O fsen vmo vpo oe_n vp vm rcv 6 ATUSBTEST-SS7400

7 Atmel Headquarters Corporate Headquarters 2325 Orchard Parkway San Jose, CA TEL (408) FAX (408) Europe Atmel SarL Route des Arsenaux 41 Casa Postale 80 CH-1705 Fribourg Switzerland TEL (41) FAX (41) Asia Atmel Asia, Ltd. Room 1219 Chinachem Golden Plaza 77 Mody Road Tsimhatsui East Kowloon Hong Kong TEL (852) FAX (852) Japan Atmel Japan K.K. 9F, Tonetsu Shinkawa Bldg Shinkawa Chuo-ku, Tokyo Japan TEL (81) FAX (81) Atmel Operations Atmel Colorado Springs 1150 E. Cheyenne Mtn. Blvd. Colorado Springs, CO TEL (719) FAX (719) Atmel Rousset Zone Industrielle Rousset Cedex France TEL (33) FAX (33) Atmel Smart Card ICs Scottish Enterprise Technology Park East Kilbride, Scotland G75 0QR TEL (44) FAX (44) Atmel Grenoble Avenue de Rochepleine BP Saint-Egreve Cedex France TEL (33) FAX (33) Fax-on-Demand North America: 1-(800) International: 1-(408) Web Site BBS 1-(408) Atmel Corporation Atmel Corporation makes no warranty for the use of its products, other than those expressly contained in the Company s standard warranty which is detailed in Atmel s Terms and Conditions located on the Company s web site. The Company assumes no responsibility for any errors which may appear in this document, reserves the right to change devices or specifications detailed herein at any time without notice, and does not make any commitment to update the information contained herein. No licenses to patents or other intellectual property of Atmel are granted by the Company in connection with the sale of Atmel products, expressly or by implication. Atmel s products are not authorized for use as critical components in life support devices or systems. Marks bearing and/or are registered trademarks and trademarks of Atmel Corporation. Terms and product names in this document may be trademarks of others. Printed on recycled paper. 1669AS 07/01