Current%20status

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
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 statusOfLinkErrorChe
cking() 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
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

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