1 / 9

ALCT-TMB loopback

ALCT-TMB loopback. Dealt with “char” bug with CERN software limiting TMB register value to only 0xff…. Teven/Todd: ddd_delay= 0 rxdata_1st=05555555 rxdata_2nd=0AAAAAAA 1st_err/latched=1/1 2nd_err=1/1

macaria-roseanne
Télécharger la présentation

ALCT-TMB loopback

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. ALCT-TMB loopback Dealt with “char” bug with CERN software limiting TMB register value to only 0xff… Teven/Todd: ddd_delay= 0 rxdata_1st=05555555 rxdata_2nd=0AAAAAAA 1st_err/latched=1/1 2nd_err=1/1 Teven/Todd: ddd_delay= 1 rxdata_1st=05555555 rxdata_2nd=0AAAAAAA 1st_err/latched=1/1 2nd_err=1/1 Teven/Todd: ddd_delay= 2 rxdata_1st=05151510 rxdata_2nd=0AAA2008 1st_err/latched=1/1 2nd_err=1/1 Teven/Todd: ddd_delay= 3 rxdata_1st=0AA8AAAA rxdata_2nd=05515555 1st_err/latched=1/1 2nd_err=1/1 Teven/Todd: ddd_delay= 4 rxdata_1st=0AAAAAAA rxdata_2nd=05555555 1st_err/latched=0/0 2nd_err=0/0 Teven/Todd: ddd_delay= 5 rxdata_1st=0AAAAAAA rxdata_2nd=05555555 1st_err/latched=0/0 2nd_err=0/0 Teven/Todd: ddd_delay= 6 rxdata_1st=0AAAAAAA rxdata_2nd=05555555 1st_err/latched=0/0 2nd_err=0/0 Teven/Todd: ddd_delay= 7 rxdata_1st=0AAAAAAA rxdata_2nd=05555555 1st_err/latched=0/0 2nd_err=0/0 Teven/Todd: ddd_delay= 8 rxdata_1st=0AAAA2A8 rxdata_2nd=05555511 1st_err/latched=1/1 2nd_err=1/1 Teven/Todd: ddd_delay= 9 rxdata_1st=00531455 rxdata_2nd=00048822 1st_err/latched=1/1 2nd_err=1/1 Teven/Todd: ddd_delay=10 rxdata_1st=05555555 rxdata_2nd=0AAAAAAA 1st_err/latched=1/1 2nd_err=1/1 Teven/Todd: ddd_delay=11 rxdata_1st=05555555 rxdata_2nd=0AAAAAAA 1st_err/latched=1/1 2nd_err=1/1 Teven/Todd: ddd_delay=12 rxdata_1st=05555555 rxdata_2nd=0AAAAAAA 1st_err/latched=1/1 2nd_err=1/1 Now this column of information is correct… G. Rakness (UCLA)

  2. Recall: Old firmware, old ALCT rx/tx scan (at 904) With ALCT in “Send Empty mode”, step in matrix of rx, tx: count the number of data words latched by TMB Result (tx vs. rx) tx ----> 00 01 02 03 04 05 06 07 08 09 10 11 12 ==== ==== ==== ==== ==== ==== ==== ==== ==== ==== ==== ==== ==== rx = 0 0 0 0 0 0 0 0 0 3d8 0 0 0 0 rx = 1 0 0 0 0 0 0 0 0 0 0 0 0 0 rx = 2 0 0 0 0 0 0 0 0 0 0 0 0 0 rx = 3 0 0 0 0 0 0 0 0 0 0 0 0 0 rx = 4 0 0 0 3d8 0 0 0 0 0 0 0 0 0 rx = 5 0 0 0 3d8 3d8 0 0 0 0 0 0 0 0 rx = 6 0 0 0 3d8 3d8 3d8 0 0 0 0 0 0 0 rx = 7 0 0 0 3d8 3d8 3d8 3d8 0 0 0 0 0 0 rx = 8 0 0 0 3d8 3d8 3d8 3d8 3d8 0 0 0 0 0 rx = 9 0 0 0 0 0 3d8 3d8 3d8 3d8 0 0 0 0 rx =10 0 0 0 0 0 3d8 3d8 3d8 3d8 0 0 0 0 rx =11 0 0 0 0 0 0 3d8 3d8 3d8 0 0 0 0 rx =12 0 0 0 0 0 0 0 3d8 3d8 0 0 0 0 Best value is alct_rx_clock_delay = 8Best value is alct_tx_clock_delay = 5 Recall: Last week, the new ALCT firmware was ½-cycle different from this ALCT firmware… G. Rakness (UCLA)

  3. With new ALCT firmware… --> Summed over all data pairs: alct_tx bad data count --------- -------------- 0 28000 1 28000 2 28000 3 2000 4 0 5 0 6 0 7 0 8 6524 9 26979 a 28000 b 28000 c 28000 Best value is alct_tx_clock_delay = 6 G. Rakness (UCLA)

  4. For each wire pair ------------------------------------------------ Cable Pair Errors vs alct_tx_clock_Delay ------------------------------------------------ delay 0 1 2 3 4 5 6 7 8 9 10 11 12 pair ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- 0 1000 1000 1000 0 0 0 0 0 948 1000 1000 1000 1000 1 1000 1000 1000 0 0 0 0 0 1000 1000 1000 1000 1000 2 1000 1000 1000 0 0 0 0 0 1000 1000 1000 1000 1000 3 1000 1000 1000 0 0 0 0 0 0 1000 1000 1000 1000 4 1000 1000 1000 0 0 0 0 0 0 1000 1000 1000 1000 5 1000 1000 1000 0 0 0 0 0 0 1000 1000 1000 1000 6 1000 1000 1000 0 0 0 0 0 1000 1000 1000 1000 1000 7 1000 1000 1000 0 0 0 0 0 195 1000 1000 1000 1000 8 1000 1000 1000 0 0 0 0 0 0 1000 1000 1000 1000 9 1000 1000 1000 0 0 0 0 0 0 1000 1000 1000 1000 10 1000 1000 1000 0 0 0 0 0 0 1000 1000 1000 1000 11 1000 1000 1000 0 0 0 0 0 999 1000 1000 1000 1000 12 1000 1000 1000 0 0 0 0 0 0 1000 1000 1000 1000 13 1000 1000 1000 0 0 0 0 0 0 1000 1000 1000 1000 14 1000 1000 1000 0 0 0 0 0 127 1000 1000 1000 1000 15 1000 1000 1000 0 0 0 0 0 619 1000 1000 1000 1000 16 1000 1000 1000 0 0 0 0 0 0 1000 1000 1000 1000 17 1000 1000 1000 1000 0 0 0 0 0 0 1000 1000 1000 18 1000 1000 1000 1000 0 0 0 0 0 979 1000 1000 1000 19 1000 1000 1000 0 0 0 0 0 0 1000 1000 1000 1000 20 1000 1000 1000 0 0 0 0 0 0 1000 1000 1000 1000 21 1000 1000 1000 0 0 0 0 0 0 1000 1000 1000 1000 22 1000 1000 1000 0 0 0 0 0 636 1000 1000 1000 1000 23 1000 1000 1000 0 0 0 0 0 0 1000 1000 1000 1000 24 1000 1000 1000 0 0 0 0 0 0 1000 1000 1000 1000 25 1000 1000 1000 0 0 0 0 0 0 1000 1000 1000 1000 26 1000 1000 1000 0 0 0 0 0 0 1000 1000 1000 1000 27 1000 1000 1000 0 0 0 0 0 0 1000 1000 1000 1000 Everybody plugged in OK… G. Rakness (UCLA)

  5. Alct_rx_scan --> Summed over all data pairs: alct_rx bad data count --------- -------------- 0 0 1 0 2 2823 3 10000 4 10880 5 20000 6 20000 7 20000 8 20000 9 10000 a 10000 b 99 c 0 Best value is alct_rx_clock_delay = 0 • This scan: • Set alct_tx_clock_delay = 6 (from previous page) • Put ALCT in “loopback” mode • Step through alct_rx_clock_delay • Send the following from TMB  ALCT to receive back at TMB: • 0x2AA in 1st frame • 0x155 in 2nd frame Previous values = (rx, tx) = (8,5) New values = (rx, tx) = (0,6) Is this difference a concern? G. Rakness (UCLA)

  6. Rx scan for each wire pair ------------------------------------------------ Cable Pair Errors vs alct_rx_clock_Delay ------------------------------------------------ delay 0 1 2 3 4 5 6 7 8 9 10 11 12 pair ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- 0 0 0 282 1000 1000 1000 1000 1000 1000 1000 1000 0 0 1 0 0 282 1000 1000 1000 1000 1000 1000 1000 1000 99 0 2 0 0 284 1000 1000 1000 1000 1000 1000 1000 1000 0 0 3 0 0 282 1000 1000 1000 1000 1000 1000 1000 1000 0 0 4 0 0 282 1000 1000 1000 1000 1000 1000 1000 1000 0 0 5 0 0 282 1000 1000 1000 1000 1000 1000 1000 1000 0 0 6 0 0 283 1000 1000 1000 1000 1000 1000 1000 1000 0 0 7 0 0 282 1000 1000 1000 1000 1000 1000 1000 1000 0 0 8 0 0 282 1000 1000 1000 1000 1000 1000 1000 1000 0 0 9 0 0 282 1000 1000 1000 1000 1000 1000 1000 1000 0 0 10 0 0 0 0 98 1000 1000 1000 1000 0 0 0 0 11 0 0 0 0 106 1000 1000 1000 1000 0 0 0 0 12 0 0 0 0 85 1000 1000 1000 1000 0 0 0 0 13 0 0 0 0 98 1000 1000 1000 1000 0 0 0 0 14 0 0 0 0 90 1000 1000 1000 1000 0 0 0 0 15 0 0 0 0 98 1000 1000 1000 1000 0 0 0 0 16 0 0 0 0 67 1000 1000 1000 1000 0 0 0 0 17 0 0 0 0 77 1000 1000 1000 1000 0 0 0 0 18 0 0 0 0 83 1000 1000 1000 1000 0 0 0 0 19 0 0 0 0 78 1000 1000 1000 1000 0 0 0 0 20 0 0 0 0 0 0 0 0 0 0 0 0 0 21 0 0 0 0 0 0 0 0 0 0 0 0 0 22 0 0 0 0 0 0 0 0 0 0 0 0 0 23 0 0 0 0 0 0 0 0 0 0 0 0 0 24 0 0 0 0 0 0 0 0 0 0 0 0 0 25 0 0 0 0 0 0 0 0 0 0 0 0 0 26 0 0 0 0 0 0 0 0 0 0 0 0 0 27 0 0 0 0 0 0 0 0 0 0 0 0 0 “Good communication window” is… • Narrow for all pairs • Widens for other pairs • Wide open for other pairs • Do I have a bug? G. Rakness (UCLA)

  7. CANbus progress Major progress thanks to “Handshake” program (E. Juska [FNAL]) • Maraton: “permanent” communication failures • Requires power-cycle of Maraton to re-establish communication • Seen on several (>5) Maratons each night for over a week • Disappeared with CANbus firmware update from 2.16  2.18 • ELMB: impedance mismatch found on cable carrying CANbus signals and power • Using 28AWG cable over ~300m  “extra” 100 on line • Decision made to buy cable with more copper • ELMB: discovered that version of CANbus driver that we were using was 3 years old, with 13 upgrades in the meantime… • To be updated on Friday evening, run handshake program over the weekend on both chains… • Remaining problems • Grounding on Maraton chain not as it should be • ELMB grounding scheme under investigation, but problematic due to the introduction of ground loops into the system Genuine hope that CANbus problems will go away in 2009 G. Rakness (UCLA)

  8. Other stuff • Mid-Week Global Run began today • Just got started, had trouble getting Global Trigger going… • Confirmed Global L1A Latency is equal to CRAFT (November 2008) • Data runs not yet going… • I am shift leader Thursday day shift • Apparently RPC Endcaps LinkBoard firmware was run with “unknown” delay values in CRAFT… This is to be fixed in a MWGR soon… • I will push them on this topic next MWGR (25 – 26 March) • Luca and Paul at Rice are running the CSCValidation package to assess where CSC’s stand with regards to the amount of the system which is working • Most problems on ME – 2 and ME – 3 (where we haven’t had access to, yet…) • I am giving no talks at the EMu meeting during CMS week • Bora Akgun (CMU) is giving the Commissioning talk • Bob Clare (UC-Riverside) is giving the DCS talk • Karoly Banicz (FNAL) is giving the Online Software talk • While debugging CFEB problems in endcaps, Misha asked if it would be possible to have CLCT pretrigger counters for each CFEB? G. Rakness (UCLA)

  9. To do • Continue with the rest of the TMB + ALCT test firmware/software at CERN • at 904 • At point 5 on chambers with problems • Combine firmware version check into configuration check  moving towards a single push-button check of all configuration • Make firmware reloading an automated procedure… G. Rakness (UCLA)

More Related