Date: Tue, 24 May 2005 18:13:01 -0400 (EDT) From: Michael J Mulhearn Subject: ADF->TAB To: L1_Cal IIB Hello! Dan, Philippe, and I have been working on testing ADF->TAB transmission using the ADF pseudo-random number generator. As you may recall, we have had success with simple repeated patterns, but not with the full pseudo-random data. We have now tested that the parity sent by the ADF agrees with the parity calculated onboard the TAB and calculated offline using captured data. Here is an example pseudo-random event captured on the TAB. The ADF is sending the 4x4 block of non-zero data. To us mortals, it looks random: Hadron TTs: eta: <--phi--> -------------------------------------------------------------------------------------------------- 00: 0x00(000) 0x00(000) | 0x21(033) 0x1c(028) 0xf6(246) 0x9a(154) | 0x00(000) 0x00(000) 0x00(000) 01: 0x00(000) 0x00(000) | 0xea(234) 0xe2(226) 0x0e(014) 0xcd(205) | 0x00(000) 0x00(000) 0x00(000) 02: 0x00(000) 0x00(000) | 0x0f(015) 0x9d(157) 0x22(034) 0x41(065) | 0x00(000) 0x00(000) 0x00(000) 03: 0x00(000) 0x00(000) | 0xe4(228) 0x87(135) 0x70(112) 0x86(134) | 0x00(000) 0x00(000) 0x00(000) -------------------------------------------------------------------------------------------------- EM TTs: eta: <--phi--> -------------------------------------------------------------------------------------------------- 00: 0x00(000) 0x00(000) | 0xb5(181) 0x44(068) 0xd5(213) 0x05(005) | 0x00(000) 0x00(000) 0x00(000) 01: 0x00(000) 0x00(000) | 0x66(102) 0xa2(162) 0xfb(251) 0x89(137) | 0x00(000) 0x00(000) 0x00(000) 02: 0x00(000) 0x00(000) | 0xb8(184) 0x43(067) 0xfc(252) 0x9f(159) | 0x00(000) 0x00(000) 0x00(000) 03: 0x00(000) 0x00(000) | 0x3a(058) 0x59(089) 0xae(174) 0x58(088) | 0x00(000) 0x00(000) 0x00(000) -------------------------------------------------------------------------------------------------- Control Signals: cable 2 event: 0x19 cable 2 spare: 0x0 cable 2 frame: 0x1 cable 2 parity: 0x7c The parity is defined as (^ means XOR): PARITY = EM(0) ^ EM(1) ^ ... ^ EM(15) ^ HD(0) ^ HD(1) ^ ... ^ HD(15) ^ BC ^ FRAME As you can see, bit errors in any TT would manifest themselves as a disagreement between the parity sent by the ADF and calculated from the data received on the TAB. This calculation can be done in the TAB firmware for every event and also offline with data capured in diagnostic memory and later read out. Here is a comparison of the parity calculated from the captured data on the TAB with the parity sent by the ADF. As you can see they agree for all 32 events captured: # TAB: ADF: BC: PARITY: BC&7: CHAN 0: BC: PARITY: AGREE: 00 1 0x7c 1 0xb5 0x19 0x7c OK 01 2 0x11 2 0x21 0x1a 0x11 OK 02 3 0xa0 3 0xe4 0x1b 0xa0 OK 03 4 0x08 4 0x04 0x1c 0x08 OK 04 5 0xdd 5 0xa5 0x1d 0xdd OK 05 6 0xbe 6 0xe3 0x1e 0xbe OK 06 7 0x3d 7 0xd2 0x1f 0x3d OK 07 0 0x56 0 0xfc 0x20 0x56 OK 08 1 0x61 1 0xc1 0x21 0x61 OK 09 2 0xa5 2 0x2e 0x22 0xa5 OK 10 3 0x93 3 0xc4 0x23 0x93 OK 11 4 0xbb 4 0xbf 0x24 0xbb OK 12 5 0x72 5 0x8a 0x25 0x72 OK 13 6 0x50 6 0x40 0x26 0x50 OK 14 7 0x36 7 0x75 0x27 0x36 OK 15 0 0x5a 0 0xb0 0x28 0x5a OK 16 1 0x05 1 0xe5 0x29 0x05 OK 17 2 0x2d 2 0xdf 0x2a 0x2d OK 18 3 0x34 3 0x89 0x2b 0x34 OK 19 4 0xa9 4 0x3c 0x2c 0xa9 OK 20 5 0x16 5 0xa0 0x2d 0x16 OK 21 6 0xea 6 0xd0 0x2e 0xea OK 22 7 0xe2 7 0x76 0x2f 0xe2 OK 23 0 0x32 0 0x3a 0x30 0x32 OK 24 1 0x53 1 0x0f 0x31 0x53 OK 25 2 0x97 2 0x4f 0x32 0x97 OK 26 3 0xa6 3 0xb2 0x33 0xa6 OK 27 4 0xee 4 0x85 0x34 0xee OK 28 5 0x05 5 0x8a 0x35 0x05 OK 29 6 0xd9 6 0x60 0x36 0xd9 OK 30 7 0xc7 7 0x57 0x37 0xc7 OK 31 0 0xa2 0 0xa6 0x38 0xa2 OK Finally, the TAB does an online parity calculation and compares it with the ADF. After 40 minutes of running, no disagreements were found: PERR0: 0 PERR1: 0 <-- The ADF is plugged in here PERR2: 0 This is already a very stringent test of the ADF->TAB data transmission, and it appears that this part of the chain is robust. There is one last step: testing that the TAB can recalculate the full pseudorandom data onboard and do a full comparison with every trigger tower, but this is only slightly more stringent than this test. I will now spend most of my time investigating the TAB->L2 (L3?) glink issues, as this seems to be the most pressing issue. cheers, mike