1. Monika Grothe, U Wisconsin, CMS week March 2004: Status of RCT software 1 Current status of RCT software Monika Grothe U Wisconsin – Madison CMS week March 2004 3 main layers: 1. Extensive body of C code, historically grown during design phase of hardware, our “repository of knowledge” about hardware functionality (main author P. Chumney) 2. C++ framework, implementation of hardware structure and functionality of a full RCT crate, groundwork for future integration with CMS run-control/CMS DAQ software (main author S. Dasu) 3. User interface code (main author last two MG):  Command line interface for manipulating registers via VME  GUIs to facilitate standardized hardware testing procedure  E-log book to keep track of hardware testing result

2. Monika Grothe, U Wisconsin, CMS week March 2004: Status of RCT software 2  Routines for initializing and operating RCT crate boards properly  Routines for testing basically any feature of the hardware that is testable by software ( f.i.Read/write LUTs, JTAG Boundary scan code to test data paths between ASICS, send test data from RCs to JSC  Originally written for old MVME crate controller, meanwhile fully ported for use with SBS  We are in the process of migrating this legacy C code into our in-the-works C++ framework  Since we use VME interrupts for purpose of geographical card addressing, a modification to the SBS kernel-level module that handles interrupts was necessary (S. Dasu + D. Bradley)  For that reason, cannot use HAL  But coupling between SBS specific code and our C/C++ operating and testing software is kept to a minimum, consists only of read(address) and write(address) routines C code: SBS-related software:

3. Monika Grothe, U Wisconsin, CMS week March 2004: Status of RCT software 3  Groundwork for future integration with CMS DAQ and run control code  Implementation of full set of functionalities provided on cards by setting VME registers  Includes also code for testing card functionality, which has been interfaced to java GUI RCTCrate.hh has one or more RCTReceiverCard.hh RCTElectronIsolationCard.hh RCTClockControlCard.hh RCTJetSummaryCard.hh which inherit all from RCTCard.hh BitRWNameDescription 0R/WCARD_011=RC in Slot 0 or 1, 0= RC in slots 2-6 1R/WCARD_ODDNOT USED 2R/WCARD_SHR_LREnable edge sharing on cables (RC 0 or 1 only) 3R/WEDC_ERR0/1=EDC Errors Disabled/Enabled 4R/WLINK_ERR0/1=Link Errors Disabled/Enabled 5R/WR0_UP/DN Changes order of R0  ’s: 0=default, 1=reversed 6R/WR1_UP/DN Changes order of R1  ’s: 0=default, 1=reversed 7R/WZERO_DATA0/1=Disable/Enable zeroing of data for any error 8RCard IdEight bits for Card identification, tied to Vcc, 9RCard IdCan be strapped to ground. 10RCard IdValue is complement of serial number of card – to 11RCard IdEase visual inspection of straps on SW4 12RCard Id 13RCard Id 14RCard Id 15RCard Id Receiver Card: Card Position, Error modes, and Card Id, VME register $06 class RCTReceiverCard : public RCTCard{ public: … // Access functions bool isCard01(); bool isSharingLeftRight(); bool statusOfEDCChecking(); bool statusOfLinkErrorChecking(); unsigned short statusOfRegionReversing(); bool statusOfDataZeroing(); // Action functions bool resetBX0(); bool disableBX0Checking(); bool resetErrors(int channel = 0xFF); bool setAsCard01(); bool setAsNotCard01(); bool enableShareLeftRight(); bool enableEDCChecking(); bool enableLinkErrorChecking(); bool enableRegion0Reversing(); bool enableRegion1Reversing(); bool enableDataZeroing(); bool disableShareLeftRight(); … C++ framework:

4. Monika Grothe, U Wisconsin, CMS week March 2004: Status of RCT software 4 “Old faithful” - Command line interface code VMEDIA for manipulating registers via VME  Handy diagnostic tool for expert users  Used also by groups outside of UW who use the UW Serial Link Test cards bash-2.05a$ more cable_pin68_test.txt print RC schematics D0728 print Make sure to check signal (pin n) and inverted signal (pin n+1) print For R0: Probe on U441 pin 6 - bit 0, 8/1, 20/2, 22/3, 24/4 print For R1: Probe on U433 pin 24 - bit 0 print read aa3.txt print Send from RC2 to RC3 - this tests 34 of the 68 pins on the cable print Sending Region 0 Bit 0 poke 1 18000000 2 dump 1 18000006 dump 1 16000006 poke 1 16000000 1 poke 1 16440006 1 poke 1 16000000 2 resys print Hit return for sending Bit 1 wait poke 1 16000000 1 poke 1 16440006 2 poke 1 16000000 2 resys print Hit return for sending Bit 2... bash-2.05a$ vmedia vmedia> read cable_pin68_test.txt vmedia> RC schematics D0728 vmedia> Make sure to check signal (pin n) and inverted signal (pin n+1) vmedia> For R0: Probe on U441 pin 6 - bit 0, 8/1, 20/2, 22/3, 24/4 vmedia> For R1: Probe on U433 pin 24 - bit 0 vmedia> vmedia> Send from RC2 to RC3 - this tests 34 of the 68 pins on the cable vmedia> Sending Region 0 Bit 0 vmedia> Hit return for sending Bit 1 vmedia> Hit return for sending Bit 2 … “read” “write” VMEDIA script VMEDIA session User interface code (I):

5. Monika Grothe, U Wisconsin, CMS week March 2004: Status of RCT software 5  Root-based GUI, for non-expert to operate Serial Link teststand at UW  Was used for testing 1420 RC Mezzanine cards User interface code (II):

6. Monika Grothe, U Wisconsin, CMS week March 2004: Status of RCT software 6 Keeping track of it all: Searchable Web display for ASCII log of Mezzanine card testing (V. Puttabuddhi + D. Bradley) User Interface code (III):

7. Monika Grothe, U Wisconsin, CMS week March 2004: Status of RCT software 7 User Interface code (IV): GUI interface for C++ framework code  Main author MG  Written in java, uses JNI to interface to C++ framework code  Intended for non-expert user, for example student, to carry out standardized tests for board validation and for spotting boards that need further inspection by hardware expert  Will grow as C code migration to C++ framework continues

8. Monika Grothe, U Wisconsin, CMS week March 2004: Status of RCT software 8 Keeping track of it all: E-log book  Keeps ASCII log file per card, identified by its barcode  Keeps card status summary files which can be made accessible via Web and can be made searchable User Interface code (V):

9. Monika Grothe, U Wisconsin, CMS week March 2004: Status of RCT software 9 “Warm start” taken to mean reset/initialize “Cold start” taken to mean initializing crate and uploading data into on-board LUTs from file With C++ framework code, called from java GUI, and full RCT crate:  “Warm start” takes only a few seconds  “Cold start” estimated by loading zeros into the LUTs:  Loading zeros only: ~20 sec per RC card, ~1 sec per EIC and JSC full crate ~2.5 min.  Loading and verifying: ~30 sec per RC, ~1 sec per EIC and JSC full crate ~3.5 min.  The RCT does not do any data acquisition, so integration in XDAQ based DAQ/run control should be relatively easy  Integration with XDAQ only needed for purpose of reset/initialize/configure of RCT crates  As finger exercise set up code to operate our Serial Link teststand from within XDAQ  Will have to integrate with HCAL XDAQ code for slice test later this year  XDAQ will be needed by RCT once we have to operate more than one crate at a time Some performance numbers: Integration with XDAQ:

10. Monika Grothe, U Wisconsin, CMS week March 2004: Status of RCT software 10 Conclusions and future plans:  Software that covers all aspects of testing production RCT boards is available, either as legacy C code or already as C++ code  A C++ framework is available that provides groundwork for future integration of RCT software with CMS DAQ  Migration of C code into C++ framework is under way  GUIs and e-log book provide user interface  Finish migration of legacy C code into C++ framework  Revise L1RegionalCaloTrigger emulator code this summer to  to do accurate bit level simulation and generation of  to generate LUT content for use both in simulation and on RCT boards  to provide online and offline diagnostics capability  Set up proper data base for record of full history of each production board throughout lifetime of the experiment  Integrate RCAL software with HCAL XDAQ-based DAQ code for RCAL/HCAL hardware integration tests later this year