D-Zero Hall Log Book for 2000 ------------------------------- The most recent entries are near the beginning of this file. This file began in January 2000. Earlier D-Zero Hall Log Books are on the web either in the directory with this file or else at: http://www.pa.msu.edu:80/hep/d0/ftp/run1/l1/inventory_logs. DATE: At: Fermi TOPICS: DATE: At: Fermi TOPICS: ------------------------------------------------------------------------------- DATE: 13,14,15-DEC-00 At: Fermi TOPICS: New And-Or Input Term List, Our SCL Receiver Yellow LED, Trouble with VME into M122, Setup of the Master Clock Selector FanOuts, Single Buffer VRBC, Power Supply Voltage Check, Work on Geo Sect #33, #37, Tests of TRICS 9.1-E and L1_TRM 3.1, Tests of Force L2_Rej and L2_Rej with two VRBC's, first test of the optical split. Came to Fermi early Wed morning because there had been trouble with VME communication with rack M122. Unfortunately when I got here it all worked. Restarted 9.1-D, Configure, 10k loops SCT without scalers, 6k loops SCT with scalers and skip next. Because the other common card to all of rack M122 is the Master Clock Selector FanOut review how they are setup. SLF CFT Ch LED L2 SC SC SC FW FW FW FW Num Cal Cal Pulse Help SCL 124 10A 10B 123 123 122 122 --- --- --- ----- ---- --- --- --- --- --- --- --- --- 0 9 9 13 2 0I 14 7 4 7I 3I 7I 3I 1 10 10 3 7 0I 15 2 5 6I 2 6I 2 2 11 11 4 3 0I 15 3 6 5 1 5 1 3 12 12 5 0 8 8 8 7 4I 0 4I 0 53 MHz I I I I I I --> Inhibit Phone Numbers for Daniel Mendoza: work office x5199 home x6392 Leslie Groer: work office x5587 Worked with Daniel Mendoza trying to make sure that we have a "signle buffer" VRBC installed in the Trig FW readout crate. What ever VRBC was in our crate when I got here Wednesday was clearly not single buffer. How to test this: To Stop our VBD from sending out events, either tie the "Grant" line to our VBD low or else wait for our VRC to die. Run our readout Trig FW setup for Spec Trig 103. If it is a single buffer VRBC then it fires 3 times and is then 100% L1_Busy. There will be 2 events in the VBD and one in the VRB waiting to transfer to the VBD. If it is a normal VRBC then it fires 25 times and then goes 100% L1_Busy. Another difference that you can see between normal and single buffer VRBC's is the amount of L1_Busy time per Hz of firing. For the normal VRBC it is about 0.00075% L1_Busy per Hz i.e. it is L1_Busy only while the data is moving on G-Link and into a VRB buffer. For the special Single Buffer VRBC it is L1_Busy about 0.025% per Hz because it remains L1_Busy until the VBD has ingested the event. Power Supply Voltage Checks: Location +5.0 Volt +3.3 Volt -2.0 Volt -4.5 Volt ---------- --------- --------- --------- --------- M122 Top 5.037 3.329 2.015 4.518 M122 Mid 5.014 3.311 2.021 4.518 M122 Bot 5.048 3.321 2.016 4.516 M123 Top 5.018 3.312 2.002 4.493 M123 Mid 5.017 3.319 2.004 4.493 M123 Bot 5.026 3.354 1.984 4.476 These are all measured on the TOM module, i.e. this is the actual backplane voltage. The previous check was 20-JUNE-00. Also check the SCL Hub-End and VRB Readout crates. Location +5.0 Volt +3.3 Volt -2.0 Volt -4.5 Volt --------------- --------- --------- --------- --------- SCL Hub-End TP 5.053 3.344 2.040 5.215 SCL Hub-End Bus 5.013 3.306 2.013 5.139 VRB Readout TP 5.044 3.331 2.048 5.222 VRB Readout Bus 5.009 3.321 2.049 5.234 These are measurments at the Test Points on the Power Pan (TP) on at the backplane bus connections (Bus). Work on the problems that Muon was having with GS Cables #33 and #37. GS #33 Tested the data coming out of the Muon end of the SCL Serial Coax Cable. It was all OK Look at the signals at the Hub-End of the Status Cable. There were no signals on the first 3 pairs of lines, i.e. L1-Busy, L1_Error, and L2_Busy. The connector on the GS end of the Status cable had clearly not been installed correctly. Replace it. Now the Hub-End of the Status cable is getting good signals on all lines except L2_Busy. One side of the L2_Busy pair (pin 5) does not make it through the cable. Because we do not need the JTAG signals on the high end of the cable (the top 8 lines) I just flipped the cable over and re-connectored both ends. Now all Status signals test good at the Hub-End. GS #37 Tested the data coming out of the Muon end of the SCL Serial Coax Cable. It was all OK Look at the signals at the Hub-End of the Status Cable. They are all OK. But the connector at the GS end of the Status cable looks a little funny. So I replaced it and and tested all the signals again. All OK. New And-Or Term Stuff. Besides the collection of NIM Cosmic And-Or Terms that we have been using to date, we now have another one. And-Or Input Term Number Current Function - Source ------------ -------------------------------------------------- 0 Copy of the Master Clock Generated L1 Sub-System Gap Signal 1 Cosmic Low Rate LeCroy Lemo Input #1 2 Cosmic High Rate and sometimes a Muon Pulser signal LeCroy Lemo Input #3 3 Scintallator_West_1 (new 14-DEC-00 for CFT cosmics) LeCroy Lemo Input #9 4 Muon Forward Pixel Scintallator test trigger LeCroy Lemo Input #6 5 Muon MDT_Fast_OR LeCroy Lemo Input #8 31:16 Dean's Calorimeter Pulser stuff 95:80 Muon Triggers 240 Outstanding L1's Limit #0 L1AL2 MSA_Out_32 241 Outstanding L1's Limit #1 L1AL2 MSA_Out_33 242 Beginning of Turn Marker SCL Helper MSA_Out_48 243 Live Accelerator BX Marker SCL Helper MSA_Out_49 244 Sync Gap Marker SCL Helper MSA_Out_50 245 Cosmic Gap Marker SCL Helper MSA_Out_51 246 Spare Marker SCL Helper MSA_Out_52 247 Skip Next N #0 FOM++ MSA_Out_40 248 Skip Next N #1 FOM++ MSA_Out_41 249 Skip Next N #2 FOM++ MSA_Out_42 250 Skip Next N #3 FOM++ MSA_Out_43 251 Tick Selector #0 Tick & Turn Scaler MSA_Out_40 252 Tick Selector #1 Tick & Turn Scaler MSA_Out_41 253 Tick Selector #2 Tick & Turn Scaler MSA_Out_42 254 Tick Selector #3 Tick & Turn Scaler MSA_Out_43 255 Permanently Tied HI Setup test triggers using And-Or Terms in the range 242-246 so that it would only fire for BX's that were: Beginning of Turn, Live BX, Sync Gap. Watched with the logic analyzer and this all worked fine. We were only firing where we should have. i.e. this Master Clock lines are properly setup so that you can allow L1_Acpt's to only be issued for BX's that were e.g. BOT. Fri. Start TRICS 9.1-E Config, Init, SCT 5k ALL ALL no errors. Move from L1_TRM ver 1.1 to 3.1 and reconfigure all and 2k loops of SCT ALL ALL with zero errors. Run Spec Trig 103 FW ReadOut and put 2 events into the log file at about 9:05 AM. Modified the Spec Trig 103 FW ReadOut mcf: drop Geo Sect 127, add Geo Sect 30 (which is not used and lets us spy with the logic analyzer), move from Tick Select AOIT 251 to 254 so that we fire on a "live BX", and include AOIT 254 in the Exp Group (so we could use it to watch the Exp Group per Bunch Scaler. Use the new COOR-TRICS Force L2_Rej. The logic analyzer says that this works just fine. Using the "Single Buffer" VRBC and sending it L2_Rej it just hangs L1_Busy. Using the "Current Production" VRBC and giving it L2_Rej it does not hang or anything like that but is it throwing away the proper events. Test the new L1 TRM (ver 3.1) by reading the counters for the FIFO pointer. Do this for the AOIT 0:15 i.e. controlled by the Master Clock test sub system gap and strobe and for AOIT 31:16 which is controlled by Dean Calo. Read a number of times and do the subtraction: L1 TRM ver 3.1 AOIT 15:0 9 samples average is 20.7 steps in the FIFO AOIT 31:16 10 samples average is 18.1 steps in the FIFO So this fits just fine with what Kirsten measured yesterday with the L1 TRM 1.1 About 3:20 PM there are two formatted dumps where the Optic Splitter was in the #1 Ch (0:3) of the first VBD. So far it is OK. About 5:50 PM there are 3 more events in the log book. With the new SCL coax cable from the SCL Hub-End to our Trig FW VRBC I have not seen the Yellow LED ever go out again. DATE: 14-DEC-00 At: Fermi TOPICS: L1 TRM Before trying L1 TRM 3_1, have a look at what we see from L1 TRM 1_1. We are providing a master clock signal as AOIT 0, and there are some cosmic ray terms on AOIT 1 and 2. This corresponds to 1/0/10/1. Register 8 reads 0xf, i.e. error checking is enabled. Register 9 reads 0x0, i.e. there have been no errors. Repeatedly reading register 10 and doing the difference between the write and read addresses yields a typical value of 21. The scaler at register address 40 is incrementing, as are the scalers at registers 42 and 44; the scaler at register 46 is not incrementing. Dean is providing some calorimeter terms on 31:16. We know specifically that the term on AOIT 31 is incrementing so have a look at 1/0/10/14. Register 8 reads 0xf. Write 0x020f then 0xf to clear any errors in register 9. Register 9 now reads 0 for a while and then eventually 0x0106, i.e. there is a FIFO read error and a missing subsystem gap error. Since it's difficult to know how stable the calorimeter input is, this may be ok. Repeatedly reading register 10 and subtracting the read address from the write address yields a typical value of 18. The only scaler on this FPGA which is incrementing is the one at register address 46. The TRM is in bypass mode for the upper bits (255:240) on which we're providing some number of master clock signals as well signals like Tick Select. This corresponds to 1/0/2 FPGAs 16, 12, 8, and 4 (for 255:252, 251:248, 247:244, and 243:240 respectively). In all cases, register 8 reads 0xf and register 9 reads 0x0. Register 10 always reads 0x8080. That is, the read and write counter never get going. The scalers for most terms are incrementing - the only exceptions are for terms 253, 252, 241, and 240. DATE: 12,13-DEC-00 At: Fermi TOPICS: M122 VME problems Sometime around 3:30 Leslie Groer called and reported that there were problems starting a run, initializing the framework, and configuring the framework. I verified that indeed rack M122 would not configure (individual cards or FPGAs may have configured, but by and large, the rack was not configuring). M123 still configures without a problem. Both racks had been configured twice before that day, and data had been taken. Additionally, the VME access lights still flash as Trics tries to talk to the various cards. So try power cycling M122. Try power cycling the communications crate in M124. No joy. Try reading and writing the scratch RAM in the VME Interface FPGA, e.g. 0/0/8/0/23 and 0/1/8/0/23. I mostly tried to write 0x0 and 0xffff. In a random sampling, this seems to basically work in the top crate, but does not work in the middle crate. The VI Master also shows a BERR light when the middle crate is being addressed. Configuring FPGAs for these two crates still is not successful. In the top crate, it's not always a hard failure, however. For instance, in M122 Top Slot 6, the main array FPGAs sometimes configure and sometimes don't. My feeling is that M122 Bottom behaves more like M122 Top than M122 Middle, but I mostly played with the top two crates. Further investigation also shows that in the top crate, it seems to be harder to write 0x1234 than 0x0 or 0xffff. It seems to eventually work, but it sometimes takes several tries during which time the value read back may be 0x1212 or 0x3412 for instance. Since one common feature is the VI Master, try replacing that with a spare that Jae has found. The behavior is unchanged. Now try swapping the known good VI Master currently used for M123 with the Master used for M122. The problem stays with M122. Try power cycling all 3 crates, and the clock, and restarting Trics. Try Trics 9.0 W. Still no luck. Another common feature is the selector fanout providing the 53 MHz to M122. Look at the front panel outputs of the SFO for M122 and for M123 - they look the same; there is no obvious problem with the SFO providing timing signals to M122. Still no clue as to what has gone wrong with the VME access to M122. Shut the framework off. 13 Dec Dan arrives, turns the FW on, and everything is just fine. DATE: 6,7,8-DEC-00 At: Fermi TOPICS: Work on VBD Incomplete Events, SCL Hub-End Master Clock timing, Meeting with French about Run 2B L1 Cal Trig. The VBD Diagnostic port is something like: Daig Port Pin Num. --------- U104 74F04 P2 ----> 1 "Sync Bit D0" ? \ U104 74F04 P4 ----> 3 "Sync Bit D1" ? | U104 74F04 P6 ----> 5 "Sync Bit D2" ? | Outputs U104 74F04 P8 ----> 7 "Sync Bit D3" ? | from VBD | UR04 74LS273 P12 ---> 9 "Request" / "Grant" 25 >--- UR03 74F574 P3 Input to VBD All even pin numbers are Ground. The L3 Diagnostic Cable Patch Panel Wiring: 50 Pin connector pin 50 is the only Gnd pins 1:8 are Grant outputs from the I/O card going to the VBD's pins 9:16 are Ready inputs to the I/O card bringing signals from the VBD's. pins 17:48 are inputs to the I/O card bring "Sync Num?" signals from the VBD's. The I/O card pinouts of the Ready Grant pairs is just the rational setup e.g. pin 1 with 9, pin 2 with 10, ... pin 8 with 16. The I/O card pinout of the "Sync Num ?" inputs are in blocks of 4 but what block of 4 is associated with what Request-Grant pair does not fit a pattern that I can see. But I do not think that the "Sync Num ?" inputs are used anyway. examples of the Patch Panel net list to a VBD VBD Pin Num 50 Pin Connector Pin Num VBD #N or #M VBD #N VBD #M ------------ ------------------------ 1 20 44 3 19 43 5 18 42 7 17 41 9 Request 15 13 25 Grant 7 5 Look at the Digital I/O card used for the VBD diagnostic cable in the VRC only pin #50 is Gnd. Pin 49 is ?? 48 I/O lines receivers are 74LS373 drivers are 74S244 examples of net list 50 pin connector pin #1 receiver LS373 P18 driver S244 P3 50 pin connector pin #2 receiver LS373 P17 driver S244 P5 The digital I/O card has 6 other Gnd vias associated with its I/O connector that are currently not used. The low logic level (low voltage level) input current to a: F574 is: 0.6 ma with an 82 Ohm series resistor this is 49 mV LS373 is: 0.4 ma with an 82 Ohm series resistor this is 33 mV OK, using a short 6" 50 conductor cable and our own single VBD patch panel fixes our "Incomplete Event" problem. All Requests except the one we are using are tied to Ground. It runs at about 30 Hz. Dean says that the pauses in data flow are when L3 stops the triggers to let the ethernet transfer of the events catch up. Watch the Request and Grant signals on the 1st MCH where there is only one VBD wanting service. Request is typically up for about 30 usec before the VRC finds it. The Grant is about 3.5 usec and is probably just a fixed lenth "pulse" from software in the VRC. The Request typically falls in about the middle of the Grant. I guess that this is a normal hardware hand shake in the VBD, i.e. it sees the Grant so it drops the Request. A concern is that once the VRC gives a Grant it immediately goes on to looking for more VBD's that want readout (and can thus trash the event) instead of waiting for the VBD that was just given a Grant to finish using the Data Cable. In the log file at about 1:25 Friday Afternoon there is of formatted and raw dumped events. This is after we have run many 10's of K events through the system. Nothing in Red. SCL Hub-End For the 0.66 velocity factor cable it is about 7.75" of cable per nsec. C is about 0.983 ft per nsec. Cut 47" from the cable that feeds 7 MHz clock to the SCL Hub-End. The intent is to reduce the delay on this cable by 6 nsec to allow the Master Clock Selector FanOut driving this signal to have its ReTiming Delay set to mid range. This Master Clock Selector Fanout is feeding Timing Line #8 (the SCL Tick Clk) on its SLF Ch#3. Because this is the only channel used on the SLF I set the other 3 channels, #0, #1, #2 to select Time Line #0 and disabled them. Now the idea is to move around the re-timing delay on this SLF and see over what range the SCL Hub-End will operate and then set it in the center. While doing this monitor with a good scope the relative phase of the 53 Clk and the 7 Clk and verify that it moves in 1 nsec steps. The results are arranged by the re-time delay digit (as seen on the front panel). All this monitoring is done via the front panel LEMO connectors on this Master Clk SLF. "3" The 7 MHz rises 1 nsec before the 53 MHz rises. SCL FanOut Amber LED is ON All received SCL data is 100% junk "4" The 7 MHz and 53 MHz rise at the same time. SCL FanOut Amber is ON All received SCL data is 100% junk "5" The 7 MHz rises 1 nsec after the 53 MHz rises. SCL FanOut Amber is ON All received SCL data is 100% junk "6" The 7 MHz rises 2 nsec after the 53 MHz rises. SCL FanOut Amber is ON All received SCL data is 100% junk "7" The 7 MHz rises 3 nsec after the 53 MHz rises. SCL FanOut Amber is ON All received SCL data is good "8" The 7 MHz rises 4 nsec after the 53 MHz rises. SCL FanOut Amber is ON All received SCL data is good "9" The 7 MHz rises 5 nsec after the 53 MHz rises. SCL FanOut Amber is ON All received SCL data is good "A" The 7 MHz rises 6 3/4 nsec after the 53 MHz rises. SCL FanOut Amber is ON All received SCL data is good "B" The 7 MHz rises 7 3/4 nsec after the 53 MHz rises. SCL FanOut Amber is ON All received SCL data is good "C" The 7 MHz rises 10 nsec after the 53 MHz rises. SCL FanOut RED is ON All received SCL data is 99% junk So we set the SCL Fanout Re-Timing delay at "9" which as seen from the front panel monitoring jacks for Ch#3 and PClk shows the 7 MHz rising 5 nsec after the 53 MHz rises. The ideal spacing might me more like 5 1/2 nsec. I have no idea why the fancy delay lines used in the SLF do not give good even 1 nsec steps. Moved to TRICS 9.1-D. Did 5K loops of SCT all cards all tests no errors. Meeting with the French about Run 2B L1 Cal Trig. Kinds of terms that we probably want: electron (with sum of 2 towers, EM fraction and isolation), Jet (with sum of 9 towers), Missing Et, Tau, conventional count of towers over threshold, EM towers go to 64 in phi. Build in an output to match with CFT at L1 ? There are 80 sectors from CFT and 32? - 64 ? from L1 Cal Trig Studies: What has been done for Run I L1.5CT Run II Level 2 Bob Hirsoky? Timescale: Some decision in April-May at Saclay, running about 2004 as Run 2A should be about 3 years for 2 fb-1. DATE: 29,30-NOV-00 1-DEC-00 At: Fermi TOPICS: SCL Hub-End work, 3k event problem with CFT, Pick off Resistors and looking at pulser signal, TRICS 9.1, Our SCL Coax Cable, L1_TRM testing. Moved the "re-timing" delay of the Master Clock's 5th Selector Fanout (the Selector Fanout that drives the SCL Hub-End) from "0" to "5". Running at zero was dangerous because that appeared to be the point in the 18.8 nsec cycle where the Time Lines were changing and thus there was no setup or hold time. Most of the Selector Fanouts run at a re-time setting of "9" but "5" was picked to match the delay lines available for the SCL Hub-End. A re-time of "5" should be just fine to make the Selector Fanout stable and happy. The switch setting for a retiming delay of 5 is: sw1 DDUUDUDU sw8. The production model SCL Hub-Controller was tested and did not work. 2 of the SCL FanOuts did not lite their amber LED's when the 7 MHz clock was enabled. The SCL Fanout (SN# 9B) with the bad channel #7 (see 7-NOV-00) was looked at some more and it is clear that it is a stuck low bit (bit of value 2) to the AMCC transmitter. So it is nothing fancy like a timing problem - it is just a bent pin or shorted trace or something like that. The other SCL Fanouts that we had pulled to get access to the Hub Controller are: 40:47 is SN# 4B, 48:4f is 19B, 50:57 is 6B, 58:5F is 9B. Swapped 9B with a spare SCL Fanout SN# and returned 9B to Ted for repair. Before we try swapping Status Concentrators to try fixing the no DTACK* problem Ted ask that we try swapping SCL FanOuts between a slot that does DTACK and a slot that does not DTACK*. Worked with Daniel Mendoza and Thomas on the CFT going l1 busy after 3k events problem. It appears to be rate independent, i.e. if you run at 3 Hz you still get stuck 100% L1 Bz after about 3k events. What normally happens is that L2 Busy starts to show up after about 1k events and it builds to about a few percent L2 Bz at 2k events and then at 3k events it switches to 100% L1 Bz and stays that way for ever. If you run with the SCL status cable pulled off then you can keep running. If you us the special single buffer VRBC then you do not have this problem. With this single buffer VRBC, if the Trig FW failed to issue a L2 Accept then you would just hang. Other systems do not see this problem. Worked with Dean to look at the trigger pickoff signal using with Run II analog electronics on the CTFE card and the French pulser running into CC TT +1,8. Pulse amplitude looks about as designed. EM signal rises in about 150 200 nsec until the reflection wacks it over and it then takes a total of 300 to rise. HD is pile-o-reflections. It looks like a "W". There is still readout noise of about 5 to 10 GeV. Had a meeting with Reiner Hauser, Maris, and Dean about the pick off resistors. Basically all that is left to do is decide on the EM1 sampling fraction and bin the 50k resistors into a small number of groups. Dean is about at the drop dead point for this data. Next meeting is next week. Run of Trics 9.0-W just to configure, initialize, and then 1 or 2 events dumped to the log file. Run of Trics 9.1-A appears to be doing the COOR stuff just fine and putting in and incrementing Lum Blk Num just fine. Captured 2 events into the log file. It is capturing Monitor data on triggered BX's. When no triggers are flowing then at least from the view point of toy trig mon the monitor pool data is not being updated. Have not tried to Configure from 9.1-A yet. Tried 9.1-B and it also did not update toy trig mon when trigger were not firing. Tried putting delay cables into both the 53 Mhz and the 7 Mhz feeds to the SCL Hub-End 10" cable in 7 Mhz --> Red and Amber LED's ON on all FanOuts 29" cable in 7 MHz --> Red LED ON in 1 FanOut SCL Data is all junk. 10" or 29" cable in 53 MHz --> all OK SCL data is good panic, the 7 MHz clock is very close to being too late. Move the Master Clock SLF from a 5 nsec delay to a 3 nsec delay. This should leave the SLF with enough setup time. Now test the SCL again 10" calbe in the 7 MHz and all is OK SCL data is good 29" cable in the 53 MHz and all RED LED are ON. The switch setting for the 3 nsec delay is sw1 DDUUDDUU sw8. The fancy Trumpeter cable is Trumpeter TWC-78-2. This is 78 Ohm diff Z and has a nominal velocity of propagation of 0.66 Attenuation per 100 ft is: at 1 Mhz 0.7 dB, 10 MHz 2.2 dB, 100 MHz 7.5 dB, 1 GHz 22.5 dB. I had the yellow LED go out on our SCL Receiver once today and it went out once yesterday. I have no idea why - too close to 128 transmitters all sending out 1.2 GHz noise ? Anyway I changed from a normal SCL Serial Coax routing through the patch panel to a short direct route all LMR-200 cable about 10 feet long all inside the rack with 2 ferite torids on it. So far it did not go out this afternoon but that does not mean much yet. Kirsten looked into testing the L1_TRM. The first interesting point is that it has not been tested since the split into the L1_TRM and the L2_TRM. There are at least 3 things to test: setup time of Sub System AOIT's and Gap before the Sub System Strobe Using zero ticks of storage in the FIFO how close can you bring the Sub System Strobe to being just before the next TRM Clk and still have it work (i.e. both the error detection and the AOIT's work) Verify that the AOIT's are actually doing what they should do, i.e. prove that the FIFOing works and does not mix up what bucket the AOIT's belong to. She made a number of special Clock Files to help with the testing of the L1_TRM. DATE: 29-NOV-00 At: Fermi TOPICS: new VXWorks Fritz updated the version of VXWorks running on the clock computer. He rebooted the clock and I ran 1000 loops of SCT without a problem. Also haven't seen any problems when subsystems are running. DATE: 22-NOV-00 At: MSU TOPICS: Run with non-zero Luminosity Blk Num Made a test run of 15 or so events for Amber that included a non zero Luminosity Block Number. By hand we put "abcd" into register 8 of fpga 4 of the Global Disable TRM (Mst 1 Slv 0 Slot 4) and the value "1234" into register 9 of this fpga. This represents a Luminosity Block Number of "1234 abcd" where "1" is the most significant and "D" is the least significant. This is Run Number 106140 and has about 15 events. The last event in the VBD was raw and formatted dumped into the log file at about 11:58 in the morning. DATE: 21-NOV-00 At: Fermi TOPICS: BXHSR delay for L1AL2 and GS counting number of L1 Accepts Do some low rate normal running with FW readout and stop at points and look at all 6 versions of "event Number" that we have in various places as was done last week. Also check the value of the L1AL2 scaler. Check/adjust the BXHSR delay for the L1AL2 and the GS counting the number of L1 Accepts. We would like to HSRO the first slice for which the L1AL2 scaler has been incremented. Therefore, readout older and older time slices until the scaler has not yet incremented, and use the last value for which the scaler had incremented. At a low rate, at the time of HSRO we expect to have 1 event waiting for an L2 Decision so we want the first time slice for which this scaler reads 1 instead of 0. For the GS counting the number of L1 Accepts, we expect the number of L1 Accepts to be the same as the number of triggers as counted by the BSF (assuming the framework is initialized to start with), by Trig Mon, and the Phase 3 Mon Req. It will be one ahead of the L3 Xfer Number as reported by the FOM++ and as seen in the VBD header. For the L1AL2, the current value in the BXHSR is set to 1 by Trics. The scaler has indeed incremented by this time slice. Try BXHSR = 2. For this time slice, the scaler has not yet incremented so BXHSR = 1 is indeed correct. For the GS counting the number of L1 Accepts, Trics currently sets BXHSR = 1. Trig_Mon Value of Display L3 Trans Value in the Trig FW Data Block of Number of Phase 3 Number ------------------------------------ Times this Mon Req in the "BSF 12x FOM++ Gtd SM #1 Trig Fired L1_Acpt VBD Header Evt Num" L3 Trns Num M123B-19 ---------- ------- ---------- -------- ----------- --------- 2 0x2 0x1 0x2 0x1 0x1 This agrees with last week's observations. Now set BXHSR = 0. Trig_Mon Value of Display L3 Trans Value in the Trig FW Data Block of Number of Phase 3 Number ------------------------------------ Times this Mon Req in the "BSF 12x FOM++ Gtd SM #1 Trig Fired L1_Acpt VBD Header Evt Num" L3 Trns Num M123B-19 ---------- ------- ---------- -------- ----------- --------- 8 0x8 0x7 0x8 0x7 0x8 14 0xe 0xd 0xe 0xd 0xe 21 0x15 0x14 0x15 0x14 0x15 This is what we want so Trics needs to modify the value it is writing to the BXHSR. DATE: 15,16,17-NOV-00 At: Fermi TOPICS: New T&T Scaler, New FOM++, PreScaler Tests, SCL work, Checking "Evt Num's", Install a "permanent" version of a SCL Serial Coax cable that allows you to plug the Logic Analyzer into any of the SCL FanOut Module outputs. It is labeled L.A. Must be very very careful plugging and unplugging these MCX connectors: pull out by the body of the connector, make sure it is perpendicular to the front panel and centered before plugging it in. Start TRICS 9.0-V and Tick and Turn Scaler version 12.1 5k loops SCT all cards and 3k loops SCT all cards, all tests, all scalers OK LED display now looks OK. When trics wakes up, before the FPGA's are configured, it tries to paint the LED Display and gets errors and these puts red error messages on TCC screen. Test of percentage prescaler Requested Resulting De-Corr DAQ And-Or Rate Percentage L1 Rate Enb Percentage = 47,712.4 Hz ---------- --------- -------------- 1 477 1 11 5248 11 31 14790 31 75 35784 75 95 45327 95 99 47235 99 Checked the signals being sent to Geo Section $32 and $33 for Muon. They look fine, but the Status Cable for GS $33 was not plugged in. Vladimir Podstavko said that GS $33 was not working when they tried it. I made a resistor + connector tester pod to plug into the far in of the Serial Coax cable to check it. It is about 112 Ohms, i.e. you can tell it from 50 Ohms, and it is small enough to still see a 1 Ohm change to verify the resistance of the cables + connections. It is in the SCL spare parts box. The cable looks fine. There are formatted and raw dumps of two events taken at about 7:25 and 7:32 this morning 16-NOV-00. While making the very slow 1/2 Hz run I would pause at times and wrote down the various "indicators" of the event count. (Soon can add to this list the value of the L3 Trans Num that is HSROed from the FOM++) Trig_Mon Display Value in the of the Number of Trg FW Data Block Value in the L3_Trans_Num Times this L1 L1 Accept Count Trg FW Data Block in the Trigger Fired GS #1 M123B-19 "BSF Evt Num" VBD Header ---------------- ----------------- ----------------- ------------ 14 d e d 36 23 24 23 37 24 25 24 51 32 33 32 decimal hex hex hex Made a recorded run # 105850 for Amber. Moved it from d0ola /buffer/buf01/D0Run on to D0mino. Captured a formatted dump of the last event in this run and Kirsten trimmed off the time stamps and we mailed it to her. The 105850.raw file is 76170 bytes long. Our events are $2cf =719 long words long. There should be 21 events in this run . So multiply it out 719 lw/event x 4 bytes/lw x 21 events = 60396 bytes. So what is the difference (15774 bytes). I've heard rummors, "header trailer" type stuff and that L3 adds its own thing that looks like another crate forth of data. In the morning when powering up L3 and issuing a L3 Reset you us "shift default + node 139". For now we have Dean's Status Cable GS# 41 plugged into Status Concentrator GS# 49 because Dean needs GS# 49 to work and does not need GS# 41. The SCL Receiver mezzanine card on the SMT crate at Geo Sect $50 died. It have "stuck" or the wrong L3 Trans Num. It had been working fine for at least a couple of months. It is SCL Receiver SN# 107. In the D0_Config start a little bit of the clean up work. For the SpecTrig_ 104_CFT 105_SVX 106_CAL 107_Muon _SetUp put the .msg content into the .mcf file and put the .msg file into obsolete. Move all 4 of these files to use Exp Group #7 and also move the SpTrg_103_FW_RO in the \scratch directory to use Exposure Group #7. In general I think that we are finished with the whole big pile of SetUp Spec Trig #0 mcf msg files and I think we could move that whole class of stuff to an obsolete directory. Things that we may/will want on TRICS as we get more serious about running. On EXIT, Coor_Configure_FW, and Initialize we may want to start asking, "Do you really want to do this Yes No". Installed FOM++ version 3.1 This is the new version with the 2nd word of HSRO being the value of the L3_Trans_Num Counter. Ran 8k loops SCT all cards without scalers and 5k loops all cards with scalers with 0 errors. Checked that the logic analyzer said that all was happy. Coming out of SCT and with just a single FW Init I ran some events into the VBD and dumped them to check to see that ALL "BSF Evt Num's" were the same. They were not. I thought that I saw this last week and yes it is real. What I saw is: L3 Trans Num = 6 VRB's 1,2,3,4 all THE-Cards all BSF's say BSF_Evt_Num = $38 VRB #5 has its 4 THE-Cards say BSF_Evt_Num = $21, $11, $35, $44 VRB #6 has its 4 THE-Cards say BSF_Evt_Num = $3d, $4f, $43, $19 VRB #7 has its 3 THE-Cards say BSF_Evt_Num = $7, $7, $7 yes VRB #8 has its 4 THE-Cards say BSF_Evt_Num = $3, $94, $11, $9e VRB #9 has its 4 THE-Cards say BSF_Evt_Num = $7, $7 yes Ch #1 Gated SM M123B-19 L1 Strobe count = 6 In all cases, for a given bsf, its header and trailer "BSF_Evt_Num's" were equal. It looks like all three cards on VRB #7 and the 2 cards on VRB #9 had the right BSF Evt Num's. Try looking at one more event. L3 Trans Num = 4e VRB's 1,2,3,4 all THE-Cards all BSF's say BSF_Evt_Num = $80 VRB #5 has its 4 THE-Cards say BSF_Evt_Num = $69, $59, $7d, $8c VRB #6 has its 4 THE-Cards say BSF_Evt_Num = $85, $97, $8b, $61 VRB #7 has its 3 THE-Cards say BSF_Evt_Num = $4f, $4f, $4f yes VRB #8 has its 4 THE-Cards say BSF_Evt_Num = $4b, $dc, $59, $e6 VRB #9 has its 4 THE-Cards say BSF_Evt_Num = $4f, $4f yes Ch #1 Gated SM M123B-19 L1 Strobe count = 4e So everything just moved forward in a rational way. Now do another FrameWork Initialize and all is well with the BSF_Evt_Num's What is going on what should we do: How does SCT trash the BSF Evt Num's to begin with ? Is Amber looking at the BSF_Evt_Num in any of her sanity checks ? If so then there is some pressure to understand this. Is it worth while to do a read only look at the BSF design to see that all looks normal ? Is it just that SCT leaves stuff incrementing and FW_Init resets some cards before others ? Last week I thougth that playing with PreScaler Ratio on the new PreScaler gave me some hard to understand results, i.e. loading a given value that was divisable by 3 or 53 always resulted in zero or 3x rate or something like that. It was just statistics of small numbers. I played a lot with ratios 1000 through 1008. 5 normal values, 3 values that divide by 3, 1 value that divides by 53. ReLoad the PreScaler a whole bunch of times with these 9 ratios and you get the mix of "zero rate" and "3x rate" that you would expect. So I see nothing funny with this. Do some low rate normal running with FW readout and stop at points and look at all 6 versions of "event Number" that we have in various places. Trig_Mon Value of Display L3 Trans Value in the Trig FW Data Block of Number of Phase 3 Number ------------------------------------ Times this Mon Req in the "BSF 12x FOM++ Gtd SM #1 Trig Fired L1_Acpt VBD Header Evt Num" L3 Trns Num M123B-19 ---------- ------- ---------- -------- ----------- --------- 42 2a 29 2a 29 29 97 61 60 61 60 60 181 b5 b4 b5 b4 b4 351 15f 15e 5f 15e 15e Start some work with the SCL Hub-End, trying to read status and such and understand what you can do. In \scratch make vio files to load the Channel Status Registers with all zeros and to read all the Channel Status Registers. The address range bla 480:4b8 and bla 600:638 does not DTACK. I went over to Ted's and he said that is could be the Status Concentrator modules at these locations. Returned SCL Receiver SN# 107 and a second one that I did not know the status of to Ted. Picked up 10 more receivers from him. They are still running tests. Talked with Dean about incomplete events. Look at VRC to VBD diagnostic path cabling. General idea is the VBD thinks it has a Grant and dumps data before the VRC is ready to accept the data. Thursday was big test with 10 crates in readout, triggering from real L1 Muon Trigger, Muon saw tracks, Cal is full and part now has HV On, muon trusses are part way in, much of the day 22 people in the control room. Ran shutdown on becane and pulled it power plugs. DATE: 8,9,10-NOV-2000 At: Fermi TOPICS: Geo Sect $67, DCI files, Master Clock work, Exp Grp PBS Scalers, TRICS 9.0-U, TDM 24 with new PreScaler, looking for ETG "incomplete events", T&T Scaler Wed ver 12 test, TRICS VBD configuration. Exit Trics and startup 9.0-T like we should be running. SCT on all cards all tests 5k looks with no errors. Daniel Mendoza said that he was not getting L2 Accepts on Geo Section $67. Logic Analyzer said the same thing. Both the "L2_Period" signal and the "L2 Accept to this Geo Section" signal were not there. Swap the SCL FanOut Module for GS 58:5F with the one for GS 60:67. GS 58:5F was SN# 010B (the good one) and now is 009B. GS 60:67 was SN# 009B (the bad one) and now is 010B. Finish fixing up the dcf dci files so that we only load each fpga once and so that all the dci file names indicate what fpga designs are being loaded. So: rename the dci file that loads up M123B-19 to be L1AL2_GS.dci setup a file to just load the Global Disable TRM card so that we do not over write trm fpga's with shed's. this is Glb_Disable_trm_shed.dci L1Bz_foml.dci becomes L1Bz_foml_miguel.dci fomppl.dci becomes fomppl_miguel.dci eg_aonm.dci becomes eg_aonm_miguel.dci Delete all old no longer used forms of these dci files. Did a full FPGA configuration and the count was 1429 configured with zero errors. 3 FM_Latches at 5 FPGA's each = 15 L1_Helper, SCL_Helper, L2_Helper at 1 FPGA each = 3 1429 - 18 = 1411 and 1411 / 17 = 83.00 So this now looks OK. Steve Chappa was at D-Zero on Wed afternoon. We are now running different PCC and Sequencer modules. These are modules that have just been tested and calibrated over in his lab. We are now going to routinely run with the Sequencer in SYNC mode (i.e. the Sequencer is obeying the Sync input that it gets from the PCC) and the PCC is in Free_Run mode (i.e. the PCC is not obeying it TeV_RF and TeV_Beam_Sync inputs). I think this is Version 33 of the Clock file and it is currently the one that gets loaded with the processor in the clock crate wakes up. Kirsten please confirm this. The LED's that you should see on are: PCC shows just the FreeRun LED Sequencer shows: BC_Phase and MCLK_MISS in red, Low Parity & High Parity in green, CLK_ON, Output_Enabled, SYNC, GPA On & Sel all in yellow. Note that after power up you will have to press the front panel "clear errors" button or else there will be additional LED's on. We also tried running with the PCC locked to TeV_RF and TeV_BS but the PCC was once in a while saying that it had not exactly done 1113 cycles before its next TeV_BS pulse arrived. The clame was that they were doing RF studies at the time and that caused the problem. So we need to test this sometime when the TeV is known to be providing stable signals. To switch to this mode I think we need to load version 34 of the clock file which will put the PCC in Normal mode. Thur Made an initial check of the Exposure Group Per Bunch Scalers. All look OK except for the upper half of Expos Group #3 PBS (as Philippe had seen earlier) Setting up the Exp Groups to pay attention to just the Accelerator Live BX AOIT = 243 one sees the proper set of PBS scalers increment, i.e. 7, 10, 13... 37, 40, 60, 63, 66... 90, 93, 113, 116, 119... 143, 146. I looked carefully at the values in Exp Grp PBS for Exp Grp #4, #5, #6, #7. in all 4 of these the value for Tick #25 was 22 or 23 less than the values shown for the other ticks. Tick #25 stayed this same fixed amount behind the other ticks as the value for the other ticks grew from 10 million to 20 million. So how did it get behind and then stay behind ? The detailed timing of the Exp Grp enable signals to the Exp Grp PBS must be OK because the count in the PBS scalers that are one Tick either side of the ones that should increment, never incremented. Put in TDM ver 24 and start TRICS 9.0-U See some SCT errors: loop 50 Terms 0:3 read ffff instead of dfff bit value 2 50 48:51 fddd dddd bit value 2 51 48:51 d555 5555 bit value 8 pass 1k loops three times, init loop 65 Terms 48:51 read ffff instead of 7fff bit value 8 33 48:51 f9bb 99bb bits value 2,4 106 48:51 fbaa bbaa bit value 4 Increase the cable delay in the cable taking the L1 Fired Strb from the FOM++ to the FanOut box by 1 or 2 feet. Run 5k loops of SCT without error. Well this can not be the permanent solution (because in fact the problem must somewhat center around the few lines in the L1 Fired Mask that have problems) but this is running well enough to let us see if there are other issues. Look at the Terminator resistor because I think it spans 4 differential signals. Try the PreScale Ratio stuff. Yes, values that are evenly divisable by 3 or 53 (the factors of 159) are going to give you problems. Some walues appear to give 0 Hz and others to give 3x what you would expect. Need more testing because this can not be deterministic. Try to start understanding why you can not run above 10 - 15 Hz before L3 starts saying "incomplete event". 1. The ETG says "incomplete event event num xyz" and for the same event the VRC says I never saw an "event num xyz". 2. Jae runs until the ETG says "incomplete event event num xyz" He then prints out events xyz-1 and xyz+1. I look at these two event printouts to see what our BSF event num did. Yes it did increment by 2 in going from xyz-1 to xyz+1. So the Trig FW did build a readout block for event num xyz and send it to the VRB's. 3. Daniel Mendoza made a VRBC that is guaranteed to buffer only a single event, i.e. it goes L1 Busy with the arrival of L1_Accept and it stays L1 Busy until the VBD says "Done" for that event. What you kind of see is that it will run at 15 to 18 Hz for a minute or so, then there will be a mistake and this causes L3 to be waiting around of something and you continue to have more mistakes and to get out of this you need to prescale yourself down to 1 Hz or something and then you can crank back up to 15 Hz. 4. Set up the logic analyzer in state mode so that it only captures data on the falling edge of Clk_7 when L2_Period is HI and it only captures the L3 Trans Num. This lets us capture a bunch of these before it fills up, i.e. a long record. Now run at a high enough rate to be getting "incomplete events" at a significant rate, stop, look at the ETG log and it says that events: $e657, e715, e722 are not there. Look at the logic analyzer and YES the Trig FW did issue L2_Accepts for these 3 events. 5. Same stunt as above but we use the VMEMetro to watch the L3 transfer number read by the VBD. Daniel Mendoza setup the VMEMetro was so that it captured the VME cycles where the VBD was reading the L3 Transfer Number from the VRBC. We ran at high rate and then stopped. Reading the ETG log we found two events marked "incomplete events", L3 Trans Numbers F96A and F998. Checking the VMEMetro we found that the VBD had read both of these events. Fri Verify that the Master Clock would power up OK. Working as robot under control from MSU, get the auto startup working again on TCC. All this because we know there are two up comming power outages - the first is this coming Monday. Try the new T&T Scaler version 12_1. It electrical outputs look OK from the point of view of the logic analyzer on the SCL Cable. L1 BX # $01 goes with Current BX # $1B. A test trigger firing only at Tick_Select_#0 fires at L1 BX # $18 that goes with Cur BX # $32. All of these numbers are the same as with the version 11-1 that has been running for some months. But 12-1 does not work with SCT. SCT does not see a difference between the two time zones of 26 like it does with version 11-1. Rather is see some hudge difference like 200 million or something. All that was supposed to change was the HSRO readout order so we think that SCT should still work. Did what data is in what monitor readout register also get changed. We still need T&T Scaler HSRO readout format described in its FPGA document. Go back to version 11-1 No test made to verify that 12-1 can properly FIFO L1 Trig Nums to the L2 Decisions. Run 5k SCT all cards with scalers 1 error (still need to study this one). Run 5k SCT all cards without scalers no errors. Test of the "new" TDM pre-scaler running in shift register PerCent mode Pre- De- Pre- De- Pre- De- Scaler Corr Scaler Corr Scaler Corr Percent DAQ Percent DAQ Percent DAQ Request Enb Request Enb Request Enb ------- ---- ------- --- ------- --- 1 % 1 % 8 % 7 % 15 % 13 % 2 2 9 8 25 22 3 3 10 9 50 44 4 4 11 10 75 66 5 5 12 10 90 79 6 5 13 11 95 83 7 6 14 12 99 87 OK while I was randomly poking around Philippe spotted the pre-scaler percentage problem. While working looking for the loss of events at high rate I by hand clamped the VBD down to reading out only 1 VRB. We then could not return to normal running. What is wrong. Finally, OK the VBD is not setup correctly. The code that TRICS is using to write the list of pointers to the Word Counts is writing to address $6100 and it needs to write this to $7000 i.e. the Word Count list is at VBD base address plus $1000 (not plus $100). The list of address where the VBD will read data from is stored at $7800 i.e. VBD base address plus 1.5 K. The file scratch\obsolete\L1FW_Readout\ Init_9_VBD.vio is correct. So how has the worked for the past month or so ? TCC has been writing the VBD configuration to "do nothing" address space within the VBD, that the VBD DTACKed, and the VBD has been living on the configuration lists in its battery backed up configuration memory. DATE: 7-NOV-2000 At: Fermi TOPICS: SCL G.S. 0x67 Yesterday Daniel Mendoza complained that they saw L1 A but no L2 on G.S. 0x67. This morning I plugged the cable feeding the logic analyzer (normally plugged into G.S. 0x2) into the spigot for G.S. 0x67. I saw L1 Period and L1 A but neither L2 Period nor L2 A. I did see the L1 Qual/L3 Xfer number and L1 Tick/Turn change at the time when I expected to see the L2 decision. Also, G.S. 0x66 (part of the same trigger) appears to be correct. The L2 Period signal is sent to the Hub Controller via one of the wide ribbon cables and then passed on to the fanout modules. The L2 A signal which is specific to a given G.S. is instead sent to the appropriate transition module. That is, the two signals which are missing come from different places and are on different cables. The suspicion is that there is perhaps something wrong with this channel of the fanout or this particular transmitter. DATE: 25,26,27-OCT-2000 At: Fermi TOPICS: Hub-End SCL Cabling, Material to Fermi and back to MSU, Power Pan is back, TRICS 9.0-T SCT HSRO Test, test L1 Qualifiers, Mike Utes test SCL Cable and mcf file, Cabling to the slot #19 scalers Finally actually get the cables installed for the routing of the L1 Qualifiers and L3 Transfer Number to the front of the 16 SCL Fanout cards. Everything is now cabled as shown in last weeks note. The only exception is that Fanout card $78:$7F is still not connected (but we do not plan to use those Geo Sections). It is 5 flat sections of the 24" Twist and Flat to connect the $40:$7F section. Tested this cabling by verifying that I could see 0,1,2,4,8 on the lowest 3 digits of these 16 bit numbers. DAQ is running OK so I believe that all these connections are OK. Brought a SM card to Fermi (SN# 48) and brought 2x HSROCB cards to Fermi. These are HSROCB's SN# 61 and 62. This gives us the following Trig FW spares in the spare cards cabinet at Fermi: 4x Gated Scalers Modules (Blue front panel) SN# 1, 48, 52, 55 1x FOM build "B" SN# 9B 1x FM SN# 02 2x HSROCB SN# 61, 62 Note that slot #18 of M123B also has a Gated Scaler Module (Blue front panel) in it that is currently not being used by TRICS. It is Scaler Module SN# 57. Bring back to MSU the following Run I spare stuff that was just taking up space in the Spare Cards Cabinet: 1x Zeller pVBA "Zeller to VME adapter" with 4 slot VME backplane and power supply and cables. 2x DRV11-J's 2x Hydra MSU SN#4 Ariel SN# 7047 and MSU SN#5 Ariel SN# 7040 1x Fancy MVME-214 MSU SN# 13 1x MVME-214 MSU SN# 10 1x Ironix MSU SN# 7 1x Motorola MVME-135 MSU SN# 2 1x Term Select P2 Paddle Board from L1.5 CT 1x VMX Driver MSU SN# 4 This removes the last of our old process and VME equipment from Fermi. All that we have left there is one MVME-214 memory module without a front panel to use as an initial target when getting VIPA crates and vertical interconnects and such running. The MVME-214 SN# 10 was pulled out of TCC's Communications Crate. Power Pan SN# 11 appeared on the kitchen work bench. L2 still has Power Pans SN# 8 (sitting on the 2nd floor L2 test area) and SN# 2 which is at UIC. SN# 11 was the one that was assembled in a panic rush for Nikos and it did not have all its varistors installed. I tested it and they had blown the fuse in the monitor line of the +5V supply. I replaced it with stuff I had here and put it back in M101 which is I expect its permanent home for now. Tested TRICS 9.0-T and the HSRO Test. There are a number of formatted event dumps in the log file. The .dci file that loads the SM in M123B-19 was edited so that L1AL2 no longer overwrites and existing SM FPGA. At powerup TCC now says 1441 FPGA's loaded. I'm not quite sure how to make N x 17 = 1441. Both SCT and HSRO appear to be working OK under 9.0-T. Most of the time was spent in HSRO and just a couple of thousand loops of SCT. HSRO ran for about 6k loops or about 1 hour. It was just left with the default 500 milsec delay before reading the VBD. There was possibly some issue about reseting the BSF Event Number. After loops of SCT the BSF Evt Num is scrambled up. I kind of thought that one FW Init did not always get all the BSF Ent Num's back together but that two FW Init's always did get all the Ent Num's from all the BSF's back in sync. I need to check this some more. Tested to see if setting L1 Qualifiers (via the COOR commands menu in TRICS) was working OK. Yes everything appeats to work. I only tested the first half so far, i.e. L1 Qualifiers 0:15 as watched from a Geo Section in the 00:3F range. Watched on the logic analyzer and all was OK. Set up a temporary SCL cable run up to the 3rd floor electronics area for Mike Utes to work on the Sequencer Controller. This is plugged into Geo Sect Num 0 right now. In the scratch directory there is a file called Setup_103_ Mike_Utes.mcf I have not connected this to a push button but for now have just left this in the Master Command File "file selected to execute" selection. This is a back door trigger that does not include Geo Section 127 and CFT appeared to be running fine with this also going. It runs at 0.5 Hz. Made a temporary cable connection from the L1 Fired Strobe FanOut box to the Gated Scaler in Slot #19 that counts the total number of L1 Accepts. This is just a temporary setup and needs to be put together with the other cabling to the other scalers in slot #19. Exit Status. We are running TRICS 9.0-T but I forgot to update the note on TCC's keyboard saying which version of TRICS to run. I did not get the new version of the Master Clock program tested on Friday. This is a version that just switches the PCC from Normal to FreeRun mode. DATE: 25-OCT-00 morning At: Fermi TOPICS: HSRO and SCT Try putting the GS and L1AL2 FPGAs into the TTS (M123-B 21) to try and determine if the problem seen last week is hardware or FPGA related. The problem is seen when the L1AL2 is loaded into the first 14 FPGAs (the last two continue to have TTS so that TrigMon works). Discover that the constraint file for the L1AL2 FPGA has the HSRO pinout constraints commented out. Uncommenting these lines and running the design through the Xilinx design manager again produces an exo which works just fine (l1al2_3_2). Switch to Trics 9.0 S. This expects 8 miguels in the EG AONM and L1 FEBZ FOM and also the GS and L1AL2 in M123-B 19. SCT now works for all cards. Run 60,000 loops on the whole L1+L2 FW No Errors. Puzzling observation: We had difficulty doing the simple test of just switching all/some TTS FPGAs over to GS or L1AL2 Fpgas. HSRO immediately stopped working with either GS or L1AL2 Fpgas. Same symptoms again if we left TTS Fpgas in sites #15 and #16 and loaded GS or L1AL2 Fpgas in sites 1-14. TrigMon was not showing GeoSect #31 100% L1 Busy, and also the Andor Fired rate of the Spec Trig #103 that we were using was frozen (!!), BUT the Tick and Turn Scaler was clearly incrementing. We then realized that manually configuring FPGAs leaves the target card in a "Disable ECL Output" state (that state is normally changed during initialize in the standard scenario). Explicitely requesting that the ECL output be enabled in the FPGA configuration menu solved the HSRO problem, but the puzzling fact is that it ALSO cured the Andor Fired Rate. So it seems that having the TTS Scaler Card ECL output disabled prevents the proper operation, capture, or monitoring service of the Spec Trig Andor Fired Scaler. That's NOT understood. Other discovery: HSRO Formatted dump now compares the Event Number from each THE-Card BSF Header/Trailer Data, and they do not all match. This may be the first time we look into this. Philippe investigated TRICS operation, and the BSF scalers are currently NOT reset during initialization. This may be enough to explain the discrepencies. Trics will be upgraded, and we can check again. Weird mode where HSRO is stuck: After running the 60,000 loops of SCT HSRO was stuck in a way that the regular sequence of VRB Crate Initialization called from the HSRO Test Menu did not cure. Nor did pushing the Reset button on the VBD. It took a full Initialization and running SpTrg #103, running some loops of SCT, then returning to HSRO Test to clear it up. It is not undestood what was wrong, or what was different before vs after. Run 100 loops of HSRO Test with default wait of 500 ms for VBD. No Errors. With VRC cable unplugged from VBD, Kirsten determines that an apropriate delay for HSRO Test to wait for the VBD may be around 250 ms. DATE: 18,19,20-OCT-00 At: Fermi TOPICS: HSRO, Scaler Card in M123B-19, Master Clock, Cabling for the SCL Runs 104008 and 104009 for Amber with Spec Trigs 103 and then 53 (plus 0). bring 80 more LMR-100 MCX connectors to Fermi Work on cabling of the L1_Qual-L3_Trans_Num from the FOM++ to the SCL Hub-End FOM++ MSA_Out 15:0 Get this from FM-Latch SCL Hub-End Pass-Through MSA_In 127:112 FanOut Cards M123M Slot 20 M123B Slot 19 for Geo Sect P3 P3 $0 : $3F Terminator +--+ +--+ +--+ +--+ | | | | | | | | +--+ +--+ +--+ +--+ | 1 sect | | 4 or 5 sects | | 1 sect | ----------------- --------------------- ------------ FOM++ MSA_Out 31:16 Get this from SCL Hub-End Pass-Through FanOut Cards M123M Slot 20 for Geo Sect P3 $40 : $7F Terminator +--+ +--+ +--+ | | | | | | +--+ +--+ +--+ | 5 sect | | 1 sect | ------------------------------------------ ------------ In Init_Post_Auxi.rio and Init_Post_Auxi.vio Kirsten has added calles to files in scratch to startup readout of the slot 19 M123B scaler card (specifically the L1AL2 card). The files called in scratch are L1AL2_Setup.rii and Init_GS_VRB.vio. These calles are commented out because starting with TRICS 9.0-Q this should all be taken care of by TRICS. We can remove these calls from Init_Post_Auxi in a couple of weeks. Steve Chappa was here to work on starting to get the Master Clock running. There are 10**9 various modules in series with the two important signals TeV_RF and TeV_Sync. This NIM stuff is in both the Accelerator rack in the control room and another crate full in the Master Clock rack. We want to change running the Master Clock Sequencer from Freerun Mode to Sync Mode. The PCC remains in Normal Mode. Kirsten made a new executable. The instructions for loading / backing up are Log on as trgmgr to d0ol02 i.e. ssh -l trgmgr d0ol02.fnal.gov ~trgmgr/master_clock/config_files/clkSetup.v27 is currently running ~trgmgr/master_clock/config_files/clkSetup.v28 is same but with the sequencer in sync mode type cdboot (exactly as it as written - it's an alias) you are now in the boot directory for the clock copy clkSetup to clkSetup_works (or something else) you need to copy v28 to clkSetup and then whack the clock if needed recover either by copying v27 to clkSetup or by copying clkSetup_works to clkSetup What I did was: Found clkSetup to be from 23AUG00 and copied it to clkSetup_saved_20OCT00. Then copied ~trgmgr/master_clock/config_files/clkSetup.v28 to clkSetup. OK the software part of this worked (after Fritz updated our vxworkds and epics stuff but that was good to do because we could not have loaded the clock at all without updating this stuff). But the hardware is not working in Sequencer Sync Mode. So clkSetup goes back to the version that we had been running. There were at least two hardware issues. 1) Either the Sequencer does not work in SYNC mode or else the PCC was not giving the Sequencer a good SYNC signal. 2) Besides the once per revolution glitch that we are stuck with, we also get glitched a number of times during Shot Setup and such as the TeV changes their clock. Even if we walk around these problems by putting the Master Clock into FreeRun we will get at least one Glitch as the clock moves to SYNC Mode. The muon push button trigger (Spec Trig 107) was modified to give them just the Geo Sect that they wanted this week and to fire at a fixed point i.e. Tick Select #0 AOIT 251. And it does not include Geo Section 127 so in principal it does not talk to L3. This is now setup the way that Sten needs it for his alignment work. Note that last week Dean's Cal push button trigger was also modified to not include Geo Sect 127. So far it looks OK running these with other data taking triggers e.g. CFT. Edit dci files to get ready to run TRICS 9.0-Q Go from 4 to 8 Miguels in the two AONM Exposure Group cards and in the L1 Busy FOM. The L1 Busy FOM was given its own dci last week. Note that the FOM++ remains at 4 Miguels and that the M123B slot 19 SM card was already setup to get 1x L1AL2 at site 16 and 15x Gated SM at sites 14:1. There are problems when we try to HSRO the slot 19 gated scaler module with the L1AL2 and the 15x Gated Scalers. This does not appear to work with either TRICS 9.0-R or by using the scratch L1AL2_Setup.rio and Init_GS_VRB.vio files. This is the first time that we have tried to HSRO from either: a L1AL2, from a Gated Scaler FPGA, or from this Scaler Module. Ideas for testing include: put a Gated Scaler into the slot 20 Tick & Turn scaler card (we know that card does HSRO alright) put 16 gated scalers into the slot 19 card. The 20 LMR-100 cables with MCX connectors look fine. Give them 32 more cables and 40 MXC connectors. Exit Fermi with the Master Clock running the software that we had been using. Exit with TRICS running 9.0-P i.e. the version that had been in use this past week. DATE: 11,12,13-OCT-00 At: Fermi TOPICS: HSRO work, SCL Cables, Backup Becane, Work on Miguel FPGA, Tests with Dean and Calo, Change the test HSRO 103 trigger mcf. Put the blank front panel with the "window" next to the VRBC so that you can see the LED's on the SCL Receiver (and still control the air flow) The special 13 stage History Shift Register in the Miguel appears to have been the problem with the Miguel. Replacing it with the standard HSRO block that is used on the other cards and Miguel comes to life. With the non-working 13 stage History Shift Register we DID continue to see hints that signals that were asserted for a long time did register (e.g. AOIT 255 or the Gap AOIT's) but that short signals (e.g. live crossing marker) do not register. We will not try to fix the 13 stage register right now. It is not clear that it is needed at all. L3 is dead on the first floor. It says, "Crate #31 (0x1f) is attached to VRC D0L3VRC1A; but that VRC is not connected to the supervisor right now!". There is some problem with the network. Brought 20 of the LMR-100 MCX connectors to Fermi and Rick is getting the cable people to start rework on the patch cables. They now make center pins that stick out 1/4" oh now they broke off 2 of the other ends. Oh 4 or 5 of the repaired cables are complete junk (and non are correct). Return them for a third try. Need to look up the cost for manufacturred cables. Visit on Thursday from French people who want to work on Cal Trig upgrades. Jerry Blazey brought them over. Jean F. Renardy was one of the people and Michel Mur was the other person. Full tour. Jerry thinks that Michel Mur is head of electronics or something like that at Saclay. I encourage them to complete a new L1 Cal Trig before the start of Run II. Need to send a note to Maris. L3 people have trouble getting the VRC on the 1st floor running. While it is stopped, i.e. not giving "Grants" to the VBD I see that VRBC does not give us a L1 Busy. Talk with Daniel Mendoza about this and show it to him. He will work on it over the weekend. He thinks that the other VRBC in use are doing the right thing and that this VRBC may have a hardware problem. Decode some more stuff about how the VBD's read parameters are setup. Take off the top 2 bits from the byte. what you have left is just a standard VME Addressing Mode value. The top two bits are decodes as follows: 0 -> ZRL default, 2 -> D32, 3 -> D16. ZRL default says something like: if it is a A24 access mode then do a D32 and if it is an A16 access then do a D16. So now we can decode the non-documented access methodes that Daniel Mendoza said we should use to get the VBD to readout the VRB's. It is using block transfer block mode to read the the VRB Data. Daniel used the modes what Gennady Briskin told him to use. He tested some other combinations and they do not work. Made a single user dumpfs backup of Becane. Learn that from the root account you need to explicitly give the directory to run any script from any directory. This is not a special property of the root directory but rather a security issue for the root account. Made a run, run number 103795. It has about 60 events. The first at least 41 will be junk. The last 10 should be good. I moved it to D0mino in the Laurens account. file name run_103795_good_evts_at_end.raw directory /RunII/home/room3/laurens Changed Dean's Calo Spec 106 Push Button Trigger to get him Geo Sect $48 and to look for his AOIT #31. Changed our setup spec trig 103 FW Readout test mcf so that we use tick select #0 and thus always fire at the same place. DATE: 4,5,6-OCT-00 At: Fermi TOPICS: Work on HSRO, LMR-100 cables, run for Amber, VRB LED, More SCL Fanouts, Jumper wires on the SCL Fanouts, re-cable SCL Hub The LMR-100 cable for Geo Section $66 is bad. The MCX end is not assembled correctly. It looks like about 70% of the LMR-100 cables are bad. Pull out all the currently not in use LMR-100 patch cables so that they can be repaired. They would like Geo Sections $68 through $6B running. Plug these in with what look to be OK patch cables. Plug in their Status Cables. There is some funny problem in HSRO that the data from the FOM++ card gets the wrong Byte Count received by its VRB channels. I have seen both too big a Byte Count and too small a Byte Count. The Byte Counts for the two channels that receive the FOM++ are always the same so it is not something completely crazey. Have swapped VRB's slots 16 <-> 17 and have tried a different G-Link Transition Module and this does not fix it. When it is in this mode of giving the wrong byte count then the pattern of LED's on this VRB (while events are floowing) does not look right and this VRB's SRC LED sometimes flashes even when no events are flowing. You can get it out of this bad mode by SCL Init. What can this be doing ? Sometimes it will also spontaniously cure itself - run fine for a couple of minutes at 1/2 Hz and then go bad again. Now try a different Fiber Optic cable. This does not fix it either. OK plug the FOM++'s fiber optic cable into CH 4-5 of the VRB for the Indiv Disables. The problem moves to where the FOM++ is now plugged in. So the problem is coming from the FOM++. And now it is in a mode where it will not go bad. so. Thur we confirm again that the problem is related to the FOM++ card and not to the VRB, Transition Module, or optical cable. Kirsten dug into looking at the data that the VRB got when the Byte Count was big (typically $22e). There is typically some garbage information before the event. For the first channel, this garbage information is frequently 0xffff. For the second channel the garbage seems to vary a bit more, but still has a bit of a pattern feel to is (e.g. 0x0101 0x0107 0x0f0f). In many cases, once the event appears it looks fine. At least some of the time, though, the event is munged as well, e.g. only the BSF trailer appears. OK perhaps its the HSROCB. Pull the HSROCB SN#48 from the spare Gated SM SN# SM52 and put it on the FOM++ which is SN# 13B. The HSROCB pulled from FOM++ is HSROCB SN# 23. OK so far things look OK. Spent time running at 150 Hz and then pause and look at the last event in the VBD and it was OK Picked up SCL Fanouts SN#: 4B, 9B, 15B, 16B, 17B. There are jumpers that I need to solder onto each VRB are to GND some floating inputs to CMOS FPGA's. The connections that need to be made are: TP5-TPG1-TP6 TP3-TPG2-TP4 TP11-TPG9 TP12-TPG10 TP7-TPG4. Kirsten installed the jumpers so that all 16 Fanout Cards that the have at D-Zero have these jumpers. Completely re-Cable the back of the SCL Crate. All FW to SCL Status Concentrators cables on now in. They probably have to be pulled in sets of 4 to get on out. Need to think about how to make the cables or fanout for the front to connect the L1 Qualifiers - L3 Transfer Number to the SCL Fanout cards. 4 SCL Receivers to Daniel Mendoza. He checked with Marc Bowden about why the LED was on for so long with each event. Basic answer is the LED strecher got switched from x msec to x sec. Work on looking for the proper alignment of data in the HSRO. Move the L1 Acpt Strobe to Capture HSRO Data Delay from a vlaue of 4 to a value of 1 in the L1 Helper. This is 0/2/21/4/reg 9 for HSRO cap reg 10 for cap Mon. Verify that changing the timing of the Capture HSRO Data and the BX History setting in the T&T Scaler do NOT effect the values put into the SCL Hub-End or the match between the L1 Acpt trig num and the L2 Decision trig num. With the L1 Acpt to Cap HSRO Delay set to 1 (you can not set it to zero) we find that typically we need to increase the current value used for the BX History Shift Register by 1. The we check to see proper alingment of HSRO Data. Check: TDM, TRM, FOM++ (except Miguel) T&T Scaler, EG AONM, FOM, PAOF. All this looks OK. Running with a trig that put us at a fixed BX we see the TDM gives $57e1 and $2000 with the Cap HSRO and BX History properly adjust Make a short run to get 15 to 30 events for Amber to look at. log into d0ol03 account d0run pw setup d0online setup coor setenv DISPLAY as necessary taker Made a run of about 15 to 30 events. Structure should all be correct checked the last event in the VBD with HSRO Analyze Event and all looked OK Run number 103628. Moved the resulting file to D0mineo and Philippe sent a note to Amber. 27,28,29-SEPT-2000 At: Fermi Topics: Work on the High Speed ReadOut Move to Trics 9.0 Rev F. This allows a longer (50 millisec) delay between resetting the VRB and reading its status register. Check that FW Init now takes care of all the necessary HSRO Init by running only FW Init after power up (i.e. no special HSRO vio or mcf files). Also check that if the data in the VRB is munged because there have been triggers not directed at our G.S., SCL Init is sufficient to restore sanity. Finally, check that the VRBC now cleans up the VRBs when it receives an SCL Init - once the data is munged, stop the triggers, run SCL_Init.rio (so issue an SCL Init but don't have Trics clean up the VRBs), and issue single triggers to our G.S. Everything looks fine. 21,22.23-SEPT-2000 At: Fermi Topics: Work on the High Speed ReadOut, Drew makes first MTB SCL test, SCL connectors, VRBC concerns. With all of the recent work on the BSF have we kept all of the documentation up to date, BSF description, HSRO data summary, HSRO timing. I need to check for difference between descriptions and what is actually being done. The Hub-End of the Status Cable for Geo Section $1f was not installed correctly and had shorted some number of the diff pairs. In general I need to order more SCL connectors: need Hub-End Status cable connectors (have lots for the Geo Sect End) Need SMA feed through connectors. LMR-100 MCX connectors others ? Running with Trics 9.0-E and testing readout. COOR Init MCF setup spec trig 103 for FW readout in auto dis RIO PiggyBack_HSRO if you want to load up the SHED's on the Glob Dis TRM. This file also puts new values in the BSF header and trailer words that are echoing register contents. But this step is not really necessary because TRICS 9.0-E does load up the SHED's in the Glob Dis TRM. Make sure that the "displayer program" on VRC (vrc_to_console.bat) is ready to run (words to display and event to display are setup). This may have changed since Friday afternoon now that the L3 System knows about the VRB on the first floor MCH. MCF Init_9_VRB This calls Init_VRBC (which is both the D16 and D8 stuff) and this calls the Init_9_VRB and this calls the Init_9_VBD Let the triggers flow either by the autodisable.mcf or seltup a prescale and dump the sutodisable Notes: the last step before starting triggers flowing was to reset the VRB system no other trigger can be flowing at this time or it will clober the VRB's. if the vrc to console program reaches the end of its event count or dies or you grap the slider to look at another part of the display window then it will quit taking events from the VBD and the VRB will fill up and the VRBC will not assert L1_Bz and the VRB will be trashed. The number of bytes that I see being transfered is 2796 Once we get all the word count issues finalized we need to look at this number again. With each L1 Accept the VRBC is keeping L1_Bz asserted for about 7.86 usec. The length of time that an optic cable pumps data into a VRB is about 5.4 usec (assuming 32 words from main array). This can be calculated and has been checked on the logic analyzer. Running the vrc to console display program and making the number of words displayed per event small and you can run up to about 12 Hz before you clober the VRB buffers. I talked with and sent eamil to Daniel Mendoza and Marvin about the L1-Bz and the SCL_Init issues with the VRBC. To work on the Daniel wanted to be able to run on and off triggers and control rate from the 2nd floor MCH that is he know about and wanted VNC. I explained the issues about VNC to him (e.g. don't leave it connected to TCC when you are not using it) and I explained that we don't want other people using it and that we don't want the pass word distributed around. Then I gave him the PW. Well he is a MSU person after all. Our COOR trigger configuration file is "tfw-only" The first run was run number 103228 In getting HSRO running we have built up a big pile of temporary files. For example just this week I made: Load_Sheds_M123T-10.rio rii and Init_2and3of9_VRB.vio. A lot of this stuff is in \scratch and in \rio After we bring HSRO into normal operation over the next couple of weeks let's try to clean out these directories so that we just have in them the stuff that actually runs the system. Can we throw all this development stuff someplace else ? It is nice to keep the development stuff, e.g. to help bring up the L1 Cal Trig readout, but I do not think that we just want it laying around in the running production FW directories. Wednesday afternoon make a special SCL coax to run Drew Baden's MTB tests in the L2 Test Stand area. I forgot to pick up this cable when he was finished on Friday afternoon. Issues with MTB wrt SCL: wrong connectors (stand too high), foot print to far forward 3/4" or so, tested only in the sence that it made output that want to the logic analyzer. 19-SEPT-2000 At: Fermi Topics: BSF for 4036XLA New Trics 8.9 H should be able to handle the different size exo for the 4036XLA part so switch BSF_4036XLA.dci to use BSF 25_2 and try configuring the framework. That works just fine and SCT runs 1000 loops without a problem so we are currently running Trics 8.9 H and using BSF 25_2 in the 4036XLA BSF FPGAs. 13,14,15-SEPT-2000 At: Fermi Topics: Work on the High Speed ReadOut Made a test of what happens when we dump data into the VRB without ever giving the VRBC a L1 Accept and then later try running in a coordinated way and reading out our data. Our data will be screwed up and it will remain screwed up for ever as far as I can tell. You might think that as soon as the trashed buffers were readout that our data would then start to look OK but that does not appear to happen. You need to reset some combination of the VRB and VRBC to get things running again. I still need to work out exactly what needs to be reset. But just resetting the VRB's and VRBC does fix the problem. From last week. Learned from Dean that at high event rate we should expect the Bus Error LED on the VBD to glow just a little. This soft glow is normal for the Run II VBD. If the VBD actually sees a bus error then it will latch on its Bus Error LED. Used a G-Link Transition Module with the logic analyzer to look directly at the G-Link data from the Global Disable TRM card. There is a new pod setup on this Transition Module and a file in the logic analyzer that goes along with it. You now get to see all 16 data bits and D16:D19 individually and DAV* and strobe. Various files for Initializing and running the HSRO. Most of these are in the scratch directory on TCC. Init_VBD inits the VBD to read out the first 6 VRB's Init_9_VBD inits the VBD to read out all 9 of the VRB's Init_VRB inits the first 6 VRB's and turns on only Ch 0 & 1 of the VRB in slot #8 Init_9_VRB inits all 9 of the VRB's and turns on all the VRB channels for the full readout of all THE-Cards Init_1of9_VRB inits all 9 of the VRB's and turns on only Ch 0 & 1 of the VRB in slot #8 Init_VRBC does the D16 part of the VRBC init Init_VRBC_D8 does the D8 part of the VRBC init PiggyBack_HSRO.rii Sets up the Shed's on the Global Disable TRM with fixed readout data and sets up the BSF on the BSF on this card so it is ready for HSRO. Initialize_GlobDisTRM_BSF.rio Touches only the BSF on the Global Disable TRM and does everything that Philippe does at FW Initialize. This is in the rio directory. setup spec trig 103 with auto disable to send trigger to Geo Sec $1F enable the auto disable for spec trig 103 Philippe made a file to do everything to the BSF in the Global Disable TRM that he does at FW Initialize time. This file is in the rio directory and is called Initialize_GlobDisTRM_BSF.rio. This files allows you to change the Global Disable BSF configuration on the fly without causing problems. To do so configure the new exo in the Glob Dis TRM BSF, then run Initialize_GlbDisTRM_BSF.rio (which will setup the P1 Timing signal multiplexer and the TRM's and stuff) and then run the PiggyBack_HSRO.rii file to load data into the SHED's and setup the reset of the BSF for HSRO. Thur I have absolutely seen a couple of time that after going through are full normal init process that we still have a L1_Busy from our VRBC. This does not always happen but I'm 100% certain that I have seen it a couple of times. We still need to continue learning how to init all this VRBC VRB stuff from no matter what state it is in. When it is stuck 100% L1_Busy for some reason pulling off the Status Cable from the front of the VRBC so that the FW does not see the Busy so that you can get the FW to send one trigger to our VRBC some how this clears the problem. You can reconnect the Status Cable and then all runs fine. As part of the init process we should try some SCL_Init stuff. I have now done this and it does NOT fix the above init problem. More coments on the Init for HSRO running problems. The only problem with HSRO is at Init time. If you start from a DC power up and then: init the VRBC (D16 & D8) init the VRB's and init the VBD what you will most likely find is that Geo Sec $1F is 100% L1 Busy. You can re-run these init files in various orders and throw in some SCL Init's and the 100% L1 Busy will not go away. For what ever reason pulling off the SCL Status cable from the VRBC makes the 100% L1 Busy go away and from then on all works OK. This brings up questions: Do we have the exact same VRBC code as CFT and Si are running ?? I have heard both yes and no answered to this questions. If we have "special" VRBC code that includes a test version of making Busy signals then the probem may be that something is wrong with this FPGA code. e.g. wake up with L1 Busy asserted and only update the state of L1 Busy at the time you get an L1 Accept. If we have exactly the same VRBC code as CFT and Si then what are they doing differently at their init time. What does the VRBC do at SCL Init time ? We hope that it does everything that is required to SCL Init the Geo Graphic section where it is running e.g. clears out and resets the VRB's, clears out it own table of pointer and buffer markers, updates its Busy signals, checks on the VBD, returns SCL Init Ack to the SCL Hub-End. I have ZERO understanding why pulling the SCL Status cable should fix the state of the L1 Busy signal. The SCL Status stuff are outputs from the VRBC and inputs to it. What is going on here ? Rework all the dci file Break out of the dci files the part that configures the Board Support FPGA. This function is moved into 3 new files called: BSF_4013L.dci BSF_4028XL and BSF_4036XLA. In each of the original dci files the appropriate "BSF file" is called via a Call_File: The only 4013L that we are currently running in a BSF position is in the FM-Latch module so it is NOT necessary to have this track BSF development. So as the 28XL and 36XLA files track the development of the BSF, the BSF_4013L.dci file will continue to reference the 20.2 version of the BSF. Also cleaned up the format of some of the dci files and added comments. The exo files that should be referenced in the BSF_40wxyz.dci file are the following: Up until 15-SEPT-2000 Goes in running without HSRO New for HSRO dci File --------------------- --------------- --------------- bsf_20_1.exo bsf_25_1.exo BSF_4028XL.dci bsf_20_3.exo bsf_25_2.exo BSF_4036XLA.dci bsf_20_2.exo no HSRO version BSF_4013L.dci File Left in Use on Goes in Friday night 15-SEPT-00 dci File ----------------------- --------------- bsf_25_1.exo BSF_4028XL.dci bsf_20_3.exo BSF_4036XLA.dci bsf_20_2.exo BSF_4013L.dci 6,7,8-SEPT-2000 At: Fermi Topics: Work on the High Speed ReadOut, SCL Cable Parts from Mark and Ted Pick up 5 more VRB's from Prep and Mark Bowden has put the latest version of code in them that includes the D-Zero Trigger Mode. These are VRB SN# 300, 326, 346, 423, 425. Also picked up 5 more G-Link Transition modules. So now we have 10 of each which should be OK for the Framework HSRO. Looking in the TRICS log file for Thursday at about 17:15 to see a "typical" event as viewed from the VBD's buffer. Steps to run HSRO as things currently stand (all files are from scratch): Piggyback_HSRO.rio D16 # To setup the SHED's in the Global Disable # TRM which is the card that we readout Init_VRBC.vio D16 # The D16 part of VRBC initialization. Init_VRBC_D8.vio D8 # The D8 part of VRBC initialization. Init_VRB.vio D16 # Setup the VRB Init_VBD.vio D16 # Setup the Zeller module Now just send triggers to Geo Section 1F for example via the Master Command file in scratch called Fix the GS 4A Status cable from Dean-Calo that had been causing a RED LED on the Hub Controller to come on. This Status cable had a bad connector installation at the GS end. So far 2 of these - the other was muon in rack 314. Also 2 bad LMR-100's going to the patch panel. Returned the 6 pre-production SCL FanOuts to Ted Zmuda. These had been in use until 1-SEPT-2000 and typically had about 3 Transmitters installed on each card. So as of this week: the machine of HSRO appears to be working and we now have to fill in the content. Next week need to bring: Tea Klennex plastic edging cable protection strip Kisten and I both saw some funny behavior when trying to run a trigger (from Master Command File) that L1 Spec Trig 103 to send L1 Acpt & L2 Decisions to our Geo Sector $1F with auto disable control. Each time after setting it up the first few clicks on its "give me one more" mcf file caused the Spec Trig to file (as viewed from Trig Mon) but nothing came out on the SCL, no this is an L1 Acpt in this SCL frame and no there is an L1 Acpt for this Geo Section. After a few clicks it would start working just fine. I don't think that software or setup could make this happen. Date: 30,31 Aug 1 Sept At: Fermi TOPICS: TRICS, HSRO, SCL Start running TRICS 8.9 F with old TDM pre-scalers. Get the 5 VRB's back from Mark Bowden. The D-Zero Trigger mode now does not make an end-of-event from >N G-Link fill frames. The VRB header was also updated so that it stays the same as the D-Zero SVX VRB header. Get 11 fully populated SCL Fanouts from Ted. Install these and move to using only the permanent SCL cables. Test things with muon and with CFT and it is OK. This put CFT in their real Geo Section $50. Have note tested with Cal. Give the 9U-6U adaptor and the SCL Receiver Tester back to Ted. Need to learn from Neal-Ted what the Red LED on the hub controller means in detail. Start running the new SCL Logic Analyzer setup. Note that the "unused" odd numbered pins at each end of the logic analyzer cables must not be grounded. One dims the display and the other resets/crashes the logic analyzer. The proper logic analyzer file to run is SCL_VIEW.DAT Nothing has changed as far as what SCL signal is on what logic analyzer pod - channel. Get the VBD adaptor connects from Ed Arko. Get a VRBC from Daniel Mendoza. Careful pulling the "transition module" cards, i.e. G-Link Receivers and the SCL Status Concentrators. With no connector pins at the top, the top pulls out faster and the card can wedge in to its slot. DATE: 31-AUG-2000 At: Fermi TOPICS: new VRB header The VRB Header has been modified to include 16 bits of user data, the firmware version, the slot number, and the configuration id (e.g. is this trigger or SVX mode). Run Scratch/Piggyback_HSRO.rio and then we can check the readout when another system is taking triggers. This does have the issue that events pile up in the VRB Input FIFO, and it's not clear how well they survive this. If the VRB buffer number and BX number are supplied before the run is started, the first event does get through the VRB cleanly, however. With a sample of 1, the header information seems to be as documented: 0x70 total byte count 0x4321 0801 0x4321 is user data, 0x08 is the slot number 0x01 is the event number 0x0828 0002 0x0828 is the firmware version 0x0002 means this VRB is in trigger mode 0x0 TBD, all 0 at the moment 0x0024 0024 channel 0 and 1 byte counts 0x0 channel 2 and 3 byte counts 0x0 channel 4 and 5 byte counts 0x0 channel 6 and 7 byte counts DATE: 23,24,25-AUG-2000 At: Fermi TOPICS: Master Clock, SCL Cables, Mark Bowden, VRB's, TRICS 8.9 Bring mechanical parts to Fermi (Herman Cease) and L2 parts to Roger. Master Clock work. Start using Timing Line #13 for the trigger for the CFT LED Pulser. As planned at this opportunity, the Sub System Gap signal was moved a couple of RF ticks earlier to put it in the proper relation ship with the Sub System Strobe signal. Talked with Steve Chappa. The only Master Clock change will be replacement of the Sequencer module. It will look 99% the same to the software as the old one. Steve Chappa is also eventually going to put a module in the accelerator rack in the control room to (in one place) clean up the TeV RF and TeV Sync signals and to control their drift with the seasonal change in temperatur. Questions from Fritz - how to manage this box and can we get it in VME. Fritz wants a meeting next Wednesday. Finished getting the labels on the SCL Status line on 3rd floor. Routed the cables to the racks in the South aisle (Dean). All the rest has been turned over to Ed to run to the racks. Still need a min of 7 more Status cables to MCH3. Default idea is to make an adaptor board and use standard 50 mil cable. Ted Zmuda now has transmitters in quantity. He will give me at least 5 fully populated Fanouts next Thursday morning. Worked on running with TRICS 8.9_ and Sheds and Megels and TDM ver 24. So far have a problem with getting the L2 Input FIFO to latch in a good mask of L1 Spec Trig's Fired. We have also had 3 or 4 crashes of 8.9 due I think to access violations. In moving between 8.8 and 8.9 one needs to edit the following things: TDM.dci for 8.9 with new scalers must edit the TDM exo from 22 to 24 FOM++.dci for 8.8 comment out the last 4 lines i.e. ative lines 5:8 for 8.9 comment out the upper middle 2 lines i.e. lines 3,4 Shed.dci comment out the bottom 2 lines for 8.8 uncomment for 8.9 M123_Top.dcf for slots 5 & 12 comment out the lower line for 8.8 and comment out the upper line of 8.9 Talk with Mark Bowden. He will remove from D-Zero Trigger mode the >N Fill Frames == End_of_Event. Return to Mark the 5 VRB's that have D-Zero Trigger mode (i.e. SN# 367, 424, 426, 427, 437) for the new software and for the "don't go into JTAG" eco. DATE: 8,9-Aug-2000 At: Fermi TOPICS: Power up after MCH move Stu Fuess shut down the framework, master clock, and TCC and turned off the water on July 30. MCH was back in position Aug 7 but we were advised to wait until Tuesday so that there was plenty of time for the various systems (e.g. water supply) to be checked out. Tuesday afternoon I got the go ahead from Rick Hance. There was some water near the valves under the floor in front of M124, but Rick and Del Miller determined that it was standing water from when the MCH had been drained and was nothing to be concerned about. I restarted TCC, the master clock, and turned on the water cooling for the framework. Within about an hour it became clear that there was condensation on the copper U bends of the radiators. The lights on the air conditioner indicated that it was dehumidifying so it was decided to not turn the framework on and hope that overnight the humidity level dropped. I also turned off the master clock in case it had water issues as well. Wednesday morning the U bends and rubber hoses for the water supply and return were practically dripping. Checked with Rick Hance and the air conditioner hadn't had its water supply (needed for the dehumidifier) returned until about 8:30 this morning. He also checked the temperature of the cooling water and decided that was ok. First order of business was to dry things out. I turned off the cooling water, opened the doors on the backs of the racks, and mopped up as much water as I could. I also found a small box fan and put that in M123 to help increase the air flow. Once things seemed to be dry, I ran the blowers for about 30 min to increase the airflow and hopefully dry up any last little damp spots. I restored the water cooling about mid afternoon. Although it increased the chances for condensation, it was decided to shut the doors to the racks and leave the framework off since this is the typical overnight situation, and we wanted to be sure it wasn't going to be a problem. After about an hour there were no signs of dampness anywhere so I turned the framework on. Everything configured just fine, and SCT ran 1000 loops without any errors. I then initialized the framework for normal running; the plan is to leave it on for any customers until about 6 this evening. Reiner has agreed to start the framework tomorrow morning. The idea is to have a responsible person check for any condensation that may have accumulated overnight before hitting the power switches for the framework. One of the keys will be removed tonight to make sure no one does anything before Reiner has a chance to check things out. DATE: 27-July-2000 At: Fermi TOPICS: HSRO Test with VRB I finally got some time with the framework this morning to play around with leaving various numbers of FPGAs out of the readout. I'll try to summarize what I saw in a reasonably coherent fashion. For the setup, see 25-July and 13-July. I started out skipping only FPGA 7. That was all fine - byte counts looked right, the data from FPGA 7 was missing, and the rest of the event looked normal. I then skipped 7 and 8, and again all was ok. Skip 7, 8, and 9 and everything is fine. From Steve's HSRO timing note, I sort of expected that we would have problems when we skipped more than 2 consecutive FPGAs, but fine. I got as far as skipping 7,8,9,10, and 11 with everything looking just fine. I then decided to try and come at this from the other side and jumped to skipping all the FPGAs between and including 7 and 16. That did not work. The byte count was off, the data looked ok up to FPGA 6, but then the trailer information was missing. I tried 15:7, got complete garbage, reset the VRB, and then things looked ok for 2 events. For whatever reason, I then tried skipping 15:6. In principle since this skips the same number as 16:7 it should fail also, but it didn't. Maybe including 16 (the last MSA FPGA) makes a difference. Can I skip all but the first and last MSA FPGAs? No. Can I skip all but FPGAs 1, 5 (with TRM programming) and 16? Apparently yes. It eventually became clear that skipping a large number of FPGAs sometimes worked fine and sometimes didn't. For instance, it might look ok for 2 events but then fail on the 3rd. So I went back and tried to figure out how many consecutive FPGAs I could skip and never have it fail. People were starting to get antsy so I didn't have a chance to readout a lot of events for the various different number of FPGAs skipped, but I did try to readout at least 3. Skipping 5 consecutive FPGAs seems to be fine. I never had a problem skipping 5 or fewer consecutive FPGAs. Beyond that, it gets questionable. When I skipped 6:1, I didn't have any problems, but I had earlier seen problems when I only readout 1, 5, and 12 (so the maximum number of consecutive FPGAs not readout is also 6). For the 3 events when I skipped 7:1 I didn't see any errors, but then it was only 3 events. I saw errors skipping 8 and 9 FPGAs, but over the course of the morning there were times I saw 4 good events even when I was skipping 9 FPGAs - it was by no means a hard failure. As is clear, the power to the MCH hasn't yet been turned off. Tomorrow is a possibility. Otherwise it will be postponed until next week. DATE: 25-July-2000 At: Fermi TOPICS: HSRO Test with VRB Modified dcf/shed.dci so that BSF version 22_1 is downloaded at configuration time. That at least allows us to piggyback our readout while other people are using the system. However the Global Disable TRM is still the only card getting the new BSF. Use HSRO_SHED.dcf, HSRO_SHED.rio and the usual 1 Hz triggers with autodisable to again setup testing of the D0 Trigger mode VRB. Technique is similar to 13-July except that there is a new file in the scratch directory called Readout_Event.mcf which issues a single trigger and handles the VRB buffer management. I believe I am seeing the same thing in the VRB as Dan saw on the VTM at the end of last week. I have readout 14 events, and they were all the same (modulo the event number) - same data, same size, nice and consistent. Here is a typical event: VRB header info 0x70 totaly byte count (including padding) 0x0 0x0 0x24 0024 channel 0 and 1 byte counts (excluding padding) 0x0 0x0 0x0 Our data channel 0 0x0404 0000 headers and FPGA 1 (TRM) 0x2021 3031 FPGAs 2 and 3 (SHED) 0x4041 0000 FPGAs 4 and 5 (SHED and TRM respectively) 0x6061 7071 0x8081 9091 0x0001 1011 FPGAs 10 and 11 (SHED) 0x2021 3031 0x4041 5051 0x6061 0400 FPGA 16 and trailers 0x0 padding Out data channel 1 0x2424 0000 headers and FPGA 1 (TRM) 0x2020 3030 0x4040 0000 FPGAs 4 and 5 (SHED and TRM) 0x6060 7070 0x8080 9090 0xa1a1 b1b1 0xc1c1 d1d1 0xe1e1 f1f1 0x0101 2400 FPGA 16 and trailers 0x0 padding Untangling this, I believe we are sending the following headers and trailers: Header 0 0x2404 i.e. word count and event number Header 1 0x2404 Trailer 0 0x2404 Trailer 1 This doesn't exactly match the BSF documentation but I believe is consistent with what Dan saw on the logic analyzer last week. When I first started up, it looked like the event number from the BSF failed to increment one time (that is, I got two events in a row with the same event number), but I only saw it that one time. After 4 events, I "started up" a second time to see if I got repeating event numbers again, but I didn't. My understanding is that the MCH is now scheduled to be closed off tomorrow morning so I will turn off the master clock and water when I go home this evening. If I get more time later today, try skipping the readout of 1, 2, 3.... FPGAs and see if the VRB eventually gets enough fill frames that it declares end of event. 18,19,20,21-JULY-2000 At: Fermi Topics: SCL Cable installation, HSRO Test with Trigger Mode VRB, bring Becane back to Fermi Bring Becane back to Fermi. Leave its "bad" monitor at MSU. It is reconnected to the net late on Thursday. Stefan takes one of the 5 initial version Trigger Mode VRB's for testing of there CFT Trigger stuff. Melony LeDu signed the Social Security form. Deliver a box of L2 hadware stuff to Roger. Route the SCL coax out onto the platform PC19 $ PC20. Currently Geograpic Section 5 is in use; 7, 6, and 4 are unused. Make a setup so that we can use the logic analyzer to see the data coming off of the G-Link Transition Module. The problems seen were: D16 start of event happens at the 2nd word of the header. There is no D19, D17 end of event. There is an extra wide gap between the last word of data from FPGA Site 16 and the first word of the Trailer from the BSF. All of this is fixed with BSF_22_1. So far edit only the scratch directory HSRO-SHED.dcf to use BSF_22_1. Current Logic Analyzer setup for G_Link receiver: Philips Logic G-Link Analyzer Input Receiver Signal -------------- --------------- D0 D0 D1 D1 D2 D2 D3 D3 D4 D4 D5 D5 D6 D8 D7 D9 D8 D10 D9 D11 D10 D12 D11 D13 D12 D16 D13 D17 or D19 D14 DAV* D15 Strobe Started out triggering on DAV* being low. Switched to triggering on D16 going HI. 11,12,13,14-JULY-2000 At: Fermi Topics: SCL Cable installation, HSRO Test with Trigger Mode VRB, Trigger Pickoff Test, Becane murdered Becane was found dead Wednesday morning. It was brought back to MSU Friday night. Got 5 of the Trigger Mode VRB's. This is with initial Trigger Mode FPGA software. These VRB's are serial numbers: ??????. As given to us the switch settings are: S1 all ON, S2 all OFF, S3 keys 1, 2, 4, 5, 7 are OFF and keys 3, 6, 8 are ON. Deliver a box of L2 hadware stuff to Roger. Working with Maris we route all the SCL cables from the holes in MCH2 & MCH3 down into the hub end and get the coax dressed in. They cut the special 25 mil twist and flat cable wrong and thus we do not have enough of it. Instead of 5 spare spools we need 2 additional spools to finish. DATE: 13-July-2000 At: Fermi TOPICS: HSRO Some initial tests of HSRO..... In the Scratch directory on D0TCC1 I have a dcf file which downloads the BSF FPGA and SHED FPGAs (to all MSA FPGAs except 1 and 5 which are used for the Global Disable signals to the TDM). There is also an rio file which writes some data into 2 registers on each of the SHED FPGAs and reinitializes the BSF (explicitly resynchs the optical link for example). My technique has been 1) initialize the framework 2) configure the SHED FPGAs 3) run the rio file to setup the SHED FPGAs 4) use the buttons to init ST 0, run at 1 Hz, autodisable 5) enable channels 0 and 1 on the VRB (in slot 12 so VME address 190c 0000 - this is the VRB in D0Trigger mode) 6) reset the VRB 7) give the VRB a readout buffer number and beam crossing number 8) use the Trics button to issue one trigger 9) give the VRB a scan buffer number and event number 10) check the byte count 11) readout the data from the VRB FIFO This morning using bsf version 20_1 (i.e. bit 17 for end of event but NOT bit 19): The first event following a VRB reset is at least recognizable. VRB header 0x60 this is the expected total byte count 0x1 this is the event number I fed in 0x0 now two unused longwords 0x0 0x1e 001e these are the channel byte counts - I expected 0x20 0x0 now the channel byte counts for channels 2/3 0x0 channel byte counts for channels 4/5 0x0 channel byte counts for channels 6/7 0x404 2021 I expected the first word to be more like 0x400 2021 the 0x2021 is the data 0x400 is header - event number (from the BSF and 4 was correct) from header 0 and in principle 00 from header 1, but... Channel 0 data 0x3031 4041 data, looks fine 0x6061 7071 data, looks fine 0x8081 9091 0x0001 1011 0x2021 3031 0x4041 5051 0x6061 3031 0x6061 is the last of the data, then I expect the least significant bits of the trailer: 0x0004 I think Channel 1 data 0x2020 0000 this is now header and data for channel 1 again the data (0x0) is ok, but I expected to see 0x2000 (word count and then 0) for the header 0x0 data, looks fine 0x0 data, looks fine 0x0 0x0101 0101 0x0101 0101 0x0101 0101 this is data and looks basically ok, but it goes on forever I never see anything resembling a trailer, and the VRB never decides it's finished with this event (according to its status reg) The second event is more messed up 0x30 total byte count is only 0x30? 0x2 evt num 0x0 0x0 0x2002 we have only 2 bytes in each channel? 0x0 0x0 0x0 0x0400 4041 well, 0400 looks like the right header info, but the rest is garbage of course if we only sent 2 words (like the 2 headers?) then the VRB pads each channel data to 2 longwords 0x4041 4041 more padding 0x2000 0101 again the header looks ok here 0x0101 0101 this continues forever The 3rd word then has a total byte count of 0x70, each channel has 0x24 bytes, and the data doesn't really look right at all (e.g. 0x0505 0000, 0x0021 0031) This afternoon I put in BSF v21_1 which includes bit 19 as an end of event signal. That improved the situation. The first event looks much the same, but now at the end of it, the VRB status reg does show that it's finished with the event. The second event is again very short (0x30 total byte count), but the third event looks pretty good. The total byte count is 0x60, and this time each of the channels has a byte count of 0x20. The data is as before (0x0202 2021 with an evt num of 2 even though this is the third event....., 0x3031 4041, etc.) but the last longword from channel 0 this time is 0x6061 0200. I expected the trailer to be 0x0002, but this doesn't look completely random any more. The data from channel 1 is also as before, but the last longword is now 0x0101 2000. The trailer info isn't quite what I expect (0x0003); it does look like word count followed by 0, maybe just coincidence. I tried a fourth event and that looked similar to the third event except that the first word for channel 1 was 0x0, that is I seemed to have no header info (although it was there for channel 0, with an event number of 3). It would probably be helpful to put some flag wires on the VTM so that we can see exactly what our data looks like before it hits the VRB. Also, we need some more tape for the label maker: clear 1/2" have one spool plus a bit, another spool would probably not come amiss but this isn't something we use a lot of clear 1/4" have most of one spool left, this is something we use a reasonable amount so probably 2 more spools white 1/2" I'm not sure this is something we've had before but at least once recently it would have been useful - one spool white 1/4" have only a bit of one spool left, we use this for cables among other things, 3 spools DATE: 3-JULY-2000 At: Fermi TOPICS: testing L1AL2 First check that during normal running (e.g. 1 Hz triggers) the outstanding scaler reads 0 as expected. Now switch to Auto Disable and assert L2 Busy for Geographic Section 0 ( L2BAD 0/2/19/1 Reg 8 write 0x5556). The 1 Hz trigger using the buttons ST 0 Init (Disabled) and ST 0 Prescale (7M) & Enable includes G.S. 7:0 so to inhibit the L2 Accept it is sufficient to force an L2 Busy for G.S. 0. Set the L1AL2 comparators 3:0 at 0x1f, 0x0, 0x7, 0x3. Issue two triggers and read the monitor data register of the L1AL2 (1/2/19/16/12): 0x0402. That is, there are 2 triggers with L1 Accepts awaiting a decision from L2. Also the value in comparator 2 has been exceeded. Release the L2 Busy for G.S. 0 (0/2/19/1 Reg 8 write 0x5555) and the L1AL2 monitor register now reads 0x0. Assert L2 Busy for G.S. 0, issue 3 triggers, monitor register 0x0403 (recall the comparators are greater than only, not greater than or equal to), issue one more trigger, monitor register 0x0504. The output of comparator 0 is now true as expected. Since the output of this comparator is AOIT 240, I ought to be able to see the scaler in the TRM (1/0/2/4/40) incrementing now. No joy. Eventually discover that the ECL outputs from the L1AL2 card have not been enabled. Once this is fixed, the TRM scaler begins to increment. Also, the scaler for AOIT 241 (the output of comparator 1) is not incrementing which is good. Now issue enough triggers to wrap the Outstanding Decision Scaler around to 2 (this scaler only goes up to 0x1f before rolling over), release the G.S. 0 L2 Busy, and check that the scaler ends up back at 0. Finally, set all of the comparators to relatively small values and carefully check that they turn on at the appropriate time. It would also be nice to check that the Outstanding Decision Scaler decrements correctly as the L2 Decisions are issued. To do this, once again start with 1 Hz triggers and switch to Auto Disable mode. Then put the L2 Helper into test mode (0/2/20/4/Reg16 0x1 -> 0x3) so that each L2 cycle must be approved by TCC. Again build up some number of outstanding events using the AutoDisable button. Now allow 1 L2 cycle (0/2/20/4 Reg 16 0x7 then 0x3) and check that the L1AL2 scaler decrements by exactly 1; it does. I continued to approve the L2 cycles one at a time until all of the outstanding events had been cleared out and the Outstanding Decision Scaler once again read 0. This seemed to work just fine. 24,28,29-JUNE-2000 At: Fermi Topics: More SCL parts from Neal and Ted, Get some parts for HSRO, Connection of the L1AL2, D-Zero Trigger Mode VRB, VME accesses during FPGA Configure. Received from Neal: 27 spools of 61 meters each of the 26 conductor flat cable for the SCL Status Cables. These are 200 ft spools or a total length of 5400 ft. This is Hitachi Style No. (Type) 20528 No of Conductors 26 File No. E41447-T. 103 of the connector for the Hub-End of the Status Cables. I believe that these are: Thomas & Betts 311-026302 Received from Ted: 140 (about) of the connector for the Geo Section end of the Status Cables. I believe that these are: Robinson Nugent P25E-026-S-TG 4 more of the SCL Receivers all programmed for zero nsec setup. Install the cables for L2 Helper MSA_Out 24, 25, 28. This provides the feed to the L1AL2 number of outstanding L1 Accepts scaler. This scaler is now ready to test. Its cabling is documented in Single_Signals. Watching the FW Configure at power up it is easy to see when Taka's Monitor data requests start to be honored by TCC. This is soon after TCC has configured the Helper Cards. So when TCC is configuring M123 it is easy to see the VME and LED's flash with the Monitor Data reads. Get from Linn Bagby a final version VRB. Get from Sean Mattingly a Run II VBD, need to get from Ed Arko a J3 backplane for VRB crate and a connector adaptor for VBD to VIPA. Had discussions with Stefan, Fred and Marvin about D-Zero Trigger Mode VRB. Final test after all poking around, passes SCT 2k loops. Bring a couple more yards of hole edge padding plastic strip stuff to Fermi plus all the stuff from last week i.e. a couple of Front_PB cards, cable press, spare PBScaler (Violet front panel) card. DATE: 27-JUNE-2000 At: Fermi TOPICS: No triggers - prescaler and L3 disable There was an attempt this morning to start two runs - one to muon (ST 0) and one to Dean (ST 1). Neither specific trigger was firing. Using Phase3_Toy_TrgMon, it appeared that ST 0 had both L1 FEBZ and L3 Disable so the control room stopped that run. Dean was still not getting triggers, however, and Phase3_Toy_TrgMon indicated that neither L1 FEBZ nor L3 Disable was responsible. Besides the "standard" AOIT (e.g. 255), ST 1 required AOIT 31 which was firing at about 23 Hz. TrgMon said the prescale was 6 and that everything (ST exposed, COOR Disable, etc.) was normal except that the trigger was not firing at all. The Decorrelated DAQ enable was only asserted about 16% of the time, but this corresponds to the prescale of 6. The first issue is that the requested prescale was in fact 5 - it appears that Trics does not correctly account for the n+1 feature of the hardware (i.e. for a prescale of n, program n-1). So why weren't there any triggers? Check the status registers on the TDM: 1/1/11/5 Regs 36 and 37. Nothing seems to be wrong so now check the TRM for AOIT 31 (1/0/10/14 Regs 8, 9, 10) - Dean has changed when he sends AOIT 31, although in principle the data and strobe relationship hasn't altered. Again, things look ok. Go back to the TDM. Now it appears that there is an L3 Disable. Check Phase3_Toy_TrgMon. It does NOT show L3 Disable for ST 1, but it does now indicate that the trigger is never exposed. Tell ST 1 to ignore the L3 Disable, and we're back to the original position - Decor. DAQ Enable asserted (and ST exposed) about 16% of the time. Still no triggers. In desperation, before just reinitializing and hoping for the best, try setting the prescale to 1. Amazingly that starts the triggers. Try a prescale of 6 (7 after the hardware), that's ok too. A prescale of 5 (6 after the hardware) shuts things off again. Finally realize that 6 is not relatively prime to 159 so we are in fact locked onto specific beam crossings which apparently don't coincide with any beam crossings in which Dean is asserting AOIT 31. The control room reinitialized and redownloaded the trigger to return to a known configuration, changed the requested prescale to 6, and now Dean is getting triggers. 20,21,22,23-JUNE-2000 At: Fermi Topics: D0-Workshop at NIU, Change Push Button Triggers to use Geo Sect 127, "Final" fix to the P1_TS Patch Panel, Cable Tray installation, Fuse Blocks on the +3.3V and +5.0V Not having Geo Sect 127 in the Exposure Group definition not only keeps us from telling L3 about L2 Accepts but it also keeps us from incrementing the L3 Transfer Number. Thus we are telling some from end system here are a pile of L2 Accepts all with the same L3 Transfer Number. This bothered Daniel Mendosa enough to make it so this was not worth while. So I edited all 3 of the Master Command File push button triggers to include Geo Section 127. All is happy again. Pulled the P1_TS Patch Panel and connected L2 Helper "Waiting L2 BAD" to M122 Bottom P1_TS_9. This is thought to be the last change required for this patch panel. Updated the documentation for this patch panel and fixed some other problems with it. At the NIU Workshop the plan for L1 Cal Trig is accepted. They understand all the important point (e.g. terms that share Ref Sets). Only open question is where to put the break between Central and North/South in the Region Terms. Need to move to document to the Web. Install the fuse blocks for the bottom crate in M122, i.e. the L2 FW Crate. The idea of the support that runs across the rack does not work. It blocks access to too much of the power pan terminal area and would make it very difficult to swap supplies. The new smaller fuse block supports go on each side of the rack, and some will hang under the diode clamp things. The new Fuse Blocks to go on the side supports are 6 1/4" x 2 1/2". Work with the people trying to get the SVX Sequencer Controller going. They have P1 and P2 swapped for the SCL Receiver. But because of very rational layout by Neal and Ted nothing blows up. Mike moved on order of 9 signals and they are making head way. Things to remind people about SCL: Must reset with SCL_ACK, Loop SCL_SYNCERROR to SYNC_LOST, Zero nsec setup of data lines wrt CLK_7, need to AND L1_Period with L1_ACCEPT to this Geo Section, need to AND L2_Period with L2_Accept to this Geo Section, need to AND L2_Period with L2_Reject to this Geo Section. So Maryland and Drew have not tested or tried plugging in SCL Receiver. It is thought that they have now sent out for production boards. Jim has will pushed on them to make some test. Work on adjusting power supply voltages in rack M122 and check in both racks: +5V +3.3V -2.0V -4.5V ---------===== ---------===== ---------===== ---------===== M122 Top 5.003 -> 5.041 3.334 1.90? -> 2.021 4.374 -> 4.523 M122 Mid 5.018 3.315 2.024 4.523 M122 Bot 4.988 -> 5.053 3.289 -> 3.321 1.943 -> 2.021 4.453 -> 4.524 +5V +3.3V -2.0V -4.5V ===== ===== ===== ===== M123 Top 5.020 3.318 2.003 4.500 M123 Mid 5.024 3.321 2.005 4.496 M123 Bot 5.030 3.354 1.986 4.482 The previous entry for checking the power supply voltages appears to have been 3,4,5-NOV-1999. The stuff in M122 that was way off was way off then too, i.e. it just has never been adjusted. Nothing has chenged very much. I will wait to tune M123 until fuse blocks are installed. Drop across the Fuse Blocks. Measure this in M122 Bottom (L2 FW) drop wire lug to wire lug: 27 mV for +5 17 mV for +3.3 drop fuse body to fuse body: 24 mV for +5 16 mV for +3.3 So all the drop across the new fuse setup for these supplies appears to be due to the fuses themselves and not to the lugs or screw terminals or fuse clip connections. Bring a couple more yards of hole edge padding plastic strip stuff to Fermi plus all the stuff from last week i.e. a couple of Front_PB cards, cable press, spare PBScaler (Violet front panel) card. 14,15,16-JUNE-2000 At: Fermi Topics: Test of TRICS 8.8, Note about P1_TS Patch Panel, Test of triggers leaking out Note that we need to pull out the P1_TS Patch Panel in M122 at least one more time to fix the distribution of the "Waiting L2 BAD" signal to M122 Bot. Are there any other changes that should be made at this time. Start running TRICS 88A and remove everything from Init_Post_Auxi_L1FW.rio (but first make a copy the old file to Init_Post_Auxi_L1FW_pre_88.rio) Edit the L2BAD.dci to move us from L2BAD_1_2.exo to L2BAD_3_1.exo This picks up the L2BAD that has the monitoring scalers in it. Items to talk about before the workshop: Does the list of L1 Cal Trig Terms look the way we want it to ? Should I globally ask/advertize the running the Trig FW without L2 as something that we want controllable from Coor ? Checked on Friday and the cable and connectors to make the 5ft LMR-100 cables are now gone from Kirstens office. Using TRICS 8.8.H I ran SCT for 1000 loops and then FW Init and setup a MCF push button trigger. I did this combination 3 times. SCT was happy. When doing the FW Init after running SCT I DID SEE triggers leak out. L1 Fired and L1 Accept to this Geo Section and L1 Qualifiers were asserted for more than 7 turns on 2 of the tests. On the 3rd test the L1 Accept to this Geo Section was not asserted but the other two signals were asserted. In all cases the first real event sent out after the push button trigger was defined did have poper match trig numbs for L1 Acept and L2 Decision. I have not done a conclusive test to see if triggers leak out during the defining of a trigger.while another trigger is already setup. Recall that in the Exposure Group PBS's we have the following issues: Slot #11 has problems and needs to be replaced <-- verify this number. Slot number 14 just has a bad or disconnected LED. Bring a couple of Front_PB cards to Fermi Bring cable press back to Fermi. Bring spare PBScaler (Violet front panel) card to Fermi. Bring angle brackets to install the cable trays. 7,8,9-JUNE-2000 At: Fermi Topics: New SCL and AO-Term for Muon, Get TCC Pause Resume working, LMR cable tooling Current list of And-Or Input Terms And-Or Input Term Number Current Function - Source ------------ -------------------------------------------------- 0 Copy of the Master Clock Generated L1 Sub-System Gap Signal 1 Cosmic Low Rate 2 Cosmic High Rate and sometimes a Muon Pulser signal 4 Muon Forward Pixel Scintallator test trigger 47:31 Dean's Calorimeter Pulser stuff 95:80 Muon Triggers 240 Outstanding L1's Limit #0 L1AL2 MSA_Out_32 241 Outstanding L1's Limit #1 L1AL2 MSA_Out_33 242 Beginning of Turn Marker SCL Helper MSA_Out_48 243 Live Accelerator BX Marker SCL Helper MSA_Out_49 244 Sync Gap Marker SCL Helper MSA_Out_50 245 Cosmic Gap Marker SCL Helper MSA_Out_51 246 Spare Marker SCL Helper MSA_Out_52 247 Skip Next N #0 FOM++ MSA_Out_40 248 Skip Next N #1 FOM++ MSA_Out_41 249 Skip Next N #2 FOM++ MSA_Out_42 250 Skip Next N #3 FOM++ MSA_Out_43 251 Tick Selector #0 Tick & Turn Scaler MSA_Out_40 252 Tick Selector #1 Tick & Turn Scaler MSA_Out_41 253 Tick Selector #2 Tick & Turn Scaler MSA_Out_42 254 Tick Selector #3 Tick & Turn Scaler MSA_Out_43 255 Permanently Tied HI Changes and Notes about And-Or Terms: And-Or Input Term #4 is new this week. It is wired up at the Trig FW but I do not know if the muon people are sending anything on this wire yet. This is for the Muon Forward Pixel people and is some kind of scintillator. All of this has to be made to work during June because some one who works with it is going back to Russia at the end of June. Technical note: I put this in the 2nd block of 4 in this group of 16 And-Or Terms so we can turn off its "aging" if wer need to. Dean's Run I tpulser test trigger that had been on And-Or Term 224 permanently gone away. Dean now sends us his pulser triggers with the full Run II And-Or Input Term setup (i.e. with Strobe and Gap signals). We temporarely have this pulged into And-Or Terms 47:31. At some point we will have to move him to a more appropriate location. The And-Or Terms 241:240 that are the ouputs of comparators that watch the number of Outstanding L1 Accepts (i.e. L1 Accepts that have not yet had their L2 Decisions distributed). This is connected but not yet fully tested. Current Setup of Geographic Sections: Muon 33 is called FMNS and is on the 3rd floor (51 decimal) 38 is called East CMETP and is on the 3rd floor (56 decimal) 3B is called East CMESC and is on the 3rd floor (59 decimal) Calorimeter 4B is on the 3rd floor (75 decimal) 4D is the Cal 5k Test Stand on the 1st floor which (77 decimal) does not readout to L3 as far as I know SVX 66 and 67 are on the 2nd floor svx (102 and 103 dec) The new Geo Section for this week is 33 the Muon Forward Pixel readout. The person associated with this, and with the new And-Or Term #4, is Evdokimov (I don't know his first name) who can be reached at x2785 or at Evdokimov@fnal.gov Stuff from Ted/Neal 5000 ft of LMR-200 (put in Kirsten's office) 1x Fanout card with 1x Transmitter Ted said that some one had been over earlier this week (muon ?) and picked up 4 SCL Receivers. TCC problem: From the point of view of the control room the TrgMon display had quit updating. COOR had been able to setup a trigger and it was running and events were moving. Look at TCC and it says: "instruction at 0047 efd5 tried to access memory location dddd de59". I assume this is an access violation. I had 10 minutes earlier stopped the toy rates trgmon (by saying bye) and then started a new toy trgmon This was TRICS 8.7 D. Big question from Dean Can COOR tell TCC to bypass L2 Global (I forget if bypass is the correct term). Dean does not want to have L2 in the way between stores and such - so need a way for COOR to tell us to operate the way that we are now (or fancier with mix of L2 Acpt and L2 Rej). People (Jae) wants to be able to run the Master Command File Push Button Triggers at the same time as real COOR Triggers that send data to L3. Can the Master Command File Push Button Triggers be setup so that Geo SEction 127 is not in their Expos Group so we will not talk to L3 about them ? Isn't it just now that Scott is telling TCC about 127 instead of TCC automatically pasting in 127 ? Crimping the LMR Cable for the SCL connections. We have used a standard Kings KTH-1000 crimp set with KTH-2082 dies for the LMR-100 and KTH-2001 dies for the LMR-200 cable. I have used this setup to install the MCX connector on the LMR-100 cable and the SMB connector on the LMR-200 cable. I have not myself installed the SMA connectors on the LMR cable with this setup but I believe that Thinh Pham over in Feynman has made the LMR SMA cables with these tools. Getting COOR TCC Pause/Resule to do anything Global Disable TRM Global Disable 7:0 maps to Non-Correlated Global Disable 3:0 and Correlated Disable 3:0 in the following way: Global Disable 3:0 maps to Non-Correlated Global Disable 3:0 Global Disable 7:4 maps to Correlated Global Disable 3:0 Global Disable 7:0 comes out of the Global Disable TRM on MSA_Out 7:0 and on MSA_Out 23:16. I'm not sure which output is currently wired to the TRM's and which is wired to the Per-Bunch Scalers. All inputs to the Global Disable TRM must connect to the appropriate MSA_In in both the range MSA_In 7:0 and MSA_In 23:16. A special rear paddle board is needed so that there is only one termination on each Global Disable signal. Check all Helper to P1-TS Patch Panel connections and wire up all the spare Helper outputs. "c" means checked. Need to write in the current function (if any) of the spare Helper outputs then copy this to the timing generation and distribution file that is on the web. Source L1 Helper -=------- Wired Through MSA_Out Output Connector To Destination 15:0 ---------------- ----------------------------------------- pins Number Pins Rack Crate P1_TS Signal Name --------- ------ ------- ---------- ----- ------------------ 1 2 c 14 7 8 M122 B 8 Transport HSRO Data 3 4 c 13 3 4 M122 B 9 Capture HSRO Data 5 6 c 15 1 2 not used 7 8 c 5 11 12 M123 B 11 L1 Maginot Line 9 10 c 15 3 4 not used 11 12 c 15 5 6 not used 13 14 c 15 7 8 not used 15 16 c 14 15 16 M122 B 15 Scaler Reset 17 18 c 6 7 8 M123 B 8 Transport HSRO Data 19 20 c 4 7 8 M123 M 8 Transport HSRO Data 21 22 c 2 7 8 M123 T 8 Transport HSRO Data 23 24 c 5 3 4 M123 B 9 Capture HSRO Data 25 26 c 3 3 4 M123 M 9 Capture HSRO Data 27 28 c 1 3 4 M123 T 9 Capture HSRO Data 29 30 c 11 7 8 M122 M 10 L1 Capture Mon Data 31 32 c 9 7 8 M122 T 10 L1 Capture Mon Data 33 34 unused Source L1 Helper -=------- Wired Through MSA_Out Output Connector To Destination 31:16 ---------------- ----------------------------------------- pins Number Pins Rack Crate P1_TS Signal Name ---------- ------ ------- ---------- ----- ------------------ 1 2 c 5 7 8 M123 B 10 L1 Capture Mon Data 3 4 c 3 7 8 M123 M 10 L1 Capture Mon Data 5 6 c 1 7 8 M123 T 10 L1 Capture Mon Data 7 8 c 1 11 12 M123 T 11 L1 Maginot Line 9 10 c 15 9 10 TCC Pause/Resume to Glb Disable TRM 11 12 c 15 11 12 not used 13 14 c 15 13 14 not used 15 16 c 12 15 16 M122 M 15 Scaler Reset 17 18 c 10 15 16 M122 T 15 Scaler Reset 19 20 c 6 15 16 M123 B 15 Scaler Reset 21 22 c 4 15 16 M123 M 15 Scaler Reset 23 24 c 2 15 16 M123 T 15 Scaler Reset 25 26 c 15 15 16 not used 27 28 c 15 17 18 not used 29 30 c 15 19 20 not used 31 32 c 15 21 22 not used 33 34 unused Source L2 Helper -=------- Wired Through MSA_Out Output Connector To Destination 15:0 ---------------- ----------------------------------------- pins Number Pins Rack Crate P1_TS Signal Name --------- ------ ------- ---------- ----- -------------------- 1 2 c 13 19 20 M122 Bot 13 Input_TRM_Read_Enable 3 4 c 3 19 20 M123 Mid 13 Input_TRM_Read_Enable 5 6 c 4 11 12 M123 Mid 14 Send_L2_Decision 7 8 c 6 11 12 M123 Bot 14 Send_L2_Decision 9 10 c 13 15 16 M122 Bot 12 L3_Control_Data_Ltch_Enb 11 12 c 5 15 16 M123 Bot 12 L3_Control_Data_Ltch_Enb 13 14 c 3 15 16 M123 Mid 12 L3_Data_Strb_Inc_Xfr_Num 15 16 c 13 11 12 M122 Bot 11 L2_Maginot_Line 17 18 c 3 11 12 M123 Mid 11 L2_Maginot_Line, not used 19 20 c 13 7 8 M122 Bot 10 L2_Capture_Monitor_Data 21 22 c 8 1 2 not used 23 24 c 8 3 4 not used 25 26 c 8 5 6 not used 27 28 c 8 7 8 not used 29 30 c 8 9 10 not used 31 32 c 8 11 12 not used 33 34 not used To connect TCC's Pause / Resume to Non-Correlated Global Disable #3 TCC's Pause / Resume comes out of L1-Helper MSA_Out_20 which is connected to the Helper P1-TS Patch Panel and appears on this patch panel's connector #15 on pins 9&10 Cable this to Glb Disable TRM input MSA_In_3 and MSA_In_19 We have no spare Front_PB's at Fermi. Need to bring the cable press back to Fermi. DATE: 9-JUN-2000 At: MSU via VNC TOPICS: Continue PBS testing Continue testing the Per-Bunch scalers. Using TRICS 8.7 Rev. C and PBS 11.1. ExpGrp #0 is programmed to veto on AOIT #251, so that all but tick #24 are exposed. We do NOT define a SpTrg to fire to avoid the effect of Skip Next Two. We run a command file that changes the programming of the CommonControlSet #3 from 0xc080 to 0xc088 to make the PBS listen to the Global De-Correlated Disable #3 and thus stop during the mini-pause added by trics while programming the AONM resources. We can now see a consistent set of scaler counts with - one step up at a constant spot - one step down at a random changing spot - a count of zero for Tick #24 - the main goal was to verify that there is no longer a "jitter" in the pattern of scaler counts caused by glitches during programming of the ExpGrp AONM resources. We also change the programming of ExpGrp #1 and the only effect is to add another set of step-up and step down to the pattern of scaler counts for Exp Grp #0. We also change the programming of ExpGrp #0 to require AOIT 255 in veto (and this stops all PBS) then back to requiring AOIT 251 in veto, and again no jitter, but only clean additional steps. The Scaler Count for Tick #24 remains zero during all these tests and we asume the count of 8 we saw yesteday was also due to glitches during AONM programming. We try again to use the COOR initialize command, and this time it properly resets the PBS scalers. It is still not clear why we thought it failed yesterday using the same trics executable and the same PBS fpga design. Looking at yesterday's logfile again did not help. Using Trics V8.7 Rev D, we verify that the Foreign scalers are now initialized to a sensible programming: - Foreign Scaler #0 (numbered 0-9 and counting right to left in the crate) is programmed to follow Common Control Gate #0, Foreign Scaler #1 follows Gate #1, etc. - Every Foreign Scaler Channel #1 is programmed to select Tick #1, Channel #2 selects Tick #2, etc. Trics V8.7 Rev D is left running as the control room takes over without warning... ------------------------------------------------------------------------------- DATE: 8-JUN-2000 At: DZero TOPICS: Connect L1FW pause signal We have discovered that the signal coming out of the L1 Helper which TCC can set to implement the COOR Pause/Resume signal was never connected back in january to the Input of the Global Disable TRM Card and thus could not propagate to the TDM cards as the Global De-Correlated Disable #3. TCC was thus NOT able to Pause/Resume the Framework under COOR's requests, nor around the SCL Initialize action, nor during the mini-pause that Trics adds every time it needs to program AONM or FOM resources. Dan has now wired this L1 Helper signal to the Global Disable TRM Inputs. ------------------------------------------------------------------------------- DATE: 8-JUN-2000 At: MSU via VNC TOPICS: Continue PBS testing Continue testing the Per-Bunch scalers. Using TRICS 8.7 Rev. C and PBS 11.1, do the normal PBS testing set-up (EG 0 VETOs on AOIT 251, so that most ticks are exposed). First just try to scroll through the Per-Bunch Scalers. There should be two discontinuities in the Per-Bunch Scaler values that we cannot avoid. There should be a "step up" corresponding to the first tick for which the Exposure Group was enabled (enabling the Exp Group is not synchronized with the beginning of the turn), and a "step down" corresponding to the Capture Monitor Data also not being synchronized to any point in the turn. Note that the "step up" should remain in a constant place once the Exposure Group is set up, while the "step down" should move around with each new Capture Monitor Data. We see a lot of +/- 1-2 count channel-to-channel jitter in the scalers. We realize that the Skip Next Tick is asserted after each L1 Accept, masking off the two subsequent ticks. We disable the ST from firing and just use Taka's Capture Monitor Data. Once we reset all of the Exposure Group scalers (more on that below) and turn off the ST, we find the "step up" and "step down" that we are looking for. Repeat several times and everything looks fine EXCEPT that Tick 24 (which should never be enabled) shows 8 counts. This 8 counts remains constant over a minute or so. Need to understand this better. The Exposure Group scalers should reset with each FW Initialize. They don't appear to be doing so. We tested the FPGA's (both Force Reset and Synchronous Reset based on P1_TS(15)) to verify that the FPGA scaler reset mechanism is working in those designs. It is. Need to understand why the scalers don't appear to reset at FW Initialize. Continue testing BXHSR depth. For this, we need to turn the L1 Accept flow back on, so that we are capturing data which corresponds to a particular L1 Accept. Also need to set up the Exposure Group to REQURE AOIT 251, so that the ST only fires on Tick 24. Need a high enough rate that we are likely get the "L1 Accept-based" Monitor Data rather than Taka's asynchronous Monitor Data. We select 5 Hz (vs. Taka's 0.2 Hz). If we don't have data corresponding to a L1 Accept on Tick 24, then we can't see the scaler increment differentially vs. the integrated PBS scaler as we scroll through the BXHSR depth. We find that the correct BXHSR depth value is 4, the same as we program to capture the inputs. This symmetry is expected, but Steve still needs to explain the particular value of 4. We still see a lot of channel-to-channel jitter in the scalers following Exposure Group programming. We also see lots of non-zero counts when zero was expected. We theorize that we are just seeing the known issue of uncontrolled AONM outputs during programming. Recall that this is a big deal because programming one Exposure Group affects the outputs for a group of 4 Exposure Groups. There are various ways to solve this problem: (1) force AONM ECL outputs LOW (problem: this affects entire card) (2) use mini-Pause as a disable to the PBS scalers. Philippe already asserts mini-Pause during programming, and it is already routed from the TRM to the PBS. But recall that the TRM needs to get 2 input copies of this signal, either by splitting the cable or by modifying the FW Helper to make a second copy. This isn't done yet so we can't just enable the mini-Pause as a disable. Also need to think about what this does to luminosity measuring. (3) some way we haven't thought of yet. Note: cannot just use an AOIT as part of an EG to do it automatically, because that AOIT is subject to being uncontrolled during EG programming. We then run out of time (the FW is initialized out from under us with no notice). ------------------------------------------------------------------------------- DATE: 7-JUN-2000 At: MSU via VNC TOPICS: Report of Trics problem - The control room reports that Trics appeared to be frozen where (as far as Philippe understood the symptoms described) the ascii output window of trics had been moved by somebody to occlude part of the dialgo box window, then moved again, and the dialog box window was not refreshed. This would correspond to Trics being busy with something and not answering to the system stimulus asking it to redraw its windows. Trics was restarted after this and before we had a chance to investigate directly. - There was subsequent confusion by the shifter(s) trying to get things back under control by themselves. All symptoms and errors were understood and explained to the daq shifter (Maarten Litmaath?) by looking at the logfiles. Nothing weird discovered. The Cosmic Ray AOIT term was not currently firing. ------------------------------------------------------------------------------- DATE: 6-JUN-2000 At: MSU via VNC TOPICS: More PBS Testing This continues the tests from 2-Jun-2000 with the same version of Trics and Pbs - fix the register IO test command file to read the correct scaler channel of the ExpGrp AONM. Result: The scalers match: ExpGroup #0 Andor Fired, Tick #24 Expo Group #0 Per Bunch Scaler and Integrated per bunch scaler. - explore the range of values of the TickHistoryControl Register. We change the control value for the integrated channel and compare the readout with the per bunch scaler for tick #24. All values from 0 (*) to 4 produce the same result, i.e. matching scaler counts. The value 5 causes a scaler reset and constant readout of zero. If the range of values (i.e. the length of the shift register) is extended we should be able to find the value for which the scaler readout decrements by one count because we capturing the scaler for the tick righ before the one that caused a L1 Accept. (*) looking at the logfile, the control value zero produced a different result. This is believed to have come from the specific trigger at 10Hz firing between the two readings. This test should be repeated once the shift register lengthened. - update the command file to read all 160 per bunch scalers. (also change the scaler firing rate to 1/10 Hz). Only the expected scalers have a non-zero count. - modify the exposure group to require AOIT #251 in veto. This should cause all scalers but the scaler for tick #24 to increment. In fact we should also see a one count step up where the first tick occured and a one count step down where the last tick occured. SpTrg #0 was prescaled to ~1/10 Hz. The result was : channel 1-23 5 / 5601 channel 24 1017 / 27715 channel 25-41 5 / 5600 channel 42-159 5 / 5601 This result satisfies the expectation, but it seems suspicious the downward transition is at tick #24. Decide to start over and reset all scalers. - initialize and re-setup ExpGrp #0 and SpTrg #0. but operator error that failed to send the prescale ratio of 70 E6 for a while. The result was: Channel #1 : 304 / 17815 Channel #2 : 266 / 64353 Channel #3 : 266 / 64353 Channel #4 : 304 / 17815 Channel #5 : 266 / 64353 Channel #6 : 266 / 64352 Channel #7 : 304 / 17813 Channel #8 : 266 / 64351 Channel #9 : 266 / 64352 Channel #10: 304 / 17815 Channel #11: 266 / 64353 Channel #12: 266 / 64353 Channel #13: 304 / 17815 Channel #14: 266 / 64353 Channel #15: 266 / 64351 Channel #16: 304 / 17812 Channel #17: 266 / 64351 Channel #18: 266 / 64352 Channel #19: 304 / 17814 etc It is not exactly clear how to interpret the data, but some things are clear - Initialize did NOT reset the scalers as was expected Philippe thinks Trics is doing what it takes to reset the scalers (via the L1 Helper synchronous reset method), and Steve is checking on the Fpga design. - There is a clear devide by 3 pattern where the skip next 2 crossings kicked in for the period of time that SpTrg #0 was UNprescaled. - there is some +/- 1 count jitter in the pattern that is not understood. - Inititialize again and sets things up right from the start, however the scaler counts not being reset by initialize prevent anything else from being learned. Note that even before we understand why initialize did not reset the scaler, we can write a RIO command file that resets the scalers by using the out of range TickHistoryControl values, or trying a direct scaler mask reset method. ------------------------------------------------------------------------------- DATE: 2-JUN-2000 At: MSU via VNC TOPICS: More PBS Testing, new FPGAs Using: TRICS Version 8.7 Rev C (programs the duplicated resources on Expo Group AONM and L1 Busy FOM which drive the Per Bunch Scalers, while still skipping PBS at slot 14) PBS version 9.1 (has registers to read back common gate inputs) Repeat the same test as yesterday: Set up Exposure Group #0 to listen to AOIT #251 which selects Tick #24 and setup SpTrg #0 to fire at 10 Hz (note that L3 disables this trigger after a while, and needs to be bypassed) We observe that the "integrated per-bunch" scaler for exposure group #0 at 0/1/20/16/34+35 is incrementing. We find that the Per Bunch Scaler for Tick #24 at 0/1/21/5/30+31 is also incrementing and that the scalers for the previous 8 neighbor ticks and the next tick are not. We read the common control gates at 0/1/21/5/14+15 for different values of the TickHistoryControl Register at 0/1/21/5/13 : TickHistoryControl 0 1 2 3 4 5 Common Gates Reg 14 0x00ff 0x00ff 0x00ff 0x00ff 0x01ff 0xffff Common Gates Reg 15 0x0000 0x0000 0x8000 0x8000 0x0000 0x00ff shows all lower AOIT contribution asserted (as should be) and all upper AOIT contribution negated (as should be for the other Expo Groups). Values 2 and 3 have the Skip Next source of global disable set. Value 4 shows the Exposure Group 0 Upper AOIT contribution asserted. So it looks like a value of 4 is the proper value to capture the information from the beam crossing that caused the L1 Accept. This was not the expected value, and Steve is going to try and explain why. (note the value 5 is believed to be over the length of the shift register). Comparison test: write a RIO command file to read the MSB and LSB registers of the Tick #24 per bunch scaler and the bunch-integrated scaler for comparison. We use a command file to read the register fast enough and not be affected by the capture monit data coming from the SpTrg firing at 10Hz (while this could be set to auto-disabled) or by the 5 second requests to Trics' monitoring server (which also cause a capture monit data and cannot yet be muted). Vertical_Master: 0 Vertical_Slave: 1 Slot: 20 Chip_Address: 16 Read_Register: 34 Read_Register: 35 Slot: 21 Chip_Address: 5 Read_Register: 30 Read_Register: 31 The two values match. Rate Test: After initial confusion, we compute that two readings 10 second apart show a difference of roughly 10* 47.9 kHz. By looking at the logfile, here is a more precise measurement: time: 14:09:02.427 Read : 56919 (=0b1101111001010111) @ @Master#0/Slave#1/Slot#21/Chip# 5/Reg# 30 Read : 1357 (=0b0000010101001101) @ @Master#0/Slave#1/Slot#21/Chip# 5/Reg# 31 time: 14:27:37.720 Read : 56846 (=0b1101111000001110) @ @Master#0/Slave#1/Slot#21/Chip# 5/Reg# 30 Read : 2169 (=0b0000100001111001) @ @Master#0/Slave#1/Slot#21/Chip# 5/Reg# 31 delta time = 1115.3 seconds (note: L1 Accept rate, and Capture Monitor data rate, were 10 Hz / 0.1 seconds) delta count = 53,215k rate = 47.714 kHz Expected rate: 53.104 MHz / 1113 bunches = 47.712 kHz, a good match. Comparison test: Try reading the Exposure Group #0 Upper And-Or Scaler (which is what is gating) this scaler) for comparison. Vertical_Master: 1 Vertical_Slave: 0 Slot: 5 Chip_Address: 1 Read_Register: 40 Read_Register: 41 The numbers are synchronized, but the PBS is lagging behind by 108 counts. The reason is that we were reading the wrong And-Or channel (the one sent to the TDM instead of the one sent to the PBS) and didn't get a chance to correct before having to relinquish ownership of the system. (Note this means Trics takes 108*159*132 ns = 2.2 ms to program all 128 inputs of one channel of one andor card. This makes sense because Trics has to program 8 (+1) registers * 16 lookup addresses * 1 write (+2 reads) = 432 IO at 5us each = 2.1 ms) It would be nice to repeat this test (aiming at the proper AONM channel), because we should be able to get exactly the same scaler count, and explore the value of the TickHistoryControl register that reads the scaler right after it was incremented. ------------------------------------------------------------------------------- DATE: 1-JUN-2000 At: MSU via VNC TOPICS: PBS Testing, new FPGAs Begin with: TRICS Version 8.7 Rev A PBS version 8.1 Begin testing PBS with a new version of TRICS which knows how to set up the Exposure Group PBS's. Note a problem with: Master 0 Slave 1 Slot 14 Chip 13 This FPGA configures correctly but fails L1 FW Initialize and Random Register Test. Many registers read back 0x0003 or 0x0303. Need to remove this card and replace with a good spare, bring the broken card back to MSU for repair. For now, kludge TRICS V8.7 Rev B to simply skip this card (it's Exposure Group 3, Ticks 81:159 + Integrated over all Ticks, we don't need it right now). Try testing the PBS, setting up Exposure Group 0 to require AOIT 251 (Tick Select: L1 Accept Tick 24). This should cause the "integrated" EG 0 scaler, and the "Tick 24" EG 0 scaler, to increment at 47 kHz. Program ST 0 to require AOIT 251 and be part of EG 0. Further, prescale ST 0 by 47 kHz to get 1 Hz of L1 Accept. We don't see the EG PBS scalers incrementing. Re-program EG 0 to require AOIT 255 (always high), still no incrementing. Begin forcing individual CCS Sets HIGH to isolate the problem. First note how CCS are mapped: CCS Set CCS In Function ------- ------ -------- 0 7:0 Exposure Group 7:0 LOWER Partial Enable 1 15:8 Exposure Group 7:0 UPPER Partial Enable 2 23:16 Exposure Group 7:0 L1 Busy Disable 3 31:24 Corr Glb Dsbl 3:0; DeCor Glb Dsbl 3:0 Recall the desired logic in the PBS. The scaler increments if: Selected EG LOWER Partial Enable AND Selected EG UPPER Partial Enable AND NOT Selected EG L1 Busy Disable AND NOT (OR of all allowed Corr Glb Dsbl) is HIGH. When we force CCS Set 1 HIGH for the EG 0 integrated scaler, the scaler begins to increment. This says that the EG LOWER Partial Enable was HIGH, the EG L1 Busy Disable was LOW, and the Skip Next Tick input was low. We did not verify rates at this time. After some thinking, we realize that TRICS is not programming the AONM's and FOM's which generate these signals. Recall that the PBS gets a private copy of all of these signals, which must be programmed separately from the copy used in triggering. We need to fix this in TRICS. See the file http://www.pa.msu.edu/hep/d0/ftp/l1/framework/hardware/general/card_and_fpga_function_by_address.txt For a review of where these signals come from. Steve also added input readback capability to the PBS. This uses the normal Capture Monitor Data mechanism and should capture the inputs synchronized with the other Framework data. This capability is in pbs_9_1.exo. Finally, we needed to modify %RND%\bsf_fpga.rni to allow Random Register Test to work. It did not properly match the current revision of the BSF FPGA, but had some old registers (and was missing some new registers). The SHED FPGA can't be loaded until Trics is updated because the initialization for an L1 TRM and the SHED FPGA are different. The appropriate line is commented out in M123_Top.dcf. L1AL2 is also not being loaded at this time. There probably aren't any initialization questions, but it's not necessary right now and since we don't know for sure that it won't cause problems, it's simpler to leave it out. To include it, uncomment the line in M123_bottom.dcf. When the framework is reconfigured tomorrow morning, it will pick up PBS_9_1.exo. DATE: 31-MAY-2000 At: Fermi TOPICS: new FPGAs Next time the framework is configured, there will be 3 new FPGAs: SHED FPGA in M123 Top Slot 20 FPGA 9 L1AL2 FPGA in M123 Bottom Slot 19 FPGA 16 PBS FPGA is upgraded from 5_1 to 8_1 17,18,19-MAY-2000 At Fermi Topics: Work on testing L2-Helper FPGA's, Bring back to Fermi the VIPA crate that had been in the L2 Test Rack and install it in M124, Get SCL Cable manufacture going, Talk with Sten about NMR Re-did the temporary delay cable on the L1 Fired Strobe signal that goes to the FanOut Box and from there to the 8 Write Clocks inputs on the L2 TRM's that FIFO the Mask of L1 Spec Trig's Fired. The "standard" cable that runs from the Pass-Through P3 connection that is the FOM++ L1 Fired Strobe output to the input to the FanOut Box had been twin twisted pairs that were 51" long. We had added to one of these pairs (the one that makes the L2 TRM Write Clock) and additional 48" i.e. 6.6 nsec. What is installed now makes this added delay 12.5 nsec long. I added a 2nd copy of this delayed signal so that we can have the FanOut Box make the Write Clocks for the Auxi Data L2 TRM. So the setup now is: +---------+ 1 144" twisted pair 7 +----------+ L2 TRM L1 Mask Wrt | FOM++ | 2 51" twisted pair 8 | FanOut | L1 Fired Strb stuff | Output | 3 144" twisted pair 9 | Inputs | will be L2 TRM Auxi +---------+ 4 nc open no 10 +----------+ Right now the Fanout Box is Input pair 7 goes to outputs 8:1 and Input pair 8 goes to outputs 20:11. I need to add something like Input pair 9 to outputs 24:21 to make some outputs for the Auxi Data L2 TRM. See the log book entry for 26,27,28-APR-2000 to see how this is currently wired up. A quick test of the new L2 Helper 15.2 (which I think is a tied design, with the new input latches, made with the 1.4 software on Becane) appears to work OK. So far it looks OK on the Logic Analyzer and on SCT. Bring back to Fermi the VIPA crate that had been in the L2 Test Rack at MSU. This is SN 0018 which is at ECO 5. I talked with Ed Arko and he said: I may keep and use this crate in M124, that at sometime I should take it to Prep and exchange it for one at current ECO, and that right now there are no uncommitted VIPA crate within D-Zero or at Prep. This crate is now installed as the lower VIPA crate in M124, i.e. the Readout crate. Connect with a Run II FW Power Pan (all 4 supplies just like the SCL Hub-End crate above it). Installed a Vertical Interconnect Slave and a MVME 214 Memory Module (that has its VME Address setup to appear as THE-Card #2) and check the VME connection with TCC and all apears OK. Put a standard depth radiator in M124 between the two VIPA crates and connect it to the cooling water circuit. The radiator is a "standard" Run I unit for a 400mm deep VME crate. Water running since Thur morning. Measure for the fuse blocks that will go behind the power supplies. The support board for these should be 18 1/2" x 2 1/2" with the mounting holes for the fuse blocks in the center and the mounting holes to the support rails left undrilled. Starting Friday morning run L2-Helper 15.2 It looks OK on the logic analyzer but we have not yet tried the test with muon doing the thing that we think breaks the 13.1 version of this FPGA. Picked up the following parts from Neal for making the SCL Cables: 500 ft of LMR-100 cable qty 97 of Johnson 133-3403-001 MCX straight connector for the LMR-100 cable. Fanout Module end of these cables. qty 80 of PE4036 SMA straight connector for the LMR-100 cable. Patch Panel end of these cables. qty 80 of PE9071 SMA bulk head feed through for the Patch Panel qty 160 of Times Microwave 3190-612 SMA straight connector for LMR-200 cable. Patch Panel end of these cables. qty 80 of PE4522 SMB rt angle connector for the LMR-200 cable. SCL Receiver end of these cables. qty 1 drilled and labeled 19" rack panel for the Patch Panel. Friday night starting at 8PM finally get in some loops of SCT. 31k loops (all cards everything being checked) zero errors . This is L2-Hlp 15.2 17-MAY-2000 at Fermi TOPICS: More L2 Helper, SCL to VRB, Master Clock SCT tested L2 Helper 14_2. It dies in the same way as 14_1 and with approximately the same frequency. Then put in 13_2 and ran SCT for 3000 loops, no problems. Still using 13_1 for normal running. VRB complained that when they first turned on the power, they saw L2 accepts (nothing from L1) even before their geographic section was included in the trigger. However they had already modified the trigger to include that G.S. so it was difficult to try and diagnose the problem. They had a similar problem last week that eventually cleared up (after which they saw L1 Accepts but nothing from L2 - unplugged them and checked the SCL data on the logic analyzer and it was perfectly fine). For help restarting the Master Clock after a power outage, see logbook entries: 21:22-SEP-1999 but note the clock is now on 1 rather than 16 26-JAN-2000 10-FEB-2000 16,17,18-FEB-2000 24-FEB-2000 (These terms are to make it easier to find this entry when searching.) terminal server, master clock, clkSetup 16-MAY-2000 at: Fermi/MSU Topic: More L2 Helper Detective Work Tests of L2 Helper Boris and co had issues with the L2 Helper, it would produce 2 L2 Decisions separated by 132 ns (with no L1 or L2 Decisions) when he would drop (and quickly re-raise?) his L2 Busy output. We were not able to re-create this behavior by manually forcing the L2_BAD inputs or outputs to simulate his L2 Busy, but we clearly saw the problem on our logic analyzer when he was controlling his L2 Busy. These problems were seen with l2_helper_13_1. Steve made a new L2 Helper (l2_helper_14_1) which latched many state machine inputs. The idea was that perhaps some signals (i.e. the L2_BAD output) were just making setup in some state machine FF's, but not in others. This could result in the state engine going to some illegal and unintended state. Kirsten loaded this L2 Helper and found that it would not reliably work with SCT. After a very few loops (typically <10) SCT would fail with the message: Waited 6 x 1000us for L2 Helper Last Status 0x0001 followed by a number of Monitor Data errors. Start to look at symptoms: Read L2 Helper I/O Readback (reg 19): 0x0043 (i.e. there is an L1 Accept to process -- note: this readback is after the new input FF's, and is exactly the signals being provided to the state machine) Read L2H State Engine Status (reg 17): 0x0001 (i.e. quiescent, this is the WRONG state to be in at this time, we should have exited from this state because there is an L1 Accept to process) Force L2H State Engine Reset: Write Reg 16: 0x8003, 0x0003 Read L2H State Engine Status (reg 17): 0x0081 (i.e. waiting for TCC Approval, this is the right state to be in at this time) Approve cycle: Write Reg 16: 0x0007 Read L2H State Engine Status (reg 17): x0101 (i.e. waiting for Approval Removal, this is the right state to be in at this time, NOTE: some other bits should be set in this register, but aren't...why?) Remove approval: Write Reg 16: 0x0003 Read L2H State Engine Status (reg 17): 0x0001 (i.e. quiescent, this is the right state to be in at this time) Read L2 Helper I/O Readback (reg 19): 0x0046 (i.e. no L1 Accept to process). Note: we have seen similar symptoms before, where the state machine fails to exit the Quiescent state and/or fails to latch bits in the Status Register. Note that l2_helper_13_1 and l2_helper_13_2 use exactly the same EDIF netlist generated by the VHDL synthesizer as l2_helper_14_1. So we can't blame the problem just on the VHDL synthesizer, because these other versions don't exhibit the same symptoms. There may be some interaction between the VHDL synthesizer and the Xilinx PAR software. Some of our previous 4013L problems were traced to strange behavior in the BITGEN program when we tied the bitstream. Make a l2_helper_14_2 which uses the 14_1 .ncd file and just re-runs BITGEN in non-tie mode. That is, we don't re-run place-and-route. Kirsten will try this new 14_2 design when she next has the opportunity. 11-MAY-2000 at: Fermi Topic: L2 Decisions in Rapid Succession After Boris reported a problem, I tried to duplicate it and capture it on the logic analyzer. Boris reports that if they assert L2 Busy and then remove it for a short time, they sometimes get two L2 Decisions separated by only 132 ns. Two methods were used to try and duplicate this problem: 1) run at 1 Hz have Logic Analyzer trigger on the L2 Period Signal assert L2 Busy by writing 0/2/19/1 Reg 8 of the L2Bad (0x5556) push run on the Logic Analyzer about 6 sec later release L2 Busy (0x5555 to Reg 8 of L2Bad) 2) switch to Auto Disable asssert L2 Busy as before setup Logic Analyzer as before and run issue some number of triggers using Auto Disable (3 is the most that can be seen on the Logic Analyzer) release L2 Busy In neither case was I ever able to see two L2 Decisions in rapid succession. The L2 Decisions were always separated by about 772*132ns=102 usec. Working with Boris, Vladimir, and Igor, we were able to reproduce the problem and see it on our logic analyzer (SCLREC14.DAT and SCLREC15.DAT). Our logic analyzer is set to trigger if there are two L2 Issued's within 1 usec. Muon is running and then manipulates the VRC so that they end up sending both L1 and L2 Busy. It's after this that the problem sometimes appears. When we see the problem, their L1 Busy is not asserted (nor is it asserted at any time in the near vicinity) and their L2 Busy is mostly asserted but is dropped briefly. Some examples of the pairs of L2 Decisions: Their L1 Trig Num Our L1 Trig Num Our L3 Xfer Num ----------------- --------------- ---------------- 0x63 0x63 0x01e0 0x41 0x41 0x01e0 0x23 0x23 0x0521 0x6b 0x6b 0x0521 0x2c 0x2c 0x0a23 0x62 0x62 0x0a23 10-MAY-2000 at: Fermi Topic: Master Clock Fritz rebooted the Master Clock because it was being switched to a new subnet. ------------------------------------------------------------------------------- 8-MAY-2000 At MSU Topic: Back up Master Clock Files FTP all files from d0ola trgmgr's directory /master_clock/config_files and from /online/ioc/m68k/mv162/d0olctl06 to d0mino laurens's directory d0ola_trgmgr/... and to \\msul1a\_e_\Archive\d0ola_trgmgr_master_clock_files\master_clock_files_2000_05 ------------------------------------------------------------------------------- 26, 3,4,5-MAY-2000 At Fermi Topics: Start Cooling Water and Drip Detectors, Connection to VESDA, Work on SCT in L2 FW, Meeting with Maris, Reiner, and Dean, SCT Tests Turn on the Cooling Water and enable the Drip Detectors to trip power to the racks. The water turn off for M122, M123, M124 is under the floor in the center aisle between M103 and M124. In general the backs of these three racks should now feel cool to the touch when they are operating (and they should feel cold if they have been turned off for a long time). Now that we have cool air to keep in (instead of hot air to let out) we are now running with the back doors closed. Be careful latching the M123 door as there are some cables that currently almost interfere with the center latch on M123's back door. Be careful latching the M122 back door as there currently is not enough room for all the L2 FW calbes. I have only been catching the top latch on M122's back door. Each of these 3 racks has two Drip Detector strips. The signal from these strips is processed by the RMI near the bottom of M124. If any strip is wet then all power is shut off in these 3 racks. If the system trips off from drip detection then the Global Permit light on the Contactor Box above M124 will go out and the red Drip Detector alarm LED on the RMI will come on. The VESDA electrical connection to the power control - safety system for M122- M123-M124 has now been made. If the VESDA (or either of the two Auxiliary Safety Loop HoneyWell Smoke Detectors in rack M113) detects smoke then all power to racks M122-M123-M124 will be shut off. If these racks trip off because the VESDA detects smoke then the Global Permit light on the Contactor box above M124 will go out and the VESDA control panel will show a high thermometer and a tripped indicator. You can see the "Trigger Rack" VESDA control panel on a TV monitor in the Control Room. For the VESDA (and the Auxiliary Safety Loop HoneyWell Smoke Detectors) to be operating we need "safety system" control power in rack M113. To have the safety system power we will now need to start keeping breakers 25-27-29 in panel PP-D0-MCR1B turned ON. L1 Cal Trig Pick Off Resistor Meeting with Reiner, Maris and Dean. My notes and the "official tentative" GeV to Volts scale information is in a mail message that I sent to them last night. Reiner now has all the stuff that he needs to make a first pass at the resistors. The official sampling point will be at 110 nsec after Spice says that the Pick Off signal has started to move up. The official guaranteed linear swing is 6 Volts diff (each leg can swing 3 Volts). The second stage summer gains should be kept above 1, e.g. 2 is a good value. The saturation in the 1 stage summer is the same as in the 2nd stage summer. SCT Tests Friday Morning TRICS 8.6.L L2_TRM-4-1 no added L1 Fired Strb Delay OK TRICS 8.6.M L2_TRM-5-1 20 nsec delay in L1 Fired Strb errors SpTrg 96-99 TRICS 8.6.M L2_TRM-5-1 35 nsec delay in L1 Fired Strb OK TRICS 8.6.M L2_TRM-5-1 20 nsec delay in L1 Fired Strb testing L1-Sp-Trg-Mask 63:0 TRM and Aux Data TRM only OK TRICS 8.6.M L2_TRM-5-1 15 nsec delay in L1 Fired Strb testing L1-Sp-Trg-Mask 63:0 TRM and Aux Data TRM only OK TRICS 8.6.M L2_TRM-5-1 6 nsec delay in L1 Fired Strb testing L1-Sp-Trg-Mask 63:0 TRM and Aux Data TRM only OK TRICS 8.6.M L2_TRM-5-1 6 nsec delay in L1 Fired Strb testing the 2 L1-Sp-Trg-Mask TRM's and Aux Data TRM only OK TRICS 8.6.M L2_TRM-5-1 20 nsec delay in L1 Fired Strb see the error testing the 2 L1-Sp-Trg-Mask TRM's and Aux Data TRM only SpTrg 96:99 TRICS 8.6.M L2_TRM-5-1 6 nsec delay in L1 Fired Strb testing all L1 & L2 FW's and all L1 & L2 Scalers OK TRICS 8.6.M L2_TRM-5-1 0 nsec delay in L1 Fired Strb see error @ loop testing all L1 & L2 FW's and all L1 & L2 Scalers 181 in L1 Fired Mask for SpTrg 112:115 TRICS 8.6.M L2_TRM-5-1 6 nsec delay in L1 Fired Strb testing all L1 & L2 FW's and all L1 & L2 Scalers OK the data delay cables for Sp Trig 15:0 & 111:96 have been pulled out. After this SCT testing leave the system setup up as follows: TRICS 8.6.M L2_TRM-5-1 6 nsec of delay in the L1 Fired Strb that feeds the two L1 Sp Trig Fired Mask TRM's at the input to L2. The data delay cables that had been on Sp Trig 15:0 and 111:96 feeding these TRM's are left removed. Still need to explore: Why this ranges in the neighborhood of 20 nsec of delay in the L1 Fired Strobe where we see errors for Spec Trig 96:99 in its L2 TRM. Picked up 4 more SCL Receivers from Ted. 1 went to Boris and 3 went to Sten. Sean confirms that L3 is receiving a good mask of Triggers Fired and Passed by L2. This has only been confirmed on Spec Trig #0 and needs to be tested on other Spec Trigs (31:0 in their current setup). Friday night tests of SCT All of this will be: TRICS 8.6.M L2-TRM-5-1 and the "data delay" calbes have been removed from Sp Trg 15:0 and 111:96 feeding the L2 TRM for the L1 Trig Mask. All test have all L1 and L2 cards selected and both the L1 and L2 scalers. 6.6 nsec delay in the L1 Fired Strb to the L2 TRM's 15k Loops OK 15.8 nsec delay in the L1 Fired Strb to the L2 TRM's 15k Loops OK 21.7 nsec delay in the L1 Fired Strb to the L2 TRM's 1k+15k Loops OK 28.3 nsec delay in the L1 Fired Strb to the L2 TRM's 10k Loops OK 37.5 nsec delay in the L1 Fired Strb to the L2 TRM's 5k Loops OK 0.0 nsec delay in the L1 Fired Strb to the L2 TRM's errors in L1 Mask TRM Spec Trig Read Instead of @ Loop --------- ---- ---------- ------ 0:3 dddd fddd 78 16:19 fddd dddd 74 64:67 ffff 7fff 21 0:3 5555 7555 170 16:19 8ccc cccc 131 Go back to 6.6 nsec for a final check out 6.6 nsec delay in the L1 Fired Strb to the L2 TRM's 5k Loops OK Turn off TCC, Master Clk, and FW to be ready for the power outage on this SAT. Bring 60 Watt light bulbs DATE: 3-MAY-2000 Morning At: MSU via VNC Topics: More L2 FW SCT SCT Testing on Wednesday Morning: - Using Trics V5.6 Rev L (no great difference from Rev K, different order of actions in SCT, do L1fw first, L2fw second, instead of inter-mixed L1-L2 actions) - Pass 1 k loops with all L1 & L2 cards and no scalers. about 1 mn 1 s - Pass 1 k loops with all L1 & L2 cards and L2 scalers only. about 1 mn 9 s - Pass 1 k loops with all L1 & L2 cards and L1 & L2 scalers. about 3 mn - Load the new TRM fpga V_5_1 into the L1 Fired L2fw TRMs. This fpga has a wall of flip-flops before the receiving FIFO. - Pass 1 k loops with all L1 & L2 cards and L2 scalers only. - Using Trics V5.6 Rev M (remove the restriction to SpTrg 0:15 & 96:111) - Errors on SpTrg 16:19 (only) for L1 Fired TRM (matching errors for AONMs) Read 0xabb9 instead of 0x3bb9 (missing bit #3 and extra bit #0) after 194 loops Read 0x0800 instead of 0x8800 (missing bit #3) after 545 loops Read 0xcccc instead of 0xeccc (missing bit #1) after 126 loops We believe that the L1 Strobe will need to be delayed for this new fpga. - Revert to L2 TRM V_4_1 and Trics Rev L - Pass 15k loops with all L1 & L2 cards and L1 & L2 scalers. No errors (except when the control room decides to initialize in the middle of SCT). DATE: 2-MAY-2000 Mid-Day At: MSU via VNC Topics: More L2 FW SCT SCT Testing on Tuesday Mid-day: - Using Trics V5.6 Rev J - SCT now waits for L2 Helper to ask for "Approval Removal" and this solves the TRM SpTrg #0 problem. - Pass 5k loops with all L1 & L2 cards (except L2 FOMs) and L2 scalers (but no L1 scalers) - SCT now correctly keeps off the flakey SpTrg channels and FOMs cause no more problems in their outputs but they help discover the following problem. - SCT occasionnaly stalls with the L2 Helper waiting for L2 BAD. Philippe traces it to the L2 Bad being improperly programmed and finds a bug in COOR-Initialize that tends to leave channels enabled. Geo Sect 128 was left enabled, and once SCT started playing with the FOMs the upper L2 BAD stalled the L2 Helper. - Rev J was fixed and ran 1k loops with all L1 & L2 cards (including L2 FOMs) and L2 scalers (but no L1 scalers). - using Trics V5.6 Rev K - SCT now cycles the L2fw twice (including changing programming) when L1 scalers are included. - Start 1k loops with all L1 & L2 cards (including L2 FOMs) and L1 & L2 scalers. But we had to give the system back before completion of the 1k loops (which now take much longer). 2-MAY-2000 Morning At: MSU via VNC Topics: More L2 FW SCT SCT Testing on Tuesday Morning: - Using Trics V5.6 Rev I - SCT Still has problems with FOM cards and must still be using SpTrg that did not receive the longer cables. - Pass 1k loops with all L1 & L2 cards (except L2 FOMs) and no L1 or L2 scalers - SCT fails if we add both L1 and L2 scalers. We finally understand that SCT sweeps the L1 Helper twice per loop when L1 Scalers are included. This will clock two slices into the L2fw L1 Fired TRMs. SCT must thus needs to become smarter and cycle the L2fw twice per loop when L1 Scalers are included in the test. - When only L2 scalers are included we get the scaler error again for TRM at SpTrg #0, cf. earlier notes. We finally realize that SCT simply checks this scaler too early, while the L2 Helper updates scalers about 100 us after the L2 cycle is approved. The reason that we didn't run into this issue for the other monit data earlier is that SCT would check L1fw registers before L2fw registers which takes a long time but that it checks L2 scalers right after approving the L2 cycle. 26, 27, 28-APR-2000 At Fermi Topics: Install Cooling water and Drip Detectors, work on installing the VESDA, check timing of L2 FW signals, tests with Muon, SCL talk for Silicon Give an SCL talk at the Silicon Lab A facility. Marcel Demarteau and Petros Rapidis. Big Zeiss machines: 0.0001 mm 0.5 arc sec accuracy. They would like to run their test stations with real hardware and not just ad hock FPGA one of a kind, it does not really work, "solutions". Work on testing the current setup and hold time of the signals going into the TRM that FIFO's L1 Mask going into the L2 FW. Huston we have a problem. +-----------+ | | "Data" i.e. TDM output bus --------+ +-------------------- +-----------+ | | "Write Clock" L1 Accept Strobe --------------------+ +-------- from the FanOut Box These signals have good electrical fidelity, they are asserted for 132 nsec as expected, the problem is that they just exactly cross over each other, i.e. there is zero hold time. They just exactly cross over each other at their 50% points. The FanOut Box has 2 sections. Left connector pair #7 fans out to right connector pairs #8 :#1. and Left connector pair #8 fans out to right connector pairs #20:#11. The outputs #8:#1 feed the L1 Accept Strobe to the TRM's that FIFO the L1 Fired Mask for the L2 FW The rest of the outputs are: #14:#11 L1 Acpt Strb to the TRM for the Auxi Data FIFOed into L2 FW. #15 to the L1 Helper #16 to the scaler in M123 Bottom Slot #19 (count of L1 Accepts) #17 to the SCL Hub-End #18 n.c. #19 via 30nsec delay cable to the Tick and Turn SCaler #20 n.c. Install the radiators and connect the cooling water to M122 M123 (and just water connections for M124). The 2 radiators each in M122 and M123 have been either soldered over in the place where they normally leak or else they have clamps on them. The setup is 3/4 hose from the center aisle distribution pipes to 4 way headers under M123-M124. From this header it is, for each rack 3/8" hose to a double connector for 1/4" hose. The 1/4" hose run up from under the floor, into the racks, and to the radiators. This series of hose sizes should be OK. Check their relative cross sections: 1/4" hose --> 0.0491 sq in 3/8" hose --> 0.1104 sq in 3/4" hose --> 0.4418 sq in Also install pressure guages which can be seen from the back of M124. The valves on the feed and return hoses to/from the M122-M123-M124 can be reached by pulling up the center aisle tile that is between M103 and M124. Remember to turn these valves on and off slowly.. Friday morning run some tests with Muon using the TRICS push button trigger setup for Muon. They teted to see that the FW does the proper things when they assert L1 Bz and L2 Bz. They artificially could assert these signals and they agree that the FW's do the proper things with each of these signals. Seen Friday afternoon a little before 4:10PM L2 Accepts at about one every 100 usec with no L1 accepts ever. It was not just something "stuck" in the FIFO because each L2 Accept had a different Geo Sect L1 Trig Num. Bring 60 Watt light bulbs. DATE: 28-APR-2000 afternoon At: MSU via VNC Topics: More L2 FW SCT On Friday afternoon run with Trics 8.6 Rev H. This version has a crudely implemented addition wrt. Rev G. It shuts off ECL output of the FOM++ while changing the programming of the L1fw cards. First run without scalers (also still without Accept/Reject FOMs). Verify that the Read/Write counters of the TRM Fifo now remain in synch after one loop of SCT. Then Run 6k loops with no errors. Next include L2 Scalers. One Error for Loop #1: L1 Fired TRM Scaler Count for Term #000 Read 0x000006db instead of 0x000006dc This suggests that SCT was successful at synchronizing to the initial scaler counts, but that this scaler didn't increment. Note that all other scalers were checked and did not complain. Repeat same test (SCT Intialize + 1 loop) L1 Fired TRM Scaler Count for Term #000 Read 0x000006e0 instead of 0x000006e1 Use Syncchronize L2 Scalers button and 1 more loop L1 Fired TRM Scaler Count for Term #000 Read 0x000006e1 instead of 0x000006e2 This suggests that the second time SCT read this scaler (for synchronizing before the second loop) it read the right answer expected by the first loop. Remove all L2fw cards for SpTrg 0:63 Run 1k loops with L2 scalers and no error. We would like to think that SCT is to blame. Note that SCT does not check relative channel #0 of the TRM for L1SPTrg Fired 64:127, but only checks relative channels 96-64:111-64. Philippe checked and hasn't yet found a problem with SCT regarding Channel #0. The problem with the L2 FOMs was simpler to spot (SCT was not keeping off the SpTrg channels without the extra length of cable). This SCT scaler error SpTrg #0 L1 Fired TRM is still not understood. One thing to try next chance we get is to run 1 loop of SCT without scalers, then manually read this scaler a few times. An indepent issue was found with the current fpga implementation of all L2 scalers. The scalers are enabled to increment by the Capture Monit Data signal instead of the Shift Monit Data signal. This does not matter for SCT, but it means that capturing the monitor data multiple times can make the scalers increment even though the L2fw is NOT cycling. An independent issue was found with Trics V8.6 Rev F,G,H. The D0 DAQ monitor program has (finally) started to ask for the newer monit data block. There was some temporary test code left in TRICS by mistake which prints extra lines about data sizes with every request from Taka. Moreover a few more lines of IO error messages are printed when the framework power is off. This generates 2-3 MB of data per hour, or < 75 MB per day. We leave the stable Ref G running and make over 400 MB of room on the disk to ride through the weekend. We could also verify that the Monitoring Server trying to capture monitoring data does not perturb SCT because the Monitata Server uses the "normal mode" method to pulse the Capture Monit Data line while the L1 Helper has been put in Test mode by SCT. Note: Philippe should move Trics to a different partition than the OS. Trics is expected to be smart enough to give up on logfiles and continue when the disk gets full, but NT would not appreciate if its system disk gets full. TCC has two identical disks; each with three partitions. The second disk is a hot spare. Philippe should move the Trics code, Trics executables, logfiles, config files, etc to the second partition (2GB) of the active disk. A similar thing should be done to MSUL1A for similar reasons. The handy links in each sub-directory of /trics would need to be rebuilt. DATE: 28-APR-2000 morning At: MSU via VNC Topics: More L2 FW SCT On Friday morning, run with Trics 8.6 Rev. G, which fixes the bug in Rev. F which did not allow the test to proceed beyond the Initialize phase. Recall that Rev. F and Rev. G are kludged to only pay attention to certain Specific Triggers. L2fw SCT is kludged so that only SpTrg #0:15 and 96:111 are verified in the L1 STFired TRM, and L2 Accept/Reject AONMs. The Accept/Reject FOMs only use the inputs from SpTrg #0:15 and only verify outputs #0:15. The FPGA complement is as it was on Thursday 27-Apr-2000, see that day's logbook entry for details. Note that we had a problem with configuring 2 FOM cards: 1/1/14 and 1/1/15. On both of these cards the BSF (bsf_20_3) failed to configure. We re-configured this crate (M123 Middle) and the problem did not occur. Has this happened before on Rev. B AONM's? The test failed at loop 8 with the following error: FOM L2 Reject output term 79:76 (upper ST's) read 0x0040 not 0x4040 Starting SCT over produced similar errors at loop 4: FOM L2 Accept output term 7:4 (lower ST's) read 0x2220 not 0x6220 FOM L2 Accept output term 67:64 (upper ST's) read 0x0000 not 0x1000 For the moment, we theorize that Philippe isn't properly handling the FOM's to only pay attention to the expected good Specific Triggers (i.e. those with extra cable length). We remove the FOM's from the test to press forward. Starting SCT again, we make it to loop 11 and abort with the following error: TRM L1 Accept output terms 15:12 (lower ST's) read 0xffff not 0xdfff And again, this time at loop 5: TRM L1 Accept output terms 15:12 (lower ST's) read 0xffff not 0xdfff AONM L2 Reject output terms 15:12 (lower ST's) read 0xbfff not 0x9fff When we drop the lower TRM, we fail at loop 19 with similar errors on ST's 111:108 and 107:104. We note that we always seem to read 0xffff from the TRM's in this failure mode. We single-step SCT (i.e. run 1 loop at a time) and note that the failure occurs the first time anything other than 0xf is predicted as a TRM output for the current L2 Cycle). We look at the TRM write address vs. the read address. After any number of loops of SCT these addresses should be the same. Following SCT Initialize, the upper L1 Accept TRM FIFO Address Register shows 0x0606. This makes sense given the oddball pattern these address pointers follow...both the Read and Write address have incremented 4 times, once for each loop performed at initialization. We then do SCT Initialize followed by 1 SCT loop. Aha! Now this register reads 0x0502. This means that the write address incremented by 6 (4 at initialize, plus TWO increments associated with loop 1). The read address has incremented once after the initialize, as it should. Do SCT Init + 2 loops and see that the write address incremented by 8 (4 at initialize, plus we assume twice for each of the 2 loops). Again the read address looks good. We check multiple FPGA's on multiple cards to find them all identically wrong. We guess that the problem is NOT due to electrical problems on the L1 STF TRM Write Clock -- this signal looks clean on the scope, and we don't see evidence of FIFO mismatches in normal running (Steve checked this @ FNAL during L2 FW installation, although this was with a different TRM design). Instead we guess that TRICS is causing this line to be activated while it changes the programming of the FOM, similar to the "200 ms" L1 Strobe problem we saw last week. We further guess that TRICS would be clocking "0's" into these TRM's (as no ST's are actually firing during changes in programming) but we are not convinced that this is compatible with what we see. We need to fix this problem. Furthermore, we need a good solution for this which works for changing programming during normal physics running, which we expect will happen somewhat frequently. This solution must take the L1 and L2 FW into account (recall that even if we stop the flow of L1 Accepts, we may have pent-up L2 Decisions to advertise...any L2 Decision we advertise must obviously be correct! Possible solutions: 1. Take advantage of the "ECL Output Enable" already present on all of our cards to force these outputs (and others) to 0 during SCT programming changes. The granularity of this solution is at the card level. 2. Add logic to the FOM++ (and other cards?) to force their electrical outputs to a known state (is it enough to force LOW? Or do we need forcing to either state?). In the case of the AONM/FOM/FOM++ cards, we could tie this to the Chip CSR "lookup program enable" signal. The granularity of this solution could either be at the chip level or at the individual output signal level, as desired. 3. Other ideas? Note the other hardware issue that was raised on Thursday: how to fix the "L1 Accept Strobe too slow to L1 Accept TRM's (and, less likely but not ruled out, Auxi Data TRM's" problem. So far, the following ideas have been proposed: 1. Remove the output latch on (some channels of) the FOM++, to get the L1 Accept Strobe started earlier. This has a strong risk of producing multiple edges on this signal, as it is allowed to update in real-time and reflect transitions in the upstream cards. This risk seems to rule out this solution. 2. Put long cables everywhere on the L1 Accept bus. This is relatively simple to do, but will be inconvenient and ugly -- lots of cables will be stuffed behind M123 if we do this. We would need to determine an appropriate length for these cables via calculation and testing. 3. Put a wall of flip-flops at the input of the L2 TRM. This would be before the FIFO. Need to think about the effect of this solution on all 3 L2 TRM uses. --------------------------------------------------------------------------- DATE: 27-APR-2000 At: MSU via VNC TOPICS: More L2FW SCT The following are Steve's notes on SCT Testing of L2 FW. They concentrate on hardware type issues. Philippe's notes below discuss software in more detail. Initial situation on Monday, following the diagnosis of the "200 ms" issue and the "bad Tick and Turn Synchronization" issue, both at SCT Initialize time:: FPGA versions: l2_helper_10_1 l2_trm_2_1 l2_aonm_1_1 l2_foml_1_2 l2bad_1_2 Saw a number of problems with the L2 Framework SCT: - @ SCT_Initialize, test frequently did not find L2 Helper state engine waiting for approval, when it should have been on closer examination, the FIFO Not Empty flag from Auxi TRM was in fact asserted (verified @ L2 Helper input readback register) but L2 Helper still in Quiescent state when it should not have been. - also walking SCT "by hand" we found the L2 Helper not waiting for TCC approval removal at the end of the L2 Cycle, but it had rather returned to the Quiescent state unexpectedly. - STFired input TRM readback on several channels in the range 15:0 and 111:96 showed missing bits (expected high saw low) at SCT Initialize - L2_AONM and L2_FOM readback read 0x0000 rather than 0xffff for the L2_Reject uses. L2_Accept read 0x0000 as expected On Tuesday, we first updated the L2_Helper to l2_helper_12_1 (which includes the 6 new scaler channels and the Waiting_for_L2_BAD output, but no major state engine changes) the first problem (failure of state engine to recognize a new L1 ST Fired Mask) went away. Steve had no reasonable explanation for this. We did not specifically test for the second problem (failure to wait for TCC approval removal). To further diagnose the TRM readback issue, we made a new L2_TRM FPGA (l2_trm_3_1) which modified the readback to tie the input to the BXHSR directly to the output PAD (i.e. after the output flip-flop). This appeared to make the symptoms considerably worse when we were able to test on Wednesday morning. We were also able to read back the AONM output for the current L2 Cycle only due to Steve's misconception about the P1 Timing Signals routed in M122 Bottom. But these AONM outputs indicated that the electrical output of the TRM's was wrong, not just the readback. On Wednesday afternoon, we made yet another L2_TRM FPGA (l2_trm_4_1) which was extra-paranoid about when it allowed its FIFO Read Counter to increment, compared to when it updated its output, even though all other FIFO-based processing (in L1_TRM and TTS) works flawlessly with allowing the Read Counter to increment (in preparation for the next event) simultaneously with updating the output flip-flops (for this event's data). The L2_TRM now updates its Read Counter a few hundred ns after updating its output flip-flops. Note that it updates its readout BXHSR simultaneously with updating its Read Counter. To do this, we appropriated the Maginot Line P1 Timing Signal, which we do not use in the L2 Framework anyway. This necessitated making a new L2 Helper (l2_helper_13_1) which cycles this timing signal. We also made a new L2 AONM (l2_aonm_2_1) and L2 FOML (l2_foml_2_1) which used this same appropriated Maginot Line (rather than the non-existent P1 TS Steve had used previously) to update their readout BXHSR's. We were unable to test these FPGA's on Wednesday afternoon. Wednesday evening, Steve asked Dan to measure the input side timing to the L1 STF TRM's. The concern was: did the data have sufficient set-up and hold time compared to the clock. Specifically, it was clear that the clock was delayed wrt the data...was it delayed enough so that the clock rising edge came AFTER the end of the data's valid period. The answer was: yes. The rising edge of the clock was exactly synchronous with the data transitioning to its new level for the NEXT cycle. This is obviously not the way we want to run this system, and probably explains the flaky results we have seen from the L2 TRM. It does not explain why the system appears to work when we have examined it on the logic analyzer and why no users appear to be complaining. On Thursday morning, we configured the FPGA's in the L2 FW as follows: FPGA versions: l2_helper_13_1 l2_trm_4_1 l2_aonm_2_1 l2_foml_2_1 l2bad_1_2 Even though we knew that the FW tests would not be wholly successful due to the issue above, we wanted to verify that we had worked out all of the readout concerns. We found no problems in readout, and when Dan installed a long cable for L1 ST 15:0, the flaky errors seen for these ST's went away. We were still not able to collect high statistics because other channels did fail. Philippe will make a version of TRICS which only checks a few channels (those for which we have long cables), so we can collect more information on this problem. We left the FW with the newest FPGA's (listed above) and the newest version of TRICS. ---------------------------------------------------------------------------- 24,26-APR-2000 At: MSU via VNC TOPICS: L2FW SCT tests Monday's L2fw SCT tests allowed the following to be understood: - The Time Zone errors have disappeared now that Trics resets the TTN Scalers using the Test Mode method of the L1 Helper during SCT. - The "200 ms L1 Strobe" syndrome is a non-issue. This signal occurs WHILE SCT is re-initializing the L1 FW cards and NOT while the L1 Helper sweeps after all cards are initialized. This also brought up two topics regarding controlling the outputs of the L1 FW. - During SCT, we may ask TRICS to shut off the electrical outputs of some cards (in particular the L1 Accept FOMs) so that we don't confuse the front-ends. - during COOR programming, TRICS already adds a micro-pause around any programming of any AONM or FOM/FOM++ cards in order to suppress SpTrg firing during that time. This may however not be enough as the output of the FOM or FOM++ could still blip while we program it and send a L1 Strobe to all GeoSect's or a L1 Accept to some GeoSect. It is not clear what to do about that, as shutting off the output of the FOM++ is not desirable in case a L2 decision needs to be serviced during that time. We may need to also hold off L2 decisions. Monday's L2fw SCT tests left us with the following symptoms: - L1 Fired TRMs: a few channels were missing some bits always the same channels, but somewhat flakey too. - AONM Reject Monitor Readout always 0x0000 instead of 0xffff for all channels - FOM Reject Monitor Readout always 0xf000 instead of 0xffff for all channels - L2 Helper sometimes stays in quiescent state even though we could see the TRMS fifo counters increment, the Auxi TRM BSF generate a FIFO Not Empty, and the L2 Helper receive the FIFO not empty. - L2 Helper can get deaf/stuck in quiescent state described above, and clocking more data in the TRM fifos does not change anything once it is stuck. - SCT Initializing the L2 Helper gets it out of its deaf/stuck state, but it sometimes gets stuck again before the required 4 L1 Helper sweeps; sometimes after 2, 3 or 4 L1 Helper sweeps. - L2 Helper did not wait for "Approval Removal" when we manually Approved a L2 cycle. - The Auxi Data TRM was not included in SCT and thus not initialized by SCT initialize. This means that the FIFO is not reset by SCT Init. This however does not explain the behavior of the L2 Helper which is supposed to be level sensitive, not edge sensitive. Trics Changes on Tuesday: The AONM and FOM readout problems were believed to come from a missing clock enable on their shift register, plus obsolete programming of their BX History Shift Control Register. Trics V8.6 Rev D - route P1(14) -> HQ(2) (Send L2 Decision) to AONMs and FOMs - initialize BX History Shift Control Register of AONMs, FOMs and TRMs to 0 - Include the Auxi Data TRM in SCT to be able to initialize it, but the card is not programmed and not verified. Fpga Changes on Tuesday: A new TRM fpga was prepared to try and learn more. Instead of driving the input of the Monitor Data shift register from the output of the receiving FIFO, drive it from the output of the output latch and update it with a delayed version of the same Input_TRM_Read_Enable signal. The L2 Helper was updated to include new scalers. Tests on Wednesday morning: - L1 Fired TRM using the OLD Fpga design (2_1) same kind of problem for the same few channels, but the current time slice is now also weird first time: 0x0222 instead of 0xffff for channels 0:3 subsequent: 0xf222 instead of 0xffff This is not understood - AONMs Reject Only get the current time slice Errors matche the L1Fired TRMs e.g. 0x2000 instead of 0xffff for channels 0:3 - FOMs Reject Only get the current time slice e.g. 0xf000 instead of 0xffff for channels 0:3 FOMs are initialized to obey any input, an idea is to let SCT initialize them to obey a single input each. - We never saw a case of "L2 Helper not waiting for approval" We don't know if it is because of the new L2 Helper with new resource routing or the inclusion of the Auxi Data TRM - L1 Fired TRM using the NEW Fpga design (3_1) same kind of problem but significantly WORSE, i.e. more channels are missing the current time slice seems to be there this time. The AONM readout matches the TRM readout. Current ideas: - Oops! P1(14) (Send L2 Decision) is not routed to M122 Bottom, and the L2 Helper does not generate a copy for M122 bottom. This explains the lack of history in AONM and FOM monitoring readout. - We are concerned that letting the L1 Fired TRM increment its read counter at the same time as it latches the Receiving Fifo output may be the source of the problem. (Lowering the load on the output of the Receiving Fifo seemed to make things worse). - There is no real rush to update the Fifo read counter, but there was no room for additional timing signal. There is however the maginot line which is not used, already routed, and generated by the L2 Helper. - The idea is to separate the "update your output latch with the current output of the receving fifo" from the "increment your read counter and shift the data for future monitoring output" (the capture monitoring data comes last). - Also use the same maginot line signal to shift the data in the AONMs and FOMs. This will have had the apropriate delay AND and another advantage over using the "Send L2 Decision" signal. A characteristic of the "Send L2 Decision" signal is that it is delayed until the L2BAD has decided the cycle could end (and a tick slot is available). If TCC has to force a Capture monitoring data, it is then not 100% defined what exactly ends up in the Monitor Data for the L2 AONMs and FOMs. Using the maginot line pulsed at a fixed time after the beginning of the L2 cycle, and independently of the completion of the L2 cycle gives a cleaner end result. Note that the Capture Monitoring Data that follows the L1 Qualifier (currently with every L2 cycle) still only happens after the "Send L2 Decision". 19,20,21 APR-2000 At: Fermi TOPICS: Work on installing the Hub-End, Work on receiving And-Or Terms from Dean, Install the last 6 cables for the L2 Busy and L2 Reject that run from the L2 FW in M122 to the SCL Hub-End in M124. Dig out the cable to carry the And-Or Input Terms from Dean's Calo Pulser to the Trig FW. This is a full setup with Sub-System Gap and Strobe. This is cable #4 in the Trig-Acq-Sync Run I cables on the West wall. Work on filling in the SCL Hub-End and putting various people into their Geographic Sections: Boris wanted Muon to be in Geo Sect 38 and 3B hex (56 and 59 dec) 38 is called East CMETP and is on the 3rd floor 3B is called East CMESC and is on the 3rd floor Dean wanted Cal to be in Geo Sect 4A and 4D hex (74 and 77 dec) 4A is on the 3rd floor 4D is the Cal 5k Test Stand on the 1st floor which does not readout to L3 as far as I know Marvin wants SVX to be in Geo Sect 66 and 67 hex (102 and 103 dec) 66 and 67 are on the 3rd floor Put the SCL Test Recvr in Geo Sect $48 Note that we have been triggering the Logic Analyzer on the L1 Issued signal on the SCL so even though we will typically not sent L1 Accepts to this Geo Sect the logic analyzer still triggers OK. Get from Ted and Tran and Neal Two final version FanOut Boards SN 003, and 004 both Rev B 18 Status Concentrators final eco boards 7 SCL Receivers with SMB and 0nsec Running with 3 Fanouts and 3 Status Concentrators. Checked the power supply voltages to the hub-end crate and all is OK. Philippe moves us to version TRICS 8.5 Rev 5 to pick up some changes that I asked for: Different buttons, one for each detector group, that take advantage of now having people in their Geo Sections and automatically doing an SCL Init when COOR says Begin Run. Remove the temporary cabling that we had used with Dean to send a "direct in Cal Pulser Trigger" to And-Or Term 224 and remove the L1 Fired Strobe that we had been sending to Dean as a "Run I type trigger". DATE: 20-APR-2000 At: Fermi TOPICS: new Clock file Clock file version 26 moves the Subsystem Gap signal 25 RF buckets earlier so that the data is aged longer in the TRM FIFO. The Subsystem Strobe was not moved; the Subsystem Gap now rises only 18.8 ns before the Subsystem Strobe. The amount of aging that goes on in the TRM FIFO was measured by repeatedly reading the FIFO read and write counters and subtracting the read counter from the write counter (after determining the stage in the counter for each of the addresses). A weighted average was made and then multiplied by 132 ns. The resulting number was 2.715 us. Boris seems to be happy running with this setup for the moment. DATE: 12,13,14-April-2000 At: Fermi TOPICS: Connect the Vesda to the M12x racks, Connect the Logic Analyzer to look at L1 and Current Turn Number, Change the Tick&Turn Scaler EXO, Work on L2 SCT, Fix L2 Stand Power Supply problem, Connection of the "smoke signal" from the Run II Trig Framework racks to the VESDA in M113. CPVC pipe is used to connect racks M122, M123, M124 to the VESDA. This is 3/4" ID pipe with a "T" in each rack that goes to 1/2" ID pipe. As the 3/4" sampling pipe passes through the air exhaust box on top of each rack it has 5 sampling holes of 1/8" diameter. These sampling holes face into the rack exhaust air flow. The "T" on the 3/4" sampling pipe at each rack switches to 1/2" pipe which passes into the rack where it runs across the top back of the rack. It is assumed that this section of the rack would not have much air flow and thus smoke could collect there. The 1/2" pipe across the back of the rack has a total of 8 1/8" sampling holes and the plugs at each end of this pipe have 3/16 diameter holes. The end of the 3/4" diameter sampling pipe in rack M122 is opened by having 4 3/8" holes near the end inside M122. Need to bring: 1x 3/4" "T", 4x 3/4" 45 deg elbow, 1x 3/4"-3/4"-1/2" "T" 4x 3/4" splices Change the Logic Analyzer setup so that instead of looking at all 16 bits of the L1 Turn Number it is now looking at 8 bit of L1 and 8 bit of Current Turn Number. The Logic Analyzer file that has all 4 probes of stuff defined is SCLREC13.dat. The overall setup of the logic analyzer now is: SCL Receiver Logic Logic Test Card Analyzer Analyzer Signal Connection Pod/Channel Display ----------------------------- ------------ ----------- ----------- SCL Receiver 7 MHz Clk Con 2 Pin 6 Pod 1 Ch 0 SCL Clock Beginning of Turn Marker Con 4 Pin 15 Pod 1 Ch 1 Beg of Turn Sync Gap Marker Con 4 Pin 13 Pod 1 Ch 2 Sync Gap Live Beam Crossing Marker Con 4 Pin 14 Pod 1 Ch 3 Live BX Cosmic Gap Marker Con 4 Pin 12 Pod 1 Ch 4 Cosmic Gap Spare BX Marker Signal Con 4 Pin 16 Pod 1 Ch 5 Spare Marker L1 Accept Issued Con 9 Pin 19 Pod 1 Ch 6 L1 Issued L1 Acpt to this Geo Section Con 4 Pin 19 Pod 1 Ch 7 L1 Geo Sect L2 Decision Issued Con 9 Pin 18 Pod 1 Ch 8 L2 Issued L2 Accept to this Geo Sect Con 4 Pin 18 Pod 1 Ch 9 L2 Accept L2 Reject to this Geo Sect Con 4 Pin 17 Pod 1 Ch 10 L2 Reject SCL Initialize Con 9 Pin 17 Pod 1 Ch 11 SCL Init L1 Qual 0, L3 Trans Num 0 Con 1 Pin 19 Pod 1 Ch 12 \ Bus L1 Qual 1, L3 Trans Num 1 Con 1 Pin 18 Pod 1 Ch 13 | L1 Qual L1 Qual 2, L3 Trans Num 2 Con 1 Pin 17 Pod 1 Ch 14 | 3:0 L1 Qual 3, L3 Trans Num 3 Con 1 Pin 16 Pod 1 Ch 15 / Hex Current Beam Crossing Num 0 Con 4 Pin 11 Pod 2 Ch 0 \ Current Beam Crossing Num 1 Con 4 Pin 10 Pod 2 Ch 1 | Bus Current Beam Crossing Num 2 Con 4 Pin 9 Pod 2 Ch 2 | Cur Current Beam Crossing Num 3 Con 4 Pin 8 Pod 2 Ch 3 | BX Current Beam Crossing Num 4 Con 4 Pin 7 Pod 2 Ch 4 | Num Current Beam Crossing Num 5 Con 4 Pin 6 Pod 2 Ch 5 | 7:0 Current Beam Crossing Num 6 Con 4 Pin 5 Pod 2 Ch 6 | Hex Current Beam Crossing Num 7 Con 4 Pin 4 Pod 2 Ch 7 / L1 Trig Num Beam Crossing 0 Con 9 Pin 11 Pod 2 Ch 8 \ L1 Trig Num Beam Crossing 1 Con 9 Pin 10 Pod 2 Ch 9 | Bus L1 Trig Num Beam Crossing 2 Con 9 Pin 9 Pod 2 Ch 10 | L1 L1 Trig Num Beam Crossing 3 Con 9 Pin 8 Pod 2 Ch 11 | Trig L1 Trig Num Beam Crossing 4 Con 9 Pin 7 Pod 2 Ch 12 | BX L1 Trig Num Beam Crossing 5 Con 9 Pin 6 Pod 2 Ch 13 | 7:0 L1 Trig Num Beam Crossing 6 Con 9 Pin 5 Pod 2 Ch 14 | Hex L1 Trig Num Beam Crossing 7 Con 9 Pin 4 Pod 2 Ch 15 / L1 Trig Num Turn Number 0 Con 11 Pin 19 Pod 3 Ch 0 \ Bus L1 Trig Num Turn Number 1 Con 11 Pin 18 Pod 3 Ch 1 | L1 L1 Trig Num Turn Number 2 Con 11 Pin 17 Pod 3 Ch 2 | Trig L1 Trig Num Turn Number 3 Con 11 Pin 16 Pod 3 Ch 3 | Num L1 Trig Num Turn Number 4 Con 11 Pin 15 Pod 3 Ch 4 | Turn L1 Trig Num Turn Number 5 Con 11 Pin 14 Pod 3 Ch 5 | Num L1 Trig Num Turn Number 6 Con 11 Pin 13 Pod 3 Ch 6 | 7:0 L1 Trig Num Turn Number 7 Con 11 Pin 12 Pod 3 Ch 7 / Hex Current Turn Number 0 Con 6 Pin 19 Pod 3 Ch 8 \ Current Turn Number 1 Con 6 Pin 18 Pod 3 Ch 9 | Bus Current Turn Number 2 Con 6 Pin 17 Pod 3 Ch 10 | Current Current Turn Number 3 Con 6 Pin 16 Pod 3 Ch 11 | Turn Current Turn Number 4 Con 6 Pin 15 Pod 3 Ch 12 | Num Current Turn Number 5 Con 6 Pin 14 Pod 3 Ch 13 | 7:0 Current Turn Number 6 Con 6 Pin 13 Pod 3 Ch 14 | Hex Current Turn Number 7 Con 6 Pin 12 Pod 3 Ch 15 / L1 Qual L3 Trans Number 4 Con 1 Pin 15 Pod 4 Ch 0 \ L1 Qual L3 Trans Number 5 Con 1 Pin 14 Pod 4 Ch 1 | L1 Qual L3 Trans Number 6 Con 1 Pin 13 Pod 4 Ch 2 | Bus L1 L1 Qual L3 Trans Number 7 Con 1 Pin 12 Pod 4 Ch 3 | Qual L3 | Trans Num L1 Qual L3 Trans Number 8 Con 1 Pin 11 Pod 4 Ch 4 | 15:4 L1 Qual L3 Trans Number 9 Con 1 Pin 10 Pod 4 Ch 5 | L1 Qual L3 Trans Number 10 Con 1 Pin 9 Pod 4 Ch 6 | The rest L1 Qual L3 Trans Number 11 Con 1 Pin 8 Pod 4 Ch 7 | of this | Bus i.e. L1 Qual L3 Trans Number 12 Con 1 Pin 7 Pod 4 Ch 8 | Bits 3:0 L1 Qual L3 Trans Number 13 Con 1 Pin 6 Pod 4 Ch 9 | is on L1 Qual L3 Trans Number 14 Con 1 Pin 5 Pod 4 Ch 10 | POD #1 L1 Qual L3 Trans Number 15 Con 1 Pin 4 Pod 4 Ch 11 / Known Gnd Pins are: Pin 20 on Con 1, 2, 4, 6, 9, 11 Con 9 Pins 12, 13, 14, 15, 16 Change the to Tick & Turn Scaler down load control file from TTS_10_1.EXO to TTS_11_1.EXO. This is to fix a problem of the L1 Trigger and the Current Turn Numbers sometimes being off by 1 or 2 when you run Single Chance Test. We still need to test to see if TTS_11_1 fixes this problem. Executing SCT Initialize for the first time after a FW Initialize causes a single L1 Accept Strobe. Executing SCT Initialize for the 2nd or "Nth" time causes L1 Accept Strobe to be asserted for about 200 millseconds. Fixed the lack of (completely loose) power return connection in the L2 Test Stand. They now have the supply that I delivered 23-FEB-2000 connected to something. Using the TCC Console push buttons to setup triggers right now has them (as requested) listening to the L1 and L2 Busy's form all 5 of the Geo Sections that are currently connected at the Hub-End. Recall that this can stop both L1 Accepts and the distribution of L2 Accept Decisions. End of the day on Friday ran 6k loops of SCT under 8.5 Rev 4. Most of the time available to test SCT at Fermilab was spent debugging the "No Fire on Pattern A" and the "Test Skip Next" Options. These test modes are now probably under control, modulo the issue we encountered at the time Philippe left on Friday, cf below. We found that there is one "Global Correlated DAQ Enable" scaler that needs to be corrected down by 2 counts (the length of the Skip Next signal) for loops when Skip Next is the only Correlated source of disable active for pattern A (there is always the Global DeCorrelated Disable #3 to guarantee the "No Fire on Pattern A" that prevents Pattern A from generating L1 SpTrg Fired). Further Skip Next tests, and longer runs, can be tried next week. One important lesson learned was that the new "No Fire on Pattern A" mode had to be further qualified to be useful to test the L2FW. The L1FW uses several of the 4 copies of the Global L1 Fired Strobe generated by the FOM++. It became clear that those four channels would have to remain programmed in lockstep by SCT in order to test the L2FW (e.g. a different FOM++ output is used to clock data into the L2 FW TRMs that hold L1 SpTrg Fired than the output used to clock the data into the L2FW TRM that holds the Auxiliary L1 Data and also generates the Fifo not empty signal sent to the L2 Helper). The decision taken for SCT was to add to the definition of the "No Fire on Pattern A" mode that these 4 FOM++ Channels be initialized as 128-input OR gates and never touched again by SCT. The "Test Skip Next" mode was first made to work without a similar constraint, but was converted to the same model for simplicity, and the 4 FOM++ Skip Next outputs are also programmed to fixed 128-input OR gates when this mode is selected. Once these issues were understood, we finally moved to trying SCT on L2FW Cards, starting with the L1 SpTrg Fired L2 FW TRM's. SCT immediately had problems at initialization time complaining that the initial state should have caused the L2 Helper to receive a Fifo not empty signal and be waiting for L2 cycle approval, but wasn't. The next thing tried was to read this input at the L2 Helper Fpga. The L2 helper register 19 showed this input (Bit #0) as low. Flipping the polarity of this wire made the helper state machine move to the state were it is waiting for approval. However it didn't change the state of Reg 19 Bit 0 and this issue is still NOT understood. Note that Bit #2 (i.e. 0x0004) is very often found set in Reg 19 as it shows that there is a "L2 Slot Available". The next step was to set the Logic Analyzer to trigger on a SCL L1 decision and thus verify that L1 Strobe was indeed being issued for that one crossing of pattern B during initialization. There was indeed a L1 SCL Frame but also a large number of additional L1 SCL frames. Sending a COOR-level initialize and following with a single SCT initialize on the same set of cards cleared the problem and produced the expected response of only one L1 SCL Frame. But any additional SCT Initialize would repeat the multiple L1 SCL frame symtoms. Removing L2FW cards (and thus leaving the L2 Helper in "normal mode") didn't change the symptoms Watching the length of the L1 Strobe on the Scope confirmed that the second (and third, fourth,...) SCT Initialize would generate a long L1 Stobe of about 200 milliseconds. Launching SCT and watching the randomly generated L1 Strobe showed only normal 132ns L1 Strobe on the Scope, and no SCT errors, even after multiple SCT initialize. Checking the FOM++ output scaler after the second SCT intialize also matched the scope measurement with about 24 MSB counts * 65k * 132 ns = .2 s (while it only incremented by 1 count at the first SCT Initialize as expected). Also the problem with L2 Helper not waiting for cycle approval at SCT initialize when L2FW cards were included seemed to go away as soon as we ran COOR-level Initialize before SCT Initialize. This wasn't investigated in great detail, but it may be explained by the flood of Fifo Not empty accompanying the long L1 Strobe. NO further L2FW SCT tests were done. A new problem that we noticed with L2FW SCT is that it will have to get smarter about predicting the initial state of the monitor output readout of all L2FW cards because of the information left in these fifos before the SCT Initialize. Philippe needs to check with Steve and understand whether it is possible to clear these fifos, or devise a method to clock something to fill these fifos with something predictable before SCT Initialize. Back to the long L1 Strobe: - It would be hard for TCC to "directly cause" a 200 ms L1 Strobe. The only mechanism currently envisioned would be to have Pattern B displayed for 200 ms instead of one 132ns crossing. - Until now, SCT initial state was to have no L1 Strobe (all FOM++ outputs low for pattern A and B) at initialize time; until this new "No Fire on pattern A" mode was introduced. If the cause of this long L1 Strobe feature has been around since the beginning, it couldn't generate noticeable symptoms. - Philippe's understanding is that SCT would catch this error if it happened during a test loop. - The "SCT Initialize" button goes one step further than just initializing the cards. It was thought useful to add a quick sanity check to the "Initialize" step, and all outputs are thus checked. SCT initialize bails out after the first card that fails, while a test loop goes through all the cards before aborting (if the option is selected). However SCT currently does not try checking Scalers at Intialize (even if the option is selected). The only scaler tested is the Time Zone Shift (not the increment) that Philippe added last week. It is thus NOT a FULL check of loop #0. But it seems that there is indeed something special about loop #0, different from loop #1. - A reason that the first SCT initialize would be different from the second one is that the second Initialize starts from the "test" state left by the first SCT Initialize instead of the "normal" state left by a COOR-level Initialize. - During SCT Initialize, the L1 Helper Function (like all cards) is first Initialized to normal COOR level mode, then initialized to SCT Test mode. - During the first SCT Initialize the L1 Helper is initialized twice to normal mode then once to test mode. During the second SCT Initialize, the L1 Helper is initialized once to normal mode and once to Test mode. Then it seems that the first timing signal sweep coming out of the L2 Helper may be weird, but subsequent ones are not. - Does the time scale 200 ms translate to something special for the L1 Helper pattern generator? - Another area to review is the usage and state of the bit that controls sweeping by the L1 Helper in Test mode (Timing Signal Control Status 0 (Test Mode) Reg 16 Bit 0). The initial state of this line during SCT initialize is high (also for COOR initialize, but this register is only valid in test mode) and SCT keeps the bit normally high and pulses it low when it wants to trigger the SCT helper. DATE: 11-APR-2000 At: Fermi TOPICS: Split AONM, FOM files Updated L2 TRM to l2_trm_2_1.exo. We now also have L1/L2 versions of AONM and FOML so I split the dci files just as was done for the TRM. l1_aonm.dci loads file l1_aonm_32_3.exo and l1_foml.dci loads l1_foml_1_2.exo. Note that UNLIKE the TRM's, the l1_aonm and l1_foml exo's were not reset to version 1 revision 1, we just kept the current version and revision numbers. For the L2 cards in M122 bottom, l2_aonm.dci loads l2_aonm_1_1.exo and l2_foml.dci loads l2_foml_1_2 At the same time, I switched the two EG AONM cards back to the standard l1_aonm exo's (they had previously been running with a different revision that was supposedly slightly faster). These changes were propagated to MSU, and the MSU_Config directory was updated to call the dci files from the DCF directory rather than the MSU_Config directory. DATE: 5,6,7-APR-2000 At: Fermi TOPICS: Work on Trig FW: Master Clock And- Or Terms, Skip Next, Move the SCL Hub-End Crate to Top, Two more Power Pans to Fermi. Moved the SCL Hub-End to the Top Slot in M124. Broke off two power studs doing this. Replaced with with studs from usused power bus. These studs are brass or copper. Logic Analyzer moved to the M125 rack between TCC and its monitor. Ted now says that we can have the SCL Hub-End parts in bulk this coming Wednesday. They are still testing receivers. Need to verify with Marvin the Cable order and the 0 vs 12 nsec issue. Brought two more Run II FW Power Pans to Fermi #12 and #13. Yes, the Skip_Next and the Skip_Next_N are now working. Details: We are running the new TDM FPGA that stretches the Skip Next into a "Skip_Next_Two" signal. Yes this works. The logic analyzer clearly says that we now skip two ticks. We may also be running the new this week FOM++ FPGA that tried to get the Skip_Next_N signals out faster. Need to check on this. In any case when you use the Skip_Next_Two and a Skip_Next_N it all appears to work OK, (no gaps in the skipping) and you see the following: Value in the Skip_Next_N Control Register Decimal Total Number of Ticks Skipped Decimal ------------------------- -------------------------------------- 0 4 1 5 4 8 8 12 11 15 This was done using the Skip_Next_N (0) which is And-Or Term #247 Skip_Next_N (0) is controlled by the lower half of the register at M123, Middle Crate, Slot 16, FPGA 11, Register 129 Tested the "Marker Signals" from the Master Clock that are delayed by the SCL Helper and then sent as And-Or Input Terms to the L1 FW. With this weeks cut of the SCL_Helper these are all working fine. All 5 of them are wired up and are listed in the following: Current list of And-Or Input Terms: And-Or Input Term Number Current Function - Source ------------ -------------------------------------------------- 0 Copy of the Master Clock Generated L1 Sub-System Gap Signal 1 Cosmic Low Rate 2 Cosmic High Rate and sometimes a Muon Pulser signal 95:80 Muon Triggers 224 Test Trigger From Dean's Calorimeter 242 Beginning of Turn Marker SCL Helper MSA_Out_48 243 Live Accelerator BX Marker SCL Helper MSA_Out_49 244 Sync Gap Marker SCL Helper MSA_Out_50 245 Cosmic Gap Marker SCL Helper MSA_Out_51 246 Spare Marker SCL Helper MSA_Out_52 247 Skip Next N #0 FOM++ MSA_Out_40 248 Skip Next N #1 FOM++ MSA_Out_41 249 Skip Next N #2 FOM++ MSA_Out_42 250 Skip Next N #3 FOM++ MSA_Out_43 251 Tick Selector #0 Tick & Turn Scaler MSA_Out_40 252 Tick Selector #1 Tick & Turn Scaler MSA_Out_41 253 Tick Selector #2 Tick & Turn Scaler MSA_Out_42 254 Tick Selector #3 Tick & Turn Scaler MSA_Out_43 255 Permanently Tied HI Worked with Jerry Blazey to make a new L1 Cal Trig Schedule. The Aug 15th and Jan 8th mile stones will go in the MOU. This week in FPGA Land: New cut of the SCL Helper FPGA to get the And-Or Terms that come from the Master Clock lined up with the right delay. New cut of the FOM++ FPGA to get the "Skip Next N" signals to become active 1 tick sooner than they were. Now they become active for controlling trigggers an a in the tick Edit the .dci file to move L2_Helper from 9_1 to 10_1. Edit the .dci file to move TDM MSA FPGA's from 21_2 to 22_1. This is the first version of the TDM that will stretch the Corelated Global Disable #3 input from 1 tick to 2 ticks in order to make the "Skip_Next" into a "Skip_Next_Two" so that the Skip_N signals have time to take effect. We have done nothing this week about seting thing up to use the new: L2_TRM, L2_AONM, or L2_FOM FPGA's with the L2 scalers. This is covered in Steve's message from 6-APR-2000 at 14:00 which also covers getting rid of some old junk stuff. Edit the D0_Config/Init_Post_Auxi.vio file so that it will now find the the SCL Hub-End Crate in the TOP crate of rack M124. That is change the VME address from $1980 0004 to $1880 0004. This file contains the VME write to turn ON the Frame Clk in the Hub Controller. I have not brought files up to date at MSU. I guess after next week's file work to split the L2 designs that this should be done. Review of what we are sending up to L3. Recall that all of this passes through the Patch Panel on top of M124: Mask of Specific Triggers that fied at L1 and Passed L2 This comes from the 2 FM D-Latches in Slots 14,15 M122 Bottom We make all 128 lines of this and right now only the first 32 Spec Trig's are being run from the patch panel up to L3. L3 Transfer Number. This 16 bit number comes from the FM-Latch card in slot 20 of M123 Bottom. Note that on the Front PB for the FM-Latch card the "L3 Strobe" signal is patched on as the 17th pair. The L3 Strobe signal comes from the L2 Helper. We have ready to send to L3 the Geographic L1 Trigger Number that belongs to the L2 Accept. This is a 24 bit number carried on two cables. It also comes from the FM-Latch in the bottom of M123 slot 20. Right now L3 does not want this information and there are no cables carrying it from the patch panel up to L3. Review what we are receiving from L3: Disable Individual Specific Triggers. These plug into Disable Individual 0 patch panel on top of M123. Right now only the first 32 Spec Trig's have disable cables coming from L3. List of SCL stuff that I currently think I have: 1x Hub Controller 1x Fanout with 7 transmitter modules 1x Status Concentrator 2x Receivers with SMB 12 nsec Marvin 1x Receiver with MCX 12 nsec Dean 1x "broken" receiver 1x Receiver with MCX (wrong side) 12 nsec Test Card --> Logic Analyzer 2x Receivers with MCX 0 nsec Boris The SLIC card looks very nice, floor plan and routing. They still are not using the Power Pan that Nikos was in a panic that I make for him back a month and a half ago or so. Did 11k loops of error free SCT at the end of the day on Friday (i.e. all the new FPGA's were in) with TRICS 8.5 Rev 4 DATE: 22,23,24-MAR-2000 At: Fermi TOPICS: L3 Disables and TRICS buttons, Spacing in time of the L1 Acpts with prescale, Cables to Hub-End, HSRO Note Book, And-Or Terms, New Clock File, Geo Section Cabling, Visit Neal and Ted, Install Temp SCL Cables to 2nd MCH, Cable the Skip Next N, Test of Status signals coming back, Listened to L1 Muon Trigger And-Or signals. Because of the problem trying to run triggers from the TRICS buttons when L3 has all the L1 triggers DISABLED, Philippe has changed the setups that you get the TRICS buttons so that they IGNORE the L3 DISABLES. Start looking at the un-even firing of the L1 Trig's when you have a prescale and a term that selects a given crossing in a turn. Steve dug into what the expected triggering should look like. This requires careful thinking to understand the effect of the prescaler's 64 bit shift register followed by the straight divider. Recal the length of some of the FW to SCL Hub cables: L2 Busy is 1x 34 pin connector then 5 twisted sections then 2x 16 pin connectors. L2 Reject is 1x 34 pin connector then 7 twisted sections then 2x 16 pin connectors. L2 Accept is 1x 34 pin connector then 3 twisted sections then another 34 pin connector then 5 twisted sections then 2x 16 pin connectors. L1 Accept is 1x 34 pin connector then ?? twisted sections then 2x 16 pin connectors. L1 Busy is 1x 34 pin connector then ?? twisted sections then 2x 16 pin connectors. Brought the HSRO 3ring book to Fermi. Kirsten will keep it here. To keep it of finite thickness, I pulled the "Command Receiver" section, the section with data sheets about HP G-Link chips that we are not using, and the old version of the VRB document. I will bring all this back to MSU and put it in a supplemental reference material for HSRO 3ring book. Kirsten is getting a current version of the VRB document to put into the Fermi HSRO 3ring book. The idea of the Fermi 3ring HSRO book is to have: G-Link Finisar Transmitter stuff, VRB and VRBC stuff, and Zeller VBD stuff. Need to bring more spools of 34 conductor twist-flat cable to Fermi. Current list of And-Or Input Terms: And-Or Input Term Number Current Function - Source ------------ -------------------------------------------------- 0 Copy of the Master Clock Generated L1 Sub-System Gap Signal 1 Cosmic Low Rate 2 Cosmic High Rate and sometimes a Muon Pulser signal 95:80 Muon Triggers 224 Test Trigger From Dean's Calorimeter 247 Skip Next N #0 FOM++ MSA_Out_40 248 Skip Next N #1 FOM++ MSA_Out_41 249 Skip Next N #2 FOM++ MSA_Out_42 250 Skip Next N #3 FOM++ MSA_Out_43 251 Tick Selector #0 Tick & Turn Scaler MSA_Out_40 252 Tick Selector #1 Tick & Turn Scaler MSA_Out_41 253 Tick Selector #2 Tick & Turn Scaler MSA_Out_42 254 Tick Selector #3 Tick & Turn Scaler MSA_Out_43 255 Permanently Tied HI We are now running on version 25 of the Clock File. This version has added the Spare Marker signal that is asserted every 396 nsec (lined up with the Interaction Marker) and continues in the Gaps. L3 Disable is plugged back into the Individual Disable 0 Inputs and tested with the TRICS V8.5 Rev 4 that the resulting L1 Trigger do Ignore the L3 Disable. I told Sean, and Jae, and Dean that we were doing this. As of right now we have 5 channels of SCL Hub-End. They are 0, 1, 2, 3, 5 Geographic Section Number Cable Label Typically connected to ---------- ------------ ------------------------------------ 0 3rd Floor #1 Muon Front-End i.e. Boris and Victor 1 3rd Floor #2 Muon L1 Trig i.e. Dave This has also been Dean Cal on the 3rd floor 2 2nd Floor #1 This will be Marvin on the 2nd floor 3 2nd Floor #2 This will be Marvin on the 2nd floor 5 us SCL Receiver in Test Card -> Logic Analyzer As of late this afternoon we are running on the new unmerged exo's for the two types of TRM's. We have NOT tested this very much but it does appear to be running OK. SCT runs and the Logic Analyzer says that the L2 Decisions have good data in them. Kirsten and I did try the "pull off the Sub-System Sync Gap signal" test and saw the appropriate FPGA say "Missing Sync Error". When we plugged back in the Sub-System Sync Gap the TRM FIFO synced back up and the error cleared. We did try listening to the And-Or Input Term cable from L1 Muon Trig. This was with the old TRM exo's. We get their Sync Gap signal back about 1.7 usec after we send it out. It is this fast because they currently have one of there processing stages missing. They are plugged into And-Or Terms 95:80 which should be their real home. We did trigger on their Term #80 and saw the rate change in the expected way as they changed stuff in their trigger. Looking at the TRM FIFO registers it said that it was happy and in sync. I forgot to write down some of the "pointer pairs" to see how deep the FIFO was running. We are running Dean on a SCL with a Status line coming back. We run 1 Hz of L1 Accepts and then Dean artificially asserts L2 Busy. The L1 Accepts continue and we can see that he gets no additional L2 Decisions. If he removes the L2 Busy within a rational amount of time then we can see a bunch of L2 Decisions flow into his system. If he keeps L2 Busy asserted for too long (and does not assert L1 Busy) then he scrambles data and gets out of sync. So with this first look all the L2 Busy machinery and code is working. Dean also artificially asserted L1 Busy and it had the expected effect. We ran a lot of high rate L1 Acpt - L2 Decision pairs into Deans stuff tonight. 700 and 1000 Hz. He was checking the Trigger Number in the L2 Decisions to see that they matches the number that he captured with the L1 Accept. But if the check failed he did nothing about it so we did not prove a lot about how well the L2 FW is running. What we did see is at the end of N minutes of high rate running when we stopped he had received an equal number of L1 Acpts and L2 Decisions. So that shows that the L2 FW is not completely flakey, Kirsten got the Master Clock running with the SCL Spare Marker making the 396 nsec clock for Marvin and Co. She has the jump in this pattern positioned in the middle of the gaps. It is all properly lined up on the SCL Interaction marker (first try). This is version 25 of the clock file. Run 10k loops of SCT with Trics 8.5 Rev 3. I installed the cabling to bring the 4 Skip_Next_N signals from the FOM++ and connect them to un-FIFOed And-Or Term Inputs. These connections are: And-Or Input Term Number Current Function - Source ------------ -------------------------------------------------- 247 Skip Next N #0 FOM++ MSA_Out_40 248 Skip Next N #1 FOM++ MSA_Out_41 249 Skip Next N #2 FOM++ MSA_Out_42 250 Skip Next N #3 FOM++ MSA_Out_43 The only testing that has been done so far is that when I program all 4 Skip Next comparators to the value $04 that the resulting And-Or Term is actually asserted for 5 ticks with each firing of L1. I still need to check that they are all cables correctly, i.e. the right output to the right And_OR input. Installed two temporary cables to 2nd MCH for Marvins testing of the VRBC. Date: 22-March-2000 At: Fermi TOPICS: new clock file On d0ola, ~trgmgr/master_clock/config_files/clkSetup.v24 This file shifts the Subsystem Gap signal five 132 ns Ticks later so that it now rises approximately 1120 ns after the Synch Gap. DATE: 15,16,17-MAR-2000 At: Fermi TOPICS: Work with FW and Commissioning, Disables from L3, Cables for SCL, And-Or Boris is cranked up (again) to have all the SCL Receivers moved to simultaneous new Data and 7 MHz clock edge. I'm supposed to contact everyone and organize this. Sten Hansen (phone 4027) They use the 50 MHz clock to ingest data from the SCL Receiver. Tested and started using the L3 disables from the L3 system to the Trig FW. This is now hooked up. TRICS 8.4 has the L1 Spec Trigs by default OBEY the disables from L3. Measure the SCL cable lengths again LMR-100 cable from FanOut Front Panels to the back of the Patch Panel 5 ft SCL Coax Front of Patch Panel to the vert up 2 ft Vert up 4 1/2 ft Top of vert up to hole going to 2nd + 1 1/2 ft ------------ 8 ft SCL Flat Cable Out of top crate and over to the vert up 6 ft Vert up 5 ft over to hole going to 2nd 2 ft ------------ 13 ft On 2nd Out of the hole to floor level 2 1/2 ft Cross the aisle to front of South row of racks 2 ft Run to the far rack 22 ft Vert to top of rack 7 ft To the back of the rack 2 ft ------------ 35 1/2 ft Going to 3rd Out of the 2nd floor hole to floor level 2 1/2 ft To the air conditioner M224 corner 1 1/2 ft Up the air conditioner M224 corner 7 ft To the ceiling 4 ft To the hole going to 3rd floor 3 ft Accross to the front of the South row of racks 5 ft Up to the level of the floor on 3rd 2 1/2 ft Run to the far rack 21 ft Vert to top of rack 7 ft To the back of the rack 2 ft ------------ 55 1/2 ft Serial Coax Short 43 1/2 ft -- round to --> 44 ft Serial Coax Long 63 1/2 ft -- round to --> 64 ft Flat Status Short 48 1/2 ft -- round to --> 49 ft Flat Status Long 68 1/2 ft -- round to --> 69 ft Visit Neal and then send him the final word drop dead list of SCL cables. This week they put the holes in the ceiling to 2nd floor. All racks are now completely full of little pieces of metal. Ran a second SCL cable to the 3rd floor. Current list of And-Or Input Terms: And-Or Input Term Number Current Function ------------ --------------------------------- 0 Copy of the Master Clock Generated L1 Sub-System Gap Signal 1 Cosmic Low Rate 2 Cosmic High Rate and sometimes a Muon Pulser signal 224 Test Trigger From Dean's Calorimeter 251 Tick Selector #0 252 Tick Selector #1 253 Tick Selector #2 254 Tick Selector #3 255 Permanently Tied HI Trigger Setup Buttons on TRICS Master Command Files Muon Setup #1 is just term #251 and a prescale by 48k to 1 Hz Muon Setup #2 is just term #2 and a prescale by 48k to 1 Hz Both of these are running a prescaler against a once per turn signal and they fire in a very non evenly spaced way. 1.7 sec, 0.3 sec, ... We should confirm that this is what we expect and think about how to run it evenly if needed. DATE: 8,9,10-MAR-00 At: Fermi TOPICS: Work on getting the L2 FW to run. Location of the Crate Layout: Crate ID Numbers, Geographic Section Num. http://niuhep.physics.niu.edu/~fortner/d0/ALGO/UNPACK/ Now have installed Transmitters in the Fanout Mmodule for Geo Sections 0,1,2,3,5. Need to edit the L2_Cabling doc to remove the mention of Send_L2_Decision being a P1 line in M122 Bottom. Need to bring / purchase some hole plugs for the LED holes in the front of the FM card front panels. None of the 3 Helper Functions (L1 HLP, SCL, L2 HLP) need to receive the FW Tick Clk. SG is going to update the Helper Function documentation and DE will update the Master Clock to Helper Function document. The may make it much easier to route the Master Clock to Helper Function signals and reduce the number of SFO required for this. The special SFO for L2 Helper is currently setup as follows: Pins on the Enters the SFO Timing Cable from L2 Helper Ch Num Line the SFO on MSA_In Signal Name ------ ------ ----------- ---------- ----------------- 0 2 19,20 not used Beginning of Turn 1 7 15,16 MSA_In_51 FW Helper Clock 2 3 11,12 MSA_In_21 Live BX Marker 3 0 7, 8 not used FW Tick Clock Install a Gray wire single signal to get a delayed copy of the L1 Accept Strobe signal to the Tick and Turn Scaler MSA_In(0) to act as the Write signal to the FIFO in the Tick and Turn scaler. This signal is delayed about 30 nsec Plastic PVC Pipe to get the VESDA over to the Run II Trigger Framework. Need about 20 ft of pipe to run along the back of the L1 Cal Trig and then about 10 feet of pipe to make the hope over aisle to the Trig FW. This pipe is about 3 3/8" in circumference. The Logic Analyzer files that have all 4 probes of stuff defined are SCLREC09.dat and SCLREC10.dat. The overall setup of the logic analyzer now is: SCL Receiver Logic Logic Test Card Analyzer Analyzer Signal Connection Pod/Channel Display ----------------------------- ------------ ----------- ----------- SCL Receiver 7 MHz Clk Con 2 Pin 6 Pod 1 Ch 0 SCL Clock Beginning of Turn Marker Con 4 Pin 15 Pod 1 Ch 1 Beg of Turn Sync Gap Marker Con 4 Pin 13 Pod 1 Ch 2 Sync Gap Live Beam Crossing Marker Con 4 Pin 14 Pod 1 Ch 3 Live BX Cosmic Gap Marker Con 4 Pin 12 Pod 1 Ch 4 Cosmic Gap Spare BX Marker Signal Con 4 Pin 16 Pod 1 Ch 5 Spare Marker L1 Accept Issued Con 9 Pin 19 Pod 1 Ch 6 L1 Issued L1 Acpt to this Geo Section Con 4 Pin 19 Pod 1 Ch 7 L1 Geo Sect L2 Decision Issued Con 9 Pin 18 Pod 1 Ch 8 L2 Issued L2 Accept to this Geo Sect Con 4 Pin 18 Pod 1 Ch 9 L2 Accept L2 Reject to this Geo Sect Con 4 Pin 17 Pod 1 Ch 10 L2 Reject SCL Initialize Con 9 Pin 17 Pod 1 Ch 11 SCL Init L1 Qual 0, L3 Trans Num 0 Con 1 Pin 19 Pod 1 Ch 12 \ Bus L1 Qual 1, L3 Trans Num 1 Con 1 Pin 18 Pod 1 Ch 13 | L1 Qual L1 Qual 2, L3 Trans Num 2 Con 1 Pin 17 Pod 1 Ch 14 | 3:0 L1 Qual 3, L3 Trans Num 3 Con 1 Pin 16 Pod 1 Ch 15 / Hex Current Beam Crossing Num 0 Con 4 Pin 11 Pod 2 Ch 0 \ Current Beam Crossing Num 1 Con 4 Pin 10 Pod 2 Ch 1 | Bus Current Beam Crossing Num 2 Con 4 Pin 9 Pod 2 Ch 2 | Cur Current Beam Crossing Num 3 Con 4 Pin 8 Pod 2 Ch 3 | BX Current Beam Crossing Num 4 Con 4 Pin 7 Pod 2 Ch 4 | Num Current Beam Crossing Num 5 Con 4 Pin 6 Pod 2 Ch 5 | 7:0 Current Beam Crossing Num 6 Con 4 Pin 5 Pod 2 Ch 6 | Hex Current Beam Crossing Num 7 Con 4 Pin 4 Pod 2 Ch 7 / L1 Trig Num Beam Crossing 0 Con 9 Pin 11 Pod 2 Ch 8 \ L1 Trig Num Beam Crossing 1 Con 9 Pin 10 Pod 2 Ch 9 | Bus L1 Trig Num Beam Crossing 2 Con 9 Pin 9 Pod 2 Ch 10 | L1 L1 Trig Num Beam Crossing 3 Con 9 Pin 8 Pod 2 Ch 11 | Trig L1 Trig Num Beam Crossing 4 Con 9 Pin 7 Pod 2 Ch 12 | BX L1 Trig Num Beam Crossing 5 Con 9 Pin 6 Pod 2 Ch 13 | 7:0 L1 Trig Num Beam Crossing 6 Con 9 Pin 5 Pod 2 Ch 14 | Hex L1 Trig Num Beam Crossing 7 Con 9 Pin 4 Pod 2 Ch 15 / L1 Trig Num Turn Number 0 Con 11 Pin 19 Pod 3 Ch 0 \ L1 Trig Num Turn Number 1 Con 11 Pin 18 Pod 3 Ch 1 | L1 Trig Num Turn Number 2 Con 11 Pin 17 Pod 3 Ch 2 | L1 Trig Num Turn Number 3 Con 11 Pin 16 Pod 3 Ch 3 | L1 Trig Num Turn Number 4 Con 11 Pin 15 Pod 3 Ch 4 | L1 Trig Num Turn Number 5 Con 11 Pin 14 Pod 3 Ch 5 | L1 Trig Num Turn Number 6 Con 11 Pin 13 Pod 3 Ch 6 | Bus L1 Trig Num Turn Number 7 Con 11 Pin 12 Pod 3 Ch 7 | L1 | Trig L1 Trig Num Turn Number 8 Con 11 Pin 11 Pod 3 Ch 8 | Num L1 Trig Num Turn Number 9 Con 11 Pin 10 Pod 3 Ch 9 | Turn L1 Trig Num Turn Number 10 Con 11 Pin 9 Pod 3 Ch 10 | Num L1 Trig Num Turn Number 11 Con 11 Pin 8 Pod 3 Ch 11 | 15:0 L1 Trig Num Turn Number 12 Con 11 Pin 7 Pod 3 Ch 12 | Hex L1 Trig Num Turn Number 13 Con 11 Pin 6 Pod 3 Ch 13 | L1 Trig Num Turn Number 14 Con 11 Pin 5 Pod 3 Ch 14 | L1 Trig Num Turn Number 15 Con 11 Pin 4 Pod 3 Ch 15 / L1 Qual L3 Trans Number 4 Con 1 Pin 15 Pod 4 Ch 0 \ L1 Qual L3 Trans Number 5 Con 1 Pin 14 Pod 4 Ch 1 | L1 Qual L3 Trans Number 6 Con 1 Pin 13 Pod 4 Ch 2 | Bus L1 L1 Qual L3 Trans Number 7 Con 1 Pin 12 Pod 4 Ch 3 | Qual L3 | Trans Num L1 Qual L3 Trans Number 8 Con 1 Pin 11 Pod 4 Ch 4 | 15:4 L1 Qual L3 Trans Number 9 Con 1 Pin 10 Pod 4 Ch 5 | L1 Qual L3 Trans Number 10 Con 1 Pin 9 Pod 4 Ch 6 | The rest L1 Qual L3 Trans Number 11 Con 1 Pin 8 Pod 4 Ch 7 | of this | Bus i.e. L1 Qual L3 Trans Number 12 Con 1 Pin 7 Pod 4 Ch 8 | Bits 3:0 L1 Qual L3 Trans Number 13 Con 1 Pin 6 Pod 4 Ch 9 | is on L1 Qual L3 Trans Number 14 Con 1 Pin 5 Pod 4 Ch 10 | POD #1 L1 Qual L3 Trans Number 15 Con 1 Pin 4 Pod 4 Ch 11 / Known Gnd Pins are: Pin 20 on Con 1, 2, 4, 6, 9, 11 Con 9 Pins 12, 13, 14, 15, 16 DATE: 10-MAR-2000 At: Fermi TOPICS: L2 Framework Work on bringing L2 FW up @ FNAL. Several iterations of TRM are required to iron out all of the "L2 Mode" issues. There are really a lot more "L2 Mode" issues than originally thought. In retrospect the 2 TRM uses are different enough that it probably would have been easier to make 2 separate FPGA's. Most of the issues revolve around the FIFO Error Detection and Self-Synchronizing, which were designed with L1 in mind. Recall that there are no Gap Markers in L2 land to support FIFO Self- Synchronization, so L2 Mode effectively forces the SS Gap and FW Gap "high." But then recall that the L1 TRM FPGA consumes a tick of data in getting the scalers out of reset (i.e. the 1st data written into the FIFO is the data for the tick AFTER the SS Gap is set). In L1 use this is not a problem, but we can't just throw away a ST Fired Mask or Global L2 Answer Mask in the L2 application. So throw away Self-Synch in L2 Mode and resynch based on the Scaler Reset mechanism (using either Reg 2 to enable a Timing Signal reset, or Reg 3 to force a reset). TCC uses Reg 3 at Initialize time. But then this FPGA has problems in L1 Mode. When we remove the SS Strobe temporarily, the FPGA senses an Empty error as it should. But then when we put this signal back in, and clear the errors, the FPGA senses an Empty Error while coming out of resynch (if we turn off error detection, then re-synch, then turn on error detection, it is happy). The temporary solution is to use two different TRM FPGA's: trm_40_1.exo called from best_known_l1_trm.dci for L1 trm_46_1.exo called from best_known_l2_trm.dci for L2 This situation is not a permanent fix. We should either use one .exo for both applications, or have two distinctly different schematic designs called something like l1_trm and l2_trm. The problem right now is that the L1 TRM is an orphan, based on an old version of the TRM FPGA schematic. Note that the L1 TRM FPGA (40_1) has not been exhaustively tested. An earlier TRM FPGA received very extensive tests to fully verify its synchronization operation. At some point we will need to perform these tests on whatever TRM FPGA will be used in the final system. Philippe produced a version of TRICS which knows about the L2 FW. At initialize time, the L2 FW is set up to: - not require L2 Answers (i.e. L2_Helper is in "No L2 Global Mode") - L2 Answer TRM's display Test Data Register A at their output - L2 Answer TRM's have 0x000f in TDR A When using any of the MCF type Specific Trigger setups (i.e. "Autodisable" or "Prescale 7MHz" for ST 0), the L2 Framework then provides an L2 Accept for Geo Sect 0 about 100 us after every L1 Accept for Geo Sect 0. We verified the following electrical signals: @ SCL Receiver - L1 Accept set at good time - L2 Decision set at good time (~100 us after L1 Accept) - L2 Accept for Geo Sect - L2 Reject for Geo Sect - L1 Accept Number with L2 Accept matches L1 Accept Number with L1 Accept - L1 Qualifiers muxed with L3 Transfer number looks correct (L3 Xfr Num with L2 Decision, only increments with L2 Accepts, verified by forcing L2 Rejects by forcing L2 Answer TRM Test Data Register A to 0x0000) @ FM_Dlatch output for cable to L3 - L3 Transfer Number increments with L2 Accepts - L2 ST Fired Mask bit 0 set high always (with TRICS programming as above) - other L2 ST Fired Mask bits set low always (again with TRICS programming as above) - forced L2 Answer TRM TDR A to 0x0000 to see L3 Xfr Num not incrementing, L2 STF Mask bit 0 remaining low We also ran with a mix of L2 Accepts and L2 Rejects. We did this by starting up 2 L1 triggers (0 & 1) and forcing the L2 Answer TRM TDR A for ST 3:0 to 0x0001. We saw both L2 Accepts and L2 Rejects in this case. We verified that the L2 Framework starts up with: - Configure FW - Initialize FW - Initialize ST 0 - Autodisable & Enable ST 0 or: - Config FW, Initialize FW, Initialize ST 0 - Prescale ST 0 by 7M and Enable It is possible to go from "autodisable" to "prescale" by: - Initialize ST 0 - Prescale ... i.e. no need to Initialize (or Configure) L1 FW. We also verified that we can program 2 L1 ST's, always accept one and always reject the other. The L2 Accept/L2 Reject show behavior that is not fully understood. They appear to change very shortly after the L1 Accept, and again a somewhat longer time after the L2 Reject. They do not always do this. It may be an issue of running at zero FIFO depth where the FIFO's are essentially latches reflecting the output to the input. The Read Enable in this TRM does not control the updating of the output flip-flops, they are allowed to update every BX. Is there a way to fix this without breaking the rest of the TRM? Need to think about the pipeline carefully. Added functionality to Master Command File button UnNamed 1, it now sets up the Tick Select comparated tied up to AOIT 251 to select L1 Accept # 24 (decimal) as the fired tick. This is to support Boris' testing. The corresponding Current Tick is #50 (decimal). To run this for Boris, do: - Configure FW - Initialize FW - Unnamed #1 - Initialize ST 0 - Autodisable & Enable ST 0 (note: an event will "sneak" out during this time) - SpTrg #0 AO(251) & Enable - now each Autodisable & Enable ST0 will generate a L1 & L2 Accept with the appropriate BX#'s. At this time Boris wants his single trigger (or trigger train) preceded by an SCL Init. Moreover the single trigger (or trigger train) must occur within 100 seconds after the SCL Initialize (he stops looking after 100 seconds). Boris is not happy with the timing of the SCL Receiver output. He expected the 7 MHz clock output and the data bits to change simultaneously as in the draft 1995 documentation. Instead the data bits change ~10ns prior to the 7 MHz clock rising edge as in the final 1999 documentation. We see this behavior on our SCL Receiver. Boris' scope captures show the 7MHz clock rising edge about 20ns BEFORE the data change, but of course we don't know exactly what he's looking at. In any event, this SCL Receiver issue is not directly under our control. We have given Dean 1kHz of L1 Accepts / L2 Rejects and he has been happy. 1kHz of L2 Accepts is too high of a rate for his PC, but he has checked 1 Hz of L2 Accepts and been happy. Dean's SCL Receiver Mezzanine card apparently died and we gave him a new one. Running the L1/L2 Framework at 10 kHz appears to not quite work. At this rate the L2 Framework input TRM's quickly fill up their FIFO's. This is because the L1 Accepts come about every 100us, while the L2 cycle time is slightly longer than that (running with no L2 Global, we have a 100us delay to simulate the L2 processing time). The stream of data on the SCL lines quickly becomes garbled. If the L1 Spec Trig is disabled and the L2 Framework input FIFOs are allowed to drain, the system can be started up again at a rate less than 10 kHz and runs without trouble. The basic issue here is that we were running without any external rate control and had all FIFO error detection shut off. We need to figure out what type of L2 FIFO error detection we should be running, and what to do in the event of an error. This error detection is not needed for rate control in the real system (it is provided externally) but is good for finding problems. Two files associated with Master Command File Buttons have been changed: \trics\d0_config\scl_initialize.rio - first stretch the SCL initialize pulse to about 650us - eventually increased to about 2 ms \trics\d0_config\SpTrg0_Init.msg - first deallocate SpTrg 0 before re-programming it, to return it to a default initialized state without needing a full L1FW_init - Now send start Digitize to Geographic Sections 0:7 (was only 0 & 1) The current default version of Trics that will auto start is "Trics_II_V8.3 (Rev7)". There is a "Trics_II_V8.4 (Rev1)" with the only addition that all SpTrgs will listen to the L3 disables, a.k.a. Individual SpTrg Disable #0. We ran a few thousand loops of SCT to verify that the addition of the L2FW to TRICS initialization and COOR programming had not broken SCT (after minor updates to SCT, cf. release notes). Date: 7-March-2000 At: Fermi TOPICS: new clock file I have made a new clock file, version 23 in ~trgmgr/master_clock/config_files on d0ola. The source code is currently available on the d0lxbld machines in ~kmoore/clkSetup_new.c This new file 1) moves the Beginning of Turn so that the first live crossing corresponds to Current BX Number 7 2) moves and lengthens the Synch Gap so that it is the same as the Cosmic Gap but happens only once per turn 3) adjusts and lengthens the Subsystem Gap so that it is positioned correctly with respect to the Synch Gap 4) adjusts the Cosmic Gap so that it isn't active until the time when the next live crossing marker would be asserted if it weren't a gap period The Subsystem Gap is asserted approximately 460 ns after the Synch Gap and is the same length as the new longer Synch Gap. The Subsystem Gap still makes its transitions approximately 76 ns before the Subsystem Strobe. The new Synch Gap makes its transitions approximately 54 ns before the Tick Clock and is about 2250 ns long. The TRM FIFO still seems to be able to synch without any difficulty. When it is synched (using Subsystem Gap), the Current BX number is 0x10 and the L1 Accept BX number is 0x95. Date: 6-March-2000 At: Fermi TOPICS: clock code To modify the clock code, first telnet to a d0lxbld machine (d0lxbld1 or d0lxbld3 are good, d0lxbld2 and d0lxbld4 are other possibilities). I don't think there is a trgmgr account on these machines yet. 0) rm -r onl_clock (if necessary) 1) cvs checkout onl_clock 2) setup -q build:mv162 onl_clock 3) cd onl_clock 4) gmake config 5) edit src/ioc/clkSetup.c 6) gmake rebuild To put the new clkSetup.c file back into cvs: 7) cvs -n update -A (to check that only clkSetup.c has changed) 8) cvs commit src/ioc/clkSetup.c 9) type in a comment to describe the changes 10) tell Fritz that there is a new version to be released Now copy the new executable to d0ola: 11) either use standard ftp or scp bin/Vx-mv162/clkSetup trgmgr@d0ola:master_clock/config_files/clkSetup.vX On d0ola, 12) cd /online/ioc/m68k/mv162/d0olct106 (for the trgmgr account, there is an alias: cdboot) 13) mv clkSetup clkSetup.old 14) cp ~trgmgr/master_clock/config_files/clkSetup.vX ./clkSetup On the d0lxbld machine, it may be necessary to add the following lines to your .cshrc file: setenv CVSROOT cvsuser@d0cvs.fnal.gov:/cvsroot/d0cvs setenv PATH $PATH':'$HOME/bin setenv EDITOR emacs setenv VISUAL emacs And these lines to your .login: setup xemacs setup cvs Additionally, I have commented out the lines #if ( ! -e ~/.noupsproducts ) then # setup cedit #endif DATE: 23,24,25-FEB-2000 At: Fermi TOPICS: Work on cabling the L2 FW, commissioning Integration Test Bring AONM Build B SN# 28B to Fermi. Bring another Run II FW Power Pan to Fermi. This is SN# 11 and will immediately go to L2 Land (Nikos). Bring Front Panels for the cable Pass-Throughs in M122 Bot,and bring R-PB's without resistors but with connectors. There were two problems getting CT to run on the L2 FW cables that were installed last week. The AONM in Slot #6 had a problem. Pull AONM SN# 15B from M122 Bottom Slot 6 and install AONM SN# 28B. Return AONM SN# 15B to MSU for repair. AONM SN# 15 reported problems on FPGA #16 in a bunch of locations: MSA 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 pin 231 232 233 234 235 236 237 238 239 3 4 5 8 9 10 11 MSA_Out 15 from Slot 10 was not making it to its destinations in slots 12 and 13. The problem was a pin not installed correctly into the adjacent socket on the triple stack of R_PB's that span slots 11,12,13 P2. Now CT is running OK so now replace the 5x R-PB's with resistors that were installed last week in locations that should have R-PB's without resistors. Run CT via: Configure with D0_L1FW_cnx/M122_M123_All_ct.dcf Register I/O with D0_L1FW_cnx/M122_M123_ct.rio Connectivity Test with D0_L1FW_cnx/L2.cnx Run 20k loops of CT with checking all connections. Cabling FW to the Hub-End: Swap the locations of the SCL Hub-End crate and the HSRO crate in M124 so that the SCL Hub-End is now the top crate in M124. Then 8 cables of each of the following 5 types are needed. All of these cables will be made from the 17 pair stock that has 24 inch twisted section and 26 inch unit cell. All cables (except the L2 Acept cables) have a 34 pin connector at one end and two 16 pin connectors at the other end. L1 Accept This is 3 twist sections long. It runs to M123 Mid slot 21 P2 & P3. This is the Pass-Through that has the L1 Accept signals from the FOM cards. L1 Busy This is 2 twisted sections long. It runs to the L1 Busy TRM's in slots 16 & 17 in M123 Top. L2 Busy This is 5 twisted sections long. It runs to the L2 BAD cards in M122 bottom slots 18, 19 P3. L2 Reject This is 7 twisted sections long. It runs to the front panels of the L2 Rej FOM's in M122 bottom slots 12 & 13. These cables use the cable pass through shelf in M122. L2 Accept Starting from the SCL Hub-End these are 5 twisted section long to reach the L2 BAD cards and then another 3 sections to reach the L2 Accept FOM's. The connection to the L2 BAD cards is via P2 at slots 18 and 19 in M122 bottom. The connection to the L2 Accept FOM's is via their front panels. These cables use the pass through shelf in M122. All of the cables that connect the SCL Hub-End to the L2 FW in M122 are routed through the back of the racks up near the top. They come down inside M122 in the back corner adjacent to M123. Control Path Cables to L3 These signals come from the front panels of FM-Latch cards in M122 bottom slots 14 and 15 and from the FM-Latch card in M123 bottom slot 20. The patch panel to connect to L3 is on top of M124. It will be the lower patch panel, i.e. under the SCL patch panel. All of these cables are the 24 inch twisted stock. the 4 cables going to M123 are 5 twisted sections long and the 8 cables going to M122 are 6 twisted sections long. Cut outs in the front panels of the cable pass through shelves. All cut outs are 1" deep and 2 1/8" wide. This can hold 8 of the twist and flat cables. M122: L2 Rej, L2 Acp, L1 Hlp L2 Hlp S.S. All of these are to the right. M123: Spare in center, L1 Trig Num and S.S. is to the right. M124: Hub Controler in the center, HSRO fibers and Spare and S.S. are to the either side of center. Dean's pulser has moved since the power outage last week. Kirsten and I found it now at BX 26 through 51 decimal. We have now been loading 38 decimal in the Tick Selector #0 control register to match up with Dean's signal. Need to bring to Fermi: At least one more R-PB with connectors but without resistors. DC cabling parts to move the SCL Hub-End crate to the top. Bars to support cables in the front of the three racks that come out of the cable pass through shelves. These should be an inch or two wide and 23" ? long. ECL pull down and terminator resistor packs for the P5 Global I/O connector on THE-Cards. 26 conductor twist and flat cable. The assembled and ready to go ECL active fanout box, one more cable clamp for the Carmen-PB More 16 and 34 pin cable connectors, more 34 conductor cable, Dan Wolff is the safety review person from the Accelerator Division. Friday was the integration test, i.e. we are not able to work on hardware. DATE: 24-FEB-2000 At: Fermi TOPICS: Ethernet and Master Clock After the power cut on the weekend, TCC's connection to the outside world was messed up. Pushing the reset button on the ethernet box fixed the problem. Additionally, the master clock booted properly after the reset (this may have been coincidental?), and it once again became possible to telnet to the terminal server t-d0-mch1. The clock has now been moved from port 16 to port 1. The clock hung again - when it was reset, the processor never even tried to talk to the fanouts. Fritz came to have a look, and he discovered that a file had been deleted. Specifically, in the boot directory there is a startup file clkSetup.st. This file does various things before eventually loading and spawning the clkSetup executable. One thing it tries to do is load the file ../d0App.dbd; this file was missing. To fix this, Fritz copied the file ../test.d0App.dbd to ../d0App.dbd. The clkSetup.st file then ran to completion and correctly loaded and ran clkSetup. Incidentally, at one point Fritz commented out the three lines dbLoadRecords("PCC.db","SCAN=5 second") dbLoadRecords("Sequencer.db", "SCAN=5 second") dbLoadTemplate("SFM_Template.db") and said that we don't actually need those yet. Also, version 3 of the clock file has been committed to CVS as version v00_00c. On d0ola in ~trgmgr/master_clock/config_files, the official release executable is stored as version 22. Version 22 and version 3 should have exactly the same timing signals, but they are not identical (e.g. for some reason version 22 is almost twice as large as version 3). DATE: 16,17,18-FEB-2000 At: Fermi TOPICS: Verify that the Turn Number Monitor readout is correct. work on installing L2 FW Cabling, Power up Master Clock rack, Tests with Muon controller. Tie up POD 3 of the logic analyzer to get 16 bits of the Geo Section L1 Trig Num Turn Number. See the 26,27,28-JAN-2000 Log Book entry for details about the rest of the Logic Analyzer connections. SCL Receiver Logic Logic Test Card Analyzer Analyzer Signal Connection Pod/Channel Display ----------------------------- ------------ ----------- ----------- L1 Trig Num Turn Number 0 Con 11 Pin 19 Pod 3 Ch 0 \ L1 Trig Num Turn Number 1 Con 11 Pin 18 Pod 3 Ch 1 | L1 Trig Num Turn Number 2 Con 11 Pin 17 Pod 3 Ch 2 | L1 Trig Num Turn Number 3 Con 11 Pin 16 Pod 3 Ch 3 | L1 Trig Num Turn Number 4 Con 11 Pin 15 Pod 3 Ch 4 | L1 Trig Num Turn Number 5 Con 11 Pin 14 Pod 3 Ch 5 | L1 Trig Num Turn Number 6 Con 11 Pin 13 Pod 3 Ch 6 | Bus L1 Trig Num Turn Number 7 Con 11 Pin 12 Pod 3 Ch 7 | L1 | Trig L1 Trig Num Turn Number 8 Con 11 Pin 11 Pod 3 Ch 8 | Num L1 Trig Num Turn Number 9 Con 11 Pin 10 Pod 3 Ch 9 | Turn L1 Trig Num Turn Number 10 Con 11 Pin 9 Pod 3 Ch 10 | Num L1 Trig Num Turn Number 11 Con 11 Pin 8 Pod 3 Ch 11 | 15:0 L1 Trig Num Turn Number 12 Con 11 Pin 7 Pod 3 Ch 12 | Hex L1 Trig Num Turn Number 13 Con 11 Pin 6 Pod 3 Ch 13 | L1 Trig Num Turn Number 14 Con 11 Pin 5 Pod 3 Ch 14 | L1 Trig Num Turn Number 15 Con 11 Pin 4 Pod 3 Ch 15 / Using logic analyzer we checked and verified that we can read from the Tick & Turn SM Monitor data and get the proper Turn Number Work on L2 FW Cabling Installed the L2 FW cables in the bottom half of the L2 FW block diagram. R-PB's with resistors that need to be replaced with R_PB's without resistors. M122 Lower Slot 11 P3, Slot 14 and slot 15 P2. M123 Middle Slot 19 P2 and P3. So I need to bring at least 5 R-PB's with connectors but without resistors. Need to bring more 34 pin connectors and 34 conductor wire. Need 3 front panels with cutouts for Pass-Through cables. Because there are no front panels on 3 slots in M122 Bottom I have been running with the M122 Top crate tunred OFF. M122 Middle needs to be on to make and ECL Hi for AO Term 255. Let's keep running with M122 Top turned OFF until I get front panels on the pass-throughts. I have done nothing to the software to run this way. Lots of red at configuration and then things work OK. I have not tried any Connectivity Tests on this newly cabled L2 FW. Also we need to test the new BSF exo files. If the building power has been off, then to power up our equipment you need to reset the RMI by pushing and holding it reset button for 5 seconds. Once the RMI is reset then you should have a "Global Permit" to our contactor box. I will add this to the Power Up instructions. To power up the Master Clock turn on the following in this order: Instrument Power Transformer Input Rack Monitor Fan Power Strip Clock +- 12Volt Push the RMI Reset Clock +5 -5.2 Volt At this point the Master Clock crate should wake up. It looks like it is setup so that the Fan Power Strip runs the fan and the Clock +-12 Volts enables the water flow. So both of these need to be on before you can reset the RMI. Worked with Mark to test 2 of his controller cards. He is now getting good Turn Number. He had bad solder connections on FPGA pins (opens and shorts). We got our SCL Receiver back from him. I have connected it and it works OK reading out into our logic analyzer. A Fermi safety inspection team when through sometime last week. We have been chewed on about a number of issues (running with no one around, exposed DC inside the racks,...) I think next week that I need to get water going and close the rack back doors. Last thing on Friday run a bunch of SCT and every this was happy. DATE: 14-FEB-2000 At: Fermi TOPICS: More Clock Files Ver Comments --- -------- 16 Subsystem Gap 148 RF Buckets later Subsystem Strobe 1 RF Bucket later to maintain correct phase with Subsystem Gap 17 Subsystem Gap 149 RF Buckets later Subsystem Strobe 2 RF Buckets later to maintain correct phase with Subsystem Gap 18 Subsystem Gap 150 RF Buckets later Subsystem Strobe 3 RF Buckets later to maintain correct phase with Subsystem Gap 19 Subsystem Gap 151 RF Buckets later Subsystem Strobe 4 RF Buckets later to maintain correct phase with Subsystem Gap 20 Subsystem Gap 152 RF Buckets later Subsystem Strobe 5 RF Buckets later to maintain correct phase with Subsystem Gap 21 Subsystem Gap 153 RF Buckets later Subsystem Strobe 6 RF Buckets later to maintain correct phase with Subsystem Gap DATE: 9,10,11-FEB-2000 At: Fermi TOPICS: Work on Testing the TRM FIFO, ECB Meeting, Work with Muon and Cal, Commissioning Meeting Still not certain how the "flpr" command works but it appears to know about both printers and queues. So for example flpr -h d0hp8k3 -q text filename Modification to a TOM The TOM in M122 Middle has been modified so that it makes some ECL outputs that are at a default state any time the power is ON. This is used for such stuff as providing a default HI to And-Or Term 255. This is TOM SN#20. The 4 default level outputs are on J2 pins 26,28,30,32 row E is the Direct and row D is the complement. This is a differential ECL LOW. Note that the TOM onboard 50MHz oscillator has been disconnected from pins 32 but the rock is still installed in its socket on this TOM. Start up TRICS 7.2 R3 and run auto disable triggers and verify that reading the Tick&Turn scaler Monitor Data for the Current BX and L1 BX numbers match what is seen on the logic analyzer. All looks fine. Testing of the TRM FIFO All of this testing is with TRICS 7.2 R3 and TRM exo 39.1 In all cases the Sub System Strobe is asserted for 3 ticks. Start the normal setup running and turn on FIFO error checking. Run with the normal timing file "V3" The logicanalyzer says it is firing at BX 20/06 Cur/L1. Reading the address counters we see: 1306, 0d03, 1c05, 0a07, 0f01, 1b04, 0415, 0217. Test to verify that if we move the Sync Gap Marker signal then the BX number of the L1 Accepts will follow. Go to timing file "V4" which has the Sync Gap Marker 2 ticks later than normal. The BX number of the L1 Accepts is now 22/08 Address Counter: 1b0b, 0d05, 0b01, 161e, 1804, 1e0f, 141c, 151d. Test to see that we have no problem is the Sub System Strobe and the TRM Clock occur at the same time. Timing file "V12" has the same relative timing of SS Gap wrt SS Strobe, they have been moved just enough so that the leading edge of SS Strobe happens at the same time as TRM Clock leading edge. The idea is to write into the FIFO at the same time as you read it. No problem. We are firing at BX 20/06 and typical address counter values are: 1d0b, 1d0f, 1718, 121f, 0c06, 001d, 0b14, 0912. Test to see that we can move the SS Gap two ticks of 132 nsec early. This is file "V13". Nothing else changes. We are still firing on BX 20/06 and typical address counter readings are: 1d0d, 1e0a, 1d0e, 1e0e, 0617, 0800, 151e, 0901, 161e. This should indicate to steps deeper in the FIFO than normal. Now move the SS Gap about as late as we can. Note that there is no change in the relative timing of the SS Gap wrt to SS Strb. We just want to test how short we can make the time spent in the FIFO. The SS Gap is issued by the Master Clock about 3.20 usec after the Sync Gap Marker. It fires at BX 20/06 and the TRM error register shows no errors. Typical reads of the address counter are: 1f1d, 1a1a, 0f0e, 1512, 0909, 1214, 1212, 0101, 0404, 191b, 1818, 1317, 0502. So part of the time the read address = the write address. I assume that this means that there is no un-read information in the FIFO. This test used timing file "V14". Try moving the SS Gap one tick of 132 nsec later. This is timing file "V15". The SS Gap is 3.33 usec after the Sync Gap Marker. Now it does not run. It fires 50% of the time at BX 21/07 and 50% of the time at BX 3f/25. Logic analyzer says these alternate. What did the address counter say ? What did the error register say ? (The error register read 0x0108, i.e. there was an Unexpected Subsystem Gap error. The address counter read 0x8080 some of the time, 0x80?? some of the time, i.e. the write address was incrementing, and some of the time both parts of the address counter were incrementing, e.g. 0x1c1a.) The next 4 tests all keep the SS Gap signal in its normal place and just move the SS Strobe in RF Buckets wrt SS Gap. The idea is to prove that the write side of the FIFO meats spec and has no special requirements. The SS Strobe is always asserted for 3 RF buckets and negated for 4. Normally we run with 4 RF buckets of setup and 3 of hold (SS Gap wrt SS Strobe). We make tests of: 1 setup 6 hold, 3 setup 4 hold, 5 setup 2 hold 6 setup 1 hold. So we have checked all of them but 2 setup 5 hold (and 0 setup 0 hold). So basically everything from only 18 nsec of setup to only 18 nsec of hold appears to work OK. ECB 2 1/2 hour Meeting We will only ever run with 3 fold symmetry. Because of tune shift and the problems going through CDF and D-Zero the Tevetron can only run with 3 fold symmetry. The other bunches, ones that would not be matched with their anti particle as they go through CDF and D-Zero have a lifetime of less than a second. We will never do "gapless" or moving gap running. We will only ever have the classical 3 Super Bunches and 3 Gaps type running. The three Super Bunches are of equal length and the three gaps are of equal length. The length of the gap could/will get shorter if/when they make a faster kicker magnet. They talk about making the gap as short as 400 nsec. This would get us back to the same "fill factor" as running with just one gap of the current 2.2 usec. Because there is no possibility of gapless running and because the gap may/will change in length, and because the SVX integrators can not be rest in one tick of 132 nsec, people want the Sync Gap Marker asserted for the full duration of one of the gaps (as it was originally specified) just like the Cosmic Gap Marker is asserted for the full duration of the cosmic gaps. The Accelerator will run at 396 for some time. The SVX systems (Si Vertex and Fiber Tracker) are going to switch and actually run the SVX chips with a 396 nsec Clock. This will be provided by the Spare Marker Signal on the SCL. This is a bit complicated because this does NOT evenly divide into 3 going around the ring. There will be one interval of 264 nsec in each of the thirds of the way around the ring. The 396 nsec clock pulses must line up with the "Interaction Marker" signals on the SCL during the Super Bunches. The all of the rest of each third is filled in with 396 nsec clock pulses except for one period of 264 during each third. This 264 nsec tick was specified to be at the Beginning, Middle, and End of the gaps. So we need to low pass filter this until it is understood. People want the Beginning of Turn Marker asserted in a very funny place. BOT is to be asserted so that the first live crossing of the first super bunch is Current BX number 7. I do not really understand this but Boris wants it and no one else cares where it is. Everything needs low pass filtering. Friday make the rounds of Dean, Boris, Fred, and Marvin. The Gap signals should become asserted during the SCL Frame that would have carried the first missing Live Crossing marker if this were not a gap. They are to remain asserted until the SCL Frame that carries the first live crossing marker of the next super bunch. The 264 nsec tick is to be in the middle of the Gap. COSMIC Low Rate is plugged into And-Or Input Term #1 COSMIC HI Rate is plugged into And-Or Input Term #2 I have left the Sub System Gap Plugged into And-Or Input Term #0 Need Tea, Kleenex, and soldering tip. Used up a spool of labeling tape The spool was "6mm 1/4" Laminated White Black Ink TZ-211". We have 2 more spools of it at Fermi. Need to get setup of the TRM FIFO error detection into the TRICS Initialize. Herman Haggerty showed me how to run the HV system for the Cosmic Ray counters. In the TrgMgr account on D0ola I made a subdirectory called "voltage". Some files were moved into it. the "testB.dat" file is the target voltages for the various channels. To run the program type "source setup-beamscint &" and a window will pop up. Follow instructions in this window to turn On Off ramp Up Down radio buttons to set the percentage of the full target values. To turn the AC power on/off to he HV supplies go to the 2nd floor of the MCH. At the top of rack M215 turn on the switches on the power distribution box labeled "Supply #4" and "Cooling". Supply #4 is also called the Cosmic Cap B. Then in rack M216 turn on the power supply chassis labeled Supply #4. Measure the Current in a couple of crates. Basically nothing was running when this was being done. per THE-Card M123 Top +5V - 37 Amps 2.64 Amps has 14 +3.3V - 10.4 0.74 THE-Cards -2V - 33 2.36 -4.5V - 39 2.79 M123 Mid +5V - 33.4 Amps 2.57 has 13 +3.3V - 11.9 0.92 THE-Cards -2V - 30.3 2.33 -4.5V - 36 2.77 DATE: 10-FEB-2000 At: Fermi TOPICS: Clock Files The Clock Files are stored on d0ola in ~trgmgr/master_clock/config_files. Terminology: Tick = 132 ns, RF Bucket = 18.8 ns Ver Comments --- -------- 1 can be used to start the clock after loss of power no Subsystem Gap or Strobe standard file prior to adding Subsystem signals 2 Subsystem Gap 2.25 usec before Synch Gap Marker use with TRM 35.1 3 Subsystem Gap 467 ns after Synch Gap Marker use with TRM 39.1 THIS IS NOW THE STANDARD FILE The timing in the subsequent files is relative to the timing here. 4 Synch Gap Marker 2 Ticks / 7 RF Buckets later 5 Subsystem Strobe 4 RF Buckets earlier so it rises with the Subsystem Gap signal 6 Subsystem Strobe 3 RF Buckets earlier 7 Subsystem Strobe 2 RF Buckets earlier 8 Subsystem Strobe 1 RF Bucket earlier 9 Subsystem Strobe 1 RF Bucket later 10 Subsystem Strobe 2 RF Buckets later 11 Subsystem Strobe 3 RF Buckets later so it rises as the Subsystem Gap falls this is also when the TRM Clock Rises 12 Subsystem Strobe 3 RF Buckets later Subsystem Gap 3 RF Buckets later so the Gap rises and then 4 RF Buckets later the Strobe rises at the same time as the TRM Clock 13 Subsystem Gap 2 Ticks earlier 14 Subsystem Gap 21 Ticks / 147 RF Buckets later 15 Subsystem Gap 22 Ticks / 154 RF Buckets later DATE: 9-FEB-2000 At: Fermi TOPICS: L1 CNX, TTS The Tick and Turn Scaler potentially had some of the same problems that the TRM FIFO had so it has been fixed. We are now using TTS_9_1. (The Xilinx design manager "lost" versions 9, 10, and 11 which is why we have seemingly jumped backwards.) L1 CNX appears to be working again. Philippe modififed Trics to include the environment variable %CNX% which points to D0_CNX here and MSU_CNX at MSU. We're now using 7.2 Rev 3. Additionally, the old cnx files had to be modified because 1) M122 bottom no longer has scalers (right now it's not included at all since it's all L2) 2) M123 bottom has scalers in 18, 19, and 21 only (internal connectivity only) 3) there is an FM in M123 bottom slot 20 (internal connectivity only) It's now run over 3000 loops without any errors. DATE: 8-FEB-2000 At: Fermi TOPICS: TRM FIFO Install TRM_39_1 and Master Clock version 3 (with the Subsystem Gap 3 and a bit Ticks after the Synch Gap coming from the Master Clock). Configure, Initialize L1 FW, Init ST 0, and then UnNamed 0 to require AOIT 0. Check that there are no FIFO synchronization errors and that there are L1 Accepts being issued. Then read the current and L1 BX Number from the Tick and Turn Scaler. Initially the Current Tick reads 0x24 and the L1 Tick number reads 0x6. This is puzzling since we know the difference used to be 26. Go off and try to get CNX working again, come back and repeat the same procedure from configuring through to reading the Tick and Turn Scaler. Now the Currrent Tick number is 0x20 and the L1 Tick number is 0x6 as expected. DATE: 2,3,4-FEB-2000 At: Fermi TOPICS: Work on Testing the TRM FIFO, Move the Comm Crate and install the RMI, Take the GERT Training, talk with Mike and Dean, URL's for the training & safety stuff Test of the Auto-Disable It appears that if you use the various TDM control registers setup a Spec Trig to use Auto_Disable, but do not give the Auto-Disable the go ahead to allow the Spec Trig to fire once, and then enable the Spec Trig to run that it fires at the rate that it would without Auto-Disable. Then when you give to Auto- Disable the go ahead to fire once, it begins to operate normally, i.e. for each go ahead to fire once, the Spec Trig fires once and then stops. The current work around will be that when TRICS sets up a Spec Trig to use Auto-Disable, it will at the same time give it the go ahead to fire once. This whole issue will have to be worked out more in the future, e.g. if an Examine is going to use Auto-Disable then it will probably want to "request" each event that it receives and not find one on its door step before it asked for it. The setup will also have to avoid the "I'm waiting for you to ask for one" vs the "I'm waiting for you to send one" lockup. There is also some confusion about how the two bits in Reg 84 should actually be used to control the Auto-Disable. If one wanted to use the bit of value 2 to see if the Spec Trig had actually fired (after being given the go ahead to fire once) then it appeared that a "1" had to be left in the bit of value 1. We need clearification about how these registers should be used. There is probably also a typo in the description of the bit of value 1, a Spec Trig fires once vs only one Spec Trig firing. Test of the "Refresh Monit Data" Last week there was some concern that possibly using the "Refresh Mon Data" in the Register I/O menu would stop further "normal" generation of Capture Monitor Data signals when the Spec Trig fired. In a explicit test of this this week I see no problem. You can run a Spec Trig at 1 Hz, use the "Read" button to see its fired scaler increment, then poke the "Refresh Mon Data" button a bunch, and then go back to using the "Read" button and everything looks normal. Test of the TRM FIFO Turn the FW on, use the TRM exo with the 26 step delay of Sync Gap Marker, use the Master Clock program that generates the Sub System Gap about 470 nsec after the Sync Gap Marker. Setup Spec Trig #0 to fire when And-Or Term #0 is asserted. And-Or Term #0 is a copy of the Sub System Gap signal. Using the logic analyzer to look at the output of the SCL Receiver it is firing on Current BX $13 L1 Trig BX $98. Kirsten realizes that FIFO Error Checking is all turned off. Note that it was also probably turned off last week when I made a test of the FIFO. Steve, please forward to Philippe how this register (Reg 8) should be setup by L1 FW Init. Keep everything else the same and turn ON all 4 kinds of error checking. Now it always fires at Cur Bx $0b L1 Trig BX $90. Reading the TRM Error Reporting Register it says "Missing Sub System Gap". The FIFO Address register periodically says $8080. It continues to fire at Cur Bx $0b L1 Trig BX $90 even if the Sub-Sys Gap signal is pulled off the 40 pin input connector for these 16 And-Or Terms (the sub-sys gap remains connected to And-Or Term #0). Reconnect the Sub-Sys Gap but put the TRM in ByPass mode. Now it always fires at Cur Bx $0a L1 Trig BX $8f i.e. one tick ealier. OK it is not working so backup to the configuration that Kirsten tested last week, i.e. the TRM FIFO without the 26 step delay of the Sync Gap Marker and the Master Clock file with the Sub-System Gap generated 2.26 usec before the Sync Gap Marker. Now it always fires at Cur BX $07 and L1 Trig BX $8c (which is rational). There are no FIFO errors reported in the error register. Reading the FIFO Address Register we see for 5 reads: $1907, $0813, $1d04, $110f, $031e. It never reads $8080. Keep everything the same but go to FIFO bypass mode. Now it stably fires at Cur BX $94 L1 Trig BX $7a. So yes the FIFO is actually storing the And-Or Term for a rational period of time. Made some additional tests that I have not typed in but I could maybe answer questions. Basically the design without the 26 step delay of the Sync Gap Marker appears to work fine but the design with the delay does not work. Is there any chance that the exo with the 26 delay came from the design that had the broken re-sync logic ? Wednesday Move the Communications Crate 6U VME, Install the RMI. There was 10U available in the bottom of M122. It now has: 1U Fan Tray, 6U VME, 1U to get air out of the VME, 2U for the RMI. I still do not have the smoke detectors. Some problem about which one of two people is supposed to open the cabinet that is full of them and hand 3 to me. Need to see Ed Arko. I have started running 7.2 R2 I do not see any problems. Took the GERT Training which is now good for two years. The URL's for this stuff are: For the required D-Zero Hazard Awareness training http://d0server1.fnal.gov/Projects/UpgradeProject/Training/ D0HazardAwareness.pdf To check on your training: http://www-esh.fnal.gov/train/itp.indiv_rpt To sign up for training: http://www-esh.fnal.gov/train/class_sched.html The Radiological challenge exam: http://www-esh.fnal.gov:8001/CourseHandout_Mat/RadWorkerTrain/Default.html To get the operating permit "Operational Readiness Clearance" (ORC) http://d0server1.fnal.gov/Projects/UpgradeProject/ESH/ ESH_Review_Criteria.pdf The electrical part of this is now at: http://www-d0.fnal.gov/~hance/guidelines.htm Tests on Friday Fire up and configure via TRICS 7.2 R2. Running the "V3" Master Clock File and the 37.1 exo in the TRM's. Verify that the 1 Hz trigger is working and that it stops when the HI is pulled off of And-Or Term #255. All is OK Setup the TRM's FIFO error checking by loading $000F at Mst 1 Slv 0 Slt 10 Chip 1 Reg 8. The FIFO error Reg 8 reads $0104, i.e. "Missing Subsystem Gap". Do a Clear Errors by writing $020F and then back to $000F into Reg 8. The error reporting register still reads $0104. Setup Spec Trig #0 to fire on And-Or Term #0, i.e. the Sub System Gap. Init L1FW, Spec Trig #0 Init, UnNamed #0. Spec Trig #0 is firing. Watch the logic analyzer on the SCL Receiver. Capture 25 L1 Acpts. On 13 of them it had Cur BX $0b L1 Trg BX $90, on 12 of them it had Cur BX $21 L1 Trg BX $07. Read the FIFO Address REgister 25 times. 14 times it reads 8080, the other 11 readings were: 0311, 121d, 1908, 1e0f, 8006, 121d, 0713, 1d0e, 121e, 800f, 001a. So it looks like 1/2 of the time it is right. Looking at multiple turns on the analyzer it is clearly alternating turns, i.e. one turn fires at Cur BX 0b and the next turn at Cur BX 21. For fun tried adding a 5 nsec delay to the Syb-Sys Strobe signal and nothing changed. Try turning off some of the types of error checking. Turn off the Missing Sub-Sys Gap error checking, i.e. write 000b to Reg 8 (actually write 000b then 020b then 0008). Now the error register reads 0108 i.e. Unexpected Sub-Sys Gap. The logic Analyzer still says every other turn is firing in the two locations noted above. OK Turn off all the error checking then force a resysc from TCC. To reg 8 write 0010 then 0210 then 0010 then 0000. Now the error register reads 0110 i.e. it remembers that the last thing that happened was that TCC forces a resysc. Look at logic Analyzer and it is always firing at Cur BX 21, even after 15 minutes of running. Review the TRM exo files: 35.1 the 1st version with the fixed error checking logic & without the Sync Gap Marker delay shifter. This works with Clock File V2, i.e. Sub-Sys Gap 2.25 usec before a standard location Sync Gap Marker. 36.1 the 1st version with the Sync Gap Marker Delay Shifter but without logic to take into consideration the shift in 132 nsec Tick phase of the delayed Sync Gap signal compared to the version of this signal on the HQ timing line. 37.1 Has a 26 step Sync Gap Marker Delay Shifter and the logic to properly phase the signal coming out of this delay wrt the TRM Clk so that it enters the error checking/re-sync logic properly. This has a 50/50 right /wrong running with Clock File V3, i.e. Syb-Sys Gap 467 nsec after the Sync Gap Marker. 38.1 Same as 37.1 except has a 25 step Sync Gap Marker Delay Shifter. Clock file V1 is the magic one to dead start the Master Clk. Kirsten note its exe is 2x the rest of the exe's. Clock file V4 is exactly the same as V3 except that Sync Gap Marker has been shifted 2 ticks later to test that the TRM FIFO output follows changes in the Sync Gap Marker. Reconfigure using the 38.1 TRM exo and still running the V3 clock file. Start things up and allow the TRM to do all types of FIFO Error Checking, i.e. write 000F to Reg 8. The error Reg now reads 0104 i.e. Missing Sub Sys Gap. The logic Analyzer says every other one is at Cur BX 0b L1 Trig BX 90 vs Cur Bx 20 L1 BX 06. This is "as expected". Try turning off the "Missing Sub-Sys Gap" error checking. Write 000b then 020b then 000b to Reg 8. Now the error reg read 0108 i.e. "UnExpected Sub-Sys Gap". The Logic Analyxer says every other one as above. Try turning off both "Missing and UnExpect Sub-Sys Gap". Write 0003 then 0013 then 0213 then 0013 then 0003 to Reg 8. Now the Error Register read 0110, i.e. the last thing that happened was a TCC requested re-sync. It is firing only on Cur BX 20 L1 BX 06. Clear the Error Register by writing 0203 then 0003 to the Reg 8. Now the error register reads 0000. Capture some FIFO Address Counter values from Reg 10: 0912, 110a, 1902, 0d03, 110a, 1318, 0914, 1e0b, 0b14, 141d, 1318, 0415, 011c, 0a06, 0b14, 1c0d. The logic analyzer continues to say only Cur 20 L1 06. Turn off all error i.e. write 0000 to Reg 8. After 10 min the logic analyzer still only says Cur 20 L1 06. Conclusion TRM exo 38.1 is the same as 37.1 except for 25 vs 26 shift delay of the Sync Gap Marker. Talk with Mike Tuts and via video with Dean. Next week there will be a ecb meeting and Dean will be there next week and will schedule time to talk about resistors. DATE: 31-JAN-2000 At: Fermi TOPICS: Random Reg Test with L2 Ran Random Register test on all cards, including the cards for the Level 2 Framework. Ran for >425,000,000 loops with no problems. DATE: 26,27,28-JAN-2000 At: Fermi TOPICS: Work on Testing the TRM FIFO, Make overall checks of timing, begin installing safety system, tests with COOR, Problem with SCL Init to Muon, Move to TRICS 7.1 Rev 4 Take FM cards serial numbers FM-02 and FM-17 to Fermi. One of these is for the FM Latch in the bottom crate of M123 (for the control data to L3) and the other is a spare to have at Fermi. Install SM Gated for Sequential L1 Accept Num in slot 18 of M123 Bottom and Install the FM-Latch in slot 20 M123 Bottom. We now have all the cards installed for the currently understood running configuration. Kirsten updated the what card is where in the FW inventory file and started the Down Load Command file loading up all the cards. We have moved to the most current version of many FPGA's (L1 Help, SCL Help, TRM, FM-Latch, L2-BAD). Specifically we are now loading: TRM_36_1, Helper_8_1, SCL_Helper_3_1, FM_Latch_1_1 (except FPGA 16 which is using FM_Latch_1_2), and L2Bad_1_2 All cards are now being configured via the proper setup of files on TCC. All cards involved with L2 FW are now being configured and so is the SM for sequential L1 Accept Number M123 Bottom Slot 18. Spare Cards now at Fermi: FM-02 SM-01 Blue "Gated SM" with HSROCB SM-52 Blue "Gated SM" with HSROCB SM-55 Blue "Gated SM" with HSROCB FOM-9B with HSROCB Upon arrive for this week the big problem had been that Muon though the SCL Initialize signal was a 80 usec up and down waveform. Well they were right. ALL the data coming out of the SCL Receiver was junk. This was caused last week when the SCL Hub-End's Frame Clk and 53 MHz Clk were moved to an SFO that ran with a re-timing delay of "9" (like all the rest of our SFO's). This did not materially change the FW to SCL timing but it did change the SCL Frame to SCL 53 MHz timing by 180 degrrees and completely killed the SCL Hub-End. Connect the Philips Logic Analyzer to the SCL Receiver Test Card SCL Receiver Logic Logic Test Card Analyzer Analyzer Signal Connection Pod/Channel Display ----------------------------- ------------ ----------- ----------- SCL Receiver 7 MHz Clk Con 2 Pin 6 Pod 1 Ch 0 SCL Clock Beginning of Turn Marker Con 4 Pin 15 Pod 1 Ch 1 Beg of Turn Sync Gap Marker Con 4 Pin 13 Pod 1 Ch 2 Sync Gap Live Beam Crossing Marker Con 4 Pin 14 Pod 1 Ch 3 Live BX Cosmic Gap Marker Con 4 Pin 12 Pod 1 Ch 4 Cosmic Gap Spare BX Marker Signal Con 4 Pin 16 Pod 1 Ch 5 Spare Marker L1 Accept Issued Con 9 Pin 19 Pod 1 Ch 6 L1 Issued L1 Acpt to this Geo Section Con 4 Pin 19 Pod 1 Ch 7 L1 Geo Sect L2 Decision Issued Con 9 Pin 18 Pod 1 Ch 8 L2 Issued L2 Accept to this Geo Sect Con 4 Pin 18 Pod 1 Ch 9 L2 Accept L2 Reject to this Geo Sect Con 4 Pin 17 Pod 1 Ch 10 L2 Reject SCL Initialize Con 9 Pin 17 Pod 1 Ch 11 SCL Init L1 Qual 0, L3 Trans Num 0 Con 1 Pin 19 Pod 1 Ch 12 \ Bus L1 Qual 1, L3 Trans Num 1 Con 1 Pin 18 Pod 1 Ch 13 | L1 Qual L1 Qual 2, L3 Trans Num 2 Con 1 Pin 17 Pod 1 Ch 14 | 3:0 L1 Qual 3, L3 Trans Num 3 Con 1 Pin 16 Pod 1 Ch 15 / Hex Current Beam Crossing Num 0 Con 4 Pin 11 Pod 2 Ch 0 \ Current Beam Crossing Num 1 Con 4 Pin 10 Pod 2 Ch 1 | Bus Current Beam Crossing Num 2 Con 4 Pin 9 Pod 2 Ch 2 | Cur Current Beam Crossing Num 3 Con 4 Pin 8 Pod 2 Ch 3 | BX Current Beam Crossing Num 4 Con 4 Pin 7 Pod 2 Ch 4 | Num Current Beam Crossing Num 5 Con 4 Pin 6 Pod 2 Ch 5 | 7:0 Current Beam Crossing Num 6 Con 4 Pin 5 Pod 2 Ch 6 | Hex Current Beam Crossing Num 7 Con 4 Pin 4 Pod 2 Ch 7 / L1 Trig Num Beam Crossing 0 Con 9 Pin 11 Pod 2 Ch 8 \ L1 Trig Num Beam Crossing 1 Con 9 Pin 10 Pod 2 Ch 9 | Bus L1 Trig Num Beam Crossing 2 Con 9 Pin 9 Pod 2 Ch 10 | L1 L1 Trig Num Beam Crossing 3 Con 9 Pin 8 Pod 2 Ch 11 | Trig L1 Trig Num Beam Crossing 4 Con 9 Pin 7 Pod 2 Ch 12 | BX L1 Trig Num Beam Crossing 5 Con 9 Pin 6 Pod 2 Ch 13 | 7:0 L1 Trig Num Beam Crossing 6 Con 9 Pin 5 Pod 2 Ch 14 | Hex L1 Trig Num Beam Crossing 7 Con 9 Pin 4 Pod 2 Ch 15 / Known Gnd Pins are: Pin 20 on Con 1, 2, 4, 6, 9, 11 Con 9 Pins 12, 13, 14, 15, 16 Before starting to look at the SCL Receiver Output, Check what the "important" Master Clock lines looks like. Examine them at their NIM test points on the Selector Fan Outs. This is with Kirsten's clock file named V3 ?? Rises x buckets High for before/after TL Name (RF buckets) Tick Clock (unless noted) -- ------------- ------------ ------------------------ 0 Tick Clock 1 1 TRM Clock 1 1 after 2 Beginning of Turn 7 3 before 3 Interaction Marker 7 3 before 4 Cosmic Gap Marker 3 before 5 Sync Gap 7 3 before 7 Helper Clock 1 2 after 8 SCL Clock 3 1 after 14 Subsystem Strobe 3 5 after 15 Subsystem Gap 7 4 before SUBSYSTEM STROBE Sync Gap rises about 450 ns before the Subsystem Gap (3 and a bit Ticks) Beginning of Turn rises about 650 ns before the Sync Gap Beginning of Turn rises about 2 us before the first Interaction Marker Beginning of Turn rises about 6.2 us before the first Cosmic Gap The Cosmic Gap consists of 2 pulses about 2.2 usec long, separated by about 4.2 us On 26-January-2000, the following tests were done for TRM_35_1 - Program for normal error detection (0x000f in Reg 8) o see that we gain synch o pull off the Subsystem Gap signal, see that we lose synch (w/ Missing Subsystem Gap Error in Reg 9) When the subsystem gap signal is removed, register 10 goes to 0x8080, and register 9 reads 0x010c. Besides the missing subsystem gap error, this indicates an unexpected subsystem gap. o regain synch and then pull off the Subsystem Strobe signal, see that we lose synch (w/ FIFO Empty Error in Reg 9) When the subsystem strobe signal is removed, register 10 again reads 0x8080 and register 9 reads 0x010a. Again there is an unexpected subsystem gap error in addition to the expected FIFO empty error. o regain synch, kill FW Gap Marker (by writing to the TS control section of the BSF to force the output LOW) see that we lose synch (w/ Unexpected Subsystem Gap Error in Reg 9) Register 9 reads 0x0108 as it should do and register 10 read 0x80xx. That is, the write address is still incrementing. o kill TRM Clock (as above) to see that we lose synch (w/ FIFO Full Error in Reg 9) Register 9 correctly reads 0x0101 and register 10 again reads 0x80xx. - program for NO error detection (0x0000 in Reg 8) and repeat the tests o see that we gain synch o pull off the Subsystem Gap signal Reg 9 reads 0, both addresses in Reg 10 continue to increment o pull off the Subsystem Strobe signal Reg 9 reads 0, the read address continues to increment but the write address stops incrementing o kill FW Gap Marker Reg 9 reads 0, both addresses continue to increment o kill TRM Clock Reg 9 reads 0, the read address stops incrementing, the write address continues to increment Steve's comments on the above results: The results mostly make sense to me, except for the "unexpected" Unexpected Subsystem Gap Errors. Maybe it's just noise as you pull the connectors off, but I'll look at the schematic a bit more before just punting like that. I was at first surprised that the read/write counters stopped incrementing when error detection was turned off, but then I realized that they stopped because you killed their clocks, not because they were being re-synched! Examination of the SCL Initialize Sequence as seen at the SCL Receiver Output: Trics 7.0 Rev 4 All latest EXO's SCT Runs OK Latest Carmen Master Clock setup (i.e. for the TRM that delays the Sync Gap internally by 26). SCL Init goes active in the SCL Frame with Cur BX Num $1f (L1 Trig BX Num $05). This is about the 6th Live Crossing BX after the Beginning of Turn. SCL Init remains asserted for 3 turns 40% of the time and for 4 turns 60% of the time. This is based on looking at 10 samples of SCL Init. SCL Init returns Low in the SCL frame that would carry Cur BX Num $1f (but of course Cur BX Num is being held at $01 when this happens). Cur BX Num and L1 Trig BX Num are both properly held at $01 during SCL Init. After SCL Init returns Low, the first SCL frame with BOT asserted has Cur BX Num $01, the next SCL Frame has Cur BX Num $02. This is the first increment of the Cur BX Num since SCL Init returned Low, i.e. the Tick and Turn Numbers appear to be starting up properly after the SCL Init. Checked that Cur BX Num - L1 Trig BX Num is 26. The Analyzer file for this is SCL REC 03 . DAT Notice that at the SCL Receiver Output the Beginning of Turn Marker is not always there. It is missing about 10% of the time. It appears to be gone in blocks, i.e. it is not missing in 1 turn out of 10 looked at but there will be a block of many turns with it missing and then many many turns all with their BOT marker. At the SCL Hub-End the the signals from the SCL helper were arriving about 40 nsec before the signals from the Tick & Turn Scaler or the L1 Glb Accept. The problem was that the SCL Helper was running on FW Tick Clk instead of Helper Clk. This was changed, i.e. Helper A SFO Ch 0 was changed from Timing Line 0 (FW Tick Clk) to Timing Line 7 (Helper Clk). Now looking at the latches at the input of the SCL Hub Controller the SCL Helper signals and the Tick & Turn signals have about 70 to 75 nsec of setup and the L1 Glb Accept signals from the FOM++ has about 65 nsec of setup. Conclusion, SCL Frame Clk wrt FW Tick Clk looks good. Wiring of the L1 FW Helper and the SCL Helper to the Master Clock: +---------------+ L1 Helper P2 | +-+ +-+ | +---+ |.| |.|-------- Glb L1 Accept | | | | | | | | | | | | | | | | +-+ +-+ | | | | | | +-+ +-+ | | | |.| |.| | | | | |\ | | | +---+ | | | | | | | +-+ | +-+ | +---------|-----+ |____________________ Cable SF8 P4 from SFO Helper B +---------------+ SCL Helper P3 | +-+ +-+ | +---+ |.| |.| | | | | | | | | | | | | | | | | | +-+ +-+ | | | | | | +-+ +-+ | | | |.| |.| | | | | |\ | |---------------- Cable SF8 P6 from SFO Helper A +---+ | | | | | | | +-+ | +-+ | +---------|-----+ |____________________ Cable SF8 P5 from SFO Helper B SFO Helper A currently drives only cable SF8 P6 SFO Helper B currently drives only cables SF8 P4 and P5 Well perhaps the missing Beginning of Turn Marker is due to a slight timing problem between the SCL Frame Clk and the SCL 53 MHz. So make a Trompeter extension cable that is 3 nsec long and use it to delay one signal or the other. If you delay the SCL Frame Clock by 3 nsec wrt SCL 53 MHz then the SCL Hub End will not run at all. Its red "I'm not happy with my Clk's" LED comes on and that is it. If you delay the SCL 53 MHz wrt the SCL Frame Clk the SCL Hub-End still works, but the data from the SCL receiver looks worse. BOT is frequently >50% of the time missing (in blocks) and other signals are sometimes asserted e.g. L2 Reject. So try making a shorted delay cable that can go in the SCL Frame Clk. The hub end will run if this 9" cable is in either the SCL Frame or SCL 53MHz line but it does not make much difference. What appears to help is pushing the connector for this analyzer on and off the pin on the Receiver Test Board. Now the BOT signal looks OK and we have just standard cables carrying clocks to the Hub End. What was learned: If SCL Frame is delayed by 3 nsec the Red LED comes on and if SCL 53 MHz is delayed 3 nsec the data falls apart. So the new setup of the SFO's that includes these two changes (SCL Hub-End Frame and 53 MHz Clk's now from their own SFO and SCL Helper Clk comes from FW Helper Clk instead of from FW Tick Clk) is show below. VME Slot 12 13 14 15 16 17 18 19 Label - SCL SCL0A SCL0B FW123 FW123 FW122 FW122 SFO Ch#0 - 14 7 4 7* 3* 7* 3* \ Ch#1 - 15 2 5 6* 2 6* 2 | Ch#2 - 15 3 6 5 1 5 1 +-+ Ch#3 8 8 8 7 4* 0 4* 0 / | Sequencer Time Paddle Trom- Trom- Carmen Carmen Carmen Carmen Carmen Carmen Line Brd peter peter Retimed 0 9 9 9 9 9 9 9 Clock P P P* P* P* P P* P * --> This Channel's Output is Disabled So the SFO in Slot 12 feeds just the SCL Hub-End with SCL Frame and SCL 53 MHz. SFO in slot 13 feeds just the Sub-System Strobe and Gap Signsl. SFO's in slots 14 & 15 are described right above here and feed the L1, L2, and SCL Helper Functions. The SFO's in slots 16,17,18,19 feed the 6 crates in M122 and M123. Now capture some L1 Accpets coming out of the SCL Receiver when you have specified the BX to fire on via Tick Selector #0 Value Loaded Value Read Value Read into Tick Cur BX Tick L1 Trig Num Selector #0 # Monit Data Tick Monit D SCL Receiver SCL Receiver Mst 1 Slv 2 Mst 1 Slv 2 Mst 1 Slv 2 Cur BX Tick L1 Trig Num Slot 21 Slot 21 Slot 21 Num in SCL Tick # in SCL Chip 16 Chip 15 Chip 16 Frame with Frame with Reg 40 Reg 36 Reg 36 L1 Accept L1 Accept ------------ ------------ ------------ ------------ ------------ $0040 $5d $43 $5d $43 $0008 $25 $0b $25 $0b $0080 $9d $83 $9d $83 Many cycles of each value were examined. All looked good. Beginning of Turn was present in all captures. The Monitor Data read from the Tick & Turn Scaler matches the logic analyzer data. The only issue is that the FW fires on a tick 4 greater than what is loaded into the Tick Selector. Analyzer file is SCL REC 04 . DAT The Air Flow, Temperature Limit, and "front panel rack power control" have been installed and are operational. To turn the power ON you still have to turn ON the "Safety System" switch on top of the air conditioner and then use the "pront panel" switches to turn on each rack. The Power Up instructions are being updated We are now using only TRICS 7.1 R4. All other icons are gone. Philippe has edited SpTrg0_Init so that it now accounts for A-O Term 255 being HI. He also made "Un-Named 0" so that it requires And-Or Term #0 HI and thus can be used with the TRM FIFO testing. Friday afternoon tests with COOR were 95% successful. Everything worked except for COOR trying to setup a trigger for Auto Disable. COOR did program a trigger and it ran and COOR could start and stop it and dissconnect and reconnect.Auto-Disable is working just fine from the Master Command File Buttons. TRM FIFO Tests watching SCL Receiver Output. Setup Sp Trg #0 requiring And-Or Term #0 to be HI. And Or Term #0 is a copy of the Sub System Gap Signal that is being feed to both AO Terms 15:0 Sub Sys GAP and to AO Term #0. When run with this trigger we always fire on Cur BX $1b L1 Trig Num BX $01. My reading on the scope of the shift between Sync Gap Marker and the Syb System Gap signal is 467 nsec. The same $1b and $01 numbers are read from the logic analyzer in the SCL Frame with the L1 Accept SCL and as monitor data from the Tick and Turn Scaler. Two events captured on the analyzer for us to look at. SG <--> BOT ? The Muon person is Mark Kozlovsky (mkozlovsky@fnal.gov) his office phone number is 3786. To get the MASTER CLOCK RUNNING again after its power has been off, i.e. to get it over the "Sequencer Halted" problem do the following: 1) log onto d0ola as trgmgr 2) cdboot (just like it's written) 3) cp clkSetup.vX clkSetup At the moment, clkSetup.v1 is the "magic" one, i.e. the one capable of turning off the "Sequencer Halted" condition. It is what we have been running up until last week. clkSetup.v2 is what we ran last week. It includes Subsystem Gap and Strobe but assumes that the TRM isn't delaying the Sync Gap. clkSetup.v3 is what we are running at the moment. It inclues Subsystem Gap and Strobe and assumes that the TRM IS delaying the Sync Gap. So right now typically use clkSetup.v1 to get over the "Sequencer Halted" problem and then return to clkSetup.v3 the file that we really want to be running. DATE: 19,20,21-JAN-2000 At: Fermi TOPICS: Work setting up the Master Clock signals for the Cosmic Ray Commissioning Run, Test of the TRM input FIFO, Test Setting up a Trig from COOR, Meeting with Neal and Ted Setup Master Clock TL-14 to make the L1 Trigger Sub-System Strobe signal and Master Clock TL-15 to make the L1 Trigger Sub-System Gap signal. So the list of Master Clock signals now is: Time Line Function Used By --------- ------------------------ ----------------------- TL0 FW Tick Clock Framework TL1 TRM Clock Framework TL2 Beginning of Turn Marker FW & AO Net Input & SCL TL3 Interaction Marker AO Net Input & SCL TL4 Cosmic Gap Marker AO Net Input & SCL TL5 Sync Gap Marker FW & AO Net Input & SCL TL6 Spare Marker AO Net Input & SCL TL7 FW Helper Function Clock Framework! TL8 SCL Tick Clock SCL TL9 Calo Xing Clock Calorimeter TL10 Calo Base Sample Calorimeter TL11 Calo Peak Sample Calorimeter TL12 Calo Transfer Calorimeter TL13 ---- TL14 L1 Trig Sub System Strobe Signal (for Cosmic NIM Trig) TL15 L1 Trig Sub System Gap Signal (for Cosmic NIM Trig) Work an the arrangement of the Selector Fan out Modules. I pulled out the unused SFO from the middle of our section so that the arrangement now looks like: VME Slot 13 14 15 16 17 18 19 Label SCL SCL0A SCL0B FW123 FW123 FW122 FW122 SFO Ch#0 14 0 4 7* 3* 7* 3* \ Ch#1 15 2 5 6* 2 6* 2 | Sequencer Ch#2 15 3 6 5 1 5 1 | Time Line Ch#3 8 8 7 4* 0 4* 0 / Paddle Trom- Carmen Carmen Carmen Carmen Carmen Carmen Brd peter Retimed 9 9 9 9 9 9 9 Clock P P* P* P* P P* P * --> This Channel's Output is Disabled Had trouble getting this setup up because of 1) a possible bad SFO, 2) you can not run SFO's with a retime of "0" or both 1&2. I right now think that the bulk of the problem was trying to run with a SFO retime of "0". That is how the SFO that feeds SCL-Tick Clk to the SCL Hub-End had been setup so we kind of did not want to change it. But with it set that way, getting signals through the SFO was problematic. So now this SFO is set the same as the rest of them. We still do not know the official range of retiming delays where you should be able to run the SFO's. We still need to measure the setup - hold time of the FW data at the SCL Hub-End vs the SCL ingestion clock. As running the L1 Trig Sub-System Gap signal is asserted for 1 full tick about 2.5 usec before the CURRENT FW Gap signal i.e. P1 TS #6 in the Top Crate of M123. The L1 Trig Sub-System Strobe is asserted for 3 RF buckets and low for 4 RF buckets. It becomes active when there are 3 RF buckets left to go in the Sub-System Gap signal. Talked with Neal and Ted about the patch panel for the serial cables. So the setup will be: come out of the FanOut with a straight MCX to LMR-100 to a Straight SMB. This plugs into an SMB jack bulkhead SMB jack. The from inside the rack there is a straight SMB on the LMR-200 that runs to the SCL receiver where it connects via either a straight or right angle SMB. Run II FW Safety System The Fermi smoke detectors just get wired in parallel. Still need to bring an FM THE-Card here for the FM-Latch in M123 Bot and bring a new soldering tip. DATE: 12,13,14-JAN-2000 At: Fermi TOPICS: Commissioning meeting about Cosmic Ray Run, Meet with Reiner Hauserabout about Resistors, Meeting with Dean about BLS signals, Work with L1 FW on more And-Or Input Terms and the Tick Selector New EXO's from Steve for this trip: 1. L2 Helper l2_helper_6_1.exo 2. TRM trm_31_2.exo 3. TTS tts_11_1.exo (Dan: I modified the TTS to go far enough back in history, it required also editing the tts_setup.rii file [replace 0x5 with 0x4], which I have done at both sites). 4. TDM tdm_20_1.exo (this FPGA includes correct Auto Disable processing, which does not allow ST's to fire while TCC is resetting Auto Disable) Edit the following .dci files in C:\Trics\DCF to pick up the new .exo files. TRM was 22-2 move it to 31-2 TTS was 8-1 move it to 11-1 TDM was 18-1 move it to 20-1 want L2_Helper to be 6-1 but there is not yet a .dci file for this. With TRM 31_2 loaded we had some trouble with the TRM to start with. Trics needed to load a different value in the control register for the BX History Shift Reg so that HSRO and Mon data would be one tick less old with the TRM 31_2 than what was used with TRM 22_2. Philippe makes a new TRICS to do this. Now SCT works fine with all the new FPGA's. The new TRICS has an icon labeled "New TRM" I deleted all of the old TRICS icons about 8 of them. Need to bring down an FM module for the FM-Latch that goes in the bottom of M123 to capture the L1 Trig Num and the L3 Trans Num going up to Level 3. I think that all other boards in the L2 FW are installed. Work on connecting the Tick Number Comparator outputs fron the Tick & Turn Scaler to the And-Or Network Input Term patch panel. Connection of the Tick Comparators. These come from the Geo Sect L1 Trig Num Tick and Turn Scaler which is: Master 1, Slave 2, Slot 21, Chip 16. Register #40 is Tick Select Comparator #0 with output on MSA_Out 40. Register #43 is Tick Select Compartor #3 with output on MSA_Out 43. These registers appear to wake up from FPGA configuration containing a value of zero. Initialize Framework does not appear to change what is in these registers. Loading values between (and including 1 and 159) produces output pulses. Loading values outside this range (only some tested) produces a low output. Compare the relation between this Tick Select comparator output signal and the Beginning of Turn Marker - Carmen Master Clock TL-2. Value in Register --------- 1 Tick Select is asserted 3.7 usec after BOT. 50 Tick Select is asserted 10.5 usec after BOT. 100 Tick Select is asserted 16.8 usec after BOT. 132 Tick Select is asserted at the same time as BOT. 150 Tick Select is asserted 2.4 usec after BOT. Tested the first 4 comparator outputs and control registers. All was OK. Cable from to Dean Calo on 3rd floor. This will use one of the Trig-Aqu-Sync cables that run up the cable tray at the West end of MCH. These were 40 wide cables and Dean has them split at his end into 16 pair + 4 pair. In the bundel of Trig-Acq-Sync cables these are the 5th and 6th from the back of the cable tray. We are using on the 4 pairs from the high end of each of these cables. At the base of this cable tray this splices into a normal 34 wide cable to run over to the patch panel under the And-Or Input Term patch panel. This is setup as follows: Dean's #1 cable Dean's #2 cable -------------------- -------------------- purp gray wht blk purp gray wht blk <-- splice brn red org yell grn blu vlt gry 1 2 3 4 5 6 7 8 ------------------------------------------------.... 34 wide cable to the patch panel pair #1 in the 34 wide calbe to the patch panel is used for: sending the Start Digitize to Dean pair #5 in the 34 wide calbe to the patch panel is used for getting the test trigger from Dean We want to use And-Or Input Terms 255:224 in FIFO ByPass mode. These are handled by the TRM at Master 1 Slave 0 Slot 2. You move these to FIFO ByPass Mode by writting a 0 into register 16 of the appropriate FPGA's on this card. The FPGA's to write to are the following: And-Or Input TRM in Slot #2 Handled by Term MSA_Out FPGA on this card ------------ -------------- ----------------- 227:224 35:32 3 231:228 39:36 7 235:232 43:40 11 239:236 47:44 15 243:240 51:48 4 247:244 55:52 8 251:248 59:56 12 255:252 63:60 16 To read the rate at which an And-Or Network Input Term is firing, read the following registers in the appropriate FPGA on the appropriate TRM card. 40 R Output Term 0 Scaler Monitor Register (LSW) 41 R Output Term 0 Scaler Monitor Register (MSW) 42 R Output Term 1 Scaler Monitor Register (LSW) 43 R Output Term 1 Scaler Monitor Register (MSW) 44 R Output Term 2 Scaler Monitor Register (LSW) 45 R Output Term 2 Scaler Monitor Register (MSW) 46 R Output Term 3 Scaler Monitor Register (LSW) 47 R Output Term 3 Scaler Monitor Register (MSW) Recall on the TRM, the MSA Out vs. MSA FPGA # mapping is as follows: MSA_Out MSA FPGA # ------- ---------- 3:0 1 7:4 5 11:8 9 15:12 13 19:16 2 23:20 6 27:24 10 31:28 14 35:32 3 39:36 7 43:40 11 47:44 15 51:48 4 55:52 8 59:56 12 63:60 16 Tests of Rev 4 of TRICS 7.0 14-JAN-2000 This is all from a fresh power up and FPGA download Init Spec Trig 0 and divide by 7 Meg It runs at the proper 1 Hz rate. The Geo Sect L1 Trig Num BX field decrements by 7 from one trig to the next. Does the fit the details of how the pre-scaler is setup ? Init Spec Trig 0 and divide by 48k It runs. If you try to register read the Spec Trig #0 Fired counter with reads about once per second then it appears to be incrementing about 150 between reads. Init Spec Trig 0 and require AO 251 and divide by 48k It runs at about 1 Hz. Often the the Spec Trig #0 Fired counter appeared to increment by 2 even though I was clicking the read register button faster the once per second. I do not understand this. With 90 loaded into the Tick Select #0 Compartor the BX field of the Geo Section L1 Trig Num always reads 93. Init Spec Trig 0 and require AO 251 and AO 224 It runs at the expected 1 Hz. Dean sends a 3.5 usec pulse on AO 224 at 2 Hz but this is not always at the same place on the turn. Right now it is in one of two places on the turn so it only lines up with our Tick Selector at 1 Hz. Right now they overlap is the Tick Selector Comparator is set between 79 and 104. I have been running it set at 90 until Dean takes a look at his data. Note that Dean is not locked to a beginning of turn counter. So he could slip (or at his next power up) be off by 1/6 or 1/3 of a turn. In his current setup alternate of his firings are on opposite sides of the ring. I have dumped all TRICS Icons except for V7.0 Rev 4. I still need to move edited files from Fermi to MSU. Is there now more old junk at Fermi that should be deleted ? Situation not to get into. It's not triggering but I can not look at anything to find out why because there is no capture monitor data because it is not triggering. Can we make a "CApture Monitor Data right now" button.