68k_Services Draft 1 ------------------------------- Most Recent Section: 19-MAY-1995 Define what Functionality we want the next L15CT test to be at D-Zero ----------------------------------------------------------------------- Rev. 19-APR-1995 1. Want to readout on the Trgr Data Cable. 2. Want Answer Done signals (both to look at and to route back to M103 L15 FW whether they are used or not). 3. Do not want the ERPB's or the Comm Ports to double buffer. 4. Do not care if a M103 L15 FW Decision Cycle is underway (i.e. when a given L1 Spec Trig fires then L15CT always processes to conclusion). 5. Want "normal" and MFP event L15CT Data Blocks. 6. Do not want to tear things up so much that it is impossible to make more simple clear DATA tests as more L1 racks have the ERPB's installed. 7. Want to handle L1 Trig's that are rejected by Muon L15. 8. For this first cut of 68k_Services we will wait for the Global DSP to indicate the Term Answers and not try to calculate the answer based on the Number of Objects Found reported in the Local DSP to EC Status Words. 9. This first cut of 68k_Services will use only a very simple routine to try to restart the DSP's if it detects an error during a L15CT cycle. 10. This first cut of 68k_Services will have facilities for control from TCC. 68k_Services uses the "Load Code" and the "Load Parameters" Interrupt Service Routines to let TCC control the operation of L15CT. 11. 68k_Services control the sending of Transmit Triggers to the ERPB cards via the ExtEnb control line to Channel #7 of the L15CT MTG. Different ways to divide up the 68k_Services -------------------------------------------- EC vs RC Time Critical vs Time Not Critical VME Bus #1 vs VME Bus #2 One thing at a time Check on and Service 3 or 4 Linear Code Section vs things at once Cyclic Code Section Organization based on the interface specification to other components of the L15CT and based around the required software flags (what sets them, what clears them, and what actions are taken based on them). Case List and Action List for the L15 Cal. Trig. ---------------------------------------------------- Actions --------------------------------------- L15CT DAQ L15CT DBlk Scenario Cycle Readout Valid Flag --------------------------------- ------ --------- ------------ 1. Pure L1 that does NOT involve our NO YES Not Valid L1 Spec. Trig(s). 2. Pure L1 that DOES involve our YES YES Valid L1 Spec. Trig(s). 3. M103 L15 decision cycle that does NO NO "Not Valid" NOT involve our L1 Spec. Trig(s). and is REJECTED (e.g. by Mu L15). 4. M103 L15 decision cycle that does NO YES Not Valid NOT involve our L1 Spec. Trig(s). and is ACCEPTED (e.g. by Mu L15). 5. M103 L15 decision cycle that DOES YES NO "Valid" involve our L1 Spec. Trig(s). and is REJECTED. 6. M103 L15 decision cycle that YES YES Valid DOES involve our L1 Spec. Trig(s). and is ACCEPTED AFTER L15CT sends its L15 Terms to M103. 7. M103 L15 decision cycle that DOES YES YES Valid involve our L1 Spec. Trig(s). and is ACCEPTED BEFORE L15CT sends its L15 Terms to M103. Notes: ------ Scenarios #2, #6 and #7 all take the same actions. Scenarios #3 and #5 do not have a DAQ Readout Cycle. Scenarios #1, #3 and #4 do not have a L15 Cal. Trig. Cycle. Guide Lines for the 68k_Services --------------------------------------------- Rev. 4-APR-1994 1. The basic philosophy is that the 12 DSP's are able to sequence themselves through all of the steps in a L15CT cycle. The 68k_Services only participates in a L15CT cycle in the following ways: 68k_Services sends out the Wake Up Word that the DSP's need to begin their work. 68k_Services monitors the progress of the L15CT cycle and intervenes only if necessary (e.g. a DSP has hung). 68k_Services provides some data to the L15CT Data Block and controls the operation of the 214 Buffers and the VBD card. 68k_Services controls the selection of MFP and "normal" events. 2. 68k_Services is divided into two basic parts. There is the "House Keeping Orbit", which in a cyclic order services a number of background tasks and the "Linear Code" section which takes over once there is a L1 trigger. 3. During the "House Keeping Orbit" do not spend more than 10 usec on any one of the jobs (i.e. be ready within 10 usec to start working on the next L15CT cycle). 4. Each of the jobs that are visited during the House Keeping Orbit should maintain a flag to show if that job has already been completed. All of the jobs are written so that it is certain that they will complete within 10 usec. 5. The first step when returning to the House Keeping Orbit is to execute the tasks that are involved with sending an event out to Level 2. 6. Do not reenter the House Keeping Orbit until it is safe for the 68k_Services to learn that there has been a new L1 Trigger. 7. During normal operation do not start any VME cycles that could hang, i.e. do not try to talk to VME Bus #2. 8. During the House Keeping Orbit try to get things setup ahead of time for the next L15CT cycle, e.g. try to get all DSP's back to step #0. 9. "Remember" the things that are setup ahead of time so that during the L15CT cycle you do not need to check on them again. 10. During the L15CT cycle do not wait for a resource until you really need it, e.g. do not wait for a Fresh 214 Load Buffer until you really need to write into it. 11. Symbols used in the assembly code have the following suffixes to indicate what type of value they stand for: A symbol that is the operand has the form "ABC". A symbol that is the address of the operand has the form "ABC_Loc". A symbol that is the address of a memory location that holds the address of the operand has the form "ABC_Handle". 12. Note that a big difference between 68k_Services and the VTC program is that VTC does not need to do any processing to get the readout started i.e. the COMINT's startup automatically and the unwind automatically form L15 rejects. 13. Routines will be call via JSR. In most cases no information will be passes on the stack (it takes too long) and no registers will be saved (they are not needed). 14. There are two RC functions and 1 EC function that may be executed from either the House Keeping Orbit or from the Something Has Happened section. The exact same code is used to implement the required function in either location in the 68k_Services program. 68k_Services Program Outline --------------------------------------------- Rev. 19-MAY-1995 House Keeping Orbit ------------------- 1. In this House Keeping Orbit there are a number of tasks to service in a continuing cyclic order. Do not spend too much time on any one of these tasks (e.g. not more than 10 usec). Do not get stuck in some task (e.g. by reading a VBD register while it is busy running its DMA list over the VME bus). With each trip through the House Keeping Orbit a counter in the 68k_Services_to_TCC Status Block in incremented. This allows TCC to know that 68k_Services is still running and has not become stuck. Do not enter the House Keeping Orbit until it is OK for the 68k_Services to learn that there has been a new L1 trigger. Keep flags that indicate whether or not each of the following tasks has been completed. The following is the list of tasks that are cyclicly serviced. Each task is marked as being a part of RC or of EC. A detailed sketch of each of these tasks can be found near the end of this document. 1. EC checks to see if all 12 DSP's are ready for a new event ------------------------------------------------------------- EC should check to see that all DSP's have finished their work on the current event, have "initialized" and are ready for a new WUW. EC clears the previously valid WUW when Glb DSP reaches Step D15. This causes all DSP's to quickly move to "Step D0" which means that they are looking for a new valid WUW. If EC is able to get all DSP's to "Step D0" then it should remember this so that it does not need to check again before giving them a new valid WUW when the next event comes in that needs L15CT processing. Also, the EC keeps a counter which indicates how long the EC has been trying to perform the Move all 12 DSPs to "Step D0" function. If this takes too long, then call an "Unstick_DSPs" routine. 2. RC checks to see if it should swap 214 Load and Read Buffers and Start a VBD DMA read cycle -------------------------------------------------- RC checks if there is a Fresh 214 Load Buffer. If the software flag that indicates whether or not there is a Fresh 214 Load Buffer is not set then RC works to try to get one. What this really means is RC checks to see if it can swap the 214 Buffers between Load and Read. The 214 Buffers can only be swapped if: The Global DSP and EC are finished writing the nth event into the current 214 Load buffer, and the VBD has finished DMA reading the n-1 event from the current 214 Read buffer. If the 214 buffers can be swapped, so that there is a Fresh 214 Load buffer, then EC should remember this so that it does not need to spend time checking to see if there is a Fresh Load Buffer before telling the Global DSP that it can begin writing the next L15CT Data Block. If this task can swap the 214 buffers then it starts the VBD DMA reading from the new 214 Read Buffer. 3. RC Manages the Conclusion of the VBD Cycle --------------------------------------------- RC manages the conclusion of the VBD cycle (i.e. when the VBD indicates with its hardware DONE signal that it has finished the DMA read). At the conclusion of the VBD cycle the SRDY signal to the VBD is dropped and a number of software flags change state. 4. EC Checks for a new L1 trigger --------------------------------- EC checks to see if the Path_Select_P2 says that there has been a new Level 1 Trigger. Note that ALL Level 1 triggers require servicing by the EC (even L1 triggers that are immediately rejected by Muon L1.5). When the Path_Select_P2 indicates that there is a new event (i.e. the Something_Happened bit is set in Path_Select) then check the Path_Select "That's_Me" bit to see if this is an "IBS" event or a "That's_Me" event. Then branch to the proper linear-code time critical straight section to processing the indicated type of event. Notes about the above steps: ---------------------------- Steps 1 and 2 involve remembering something so that you may not need to check it again during time critical processing. For best performance the steps listed above should be executed in a specific order. The current thinking is that it would be best to execute in the following way: 1 through 4, and then the cycle 1, 4, 2, 4, 3, 4 and repeat. To prevent hanging VME cycles the following steps are taken: For all events we never talk directly to the VBD. We always just read via a VME Bus #1 Ironics card the state of the VBD's DONE signal. For most events we never talk to VME Bus #2 at all. In this way we only need VME access to VME bus #2 to load up the VBD at initialization time, to load up the Short I/O 214 at initialization time, and to modify one location in the Short I/O 214 during the readout of MFP events. For any event that involves a VBD transfer to L2 we need to talk to VME Bus #2 to set the TAS number for VBD to read. Something Has Happened ---------------------- Once 68k_Services learns that there has been a Level 1 trigger (via reading the Path_Select_P2) then it begins executing the following sequence of steps. This is the "Linear Time Critical" section of the 68k_Services. 1. When there is a Level 1 trigger (any Level 1 trigger) the L15CT hardware will automatically perform the following steps. 1. L15CT Hardware sets the Front-End Busy. 2. L15CT Hardware latches the TAS Number. 3. L15CT Hardware maps the Spec Trig's Fired into L15CT Terms that need to be Evaluated. 4. L15CT Hardware indicates if >= 1 L15CT Term needs to be evaluated. 5. If >= 1 L15CT Terms need to be evaluated then the L15CT hardware causes the ERPB's to send their data to the DSP's. 6. L15CT Hardware clears all L15CT DONE lines that go back to M103. 2. EC looks to see if 1 or more L15CT Terms need to be evaluated. If zero L15CT Terms need to be evaluated then execute "IBS" processing. If >= 1 L15CT Term(s) needs processing then execute "That's Me" processing. "IBS" Processing ---------------- This will be an "IBS" readout (if it happens). Watch the "Readout Required" and the "Dump Event" signals from the Readout Control P2 Paddle card. Lots of L1 triggers will turn into "Dump Event" after just a few beam crossings (because of Muon L15 rejects). We will not start any serious process to prepare for readout until we learn if readout is going to be required. 1. Get the TAS Number. This should take only about 1.5 usec i.e. < 1 BX. 2. Wait and watch the Readout Control P2 Paddle Card until either the "Readout Required" or the "Dump Event" signal becomes active. Then take the proper one of the two following paths. "IBS" "Dump Event" Processing ----------------------------- OK, this was an "IBS" event but M103 L15 FW has rejected it. Thus we just need to unwind from here and go back to the House Keeping Orbit. 1. Clear both the Readout Control and then the Path Select P2 Paddle Cards by pulsing the proper Ironics lines high. This also clears the EC Front-End Busy that is generated on the Path Select P2 Card. 2. Increment a counter in the 68k_Services_to_TCC Status Block that counts how many "IBS" events with no readout to L2 have been processed. 3. Print "i" on the 68K_Services MVME135 console. The printing of this character is controlled by the print character prescale counter. 4. Return to the House Keeping Orbit. "IBS" "Readout Required" Processing ----------------------------------- OK, this is an "IBS" event and we do need to readout. Thus we need to make the dynamic part of the Crate Header and the word in the Frame Code Section that indicates that this was an "IBS" event. Let's build these words in 68k local memory (or registers), then verify that we have a Fresh 214 Load Buffer, and then move all of this stuff into the 214 Load Buffer. 1. Clear both the Readout Control and then the Path Select P2 Paddle Cards by pulsing the proper Ironics lines high. This also clears the EC Front-End Busy that is generated on the Path Select P2 Card. 2. Build the dynamic words of the Crate Header. 3. Build the necessary words of the Frame Code Section. 4. Check the software flag to see if we have a Fresh 214 Load Buffer. If we do not have a Fresh 214 Load Buffer then start the necessary RC servicing and wait here until we have a Fresh 214 Load Buffer. 5. Move the dynamic Crate Header words and the necessary Frame Code Sections words into the Fresh 214 Load Buffer. 6. Clear the software flag that says that we have a Fresh 214 Load Buffer. 7. Set the All_Data_In_Load_Buf software flag that indicates that all of the data for this event is now in the 214 Load Buffer. 8. Increment a counter in the 68k_Services_to_TCC Status Block that counts how many "IBS" events with readout to L2 have been processed. 9. Print "I" on the 68K_Services MVME135 console. The printing of this character is controlled by the print character prescale counter. 10. Return to House Keeping Orbit. "That's Me" Processing ---------------------- OK, At least one Spec Trig has fired that requires the L15CT to cycle. We do not know at this time if the M103 L15 FW will reject or confirm this event so we do not know if we are going to need to readout or not. 1. Read the TAS Number and from the Readout-Control P2 card. Store the TAS Number in Sync Word format in reg D7. 2. Check the MFP_Event software flag that tells us if this is going to be a "normal" event or a "MFP" event. 3. Read the Term-Select P2 card to obtain the list of L15CT terms that need to be evaluated on this cycle of L15CT. 4. Form the Wake Up Word and store it in reg D2. The information that is needed to form the new Wake Up Word is: Terms that need to be evaluated, MFP_Event flag, and the LSByte of the TAS number. Do not send the new Wake Up Word to the DSP's yet. 5. Check the software flag that tells us if all 12 DSP's are at Step D0. If they are not all at Step D0 then work to get them there and wait here until they are all at Step D0. Keep track of how long it takes to get them all to Step D0. If too much time elapses, then perform the appropriate type of error recovery operation. 6. Send the WUW to the three Local DSP locations and then to the one Global DSP location. 7. Clear the software flag that says all DSP's are at Step D0. 8. OK, things should now be under control for about 70 usec or so. Thus, we can start in on some other work. Do everything that we can to get ready in case this event is readout. 1. Build the dynamic words of the Crate Header in 68k local memory. Make the "Mark and Force Pass Mask" word of the Crate Header, consult the MFP_Event software flag to see if this is an "MFP" event. Store the "Mark and Force Pass Mask" in register D6. Do NOT try to put the Crate Header into a 214 Load Buffer at this time. 2. If the MFP_Event software flag is set then: clear the MFP_Event software flag, load the MFP ratio (given to us by TCC) into the MFP Down Counter, set the If_Transfer_Want_MFP_Transfer software flag, and set all Term Answers to Hi and set all Term DONEs to active. 3. Decrement the MFP Down Counter and if it now reads zero then set the MFP_Event software flag for the next event. 4. Build a List of Spec Trig's Fired 15:0 in register D1. Read the information that is required to build this list from the Term-Select P2 card. 5. Build the 2nd longword of the Type 0 Entry of the DeBug Section of the L15CT Data Block. Store this in register D3. Use the If_Transfer_Want_MFP_Transfer software flag to build this longword of the Type 0 Entry. 6. Build as much as we can of the "Masks of Terms" longword that is part of the Frame Code section of the L15CT Data Block. This is stored in register D2. We use the list of Terms that need to be evaluated and the If_Transfer_Want_MFP_Transfer software flag to build the Masks of Terms. 7. Disable the L15CT MTG from sending out any more Transmit Triggers to the ERPBs. We need to get this stopped before we drop Front-End Busy and now is a good "free" time to do it. We block the Transmit Triggers by making inactive the control line to the ExtEnb input of L15CT MTG Ch #7. This control signal comes from the LSBit of Port #1 of the Path Select Ironics card. The L15CT MTG will be re-enabled to send out Transmit-Triggers in the house keeping routine that takes all 12 DSP's back to Step D0. 8. We still do not know if we are going to readout this event or not but we have done everything that we can to get ready to readout. The information that 68k_Services needs to put into the L15CT Data Block is stored in registers for transfer to the "That's Me Readout Required" routine. We need to have completed all of this work before the Global DSP reaches Step D3. 9. Read the Global DSP to EC Status Word and wait for the Global DSP to reach Step D3. Keep track of how much time has elapsed while waiting for the Global DSP to reach Step D3. If too much time (i.e. about 10 milliseconds [note that the Global DSP requires about 350 microseconds to reach Step D3 for MFP events)] elapses, then perform the appropriate error recovery routine. Note that we need to check for GDSP Step D3 or any Step greater than that. 11. If this is NOT an MFP event then do the following. Once the Global DSP has reach Step D3 take the "Term Answers" byte from its status word and send the Term Answers to the M103 L15 FW. Then send the Term Done's to the M103 L15 FW. If this is an MFP event then do not send the tern answers from Glb DSP to the L15 FW In either case store the Global DSP's Status (which includes the Term Answers) in register D5. 12. Wait and watch the Readout Control P2 Paddle Card until either the "Readout Required" or the "Dump Event" signal becomes active. Then take the proper one of the two following paths. "That's Me" "Dump Event" Processing ----------------------------------- OK, this was a "That's Me" event but the M103 L15 FW has rejected it. Thus we just need to unwind from here and go back to the House Keeping Orbit. 1. Clear both the Readout Control and then the Path Select P2 Paddle Cards by pulsing the proper Ironics lines high. This also clears the EC Front-End Busy that is generated on the Path Select P2 Card. 2. Send to the Global DSP a "Transfer to 214 Required Word" that indicates that there will NOT be a transfer to the 214 Load Buffer. 3. Clear the Told_GDSP_to_Transfer software flag. 4. Test the If_Transfer_Want_MFP_Transfer software flag. If it is set then Increment the counter in the 68k_Services_to_TCC Status Block that counts how many "MFP" events with no readout to L2 have been processed. If this software flag is cleared then increment the counter in the 68k_Services_to_TCC Status Block that counts how many normal "That's Me" events with no readout to L2 have been processed. 5. Test the If_Transfer_Want_MFP_Transfer software flag. If it is set then print "f" on the 68K_Services MVME135 console. If this flag is cleared then print "n" on the console. These character prints are "pre scaled". 6. Clear the If_Transfer_Want_MFP_Transfer software flag. 7. Return to the House Keeping Orbit. "That's Me" "Readout Required" Processing ----------------------------------------- OK, this is a "That's Me" event and we do need to readout. Thus we need to: 1. Clear both the Readout Control and then the Path Select P2 Paddle Cards by pulsing the proper Ironics lines high. This also clears the EC Front-End Busy that is generated on the Path Select P2 Card. Yes, it is OK that we are dropping EC Front-End Busy at this point; we know how to finish handling this event, Global DSP has all of the data, new data could flow into the Local DSP's without hurting anything, no new L15CT processing will start until there is a new WUW. 2. Check the software flag to see if we have a Fresh 214 Load Buffer. If we do not have a Fresh 214 Load Buffer then start the necessary RC servicing (Conclude_VBD_Cycle, All_DSPs_to_Step_D0, and Swap_Load_Read_Bufs) and wait here until we have a Fresh Load Buffer. 3. Finish any work required to build the dynamic words of the Crate Header and move them into the 214 Load Buffer. This includes the SYNC Word, VALIDITY Word, and the MFP Mask Word. 4. Finish building the words of the Frame Code Section and move them into the 214 Load buffer. This includes the: EC Starting Status, EC Finishing Status, RC Finishing Status, List of L1 Spec Trig Fired, and the Masks of Terms 5. Load the second longword of the Type 0 Entry in the Data Block DeBug section into the 214 Load Buffer. This is an event to event dynamic longword that indicates if the DeBug section is from an MFP event. 6. Send to the Global DSP a "Transfer to 214 Required Word" that indicates that we do need a transfer to the 214 Load Buffer. Set the Told_GDSP_to_Transfer software flag. 7. Clear the software flag that says that we have a Fresh 214 Load Buffer. 8. Set the This_Transfer_is_MFP software flag equal to the If_Transfer_Want_MFP_Transfer software flag. Then always Clear the If_Transfer_Want_MFP_Transfer software flag. 9. Test the This_Transfer_is_MFP software flag. If it is set then Increment the counter in the 68k_Services_to_TCC Status Block that counts how many "MFP" events with readout to L2 have been processed. If this software flag is cleared then increment the counter in the 68k_Services_to_TCC Status Block that counts how many normal "That's Me" events with readout to L2 have been processed. 10. Test the This_Transfer_is_MFP software flag. If it is set then print "F" on the 68K_Services MVME135 console. If this flag is cleared then print "N" on the console. Printing of these characters is controlled by the print character prescale counter. 11. Return to House Keeping Orbit. List of Software Flags Maintained and Used by 68k_Services -------------------------------------------------------------- Rev. 13-JULY-1994 1. Software flags for DSP management: 1. All_DSPS_at_Step_D0 This is a single software flag that indicates that all 12 DSP's are at Step D0 (i.e. that they are "initialized" for the next event and waiting to receive a fresh Wake Up Word. 2. Software flags to control MFP events and the length of the DeBug Section at the end of the L15CT Data Block. 1. MFP_Event This is a single software flag that indicates if the next event that cycles the L15CT will be an MFP event. During the processing of the "current" event this flag is first cleared, the MFP Down Counter is updated, and if the MFP Down Counter has expired, then this flag is set. 2. If_Transfer_Want_MFP_Transfer This is a single software flag that indicates for a given Thats_Me event, if that event wants to have the long MFP DeBug section if the event ends up being readout (i.e. not rejected). This flag is used to control the setting or clearing of the This_Transfer_is_MFP software flag in the Thats_Me_Readout_Req section. The If_Transfer_Want_MFP_Transfer is set in the Thats_Me_Processing section if this readout is going to try to be an MFP event (it does no know for certain yet because it may be rejected). This flag is always cleared upon exiting either the Thats_Me_Dump or the Thats_Me_Reaout_ _Req sections. 3. This_Transfer_is_MFP This is a single software flag that indicates if this is an MFP event and thus if the transfer for this event needs the long Word Count for the DeBug Section. This flag is set in the Thats_Me_Readout_Req section if the If_Transfer_Want_MFP_Transfer software flag is set. This flag is always cleared when exiting the House Keeping Orbit task that swaps the 214 buffers and starts the VBD DMA readout cycle. 4. Previous_Transfer_Was_MFP This is a single software flag that indicates if the transfer for the previous event used the long MFP Word Count. When exiting the House Keeping Orbit task that swaps 214 buffers the state of Previous_Transfer_Was_MFP is set to that of This_Transfer_is_MFP before the This_Transfer_is_MFP is cleared. 3. Software flags for 214 Buffer and VBD management: 1. Fresh_Load_Buf_Availb This is a single software flag that indicates if there is a Fresh 214 Load Buffer available. This flag is set each time the 214 Buffers are switched between Load and Read. This flag is cleared as soon as any data is written into the fresh 214 Load Buffer. 2. All_Data_In_Load_Buf This is a single software flag that indicates if ALL of the data for a given event has been written into the 214 Load Buffer. This flag is set as soon as the last of the data for an event is written into the 214 Load Buffer (set in IBS_Readout_Req for IBS events or else set in All_DSPs_at_Step_D0 for Thats_Me events). This flag is cleared when the 214 Buffers are swapped between Load and Read functions. 3. Told_GDSP_to_Transfer This is a single software flag that indicates whether or not the All_DSPs_at_Step_D0 routine should set the All_Data_in_Load_Buf software flag. The Told_GDSP_to_Transfer flag is cleared in the That's_Me_Dump routine and it is set in the That's_Me_Readout_Req routine. 4. Which_214_Is_Load_Buf This is a single software flag that indicates which of the two 214 buffers is the Load Buffer. If this flag is set then 214 #2 is the Load Buffer. If this flag is cleared then 214 #1 is the Load Buffer. This flag is set in and used by the routine that swaps 214 buffers between Load and Read. 5. State_of_RC_FE_Busy This is a single software flag that indicates if the Readout Control Front-End Busy signal is currently asserted. This flag is set when the Readout Control Front-End Busy signal is asserted. This flag is used by the routine that swaps 214 buffers between Load and Read. 6. SRDY_Has_Been_Sent This is a single software flag that indicates that a SRDY signal has been sent to the VBD. When the SRDY signal is sent: this flag is set and the VBD_Is_Ready flag is cleared. 7. VBD_Is_Ready This is a single software flag that indicates that the VBD is prepared to receive a new SRDY signal. When the VBD DONE signal is received from the VBD: this flag is set, the SRDY_Has_Been_Sent flag is cleared, and the SRDY signal itself is cleared. Note that the VBD_Is_Ready software flag is not really set as soon as the VBD DONE signal is received but rather this flag is set at the conclusion of the VBD DONE protocol. 4. Software flags used for error recovery 1. Executing_Thats_Me_Processing This is a single software flag that indicates that the Service 68K code is currently in the Ser68_Thats_Me_Processing_1 routine. It is SET upon entry to the Ser68_Thats_Me_Processing routine, and it is CLEARED upon exit from the Ser68_Thats_Me_Processing routine. It is used to indicate whether error recovery needs to worry about building and sending a Data Block (i.e. pay attention to and follow the Readout Control Paddleboard), or whether error recovery can just ignore the VBD. Errors found during Ser68_Thats_Me_Processing_1 are found after the beginning of a TAS Protocol, so the Readout Control Paddleboard must be examined and a Data Block must be built and sent if the event is to be read out. Thus the normal sequence of steps during building the event in a 214 Buffer and sending it out look like the following: _________ __________________________ SF Fresh_Load_Buf_Availb \____________/ ___ SF All_Data_In_Load_Buf __________________/ \__________________________ ____________ SF SRDY_Has_Been_Sent ______________________/ \_____________ ______________________ ________ SF VBD_Is_Ready \_________________/ ____________ HS SRDY to the VBD ______________________/ \_____________ ______ HS DONE from the VBD ________________________________/ \_________ Actually writing _________ AC into the Load Buf ______/ \________________________________ Swap 214 Buf's ____________________ ____________________________ AC Load <-> Read ____________________X____________________________ Detailed Sketch of each of the House Keeping Orbit Tasks -------------------------------------------------------------- Rev. 19-MAY-1995 1. EC checks to see if all 12 DSP's are ready for a new event ------------------------------------------------------------- Sketch of this task: 1. Check to see if the software flag is set that says that all DSP's are at Step D0. This is the "All_DSPS_at_Step_D0" software flag. If this flag is SET then exit this routine. If this flag is NOT set then continue. 2. Read the DSP to EC Status Word for the Global DSP. If it has reached Step D15 then continue on with this routine. If the Global DSP has not reached Step D15 then exit this routine. Note that by the time that the Global DSP reaches Step D15 it is almost certain that the other 11 local DSP have also reached Step D15. 3. If we make it to this point then we will begin the following atomic process which will bring all 12 DSP's back to Step D0. Re-Enable the L15CT MTG to send Transmit Trigger to the ERPBs. The Transmit-Trigger to ERPB has been blocked since beginning to wait for GDSP to reach Step D3 in the "Thats Me Processing" routine. Sending out Transmit Triggers has been blocked by the inactive state of the control line to the ExtEnb input of L15CT MTG Ch #7. This control signal comes from the LSBit of Port #1 of the Path Select Ironics card. Note that if there has been a L1 trigger fire since the Front-End Busy was dropped a little while back, and if this L1 trigger required L15CT processing then the PAL in Ch #7 of the L15CT MTG has "remembered" this and it will now send out the Transmit Trigger. Clear the previous valid Wake Up Word. Clear the loop counter which was timing how long it took for the Global DSP to reach Step D15. Check the Told_GDSP_to_Transfer software flag. If it is set, then Set the All_Data_In_Load_Buf software flag. Clear the previously valid "Transfer to 214 Required Word". Check to see that all 12 DSP's now indicate in their "DSP to EC Status Words" that they are all at Step D0. You should either keep a loop counter to sense errors in moving to Step D0, or wait a sufficient amount of time (i.e. 50 microseconds) before checking these Status Words and then check each Status Word only once. If any DSP does not move to Step D0 in a reasonable amount of time then perform the "Unstick_DSP" operations required for a "D0" error. Set the software flag, All_DSPs_at_Step_D0, that indicates that all 12 DSP's are at Step D0 and ready for the next WUW. Exit this routine. 2. RC checks to see if it should swap 214 Load and Read Buffers and Start a VBD DMA read cycle -------------------------------------------------- Sketch of this task: 1. Check to see if the Fresh_Load_Buf_Availb software flag is set. If this flag is SET then exit this routine. If this flag is NOT set then continue. 2. Check to see if the All_Data_In_Load_Buf software flag is set. If it is NOT set then exit this routine. If this flag is SET then continue. 3. Check to see if the VBD_Is_Ready software flag is set. If it is NOT set then exit this routine. If it is SET then do the following as an atomic process: OK, we have verified that the 214 buffers need to be swapped and that all necessary pre-swapping conditions exist (i.e. the the data for event "n" is in the Load Buffer and the VBD has finished reading event "n-1" from the Read Buffer. Just before swapping Load and Read Buffers we need to copy the 16 bit TAS Number from its location in the MSWord of the SYNC longword in the Crate Header section of the current Load Buffer into the Short I/O storage location where the VBD will read it as it is reading the rest of the event data. Swap the 214 Buffers between Load and Read. Use the software flags: Which_214_Is_Load_Buf to control which 214 buffer is made the new Load Buffer. Updata the Which_214_Is_Load_Buf software flag. Use the software flag State_of_RC_FE_Busy to control the state of the Readout Control Ironics Port #4 bit 1 (i.e. RC Front-End Busy) when swapping the buffers. Set the Fresh_Load_Buf_Availb software flag. Check the This_Transfer_is_MFP and the Previous_Transfer_Was_MFP software flags and take one of the following four paths: 1) If the This_Transfer_is_MFP software flag is set and the Previous_Transfer_Was_MFP software flag is cleared then: Change the Word Count for the DeBug Section in the Short I/O Memory to the MFP event Word Count value. 2) If the This_Transfer_is_MFP software flag is cleared and the Previous_Transfer_Was_MFP software flag is set then: Change the Word Count for the DeBug Section in the Short I/O Memory to the "normal" event Word Count value. 3) If the This_Transfer_is_MFP software flag is cleared and the Previous_Transfer_Was_MFP software flag is cleared OR 4) If the This_Transfer_is_MFP software flag is set and the Previous_Transfer_Was_MFP software flag is set then: Take no action to change the Word Counts in the Short I/O memory or to change the Set the Previous_Transfer_Was_MFP software flag equal to the This_Transfer_is_MFP software flag. Clear the This_Transfer_is_MFP software flag. Send the SRDY hardware signal to the VBD. Set the SRDY_Has_Been_Sent software flag. Clear the VBD_Is_Ready software flag. Clear the All_Data_In_Load_Buf software flag. Exit this routine. 3. RC Manages the Conclusion of the VBD Cycle --------------------------------------------- Sketch of this task: 1. Check the VBD_DONE hardware signal. If it is NOT set then exit. If it is set then do the following steps as an atomic process: Drop the SRDY hardware signal. Clear the SRDY_Has_Been_Sent software flag. Check that the VBD_DONE hardware signal has now dropped (in response to us dropping the SRDY hardware signal). As soon as VBD_DONE drops then set the VBD_Is_Ready software flag. Exit this routine. 4. EC Checks for a new L1 trigger --------------------------------- 1. Read the Path Select P2 to check if a new L1 trigger has occurred. Examine the "Something_Happened" bit of the Path Select P2 card to learn if there has been a new L1 Trigger. If there has NOT been a new L1 trigger then exit this routine and return to the House Keeping Orbit. 2. If there has been a new L1 Trigger then read the Path Select P2 card again. This time examine the "That's Me" bit to learn if any L15CT Terms need to be evaluated for this event. 3. If some L15CT Terms do need to be evaluated then branch to the "That's Me Processing" routine. If no L15CT Terms need to be evaluated then branch to the "IBS Processing" routine. Note that in step 2 above the Path Select P2 card is read for a second time. This uses an extra 500 nsec but it avoids skew problems between the "Something Happened" bit and the "That's Me" bit. List of the Software Routines as they exist as Source Modules ------------------------------------------------------------- Rev. 19-JULY-1994 The following list of source modules is arranged in their calling order during normal program execution. Ser68_Main_1.src Ser68_Main_Symbols_1.include Ser68_Revision_Number.src Ser68_Version_Number.src Ser68_Init_Processor_1.src Ser68_Init_Ironics_1.src Ser68_Init_Memory_1.src Ser68_Init_VBD_1.src Ser68_Init_Data_Structures_1.src Ser68_Orbit_Master_1.src Ser68_all_DSPs_to_Step_D0_1.src Ser68_Swap_Load_Read_Buffers_1.src Ser68_Conclude_VBD_Cycle_1.src Ser68_Test_for_New_L1_Trig_1.src Ser68_IBS_Processing_1.src Ser68_IBS_Dump_Event_1.src Ser68_IBS_Readout_Req_1.src Ser68_Thats_Me_Processing_1.src Ser68_Thats_Me_Dump_Event_1.src Ser68_Thats_Me_Readout_Req_1.src Ser68_Load_Code_Interrupt_1.src Ser68_Load_Param_Interrupt_1.src Ser68_Error_Recovery_1.src Ser68_Clear_RC_and_PS_1.include Note that the Ser68_Clear_RC_and_PS_1.include routine is used in the Ser68_IBS_Dump_Event_1.src, Ser68_IBS_Readout_Req_1.src , Ser68_Thats_Me_Dump_Event_1.src, and Ser68_Thats_Me_Readout_Req_1.src routines. The following is the flow path through the linear section of 68k_Services. The character shown in parenthisis is the character printed by 68k_Services just before it returns to the House Keeping Orbit. /-----> Read (N) /----> Normal ---< / \-----> Dump (n) / /---> That's_Me ----< / \ / * \ /-----> Read (F) | * \-----> MFP -----< | * \-----> Dump (f) | * * | * * | * * / * * Detect / * *** Byte Sync ***> (!) "Some- / * Error thing ---< * Happened" \ * \ * \ * /*****> Read (E) | ***> Error Recovery *****< | \*****> Dump (e) | | | \ \ /-----> Read (I) \------> IBS -----------------------------< \-----> Dump (i) --- Flow path for events during which no errors are sensed *** Flow path for events during which an error is sensed IBS = Innocent by Stander i.e. do not get data from Level 1 Cal Trig, do not run the DSP's, just make an "empty" L15CT Data Block. That's Me = Get L1 Cal Trig data, and run the DSP's. MFP = A Mark and Force Pass event is a "That's Me" event with the large Mark and Force Pass L15CT Data Block and all the L15 Term Answers set True independent of the L15CT calculations. Normal = Is a "That's Me" event with a normal L15CT Data Block and the answers from the L15CT calculations are sent back to the L15 Framework as the L15 Term Answers. Character Printing on the 68k_Services Terminal Screen The diagram above shows all of the possible flow paths through the linear section of 68k_Services. Each of these flow paths results in a single character being printed on the 68k_Services terminal screen. Because of the high rate of looping through the linear section of 68k_Services it is not possible to print all of these characters. For example we could easily be looping through "i" and "n" at over 1kHz. For this reason the printing of characters on the 68k_Services terminal screen is prescaled. The factor by which this character printing is prescaled is controlled by the value of the symbol "Char_Print_Ratio" in the Main_Symbols.Include file. For now this is set to 10. Each time that 68k_Services is initialized (e.g. via the Load_Parameters interrupt) the value of the character print prescale counter is set so that a character will be printed on the very first trip through the 68k_Services linear section. This is to insure that you have some indication about what is going on in case there is a problem when 68k_Services starts up. There are some exceptions to this character printing prescaling. All "e", "E", and "!" are printed. These characters indicate a problem and need to always be printed. Interrupt Routines: Load Code and Load Parameters ------------------------------------------------------------ Rev. 26-AUG-1994 The Ser68_Load_Code_Interrupt_1 interrupt service routine is called by TCC via the SIGHP interrupt from the MPCSR register on the MVME135 board. This routine will not actually load code into the 68k_Services MVME135 but it will re-initialize the running code and it does provide an analog to how the TCC handles the Hydra-II cards. When called Ser68_Load_Code_Interrupt routine performs the following steps: 1. Stop doing what ever 68k_Services was doing. 2. Clear the SIGHP interrupt bit from the MPCSR register. 3. Unwind the interrupt by forcing the Stack Pointer to its initial value. 4. Set the Interrupt Priority Mask to allow priority 2 and above interrupts. 5. Put CR, LF on the 68k_Services MVME135 console. 6. Call the Ser68_Init_Processor_1 routine. 7. Call the Ser68_Init_Ironics_1 routine. 8. Call the Ser68_Init_Memory_1 routine. 9. Call the Ser68_Init_Data_Structures_1 routine. 10. Save the block of Software Flags in a safe memory area so that they will not be overwritten by ffffffff's. 11. Put a message on the 68k_Services MVME135 console. 12. Set the 68k_Services to TCC Status Block first longword to $68000000. 13. Go into a dead forever loop. The Ser68_Load_Param_Interrupt_1 interrupt service routine is called by TCC via the SIGLP interrupt from the MPCSR register on the MVME135 board. This routine will actually check and load parameters into the 68k_Services MVME135, e.g. the MFP ratios. This routine also provides an analog for TCC to follow in the same way that it handles the Loading Paramters into the Hydra-II cards. When called Ser68_Load_Param_Interrupt routine performs the following steps: 1. Stop doing what ever 68k_Services was doing. 2. Clear the SIGHP interrupt bit from the MPCSR register. 3. Unwind the interrupt by forcing the Stack Pointer to its initial value. 4. Set the Interrupt Priority Mask to allow priority 2 and above interrupts. 5. Restore the block of Software Flags from their safe storage area (that kept them from being overwritten by ffffffff's) to their normal operating locations. 6. Check value of the following items in the Parameter Block: Parameter Block Memory Map Version and Revision Numbers The Crate ID, and the MFP Ratios. 7. From the Parameter Block, copy the appropriate information into the Frame Parameter Section and the Term Parameter Section of the L15CT Data Block in both MVME214 Buffer Memories. 8. Load the MFP Ratios into the 68k_Service execution section. 9. Clear the previously valid Wake Up Word and clear the previously valid Transfer Word. 10. Delay about 2 millsec to let the DSP's see the cleared WUW and the cleared Transfer Word. 11. Verify that all 12 DSPs are at Step D0. Note that the Error Recovery "un-stick DSP's" should NOT be attempted if all DSPs are not found at Step D0. If all 12 DSP's are NOT at Step D0 then 68K_Services will provide an error code to TCC which indicates this (in the 68K-to-TCC Status Block) and then 68k_Services will go into a wait forever loop until TCC is read to try again. If all 12 DSP's are at Step D0 then continue with this Load_Param_Interrupt routine. 12. Zero the counters in the 68k_Services_to_TCC Status Block which keep track of the number of times that 68k_Services has attempted the different types of Error Recoveries (e.g. recovering from GDSP never reaching Step D3. Zero the counters in the 68k_Services_to_TCC Status Block that counts how many times each of the paths through 68k_Services has been taken. 13. Put a message on the 68k_Services MVME135 console. 14. Set the 68k_Services_to_TCC Status Block to the appropriate value(s) indicating either success or failure. 15. Jump to the Orbit Master routine if there are were no Parameter or DSP errors, otherwise go into a dead forever loop. Temporary Routine to check the Byte Alignment of the Headers in the Object Lists ------------------------------------------------------------ Rev. 19-JUL-1994 To verify that we do not have a Byte Alignment problem in the DSP to DSP transfer process we will temporarily start checking "DSP ID byte" in the headers in the Object Lists. The "DSP ID bytes" give us an easy know fixed target to look at to verify the byte alignment in the DSP Comm Ports for the DSP to DSP transfers. We will do this checking only on the MFP events. If there is a byte alignment problem then it should exist for all events so checking on only the MFP events gives us an easy way to spot the problem with out slowing things down by checking on all events. The short routine to do this byte alignment checking will be patched into the "Swap Buffers" routine. This sound like a strange place to put it but this is the place where you know that all of the DSP data is in the 214 Load buffer (Where 68k_Services) can see it and this is the place where you know whether or not this is an MFP event. If this routine spots a problem then it will increment a counter in the 68k_Services_to_TCC Status Block and print a "!" on the terminal screen. This printing is not prescaled by the print character prescale. The counter in the 68k_Services_to_TCC Status Block is set to zero by the Load_Parameters interrupt. This counter can be examined by the TCC during the Load_Code process before it is zeroed by the Load_Parameters ISR. Description of the Error_Recovery Routine ------------------------------------------------- Rev. 13-JULY-1994 The routine Ser68_Error_recovery_1 is used to get the DSP's going again if one of them hangs for some reason (e.g. an ERPB did not send all its data). This routine may be entered for any of the following reasons: - The Global DSP does not report that it reached Step D3 (Returning Terms to EC) within a reasonable (i.e. about 600 microseconds) amount of time. This error is sensed in Ser68_Thats_Me_Processing_1. - One or more DSPs are not able to progress to Step D15 within a reasonable (i.e. about 2 milliseconds) amount of time. This error is sensed in Ser68_all_DSPs_to_Step_D0_1, which is called from both Ser68_Thats_Me_Processing_1 and Ser68_Orbit_Master_1. - One or more DSPs are not able to progress to Step D0 within a reasonable (i.e. about 50 microseconds) amount of time. This error is sensed in Ser68_all_DSPs_to_Step_D0_1, which is called from both Ser68_Thats_Me_Processing_1 and Ser68_Orbit_Master_1. The error recovery performed by this routine (these routines?) must be variable depending when the error was discovered. Errors recovery from errors sensed in Ser68_Thats_Me_Processing_1 must include building and sending a L1.5 Cal Trig Data Block, while errors sensed from Ser68_Orbit_Master_1 do not require generation of a L1.5 Cal Trig Data Block. The general rule to follow when determining what error recovery to perform is: - Do whatever you can, in the amount of time available, to keep the overall triggering and acquisition system to keep from crashing. During error recovery, Front End Busy must be asserted. This will prevent new triggers from interfering with the error recovery process. Also note that it is necessary to be able to turn off this automatic error recovery. During serious system debugging, the best debugging aid available via the Service 68K is leave the DSPs "hung" at the point in the code where the error was detected. The automatic error recovery is intended to be used during unattended global running of the L1.5 Cal Trig, not during serious system debugging. The specific actions required for error recovery are: I. Recovery from an error sensed in Ser68_Thats_Me_Processing_1 (i.e. the Executing_Thats_Me_Processing flag is SET when the Error Recovery routine is called) 0. Front-End Busy will already be asserted, so we do not need to raise it now. 1. We need to check to see whether this event should be read out or dumped, by checking the Readout Control Paddleboard. Note that typically, the event will be read out (because the L1.5 FW will have timed out). 2. If this event is going to be dumped, we can clear the Executing_That_Me_Processing software flag and jump immediately to the "Error Recovery Common Code," i.e. we don't need to build a L1.5 Cal Trig Data Block, nor do we need to kick the VBD. 3. If this event is going to be read out, then we need to put some information in the L1.5 Cal Trig Data Block. Note that we have to provide a L1.5 Cal Trig Data Block before the Token Loop Count is exceeded. The Token circulates 2000 times. Each VBD requires 2 usec to pass it on (if it does not read out). There are 8 VBD's on Data Cable #0 (5 OTC's, L1, L0, and L15CT). This gives 2000 times x 2 usec per VBD x 8 VBD's = 32 milliseconds minimum available time to complete the Data Block and "kick" the VBD. 4. Before putting any data in the L1.5 Cal Trig Data Block, we need to check the software flag to see if we have a Fresh 214 Load Buffer. If we do not have a Fresh 214 Load Buffer then start the necessary RC servicing and wait here until we have one. 5. Clear the software flag that says we have a Fresh 214 Load Buffer. 6. Build the necessary words of the Crate Header and the Frame Code Section and move them into the 214 Load Buffer. We need to set a flag in the Processing Error Global Flag byte of the Data Validity Word (the 6th longword of the Crate Header) indicating that there was an error for this event. We also need to set a flag in the L1.5 Cal Trig Engine Control Finishing Status detailing the error which was discovered (a "D3" error). 7. ??? What about MFP counters/flags/word counts etc ??? 8. Set the All_Data_In_Load_Buf software flag 9. "Kick" the VBD (note that this is a multi-step process in itself, involving checking the VBD status, swapping Load/Read Buffers, setting and checking other software flags, etc. Can we just call the Ser68_Swap_Load_Read_Buffers_1 and Ser68_Conclude_VBD_Cycle_1 routines? Probably not because of the multiple exit points in Ser68_Swap_Load_Read_Buffers...unless we first guarantee that all of its conditions for completion will be met. 10. CLEAR the Executing_Thats_Me_Processing software flag. 11. Proceed to the Error Recovery Common Code. II. Recovery from an error sensed in Ser68_Orbit_Master_1 (i.e. the Executing_Thats_Me_Processing flag is CLEARED when the Unstick routine is called) 0. Note that the Front End Busy will NOT be set when we detect this error. We need to set the Front End Busy to provide protection during the error recovery period. 1. We need to wait at least 15 microseconds to guarantee that the ERPBs are in a quiescent state. We cannot hope to successfully Unstick the DSPs unless there is no data arriving via their Comm Ports (otherwise their DMA counters will be munged). 2. Proceed to the Error Recovery Common Code. III. Error Recovery Common Code 0. When we enter this point of the code, we are being protected by the Front End Busy, there should be no triggers flowing and no ERPB/DC activity. 1. We need to increment an error-specific counter. There are 3 counters, one each for "D3," "D0," and "D15" errors, regardless of which routine the error was sensed in. 2. We need to collect the 12 DSP-to-68K Status Words (either by re-reading the 12 Status Words from the Shared Dual Port Memories, or remembering the last read Status Words. 3. We need to build an "Error Code" longword, indicating which error type was sensed. 4. We need to report all 16 of these longwords (3 counters + 12 DSP-to-68K Status + 1 Error Code) to the TCC in the 68K-to-TCC Status Block section reserved for error recovery reporting 5. We need to issue the "68K Detected an Error" Interrupt (i.e. IIOF2) to all 12 DSPs (note that we always issue this error to all 12 DSPs regardless of which DSP actually was found with an error condition). Recall that this interrupt is actually issued via VME writes, and it should be cleared by the 68K after it is set. 6. We need to check that all 12 DSPs correctly proceeded to Step D0 within a reasonable amount of time. If one or more DSPs DID NOT correctly proceed to D0, DO NOT try to unstick any more, but just go to a "loop forever" dead loop. Front End Busy will be stuck high, so this condition should be noticed quickly by shifters who should be instructed to call us. 7. Release Front-End Busy (done by resetting the Path Select P2 card) and reset the Readout Control P2 card. 8. Print some brief error message on the 68K console screen 9. Proceed to the Housekeeping Orbit. Modifications to 68k_Services for use with the Multiple (4) Terms Same Tool ----------------------------------------------------------------------------- Rev. 17-AUG-1994 1. Change the Longword Length of the Frame Parameter section of the L15CT Data Block from 33 to 81. 2. Change the Longword Length of the Tool Parameter section of the L15CT Data Block from 33 to 129. 3. Change the Longword Length of the DeBug section for an MFP event in the L15CT Data Block from 2930 to 3205. 4. Make the following modifications in the Load Parameters ISR module. 1. Modify the "List Length" longword at the beginning of the Frame Parameter Section to indicate 4 Frame Parameter Term Blocks. 2. Copy 4 Frame Parameter Term Blocks from the from the Parameter Block given to us by TCC into their area in the Frame Parameter Section of the L15CT Data Block in both MVME214's. Note that each Term has 32 longwords in the Parameter Block and only 16 longwords in the Frame Parameter Section of the L15CT Data Block. 3. Modify the "List Length" longword at the beginning of the Tool Parameter Section to indicate 4 Local Term Blocks and 4 Local Term Blocks. 4. Copy 4 Local Tool Parameter Blocks from the from the Parameter Block given to us by TCC into their area in the Tool Parameter Section of the L15CT Data Block in both MVME214's. Note that each Term has 32 longwords in the Parameter Block and only 16 longwords in the Tool Parameter Section of the L15CT Data Block. 5. Copy 4 Global Tool Parameter Blocks from the from the Parameter Block given to us by TCC into their area in the Tool Parameter Section of the L15CT Data Block in both MVME214's. Note that each Term has 32 longwords in the Parameter Block and only 16 longwords in the Tool Parameter Section of the L15CT Data Block. >>>>><<<<<>>>>><<<<<>>>>><<<<<>>>>><<<<<>>>>><<<<<>>>>><<<<<>>>>><<<<<>>>>> List of other sections that need to be added to this 68k_Services document -------------------------------------------------------------------------- Rev. 25-JUL-1994 1. Need to learn more about and understand: Double Buffering of input to L15CT, who sends the Transmit Trigger to the ERPB's. When to send Term Answers&Dones back to M103 L15 FW. Signal from M103 L15 FW that says a L15 Decision Cycle is underway (or still underway). Who generates the RC Front-End Busy from L15CT. The EC Front-End Busy is pretty much understood. Where are timeouts needed to keep things from getting stuck. How to restart the DSP's if needed. What error counters should be kept. Are any "Trouble Bits" needed to send warnings to TCC - TrgMon. Are any "State Bits" needed for performance monitoring. Known things that need to be added to 68k_Services ----------------------------------------------------- Rev. 24-AUG-1994 1. Detect errors and timeouts. Maintain counters of these. Have routine to handle all types of these. The following is the list of known places where L15Ct could get stuck: 1. In the routine all DSP's to Step D0, one or more of the 12 DSP's could fail to move to Step D0 when its previously valid Wake Up Word is cleared. 2. In the IBS_Processing routine, 68k_Ser could wait forever trying to learn from the Readout Control P2 if the event should be transfered to L2 or dumped. 3. In the IBS_Readout_Required routine, 68k_Ser could wait forever looking for a fresh Load Buffer. 4. In the Init_Data_Structures routine when 68k_Ser is working with the VBD it could hang trying to setup an initial buffer. 5. In the That's_Me_Processing routine, 68k_Ser could wait forever trying to learn from the Readout Control P2 if the event should be transfered to L2 or dumped. 6. In the That's_Me_Processing routine, 68k_Ser could hang waiting for the Global DSP to reach Step D3. 7. In the That's_Me_Readout_Required routine, 68k_Ser could wait forever looking for a fresh Load Buffer. 2. Make certain that any place where 68k_Services can get stuck, that it sends back to TCC a status code indicating the problem and that it puts a message on the terminal screen before going into a dead loop.