Channel Link Tester D.Calvet, CEA Saclay Created 17 June 2003 Last Revised 30 September 2004 0. Contents ----------- 1. Introduction 2. Hardware installation 3. Operation 4. Trigger 5. Sequence of operation 6. LED indicator 7. Host PC parallel bus interface 8. Host PC RS232 serial interface 9. Channel Link cable interface 10. SCL interface 11. Mezzanine card top-side connectors 11.1 Connector for a logic analyzer 11.2 Connector for hard metric cables 11.3 Debug and control pins 12. Firmware 13. Address decoding and Registers Map 14. Description of data generated in bit error counting mode 14.1. Selecting random seeds 14.2. Checking the beam crossing counter values 14.3. Putting it all together 15. Control software 15.1 Organization of the code 15.2 Configurations and platforms 15.3 User interface and command interpreter 15.3.1 General Control Commands 15.3.2 Sequencer Commands 15.3.3 Status and Results Commands 15.3.4 Test and Debug Commands References 1. Introduction --------------- The Channel Link Tester is designed to test the digital ouptut of the ADF card [1]. It includes a 2 Gbit/s Channel Link 48-bit deserializer chip [2] on a mezzanine card plugged ontop of a Xilinx Virtex II evaluation kit [3]. The FPGA kit is connected to a host PC that controls the hardware via a digital I/O card [4]. Control using a RS-232 serial port is also supported. 2. Hardware installation ------------------------ To operate the tester, the following hardware is needed: - a Xilinx Virtex II evaluation kit as described in [3], - the Channel Link Receiver Mezzanine card, - a digital I/O card as described in [4], or a RS232 cable - a control PC (Windows if the tester is controlled via a digital I/O card; Windows or Linux if the tester is controlled via RS232). Connect the mezzanine card to the evaluation kit. - All I/O banks must be set to 3.3V standard. - Remove all the jumpers to the DIP switches and the 7-segment display. - Keep the jumpers on the RS232 interface if the tester is controlled via a RS232 link, and remove them otherwise. - Close the JTAG slot bypass jumper. - Push button SW3 is the hardware RESET. - Connect the parallel cable referenced "Positions 1-50" to the tester mezzanine board if the tester is controlled via an I/O card, - or connect a RS232 cable (not a null modem cable) to the evaluation kit. - Set the MODE SELECT jumpers in the appropriate way to configure the devices of the evaluation kit via JTAG (if this is the first use of the tester), or via the on-board serial PROM if the firmware of the tester was previously burned in this device. - When MODE SELECT jumpers at positions 5-6 and 7-8 are removed, devices need to be configured via JTAG. - When these 2 jumpers are placed, the FPGA is configured at power-up using the on-board serial PROM. - Use a Xilinx cable IV JTAG cable or equivalent to burn the firmware of the tester in the configuration PROM of the evaluation kit. Refer to Xilinx tools and documentation for details. - Switch the power on the evaluation kit. - The DONE LED should illuminate if the kit is configured to boot from the content of the serial PROM. - Otherwise, the DONE LED will only illuminate when the FPGA has been succesfully programmed via JTAG. The hardware part of the tester is now ready to operate. 3. Operation ------------ The tester can operate in two modes: - data recording mode - and bit error counting mode. In data recording mode, the data received by the Channel Link de-serializer (36 bit out of 48 bit) are stored in a 2-K word x 36 bit wide buffer. When filled, this buffer can be read by the host PC via the appropriate interface. In error counting mode, each bit of the received data is compared to a pre-defined pattern generated internally by a series of pseudo-random generators identical to that included in the ADF card. Whenever, a mismatch occurs, the corresponding bit error counter is incremented. Error counters are accessible by the host PC. In addition to the received data, the tester counts the number of 36-bit words received and measures the frequency of incoming data frames. 4. Trigger ---------- Triggering the tester can be done in 3 ways: - when the received 36-bit word matches a programmable 36-bit pattern, - when an external input matches a programmable bit state - when ordered to trigger by the application software running on the control PC. Each trigger bit can be programmed to match a 0, 1 or X value. Recording the received data starts as soon as the trigger is armed and stops when the (programmable) number of word to capture after the trigger has been reached. When the trigger condition is satisfied, data recording in memory continues and counting received words and bit errors starts. When the desired number of words has been recorded, all counters are frozen and data capture stops. The number of words to record includes the word that caused the trigger and at least the following word. Hence the minimum value should be set to 2. In this case, the memory of the tester will contain the words that were received between the instant when the trigger was armed and the instant when the trigger condition occured (2048 words depth memory). When the desired number of words to capture is set to 4095, the data available in memory will be the 2048th to 4095th words received after the trigger. Upon a hardware reset, the number of frames to capture is set to 1024, i.e. the data that caused the trigger to fire is stored in the middle of the trace memory. To help locating the memory position where the data word that caused the trigger is stored, the corresponding 11-bit address is captured and can be read by the host PC. 5. Sequence of operation ------------------------ Following a hardware or a software reset, the tester is in its default state. All internal programmable registers can be read and written via the host PC. When properly configured, the host PC instructs the tester to start data capture and to watch for a trigger condition. When a trigger condition occurs, error counters and the received word counter are enabled. When the number of 36-bit words reaches the programmed value, data recording stops and error counters are disabled if the tester is in data recording mode. In bit error count mode, data is stored continuously, overwriting the data previously stored when the address counter indexing the memory rolls-over. Bit errors are monitored on each of the 36 bit lines independently by comparing each received bit with its expected value. Each bit line is associated with an 8-bit saturating error counter. A 48-bit counter counts the number of 36-bit words received. Assuming that the tester is operated at its nominal 60.56 MHz rate, the received word counter rolls-over after ~53 days. In both modes of operation, data recording and error monitoring can be aborted via the host PC. In error counting mode, the tester can also be optionally stopped when an error is detected. This allows capturing errored words for analysis. When the tester is stopped, stored data, error counters and the received word counter can be read via the host PC. Before starting a new data capture, the tester must be soft reset by the control software running on the PC. This operation clears all error counters and the received word counter but does not affect other registers (i.e. the trigger pattern and mask). Neither a hardware reset nor a softare reset clears the memory storing received data. Clearing the memory buffer should be made by the software controlling the tester if needed. 6. LED indicator ---------------- The user LED of the evaluation kit shows the operation of the tester. When this LED is OFF, the tester is in a default inactive state. The LED is ON when the tester is recording data and waiting for a trigger. A fast blinking indicates, that the tester error counters and received word counters are enabled. A slow blinking indicates that the desired number of words has been reached (data recording mode only), that a bit error occured (in error counting mode and only if this option is activated), or that the user aborted the run (in both modes of operation). 7. Host PC parallel bus interface --------------------------------- The FPGA evaluation kit communicates with the host PC via a digital I/O card. The interface used is a generic bus interface. The signals are: - ADDR<11..0> : (Input) address bus - DATA<7..0> : (Input/Ouput) data bus - CS_B : (Input) active low chip select. When low, this indicates that a read/or write operation targetting the tester is taking place on the bus. - WE : (Input) write enable (active high). When high, this indicates that the host PC is writing data to the tester; when low, the PC is reading data from the tester. - WCLCK : (Input) write clock (for synchronous write ressources). This is connected to the 24 MHz oscillator of the FPGA kit. - DTACK_B : (Output) data acknowledge (active low). This is asserted low by the tester to acknowledge the current read or write transaction on the bus. - BUS_EN_B : (Input) active low bus enable. This active low input is used to enable/disable the tri-state drivers on the signals of the bus. When the parallel cable is not connected to the tester board or when the I/O card is not configured, all drivers are tri-state. All these control-bus related signals are connected to the PCI I/O card via a 50-pin connector. A low level library written in C is provided to implement read/write cycles from/to the tester. This library supports 8-bit and 16-bit data wide busses. Data bus width is determined by sensing the state of the input pin DATA_BUS_WIDTH. This pin is hardwired to a logical low level on the tester mezzanine card to indicate that the device has an 8-bit wide data bus. The board has also a CARD_ID (2 bits) that can be read by the control software to determine board type, revision, etc. The CARD_ID bits are harwired to "00" on the Channel Link tester board. For details on I/O board pin to bus signals mapping, see bus_if.h bus_pcidio.h and bus_pcidio.c. 8. Host PC RS232 serial interface --------------------------------- Because using a parallel I/O card to control the tester requires additional hardware (unsupported under Linux or in a portable PC), a simpler scheme based on RS232 was proposed and implemented by J. Marquet (summer student). The idea is to devise a synthetisable component that translates a specific protocol carried over RS232 on the control side, to actual read and write transactions on the microprocessor-like bus of the tester. This translator component is then simply coupled to the tester component based on the parallel bus interface. The whole block is synthetized and downloaded to the FPGA of the evaluation kit. A RS232 transceiver and a DB9 connector are available on the kit. The RS232 to parallel bus interface supports an address bus width of 8 to 24 bits (in 4 bit increments), and a data bus width of 8, 16 or 32 bit. All bus sizes are determined at compile time. The Channel Link tester requires a 12-bit address bus and an 8-bit data bus. The parameters of the RS232 communication are: - 8 bit characters, - 1 start bit - and 1 stop bit, - no parity - and no flow control. - Supported baud rate range from 1200 bauds to 57600 bauds. Baud rate is determined at compile time. The protocol exchanged over RS232 is composed of human-readable strings of ASCII characters. Each line correspond to one action or transaction to accomplish on the bus and must be terminated by CR (Carriage Return) and LF (Line Feed) characters. All lines have an identical format, and are composed of a fixed number of fields separated by space characters. The format of a line is:
The field is 1 character wide and specifies the operation to perform. Valid characters are: I : Initialize. Must be done before any action can be performed on the bus. W : Write. Performs a write transaction on the bus. R : Read. Performs a read transaction on the bus. Q : Quit. All subsequent actions are dropped until the next Initialize command. Note that this command is just composed of a character Q followed by CR and LF. The
field is composed of the required number of ASCII characters to represent the hexadecimal digits of the address where the action is to be made. The field is 1 character wide and is used to select individual bytes for the versions of the interface that have a 16-bit or 32-bit wide data bus. This field is an hexadecimal digit, each bit is active low. For example, the value E selects byte 0, the value C selects both byte 0 and 1. The field represents in ASCII the hexadecimal value of the data read or written. This field is composed of 2, 4 or 8 characters depending on the width of the data bus. The CR and LF characters terminate the line and trigger the actual actions on the bus. At initialization, the number of characters received for the address and data fields are used by the logic to check that the width of the different busses match. For read transactions, the data field transmitted by the host PC must be present but can contain any value. All command strings are echoed to the host PC after sucessfull completion. In case of error, characters "?" are placed in the data field; these are detected by the control software. A typical sequence of communication between the control PC and the tester is given below. PC to tester Reply from tester Meaning -------------------------------------------------------------------------------- I 444 4 44 I 444 4 44 Initialization OK W 012 E AB W 012 E AB Write 0xAB at address 0x123 OK R 012 E 00 R 012 E AB Read 0xAB at address 0x123 OK ... R 450 E 00 R 450 E ?? Read transaction failed ... Q Q Interface closed -------------------------------------------------------------------------------- To check the interface, a simple RS232 terminal can be used instead of the control software of the tester. Commands are typed by hand, but pipe-lining several commands is not supported: you must wait for the completion of one line before starting to type the next line. Common errors when using the RS232 to control the tester are: - improper cable. Use a normal (i.e. non-crossed) cable, not a null-modem cable. - missing jumpers on the evaluation kit to connect the RS232 transceiver to the FPGA. - a different baud rate was set in the control software and in the firmware. Make sure baud rate is correct on both sides, and recompile both the firmware and the software if doubts subsist. - bus sizes do not match. same fix as above. - the terminal is not configured properly for handling CR and LF. Each line sent by the control PC must be terminated by one and only one CR and LF characters. The hardware sends back 1 CR and 1 LF; these characters must not be replaced automatically by the host. Remember also that RS232 is not very fast. The proposed protocol adds a lot of overhead (this is the price to pay for a nice human readable ASCII syntax). To read or write a single byte of data, 12 bytes need to be sent in each direction of the RS232 port. Part of the communication overlaps, but roughly, the time taken corresponds to sending ~16 characters over RS232. At the maximum speed that could be achieved (57600 bauds) this translates to 2.8 ms per byte, i.e. a typical throughput of 360 bytes per second. This is adequate to transport small amounts of data. When reading the whole memory of the tester (2048 x 36 bits), 10 KB of data are read. The communication takes ~30 seconds. 9. Channel Link cable interface ------------------------------- Channel link data is received via an 8-pair LVDS cable. See the schemacis of the tester mezzanine card for details. The 36-bit received are used as follows: - bit 0 to 31: 32 streams of serial data; each composed of 8 bits frames (LSBs come first) - bit 32 : BC_COUNT bunch crossing counter - bit 33 : FR_8_10 ignore this bit at present; assume it is always '0' - bit 34 : FRAME signal. Indicates that the current bits received are the LSBs - bit 35 : PARITY the odd parity of the other 35 bits. The tester checks for bit errors on bit line 0 to 35. In error counter mode, Bit 0 to 31 are generated by a series of 32 16-bit LFSR. Each has a 16-bit programmable seed. The LFSR's are clocked by the channel link receiver clock (60.56 MHz nominal). See serout.vhd for implementation of the LFSR. The FRAME bit (bit 32) shall be 1 every 8 ticks of the received clock. If this is not the case, the corresponding error counter is incremented. BC_COUNT is the D0 bunch crossing counter (1 to 159). Synchronizing this counter requires to decode the information provided by the Serial Command Link (SCL) in D0. Although these signals can be made available on the tester, this functionality is not integrated in the current version of the firmware. Checking the validity of the bunch crossing counter is made by taking one of the values sent by the ADF as an initial value for the local bunch crossing counter. 10. SCL interface ----------------- The tester has an input for SCL signals identical to that of the ADF card. In the current version of the tester, only the SCLIF_SPARE signal is used. This signal is the external trigger input. 11. Mezzanine card top-side connectors -------------------------------------- 11.1 Connector for a logic analyzer ----------------------------------- The Channel Link Receiver mezzanine has a 40-pin HE-10 male header for connecting a logic analyzer. This connector gives access to the 36-bit of data being received and the de-serializer clock. See labels on the printed circuit board for details. All pins are 3.3V LVCMOS outputs. 11.2 Connector for hard metric cables ------------------------------------- The Mezzanine card has a 11x5 pins 2 mm hard metric male header for connecting 1 cable to the SCLD board (possible future expansion), and 1 cable to the ADF board being tested. Looking into the connector, the cable connected to the ADF must be placed on the right side of the connector (labelled RX), leaving the last row empty (hardwired to GND). The first 2 pairs of the cable must be on the left side. If used, the cable connected to the SCLD must be connected on the left side of the connector (labelled SCLIF), leaving the first row empty. There must be an empty row between the 2 cables. The first 2 pairs of the SCLD cable must also be on the left side. Refer to the schematics of the corresponding boards if needed, although mis-insertion of a cable shall not damage any device. 11.3 Debug and control pins --------------------------- The tester mezzanine card has an 8-pin male header for debug and a couple of control pins. There is 1 debug input pin (labelled I0) and 2 debug output pins (labelled O0 and O1). These are LVCMOS 3.3V I/O's and are NOT 5V tolerant. Note that when the control of the board is made through RS232 instead of the parallel I/O card, the debug input is no longer available (hardwired to the Receive pin of the RS232 transceiver). The DESKEW pin of the Channel Link receiver is connected to the left pin on the last 2 rows of the 8-pin header. Placing a jumper on the last row will set DESKEW to a high level. Placing a jumper just above the last row will set DESKEW to ground. If both jumpers are installed, DESKEW will be low. 12. Firmware ------------ The firmware of the Channel Link tester is entirely written in VHDL ('87 or '93). The target device family is the Xilinx Virtex II. The firmware does not depend on any proprietary package (except Xilinx specific libraries) and should compile and run on any VHDL simulator. ModelSim is the simulator used by the author. The specific library from Xilinx to map is unisim. Refer to Xilinx ISE documentation for installation. The VHDL files that are specific to the Channel Link tester board are located in the directory: /vhdl/dzero/chalink_tester The corresponding ModelSim project is chalink.mpf. The files for the components that are also used in other designs are located in the directory: /vhdl/dzero/common Refer to the document "ADF Board Firmware: Description, Simulation, Synthesis" for a description of the VHDL models of the common components. The source files for the interface of the tester to RS232 are in: /vhdl/dzero/bus2rs232 The files included in the chalink project are the following (in compile order): 0. utility_pkg -------------- Various utility functions. 1. cha_reg ---------- N-bit wide register based on D-flip-flops with synchronous write enable and asynchronous preset. 2. Sr_pl -------- A generic width shift register with parallel input and serial output. This component performs a Right Shift with the LSB taken from the serial input SIN. Load and Enable are synchronous; Reset is asynchronous. 3. sr_pl_po ----------- A generic width shift register with parallel input and parallel output. This component performs a Right Shift with the LSB taken from the serial input SIN. Enable is synchronous; Reset and Load are asynchronous. 4. trigger ---------- A synchronous, generic width equality comparator with maskable inputs, plus 1 input to force the ouput. 5. trigger_test --------------- Test bench for trigger component. 6. lfsr ------- A 16-bit LFSR similar to that implemented in the ADF card. This is used to generate a pseudo-random stream similar to that generated by the ADF to check data integrity in error counting mode. 7. lfsr_test ------------ Test bench for LFSR. 8. cnt_sat ---------- A N-bit saturating counter with asynchronous RESET and synchronous count enable. 9. gen_ctrl ----------- State machine controlling the tester. This can be in one of the following states: . RESET : waiting for configuration . ARMED : trigger armed . RUNNING : capturing data . STOPPED : data captured 10. freq_meter -------------- A frequency meter to measure the frequency of the incoming data frames. The result is coded with 16-bit precision and is expressed in kHz. The range is 0 to 65534 kHz. A returned value of 65535 indicates overflow. 11. ChalinkR ------------ Top level component of the Channel Link tester. It includes all the logic needed to build the tester: - a sequencer - a 37-bit wide trigger - 4 blocks of RAM 2-K word x 9 bits (make a 2-K word x 36-bit RAM) - 32 LFSR - 36 error counters - Bus interface - Registers for trigger pattern and mask, configuration, etc. - miscellaneous logic. 12. ChalinkR_FPGA ----------------- ChalinkR_FPGA is the top level component for synthetis, place and route, and download in the FPGA evaluation kit. It adds all I/O pads to the ChalinkR component which contains all the logic of the tester. For FPGA configuration file generation, use the Xilinx ISE project located in: /vhdl/dzero/chalink_tester/chalinkT.npl Pin assignements and constraints are in: /vhdl/dzero/chalink_tester/chalinkr_pinout.ucf 13. ChalinkR_FPGA_test ---------------------- Test bench for ChalinkR_FPGA. It contains an array of 32 LFSR and an 8 bit- bunch crossing counter to simulate Channel Link input. Running the model is made by co-simulating the VHDL test-bench with the control software of the tester. In the ModelSim VHDL simulator window, execute the script tester.tcl to display most of the signals of interest. Then execute the modelsimserver.tcl script to launch the TCP/IP socket server where the control software will connect to run the co-simulation. Run the control software program from a DOS window by changing to the appropriate directory and typing the command: J:\projects\bin\d0\chalink\winnt\debug>chatest This starts the command interpreter that controls the tester and execute the corresponding actions on the VHDL model of the tester. A number of additional files are needed to control the tester over a RS232 link. These are: 14. constant_package -------------------- This defines various constants. 15. rs232_deserializer ---------------------- This block performs the de-serialization of the RS232 input. 16. interpret_char ------------------ This component interprets the individual characters that are received: is this a valid character, an hexadecimal digit, etc. 17. interpret_line ------------------ This interprets each of the lines of characters that are received. Each line correspond to one transaction to perform on the bus and must be terminated by CR and LF. 18. bus_control --------------- This block performs the actual read or wrote transaction on the bus. The target must return an acknowledge, otherwise the transaction will time-out. 19. rs232_serializer -------------------- This block echoes on the RS232 link the command line for sucessfull write transactions, and serializes the ASCII-formatted data returned by the target for read transactions. 20. bus2rs232 ------------- This bloc wraps all the building blocks of the RS232 to bus interface. 21. ChalinkR_RS232 ------------------ The tester and the RS232 bus interface grouped in one component. 22. ChalinkR_RS232_FPGA ----------------------- Top level entity to be synthetized. For synthesis, place and route, use Xilinx ISE project: /vhdl/dzero/chalink_tester/chalinkT_RS232.npl Pin assignements and constraints are in: /vhdl/dzero/chalink_tester/chalinkr_rs232_pinout.ucf The baud rate must be set to the appropriate value for behavioral simulation (e.g. 307200 baud) and for synthesis (e.g. 57600 baud), according to the values compiled in the control software. 23. acia -------- A model of a RS232 serial device for co-simulation with the control software of the tester (version with control made over RS232). This component is used when simulating the version of the tester that is controlled over RS232. 24. acia_test ------------- A simple test bench to test an acia in loop-back mode along with the control software of the tester. 25. ChalinkR_RS232_FPGA_test --------------------------- Test bench for the tester controlled by RS232. 13. Address decoding and Registers Map -------------------------------------- The Channel Link tester is controlled over a 12-bit wide address bus and 8-bit wide data bus. The 2048 x 8 bit memory map is the following: ------------------------------------------------------------------------------ |A11A10 A9 A8 A7 A6 A5 A4 A3 A2 A1 A0 | Ressource | Access | ------------------------------------------------------------------------------ | 0 0 0 0 X X X X X X X X | Mode and Page selection | R/W | | 0 0 0 1 X X X X X X X X | Trigger Control | R/W;RO | | 0 0 1 0 X X X X X X X 0 | Nb of words to record (low) | R/W | | 0 0 1 0 X X X X X X X 1 | Nb of words to record (high)| R/W | | 0 0 1 1 X X C4 C3 C2 C1 C0 0 | LFSR Seed Low byte | R/W | | 0 0 1 1 X X C4 C3 C2 C1 C0 1 | LFSR Seed High byte | R/W | | 0 1 0 0 X X C5 C4 C3 C2 C1 C0 | Error Counters | R/clear| | 0 1 0 1 X X X X X T2 T1 T0 | Trigger Pattern | R/W | | 0 1 1 0 X X X X X T2 T1 T0 | Trigger Mask | R/W | | 0 1 1 0 X X X X X 1 1 0 | Receive Frequency Low byte | RO | | 0 1 1 0 X X X X X 1 1 1 | Receive Frequency High byte | RO | | 0 1 1 1 X X X X X B2 B1 B0 | Received word count | RO | | 0 1 1 1 X X X X X 1 1 0 | Trigger Position Low byte | RO | | 0 1 1 1 X X X X X 1 1 1 | Trigger Position High byte | RO | | 1 M10M9 M8 M7 M6 M5 M4 M3 M2 M1 M0 | Received data memory | R/W | ------------------------------------------------------------------------------ C<5..0> or C<4..0> : channel ID from 0 to 31 for LFSR seed; 0 to 35 for error counters; T<2..0> : trigger pattern and trigger mask word composed of 5 bytes each. Only 37 bits are used. Bit 0 of byte 0 corresponds to channel #0; bit 4 of byte 4 corresponds to the external trigger bit and mask. B<2..0> : byte ID from 0 to 5 to select byte in 48-bit Received Word Counter M<10..0> : address location from 0 to 2047 in received data memory. Because this memory is 36-bit wide, determining the byte to access is made using paging. The 4-bit page selection of the MODE/PAGE register is used to select the desired byte location. Page 0 to 3 give access to 8-bit data words, page 4 gives access to 4-bit data words, pages 5 to 7 shall not be used at present. The following registers are defined: MODE/PAGE Register ----------------------- D7 D6 D5 D4 D3 D2 D1 D0 | | | | | | | | | | | | | | | +----- Mode Select : 0: data recording mode | | | | | | | 1: bit error counting mode | | | | | | +-------- Stop control : 0: no stop on bit error | | | | | | 1: stop on bit error | | | | +--+----------- unused +--+--+--+----------------- Page Select : 0 to 7 (0 to 4 used) Trigger Control Register ----------------------- D7 D6 D5 D4 D3 D2 D1 D0 | | | | | | | | | | | | | | | +----- RESET: pulse high for soft RESET | | | | | | +-------- ARM Trigger : set high to arm trigger | | | | | +----------- FORCE Trigger : set high to force trigger | | | | +-------------- ABORT run : set high to abort trigger +--+--+--+----------------- Internal State of the tester: | | | +----------------- Reset | | +-------------------- Trigger armed (waiting for trigger) | +----------------------- Capturing data +-------------------------- Stopped (memory full or run aborted) The 4 upper bits are Read only. The 4 lower bits can be Read/Write. Note that the 4 lower bits are not self clearing. The control software should not set more than one bit to 1 for proper operation. 14. Description of data generated in bit error counting mode ------------------------------------------------------------ In bit error counting mode, the tester is used to verify the integrity of the data produced by an ADF board in test mode. For every beam crossing period, the ADF board sends 36 bytes of data in 8 frames of 36-bit. Data is shifted LSB first. The serial communication is clocked at 8 times the beam crossing frequency. The 36-bit word that is being sent at each clock cycle is: bit 35 : parity (XOR of all 35 other bits) bit 34 : FRAME. Set to '1' every 8 cycles to indicate LSB of data being shifted bit 33 : FR_8_10. Set to '0' in this mode of operation bit 32 : BX_COUNT. Current beam crossing counter (1 to 159). bit 31 to 0: pseudo-random data The pseudo-random data stream is generated by an array of 32 16-bit Linear Feedback Shift Registers (LFSR's). The seed of each LFSR is programmable. The equation of the feedback loop of each LFSR is: bit(15) <= NOT (bit(0) XOR bit(1) XOR bit(3) XOR bit(12)) Where bit(15) is the MSB. The content of the LFSR is right-shifted and the serial output is taken from bit(0). The repetition period for the pattern of an LFSR is 65,535 frames (state 0xFFFF is a permanent state and an invalid seed). Given that the FRAME signal repeats every 8 frames, the repetition period becomes 524,280 cycles (~8.7 ms at 60 MHz). Taking also into acccount that the period of the beam crossing counter is 159 beam crossings, the global repetition period of the 36-bit wide pattern is 159 x 8 x 65535 = 83,360,520 frames (~1.3 s). Note however that the trigger of the tester tries to match a 1-bit slice of each of the 32 LFSR's. Depending on the initial seeds of the LFSR's, the repetition period of a bit pattern that can cause a trigger can be only a few frames (e.g. if all random seed are identical), or can occur only once per period of the 524,280 frame pattern. 14.1. Selecting random seeds ---------------------------- Because counting errors can only be done if all random generators at both ends of the communication link are perfectly synchronized, it is mandatory that the trigger pattern occurs only once per repetion period of the global pattern (we ignore the state of BX_COUNT bit lane for simplicity). The suggested procedure to pick the 32 16-bit random seeds correctly is the following: - choose an arbitraty 32-bit trigger pattern (for the 32 lower bits of the tester). For example, we choose 0x00000000. - Choose 1 bit column position among 16 where we would like the trigger pattern to be found. For simplicity, we choose bit 0, i.e. the LSB of all LFSR seeds - For a subset of the 32 LFSR's (e.g. start with 10), pick a 16-bit random seed, as "different" as possible from the other ones, with the only constraint being that the LSB matches the corresponding bit in the trigger pattern (i.e. always 0 in our case). Set the other seeds to the same value (still with the LSB matching the trigger pattern). - Simulate the 65535 consecutive states of the array of 32 16-bit LFSR's (e.g. using the VHDL testbench), and count the occurence of the trigger pattern. If the trigger pattern occurs more once, set one more seed to an arbitrary value. Repeat the procedure until the trigger condition is only satisfied once per period. (if the trigger pattern never occurs, something is going wrong...). Once a subset of random seeds that works has been found, the seed for other channels can be arbitrary. We give below a set of 18 seeds where the bit slice composed of 18 zeroes happens only once per period (65535): 0x0000, 0xFFFE, 0x012E, 0x0C26, 0xA128, 0x16EA, 0x2AB4, 0x36BA, 0xAA00, 0x0332, 0x1FFE, 0xA002, 0x1F0E, 0xC002, 0x7202, 0xE412, 0x7208, 0x3208. Other seeds can have an arbitrary value. The interested reader will find the minimum subset of random seeds that satisfies an arbitrary trigger pattern. 14.2. Checking the beam crossing counter values ----------------------------------------------- Because there is no connection between the tester and the Serial Command Link to give the synchronization on beam crossing numbers, the tester guesses the value of the beam crossing counter from the stream that is being received. When a trigger occurs, the tester takes as a seed for its own local beam crossing counter, the value being de-serialized from the ADF board being tested. Then, the tester increments this counter on its own every 8 frames, and wraps-around to 1 after reaching 159. The tester extracts from this local counter the expected value of the beam crossing counter bit and compares it with what is being received on BX_COUNT to determine whether a transmission error occured or not. Note that this process only works if the tester is able to get the right initial value of the beam crossing number on the fly. It is therefore mandatory that the trigger occurs when FRAME is asserted, so that 8 consecutive frames of data can be correctly mapped to the 36 original bytes. The user must not mask the FRAME bit in the trigger mask and must set the bit corresponding to FRAME to '1' in the trigger pattern. Recommended values are: trig_mask 0x1B-------- (mask external trigger bit, PARITY, FR_8_10 and BX_COUNT) trig_pattern 0x4 -------- (match FRAME=1 and desired data pattern). Note that not all versions of the ADF firmware and test setup allow counting bunch crossings. Use the tester in data capture mode to see if BX_COUNT are being generated correctly in your particular setup before attempting to measure data integrity on this line. 14.3. Putting it all together ----------------------------- Given the previous recommendations, a typical sequence of commands for the tester to correctly count errors on data bits, FRAME, BX_COUNT and PARITY includes the following settings: ... reset mode 1 trig_pattern 0x400000000 trig_mask 0x1B00000000 lfsr 0x0000 0xFFFE 0x012E 0x0C26 0xA128 0x16EA 0x2AB4 0x36BA 0xAA00 0x0332 0x1FFE 0xA002 0x1F0E 0xC002 0x7202 0xE412 0x7208 0x3208 ... (14 other seeds) arm_trigger ... This obviously assumes that the same set of random seeds had been set-up in the ADF board. A typical sequence of commands for the ADF and the tester are given in: d0/tests/ber/cmd.txt Do not forget to re-program the initial state (i.e. seeds) of each LFSR of the tester before starting a new error count measurements. All LFSRs start operation when the tester goes from the state WAITING FOR TRIGGER to CAPTURING DATA. 15. Control software -------------------- The control software of the tester is entirely written in C. It provides all the necessary functions to operate the tester from a simple non-graphical window. 15.1 Organization of the code ----------------------------- The source code is located in the directory: projects/d0/tester The following libraries are used: - chalib : (projects/d0/tester) Channel Link tester library - utils : (projects/utils) various utility functions - misc_util : (projects/d0/misc) additional utility functions - bus : (projects/d0/bus) implementation of the bus interface The executable programs are located in: projects/bin/d0/chalink/winnt/debug (Windows) projects/bin/d0/chalink/winnt/release (Windows) projects/bin/d0/chalink/linux (Linux) 15.2 Configurations and platforms --------------------------------- The tester is controlled via a "bus" abstract entity that is available in several flavors. By compiling and linking the tester software with each of the possible bus libraries, all the different versions of the control software can be produced. The different configurations supported are given in the table below. Bus implementation Windows Linux Executable code Comments ----------------------------------------------------------------------------- Software stub - no Yes Yes chatest_ram For development and debug actual hardware controlled Tester board + National Yes No chatest_pcidio No Linux driver available Instruments PCIDIO 96 from NI for this hardware parallel I/O card VHDL model of tester + Yes Yes chatest Use ModelSim VHDL simulator VHDL model of // I/O Tester board connected Yes Yes chatest_rs232 to RS232 COM port of PC VHDL model of tester + Yes Yes chatest_rs232vhdl Use ModelSim simulator VHDL model of RS232 ------------------------------------------------------------------------------ 15.3 User interface and command interpreter ------------------------------------------- The tester is controlled from a simple DOS command window and does not use any graphical user interface. Commands/results are entered/displayed in ASCII. After performing several initializations, the control software of the tester enters a command interpreter. Type "help" to get the list of command. A brief description of each command is given below. 15.3.1 General Control Commands ------------------------------- verbose [++ | -- | ] ------------------------------------ Show or increment or decrement or set verbose level. Use this command to control the number of debug messages that are produced when entering commands. This command is helpful when developing/debugging code to get a trace of all the functions that are called by a given command. display [binary | wave | hexa | delineate] ------------------------------------------ Show or set how to print received data. By default the data received by the tester will be displayed in binary mode like this: ADDR TRIG E PF8B10987654321098765432109876543210 ---- ----- - ------------------------------------ 110 -2 | 100010001000010000010010001000010000 111 -1 | 100001011111101001110101011111101001 112 0 | 010100000000000000000000000000000000 113 1 | 000011111010101110001111111010101110 114 2 | 100101010001001110000001010001001110 The column ADDR is the memory address where the data was read. The TRIG column is the position of the data word relative to the data word that caused the trigger to fire. The column E shows whether the parity calculed on the data that was received differs from the parity bit transmitted by the sender. The P column contains the parity received. The F column corresponds to the FRAME signal; the 8 column to the FR_8_10 signal; the B column to the BX_COUNT signal; the other columns correspond to the channel 31 downto 0 of the data being sent by the ADF. In wave mode, 0's and 1's are replaced by ASCII art: ADDR TRIG E PA FR 81 BC 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 110 -2 | | | | | | | | | | | | | | | | | | | | | | 111 -1 | | | | | | | | | | | | | | | | | | | | | | 112 0 | | | | | | | | | | | | | | | | | | | | | | 113 1 | | | | | | | | | | | | | | | | | | | | | | 114 2 | | | | | | | | | | | | | | | | | | | | | | Set the number of columns of the terminal window to 130 for a correct display. Note that 0's correspond to vertical bars on the right. When the mode of display is set to "hexa" the output will be the following: ADDR TRIG P DATA ---- ----- - ----------- 110 -2 | 0x888412210 111 -1 | 0x85fa757e9 112 0 | 0x500000000 113 1 | 0x0fab8feae 114 2 | 0x95138144e A '*' in the P column indicates a mismatch between the parity received and the parity computed locally. When the display mode is set to "delineate", the software will use the value of the FRAME signal to interpret 8 consecutive 36-bit frames as set of 36 bytes. FRAME is active once every 8 frames to indicate that the current word are the LSBs of data. The typical output in this mode is: ADDR TRIG E BC 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 ---- ----- - -------------------------------------------------------------- 110 -2 | XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX 111 -1 | XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX 119 7 | 1d 02 0e 02 fe 32 00 ba b4 ea 28 26 2e fe 00 08 08 12 02 02 0e 127 15 | 1e c0 1f a0 1f 03 aa 36 2a 16 a1 0c 01 ff 00 32 72 e4 72 c0 1f 135 23 | 1f f0 f6 96 00 12 e5 0c 15 7c ac ae 53 ee 0f a1 e5 e8 0b f0 f6 De-serialization can only be done after finding FRAME signal asserted. For data words that cannot be interpreted, the value "XX" is displayed. If one or several parity errors are detected on 8 consecutive frames, a '*' is printed in the corresponding column. Note that the FRAME and FR_8_10 signals are not shown in this mode. mode [0 | 1] ------------------------ Show or set the mode of operation of the tester: 0: data capture 1: error counting stop_control [0 | 1] ------------------------ Show or set the stop control flag. When set to 0, the tester will not stop when an error has been detected. When set to 1, the tester will abort the run if an error is detected. The content of the memory buffer can be read to analyze the error. To help diagnosis, data recording is not stopped as soon as an error is found: the frame in error and the following 15 frames are captured. trig_pattern [<[0x]value1>] (37 bits) ----------------------------------------- Show or set the trigger_pattern word. Bit 0 to 35 correspond to the 36 bits sent by the ADF board. Bit 37 is the external trigger input. trig_mask [<[0x]value1>] (37 bits) ----------------------------------------- Show or set the trigger_mask word. When a bit of the mask is set to '1', the state of the corresponding bit in the stream received is ignored to detect a trigger condition. When a bit of the mask is set to '0', the corresponding bit in the data stream must match the value specified in the trigger pattern word to cause a trigger. number_words [ number ] --------------------------- Show or set the number of words to capture after a trigger. The minimum recommended value is 2, the maximum value is 2047. The number of words to capture is set to 1024 (i.e. trigger in the middle of the trace memory) after a hardware RESET. lfsr [<[0x]value1>...<[0x]valueN>] ---------------------------------------------- Show or set the seed of the LFSRs (error counting mode). See the discussion on how to pick up a correct set of random seeds in Section 14. 15.3.2 Sequencer Commands ------------------------- reset ----- Perform a software reset. This initializes the tester without clearing the trigger pattern, trigger word, and other settings. This also does not clear the content of the trace memory. This command must be entered before attempting to arm or re-arm the trigger. In error counting mode, it is also necessary to re-enter all the seeds for the LFSR's before starting a new run. arm_trigger ----------- Arm the trigger. After entering this command, the tester will start comparing the received data to the trigger word and mask. force_trigger ------------- This command is used to force the trigger manually. abort ----- This command aborts the current run (used mainly in error counting mode). 15.3.3 Status and Results Commands ---------------------------------- state ----- Shows the state of the tester. Valid states are: RESET, ARMED WAITING FOR TRIGGER, CAPTURING DATA, STOPPED. received -------- Shows the number of 36-bit words captured. position -------- Shows the memory address (in the trace buffer) of the frame that caused the trigger. frequency --------- Shows the measured reception frequency. Should be in 50MHz - 64 MHz range for current tests. errors ------ Shows the number of errors on each channel. locate error ------------ In bit error counting mode and when programmed to abort the run if an error is detected, this command will give the memory address to locate the first frame that does not match the expected pattern. The next 15 memory locations countain the 15 frames that were received after the first error was encountered. Starting from the 16th memory location are kept the frames recorded before the occurence of the error (from the 2033th before the error and so forth). statistics ---------- Shows statistics. Typical output is: Reception Frequency : 64.000 MHz Frame Received : 17975.756546 millions Data Volume : 647.127236 Gbit Estimated Run Time : 280 s (0 hr, 4 min, 40 sec) Link Throughput : 2.304 Gbps Total Error Count : 0 statistics loop ---------------------------- Displays statistics in a loop. Specify the number of iterations and the delay between each iteration in minutes (up to 35 minutes between 2 measurements). If no delay parameter is supplied, statistics are displayed every second. read_data --------- Reads and shows the whole content of the trace memory buffer in the mode specified for display. read_data [ ] ---------------------------------- Reads and shows part of the trace memory buffer. 15.3.4 Test and Debug Commands ------------------------------ write_data [ value1...valueN] -------------------------------------------- Writes words in the memory buffer (for tests). Note that only the 32 lower bits of each 36-bit word can be written. peekb <0xaddress> ---------------------------- Reads a byte at the specified address. pokeb <0xaddress> <0xdata> ------------------------------------- Writes the specified byte at the specified address. References: ---------- [1] ADF card support documents. [2] DS90CR484 48-bit LVDS Channel Link Deserializer, National Semiconductor. [3] Virtex II Reference Board User's Manual, Memec Design, Insight. [4] PCI-DIO 96 User Manual, National Instruments.