From mp@hep.ucl.ac.uk Mon Jan 19 19:58:00 1998 Date: Mon, 19 Jan 1998 15:18:05 GMT From: "MARTIN POSTRANECKY,UCL-PHYSICS DEP,HEPP GROUP,GOWER ST,LONDON WC1E 6BT,TEL:(00-44)-[0]171-419 3453,FAX:[0]171-380 7145" To: meh@ax8.hep.ucl.ac.uk, mp@ax8.hep.ucl.ac.uk Subject: Note of John Lane's "POOH","PIGLET", etc, etc... tests ZUKVS2::userdisk:[UCL.Pooh]Pooh.TXT ZEUS02::disk$online:[Lane.TC]Pooh.TXT Piglet and the Pooh family : or how to test the LTCs 12-Feb-1993 J.B.Lane ==================================================== Piglet and the rest of the Pooh family are occam programs to test the essential functions of the Z / TRIG LTC - MTC system. In practice this means checking the operation of the LTCs with emphasis on testing the LTC Interrupt register at high rates. In particular, Piglet is optimised to test contention in the Interrupt register. Contention occurs when an interrupt bit is cleared at the same time as another interrupt bit is set (event is validated). The family of programs have the following purposes : Piglet : Give the LTCs a hard time Pooh : Test the system stand-alone PoohBear : Test the system with the GFLT Tigger : Test the pipeline synchronisation The same LTC handler is common to all programs, and checks each LTC for errors. The data transfers from pipeline to DPM buffers are not checked, in order to enable the system to run at high rate. The event rate is limited by the LTC handler to about 40us or 25kHz. The differences between the programs are in the MTC handling and the configuration : Piglet Pooh PoohBear Tigger Control ROC ROC GFLT GFLT RBOX LTC no yes yes yes Freeze no no no yes ROC : Stand-alone test with the MTC under ROC Control. GFLT : Test with the GFLT and the MTC under GFLT Control. RBOX LTC : Does it include the LTC in the crate with the MTC (the RBOX) ? Freeze : Is the system in ROC Pipeline Freeze mode (set on the MTC) ? This mode is used to buffer only one event at a time and so the buffers-full condition does not occur. Program descriptions -------------------- Piglet : "Piglet is a small animal" so he fits into the internal memory of the transputers and runs very fast. It excludes the LTC in the crate with the MTC (the RBOX) which allows the MTC handler to monopolise its transputer. It is optimised to test contention in the Interrupt register. Contention and buffers full occur regularly. As well as normal Triggers it generates re-Initialise, Test Enable, End Of Run Trigger, and can generate Aborts and Triggers in Fast Clear mode. Pooh : "What's a Pooh?" Pooh is the same as Piglet except that it includes the LTC in the crate with the MTC (the RBOX). The MTC handler has to share its transputer with the LTC handler which reduces contention in the Interrupt register. Contention and buffers full can occur. PoohBear : "Pooh is a Bear." PoohBear is the same as Pooh except that it is with the GFLT. The GFLT generates Initialise and Triggers etc. Contention and buffers full can occur. Tigger : checks the Trigger Address "because Tiggers do things like that". The only difference from PoohBear is that the system is in ROC Pipeline Freeze mode. This allows the LTC handler to check the Trigger Address and End Copy Address. Contention can occur but buffers full does not occur. How to run the programs ----------------------- The programs are run from ZUKVS3 using the ISERVER from the occam Toolset. They are independent of both the main DAQ software and the test software for a single LTC (TCT, SST and ROCTEST), which all use the HARNESS. First login to ZUKVS3 and run the command file to set up some symbols etc. : $ @userdisk:[UCL.Pooh]setup Then just type the name of the program, e.g. : $ Piglet For example, to check the cabling is OK so that the system runs, you could first try Pooh stand-alone and then PoohBear with the GFLT (or Test Box). The first event causes a Count message from each LTC handler. Pressing the space bar generates an error summary and the program continues. Any other key causes the message handler to exit after giving the summary. Having problems ? ----------------- 1. Make sure you are using QTA0: (link0) (you can type SHOWLINK). 2. The program has booted and should be running if it says "Hello World !" 3. If no Count messages appear : - on the LTCs check that the MTC Clock LED is on. - on the MTC check that the BUSY inputs are correct... BUSY inputs enabled by the LTC Mask register must be connected. This will soon be inputs 1-17 ! *** BUSY cables 1-17 should be connected to BUSY inputs 1-17 respectively. - If under GFLT Control have you sent Initialise and Triggers ? The source is in ZUKVS2::userdisk:[UCL.Pooh] although ZUKVS3 is being used too at present. *** MTC related messages -------------------- These messages come from the MTC handler (under ROC Control). More info coming in a later edition... *** LTC related messages -------------------- These messages come from the LTC handler. Note that in correct operation the LTC Interrupt register bits are cleared by the software only and cannot be set by the software. The hardware can be up to 9 events ahead of the software. The first two values in the messages are hexadecimal and depend on the message; they give the expected value (in some sense) and the value obtained respectively. The remaining three values are common to all messages : buff : buffer number (corresponds to the expected DPM Valid bit). This is the buffer being analysed and not the Buffer Count register. event : the event number in hexadecimal as counted by the LTC handler. crate : the crate number in the order given by the transputer network. Count FLTN 00000000 info 00000000 buff 0 event 00100000 crate 0 Event count : A message every 100000 HEX events (about 1 million) showing that the LTC is active. If, for example, the LTC is stuck in the Available state, there is no message. The first Count message is after the first event. FLTN : expected Trigger Number info : DPM Info register Error CLEAR interrupt mask 00000080 bits 00000780 buff 6 event 00000006 crate 1 CLEAR Interrupt bit not cleared : The expected DPM Valid bit is still set in the LTC Interrupt register after it should have been cleared. mask : expected DPM Valid bit bits : Interrupt register Error SET interrupt mask 00000080 bits 00001F01 buff 6 event 00000006 crate 2 SET Interrupt bit not set : The expected DPM Valid bit is not set in the LTC Interrupt register even though another DPM Valid bit is already set. mask : expected DPM Valid bit bits : Interrupt register Error READ interrupt bits 00001F81 bits 00001F03 buff 6 event 00000006 crate 3 READ Interrupt bit clear : A bit appears to be set but then clear in a sequence of reads from the LTC Interrupt register. A SET error may follow. bits : Interrupt register ( first read) bits : Interrupt register (second read) Error WRITE interrupt bits 00001F81 bits 00000602 buff 6 event 00000006 crate 4 WRITE Interrupt bit cleared : A DPM Valid bit that is set and should not be cleared is cleared by a write to the LTC Interrupt register. The purpose of the write is to clear the expected DPM Valid bit (given by the buffer number). A SET error should follow. bits : Interrupt register before write bits : Interrupt register after write Error NOSET interrupt mask 00000080 bits 000006FE buff 6 event 00000006 crate 5 NOSET Interrupt bit not clear : The expected DPM Valid bit is set in the LTC Interrupt register after it should have been cleared... It is not a CLEAR error because the Trigger Info has changed in the corresponding DPM Info register, indicating a new event. This error may be caused by a SET error in the next event. mask : expected DPM Valid bit bits : Interrupt register Error INT interrupt mask 00000080 bits 00001F81 buff 6 event 00000006 crate 6 INT Interrupt not received : The expected DPM Valid bit is set in the LTC Interrupt register but there is no interrupt from the Transputer Event pin. mask : Interrupt Mask register (should equal expected DPM Valid bit) bits : Interrupt register Error FLTN FLTN 00000006 info 00000007 buff 6 event 00000006 crate 7 FLTN Trigger Number error : The FLTN in the DPM Info register does not have the expected value. FLTN means First Level Trigger Number. FLTN : expected Trigger Number info : DPM Info register Error GBCN trigger address 04390000 info 00000006 buff 6 event 00000006 crate 8 GBCN Trigger Address error : The GBCN in the DPM Info register does not correspond to the value of the Trigger Address register : Trigger Address = 2 * GBCN - 1 GBCN means GFLT Bunch Crossing Number. This check is done by Tigger only (requires ROC Pipeline Freeze mode). trigger address : expected Trigger Address ( left half of HEX value) : Trigger Address register (right half of HEX value) info : DPM Info register Error COPY end copy 0000010F addr 00000110 buff 6 event 00000006 crate 9 COPY End Copy Address error : The End Copy Address register does not have the expected value : End Copy Address = Trigger Address - Jumpback + Window End where Jumpback = pipeline length - MINUS jumpback and pipeline length = Pipeline End + 1 This check is done by Tigger only (requires ROC Pipeline Freeze mode). end copy : expected End Copy Address addr : End Copy Address register Error EOR end of run CSR 00000024 info 00000006 buff 6 event 00000006 crate 10 EOR End Of Run error : This is either of the following : - The EOR Readout Type is in the DPM Info register but the EOR bit in the CSR is not set. - The EOR bit in the CSR is set but the EOR Readout Type is not in the last valid DPM Info register. CSR : Control Status register info : DPM Info register