Initialization of the L1.5 Cal Trig DSPs ---------------------------------------- 9-JUN-1994 Introduction ------------ This file describes the loading of code and initialization of the L1.5 Cal Trig. It does not describe the function of the L1.5 Cal Trig during normal running (i.e. the "Algorithm") but instead only describes the Initialization of the L1.5 Cal Trig. It also does not describe the overall system flow during Wakeup time, nor does it describe the 68K Service CPU's actions during Wakeup time. The Initialization of the L1.5 Cal Trig requires the following steps: (1) Bring the L1.5 Cal Trig to a known quiescent (preferably STOPPED, i.e. all DSPs in RESET) state. The TCC should halt all of the DSPs upon receipt of a L15CTSYS LOADCODE message (i.e. before loading code the TCC halts the DSPs. There is no special COOR message to force all DSPs to halt). (2) Load the code into the DSPs (one DSP chip at a time) using the On-Chip ROM Boot Loader. Note that once a chip has loaded all of its code it will automatically begin running that code. The DSPs must be programmed to do a minimal "set-up" action, communicate that the code is loaded and ready for parameters (also the code tells the TCC which DSP it is intended for, the TCC can use this to verify that it has loaded the correct code into the correct DSP) and then WAIT for permission to continue (i.e. wait for an interrupt from the TCC). The code is returned in the first longword of the "DSP to TCC Status" block. The communication from the DSP to the TCC is described in the file: [D0_TEXT.LEVEL_15.CALTRIG.HARDWARE_SOFTWARE_TEXT] STATUS_CODES_FROM_DSP_TO_TCC.TXT The TCC should load the code for a single DSP into the Shared Dual Port Memory, then "boot" that DSP, then WAIT for the good return status code, and then repeat the process for the next DSP. There are no known DSP order dependencies at LOADCODE time. The TCC should load code into the DSPs upon receipt of a L15CTSYS LOADCODE message. (3) Begin the Parameter-downloading protocol with the Local DSPs. This is done by loading the Parameter Block into the Hydra Shared Dual Port Memory and then issuing the "Load Parameters" interrupt to each DSP. The TCC should issue this interrupt to one DSP and wait for the DSP to respond with its status code before progressing to the next DSP. Note that when the Parameter Block is loaded into the Hydra Shared Dual Port Memories, the unused part of these memories (as well as the status information in the upper part of these memories) should be forced to $FFFFFFFF. The TCC should load Parameters into the DSPs upon receipt of a L15CTSYS START message (i.e. before starting the DSPs the TCC loads Parameters into the DSPs. New Parameters are ONLY loaded to the DSPs in conjunction with a START message from COOR). Recall that in this initial implementation a single START message should always be associated with and preceded by a single LOADCODE message. (4) The Local DSPs now load their Parameters. The action is the same in each DSP so I will only describe a typical DSP. (4-a) A DSP loads its Universal Parameters. This is done by FRAME Code in the DSP. The Frame Code checks the following things while loading Universal Parameters: - the Memory Map Version specified in the Universal Parameter Block Header is compared with the Memory Map Version expected by the Frame Code - the number of Terms defined is compared with the number of Terms expected by the Frame Code - the number of Universal Parameters defined is compared with the number of Universal Parameters expected by the Frame Code - each Universal Parameter is range-checked by the Frame. The Frame knows the valid range for each Parameter. Note that Parameter type (i.e. floating- point vs. integer) is NOT checked (because it is not possible to tell a floating-point parameter from an integer). The Frame must know the type of each Parameter If the Frame Code finds a mismatch in any of the comparisons described above, it reports the error to the TCC and halts. Otherwise it continues to the next step. (4-b) The Reference Set Data is loaded for each Reference Set. This is done by the Frame Code. No checking is done at this point. (4-c) For each Term, the DSP loads its Term-Specific Parameters. This is done in multiple steps: (4-c-1) A DSP loads its Frame Parameters. This is done by FRAME Code in the DSP. The Frame Code checks the following things while loading Frame Parameters: - the Parameter Block Type specified in the Frame Parameter Block Header is compared with the expected (Frame) Parameter Block Type - the Term Number specified in the Frame Parameter Block Header is compared with the Term Number for which the Frame is currently processing the Frame Parameters - the number of Frame Parameters defined is compared with the number of Frame Parameters expected by the Frame Code - each Frame Parameter is range-checked by the Frame. Again the Frame cannot check for integer vs. floating-point correctness If the Frame Code finds a mismatch in any of the comparisons described above, it reports the error to the TCC and halts. Otherwise it continues to the next step. (4-c-2) The DSP then loads its Local Tool-Dependent Term Parameters. This is partially done by the Frame Code and partially done by the Tool Code. The Frame Code checks the following things while loading Local Parameters: - the Parameter Block Type specified in the Frame Parameter Block Header is compared with the expected (Local) Parameter Block Type - the Term Number specified in the Frame Parameter Block Header is compared with the Term Number for which the Frame/Tool is currently processing the Local Parameters - The Tool Number specified is compared to the Tool Numbers of ALL Tools assembled into the executable If the Frame Code finds a mismatch in any of the comparisons described above, it reports the error to the TCC and halts. Otherwise it calls the Local Tool (via the Tool Initialization entry point), passing several pieces of information to the Tool. The information passed consists of: Tool Number of the Tool being called; Term Number to which the Tool is mapped; Reference Set Type found in the Header; and the address in Dual Port Memory of the remaining Parameters for this Tool. The Tool Code then checks the following things while loading Local Parameters: - the Tool Number (passed by the Frame) is compared to the Tool Number of the Tool which is currently being initialized - the Reference Set Type specified in the Header (passed by the Frame) is compared to the Reference Set Type expected by the Tool - the number of Local Parameters defined is compared with the number of Local Parameters expected by the Tool Code - each Local Parameter is range-checked by the Tool. Again the Tool cannot check for integer vs. floating-point correctness If the Tool Code finds a mismatch in any of the comparisons described above, it reports the error to the Frame Code (which in turn reports the error to the TCC and halts). Otherwise it generates all derived constants and then continues to the next step. (4-d) All Parameters have been successfully loaded (otherwise the code would not have reached this point in the execution). Each DSP now must report a "success" code to the TCC via the Dual-Port Memory, and now is ready to begin receiving Trigger Tower data through Comm Ports (and also looking for their Wakeup Words from the EC to appear in Dual-Port Memory) (5) The Global DSP also loads its Parameters, in a similar fashion. Note that the Global DSP does not load Reference Set data (ever), and also in this first implementation, the Global DSP does not load Frame or Tool Parameters. It only checks the Memory Map Version and Revision Numbers, as well as the number of Terms defined. (6) As the DSPs load their Parameters, the TCC polls the Dual-Port Memory looking for either a "success" or "failure" code from each DSP. When the TCC has seen all responses (or if too much time has elapsed), it replies with a "success" or "failure" message to COOR. "failure" code to COOR (7) Note that all DSPs will wait at State D0 after they have loaded their Parameters (assuming that the Parameter load was successful). (8) Now the Service 68K should begin operation. Note that no Service 68K operation is required (or desired) during the time TCC is loading code into the DSPs, so the Service 68K is put into a "do-nothing" dead loop during this time. The Service 68K does have work to do during the "load Parameters" time. See the file Wakeup_L15CT_Outline.txt for a description of the overall system flow during "Waking up". When the Service 68K begins operation, it should expect all 12 DSPs to be at State D0, with the Local and Global Wake Up Words set to $FFFFFFFF.