1 / 10

Current status of RCT software

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)

holly
Download Presentation

Current status of RCT software

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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. C code: • 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 SBS-related software:

  3. Bit RW Name Description 0 R/W CARD_01 1=RC in Slot 0 or 1, 0= RC in slots 2-6 1 R/W CARD_ODD NOT USED 2 R/W CARD_SHR_LR Enable edge sharing on cables (RC 0 or 1 only) 3 R/W EDC_ERR 0/1=EDC Errors Disabled/Enabled 4 R/W LINK_ERR 0/1=Link Errors Disabled/Enabled 5 R/W R0_UP/DN Changes order of R0 f’s: 0=default, 1=reversed 6 R/W R1_UP/DN Changes order of R1 f’s: 0=default, 1=reversed 7 R/W ZERO_DATA 0/1=Disable/Enable zeroing of data for any error 8 R Card Id Eight bits for Card identification, tied to Vcc, 9 R Card Id Can be strapped to ground. 10 R Card Id Value is complement of serial number of card – to 11 R Card Id Ease visual inspection of straps on SW4 12 R Card Id 13 R Card Id 14 R Card Id 15 R Card Id C++ framework: • 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 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(); … Receiver Card: Card Position, Error modes, and Card Id, VME register $06

  4. VMEDIA session VMEDIA script 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 … 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 ... “read” “write” User interface code (I): • “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

  5. User interface code (II): • Root-based GUI, for non-expert to operate Serial Link teststand at UW • Was used for testing 1420 RC Mezzanine cards

  6. User Interface code (III): Keeping track of it all: Searchable Web display for ASCII log of Mezzanine card testing (V. Puttabuddhi + D. Bradley)

  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. User Interface code (V): • 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 Keeping track of it all: E-log book

  9. Some performance numbers: • “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 Integration with XDAQ:

  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

More Related