Introduction

1. A Simple And Complete USB Interface Package For Test Bench DevelopmentD.Breton, C.Cheikali, J.Maalmi (LAL Orsay)

2. Introduction • USB 1.1 (~ 1 MBytes/s) Interface based on the FT245B circuit from FTDI. • A specific frame protocol has been defined to cover all usual acquisition modes. • Data acquisition can be driven either by the program or by the peripheral. • Interruptions are provided. • The package comprises hardware description, firmware and software: • Requires just a few components on the board and little firmware in user’s FPGA. • Software offers a complete library for Windows and Linux. • C and LabView kits are available • A configuration and test program is also provided • NEW! USB 2.0 (5 to 25 MBytes/s )Interface based on the FT2232H circuit from FTDI. • NEW! It is possible now to program Altera FPGAs in Active Serial mode through the USB2.0 interface!

3. Overview of the USB Interface Only with dual ports FTDI chips FT245B, FT245R, FT2232C, FT2232H … Altera Config EEPROM FPGA USB Interface Block n_config nsco, dclk,asdi, epc_data conf_done Library + Test Software data FTDI chip RD WR RXF TXE FTDI config EEPROM OSC Are present inside FT245R

4. FT245B Block Diagram • The entire USB Protocol is handled inside the chip • The FPGA interface is very simple, limited to an 8-bit data bus and 4 control lines FPGA interface FPGA USB Interface Block USB connector PC FT245 Config EEPROM OSC

5. User Interface • The USB Interface Block is entirely written in Verilog and can be implemented on any type of FPGA (Altera, Xilinx, Actel …) FPGA subadd User Interface element 1 • An element can be: • register, FIFO, RAM, a command… USB Interface Block 7 data usb_data F T D I chip 8 8 n_read RD n_write WR busy n_sync RXF User Interface element N interrupt read_req TXE n_wait single_data_bus

6. The frame protocol: Writing • USB is actually only a « byte pipe »: the bytes sent from the computer are just presented to the user side without any dedicated meaning. • Thus a simple and effective encapsulation frame protocol has been developed in order to distinguish between the different bytes. This protocol permits sending data frames and interrupts. It has been chosen to be the simplest possible in order to generate the minimum dead-time. The main principles are the following: • A fixed header byte. • A control byte with the number of bytes to transfer (minus 1 in order to permit all the values up to 256). • A control byte to indicate the transfer direction and give the sub-address. • N data bytes. • A fixed trailer byte. Figure 7: chronogram of a write operation

7. The frame protocol: Reading • The frame format is the same for the write and read transfers, which simplifies data identification. • For the write accesses, the number of bytes is limited to 256. For the read demands, the data field will be used to encode the MSB of the number of bytes to transfer, which is then able to reach 65536 (16 bits). Figure 8: chronogram of a standard read operation

8. Use of ’n_wait’ • For the slow peripherals, n_write and n_read can be retained as long as necessary thanks to the n_wait signal.

9. Use of ‘busy’ • The « busy » signal is used during all types of access. During standard read or write operations, it just covers the phase where acess is made to the peripheral.

10. Interrupts • There are two types of interrups : • Error Frames Interrupts (Header or Trailer) that are generated by the USB_Interface_Block • User Interrupts that are generated by the peripheral user. • The interruption format is shown on tab 4. • It is a standard frame but where the R/W byte sent back equals 0, which is impossible in case of a standard reading (where it is equal to 1). • For a frame error Interrupt, the Subadd value is the one used in the last reading/writing operation • For a user interrupt, the Subadd value is 0x7F • A special Status Byte is reserved for Header and trailer errors • For user interrupt the Status Byte is determined by the user. There is a priority order for the interruptions: 1) Header, 2) Trailer, 3)User, 4) Read-request.

11. Extended Read • Tab 5 describes the format of the frame transmitted to the computer after a read-request triggered by the user. • This type of frame permits a peripheral-driven acquisition mode of blocks up to 256 bytes. • This mode is supposed to offer the fastest dataflow

12. Schematics of the FT245B-based USB Interface

13. The Software library • LALUsbv2 Library: It is a library intended for software applications communicating over USB bus with boards using FT245xx or FT2232x controllers manufactured by FTDI Ltd. • It is an extension of FTDI FTD2XX library: It provides a simplified error handling mechanism, a data encapsulation and an interrupt management complying with the specifications of the LAL USB Communication protocol. • LALUsb has been designed to free the user from knowing about LAL frames format, for neither encoding nor decoding. • LALUsb is mainly used as a “shared” library (DLL) but a “static” version (.lib file) is also available. • LabView VI’s Library also available

14. Examples of functions • Device initialization, open and close • BOOL USB_FindDevices(char *DeviceDescriptionStr); • intUSB_GetNumberOfDevs(void); • intOpenUsbDevice(char *sernumstr); • unsigned char USB_GetVersion(int id); • BOOL USB_Init (int id, BOOL verbose) ; • void CloseUsbDevice(int id); • BOOL USB_PurgeBuffers(int id); • Write and Read in « LAL » format • intUsbWrt(int id, char sub_addr, void *buffer, int count); • intUsbRd  (int id, char sub_addr, void *array, int count);

15. TEST 245 : Utility for Configuration and Test • Test245 : (Windows 2000 SP2, XP and Vista, MacOS X, Linux) • Test245 is a little utility intended for testing and debugging freshly designed boards or devices based on FTDI FT245xx (and now also FT2232xx) family of USB controllers and complying with LAL USB Communication protocol • It is also used to configure new devices. • It relies on LALUsbv2 library functions to perform various input-output tests

16. Device Configuration Wizard

17. Board Examples • The FT245B-based interface has been used in IN2P3 and IRFU for different boards: The ASPIC Back End Board ( for LSST) The MATACQ14 14-bit/2GS/s digitizer board The Lumi_PM test board for ATLAS luminometer The MAROC2_USB test board for ATLAS Luminometer The USB WaveCatcher Board

18. Software Examples WaveCatcher SiPM Charge Histo AlfaPMF application at CERN The C program for ATLAS Lumi-PM acquisition The LabView program for MATACQ board acquisition

19. What is new with the USB 2.0 Interface? • FT245, and FT2232D are limited to 1MByte/s • FT2232H offers the same asynchronous interface as the FT245 but with the ability to reach 5MBytes/s. • no change for the user interface in the FPGA (except the clock frequency) • no change for the software • FT2232H also offers a synchronous interface that adds only two wires to the FPGA interface but is supposed to reach 25 MBytes/s. (to be tested soon) • Possible changes for the user interface • no change for the software • FT2232H offers a second port that can be dedicated to FPGA EEPROM configuration. (also true with FT2232D)

20. Schematics of the FT2232H-based USB Interface

21. Documentation • Coming soon : Documentation of the Interface based on the FT2232H chip • Documentation of the LAL USB Interface based on the FT245 chip • Documentation the software library

22. Conclusion • We have designed a very simple to use USB package • It is Plug&Play • It includes hardware, firmware and software • It is available with different FTDI chips, depending on the application (…) • A specific protocol has been developped, permitting all types of data transfer • 1MByte/s versions have been used for 3 years for different labs and boards • 5 to 25 (?) MBytes/S version is being developped • Hardware is already available for board design  All information on the web site: http://electronique.lal.in2p3.fr/echanges/LALUsb/index.htm