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 inter-face 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 eas-ily 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.
Simple Simulation Environment
Command File: hst_cmds Report File: hst_log Command File: app_cmds Monitor Model Host Bus Functional Model USB Device
Core ApplicationModel
USB Test
Environment
ATUSBTEST-SS7400
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
con-nections 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 neces-sary 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
EPs to the host. ep0_data is the file that con-tains 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 appli-cation 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, appli-cation 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 automati-cally exit upon completion of the last executable command in the hst_cmds file.
Logs and Reports
Pre-simulation Logs
hst_cmd.outWhen 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”
ATUSBTEST-SS7400
Post-simulation Logs
Host Sideep0_rcvd_app
This file stores the data received on the USB line to end-point EP0 from the device. It also specifies the transaction number for which the data was received.
ep1_rcvd_app
This file stores the data received on the USB line to end-point EP1 from the device. It also specifies the transaction number for which the data was received.
ep2_rcvd_app
This file stores the data received on the USB line to end-point 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 end-point EP0 from the host for the setup, data portion of the control transfer.
ep3_rcvd_host
This file stores the data received on the USB line to end-point EP3 from the host.
app_log
This file stores the interrupts received, action performed, count value and interrupt status register value for the com-plete 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 recom-mended 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 end-points, 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 Sup-port 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 direc-tory SS7211/SS7400/
2. Compile all Verilog files (SS7211/SS7400) in the directory SS7211/SS7400/
the compile_mti file has the script for the compila-tion 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/SS7400
4. The batch file:
Compiles the host commands files to bit pattern for Verilog;
Runs the Verilog simulation; and
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
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 SS7211
SS7400 Host model exe file, ram_data, batch fileshost, application, xvr, ram models and testbench TEST DOC SCRIPTS RSLT TEST1 TEST12 Command and Data Files Command and Data Files SS7211 Document SS7400 Document Test Environment Document
SYNTHESIS SCRIPTS run_mti (script to run test cases)
TEST1 TEST12 hst_log and monitor.log hst_log and monitor. log compile_mti (compile script for Model Tech tool)
ATUSBTEST-SS7400
Appendix A: Functional Block Diagrams
Host Model
Host Model I/O
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)
vpo vmo oe_n clk clk_4x suspend fsen iso vp vm line_rcv
Note: This table shows the pinout of the transceiver model used in the building of the testbench.
Transceiver Model I/O
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
vpo vmo oe_n fsen vp vm rcv
© Atmel Corporation 2001.
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.
Atmel Headquarters
Atmel Operations
Corporate Headquarters
2325 Orchard Parkway San Jose, CA 95131 TEL (408) 441-0311 FAX (408) 487-2600Europe
Atmel SarLRoute des Arsenaux 41 Casa Postale 80 CH-1705 Fribourg Switzerland TEL (41) 26-426-5555 FAX (41) 26-426-5500
Asia
Atmel Asia, Ltd. Room 1219Chinachem Golden Plaza 77 Mody Road Tsimhatsui East Kowloon Hong Kong TEL (852) 2721-9778 FAX (852) 2722-1369
Japan
Atmel Japan K.K. 9F, Tonetsu Shinkawa Bldg. 1-24-8 Shinkawa Chuo-ku, Tokyo 104-0033 Japan TEL (81) 3-3523-3551 FAX (81) 3-3523-7581Atmel Colorado Springs
1150 E. Cheyenne Mtn. Blvd. Colorado Springs, CO 80906 TEL (719) 576-3300 FAX (719) 540-1759Atmel Rousset
Zone Industrielle 13106 Rousset Cedex France TEL (33) 4-4253-6000 FAX (33) 4-4253-6001Atmel Smart Card ICs
Scottish Enterprise Technology Park East Kilbride, Scotland G75 0QR TEL (44) 1355-357-000 FAX (44) 1355-242-743
