SiteMap (Historical BU CMS wiki main page)

Software work spring 2008

2008-02-12 (hazen, BU)


at $XDAQ_ROOT/hal/hcal. COmpleted:

2008-02-08 (hazen, BU)

Working to spruce up hcalOSLB class. Here is the Doxygen documentation for the proposed changes.

Updated the class and implemented new functions in work area ~hazen/hcal_3_11_3 on cms1. Compiles and initializes ok, but no OSLB is in the HTR configuration yet.

Testing at BU, Spring 2007

2007-09-20 (hazen, CERN)

Booted off HO partition. Move to hcaldaq07, caen:1 (S2F05/Bottom).

Testing with 7 links connected to RPC (8th fiber connector broken). SLBs in VME slots 2, 3, 4, 5.

RPC synchronization procedure

Currently this is all done in a C program which can talk to both ends of the links in the RPC subsystem. They need to move it to firmware to speed it up (700 links!). So, we can hopefully define a procedure which uses (i.e.) a TTC broadcast command to trigger it and has timing defined by counting clocks or orbits from the start.

2007-09-19 (hazen, CERN)

Install private source for 3.9.7 via cmsusr1 and compile on hcaldaq09. Copied latest sources for changed files from CVS.

Need to add /opt/daq/lib in library search path in hcalDCC/tool/Makefile

2007-09-14 (hazen, BU)

oSLB cfgScript requires the following. First, in the relevant HTR section, define this as an oSLB:

  HTR {
     if ( SLOT == 11 && MEZZANINE_SITE == 3 ) {
       mezzanineCard = "OSLB"

Then create an oSLB section like this:

  OSLB {
     addressTablePath = "/home/daqowner/dist/hal/oSLB_v2.dat"
     mode = 1
     map = 0
     testPattern = 0x12345678
     firmwareVersion = 9

2007-09-13 (hazen, BU)

Can see muon bits again. All looks ok so far. Had to go back to HTR firmware 183f (in file named 283f in my ~/src/htr directory) because v44 sends only zeroes. E-mailed Drew and Tullio about it. Anyhow, with v183f:

  ./htr -s 11 -x load_rams.htr          # load input pattern rams
  ./htr -s 11 -x load_muon_lut.htr      # setup output LUT with muon bits set
  ./htr -s 10 -x dump_all.htr           # capture and dump data

Setup oSLB using the DAQ, dump data. Looks good. Only a superficial look at the data though.

2007-09-12 (hazen, BU)

Proposed new software interface (hcalOSLB.cc) oSLB_Class stubbed in hcalOSLB.cc. Need firware and actual implementation!

Data format as follows:

The control bits work like this:

  check_ena        (bit 0 at 0x4c) - enables error check bits on bits 24-31
  check_data_ena   (bit 1 at 0x4c) - enables BC0, BCn as above
  test_ena         (bit 7 at 0x04) - sends test pattern (fixed 12345678 now)
  test_rand_ena    (bit 2 at 0x4c) - with test_ena, sends pseudo-random pattern

The program trivalDump.cc (sic) in ~hazen/src/oSLB on cms2 can decode and display this format.

2007-09-11 (hazen, BU)

paper and firmware: (ho_rpc.vhd , td_logic_1164_ktp.vhd ) new HTR firmware v44] installed in slot 11 HTR

New firmware is ~ working. Data format not completely understood, but I see the 19 bits of data and some BCN starting at bit 25 in the output.

The oSLB experview is a work in progress.

2007-07-20 (hazen, CERN)

Please see oSLB_July_2007_Test_Summary for copy of e-log summary entry.

Testing at CERN. 5 SLB installed in HO crate 7, VME slots 2-6. Links cabled per diagram .

Links are numbered as follows:

VME slot 2 Links 1, 2
VME slot 3 Links 3, 4
VME slot 4 Links 5, 6
VME slot 5 Links 7, 8
VME slot 6 -Spare oSLB

As of now, valid data is seen on links 1, 2, 7, 8 by RPC guys. Link 3 has flaky data. Link 4 doesn't work. oSLB in slot 4 has problems: GOLs don't return ready bits, and always send sync pattern.

On 4 working links, we see muon bits! They arrive 19 clocks after the BcN where we send them. No BC0 is seen. This is understood.

Tullio is making new HTR firmware to send local BC0 instead of the one from the fanout.

2007-07-13 (hazen

Talked to Drew. Needed version 183F, not 183E. Now installed on slot 11 top FPGA (only). Also, the 'SPY' command in the SPY menu in htr.cc resets the FIFO before readout, which refills the SPY FIFO without waiting for TTC command. The 'ALL' command doesn't do this.

Now it works.

2007-07-12 (hazen)

Preparing for CERN tests. Updated HTR in slot 11 to v183d firmware. First, will attempt to reproduce success of 4/9/07 as documented in DCCSoftware .

Using files/scripts in ~hazen/src/htr/oSLB on cms2.bu.edu:

  ./htr -s 11 -x reset_oslb.htr         # reset oslb, send idle pattern to resync
                                        # leave oslb sending 555555, aaaaaa
  ./htr -s 11 -x set_oslb_mode.htr      # switch oslb to sending muon bits (mode 0)
  ./htr -s 11 -x load_rams.htr          # load input pattern rams
  ./htr -s 11 -x load_muon_lut.htr      # setup output LUT with muon bits set
  ./htr -s 10 -x dump_all.htr           # capture and dump data

Updating HTRs in slots 10, 11 to 183E (latest test version from Drew). In principle this implements a new feature whereby the pattern RAMs and spy buffers are both triggered by a TTC command. Write 0x40 to 0x2c0 on HTR Xilinx to enable.

Doesn't work... need to talk to Drew.

Testing at CERN, July 2006

See [http://cmsdoc.cern.ch/cms/HCAL/document/904/log/2006-jul-15/2006-jul-15.html Dick Kellog's Log] for these tests

''7/13/06'' -- Overnight run using "simple" clock setup, 0 errors seen. Use 24 bit LFSR random test. RPC receiver is checking both TLK deserializer errors and LFSR errors.

''7/14/06'' -- Rewire TTC to emulate final setup.

''7/15/06'' -- Studying error rate ''vs'' optical power. Details on Dick's Log LINK . Two links through duplex 50m cable. Insert optical attenuator. Without atten, power is -5dbB both links. OK at -11 and -16dBm for each link on the timescale of 10 minutes (5e11 bits).