-------------------------------------------------------------------------------- TRICS II Version 10.0 Release Notes ------------------------- 11-Apr-2002: (Rev H) General Switch from very old versions of libraries to current versions ITC v00-00-07 -> v02-14-00 Thread_Util v00-02-00 -> v00-10-01 Ace V5.0 -> V5.1.17 Change method of implementing Force L2 Reject (cf. below) Reset the L2 Answer TRM during SCL Init (cf. Below) Implement new Register Dump feature (cf. below) Implement the "L2 Unbiased Sample" control programming (cf. below) Initialize the new Tick and Turn Fpgas with control of which scalers get reset by the hardware SCL Initialize. The Download file will need to be updated to load new TTS FPGA in all sites, but this upgrade should be backwards compatible with the old TTS FPGA. New messages to siwtch Mode for Ignore/Obey L2 Global Answer (cf. below) New message to sepcify the L2 Data Path (cf. below) Add support for Sin(Phi) and Cos(Phi) function in slope of Momemtum Lookup PROMs (cf. below) Stir the soup, hopefully for increased long term ease of maintenance: Cleanup some COOR message names and command file names that have drifted enough from the original intention to become a possible source of confusion. (cf. COOR messages and Master Command File Menu below) COOR Messages: Rename the following messages to match reality "L1FW_Configure" -> "Configure_FPGAs" "L1FW_Initialize" -> "Full_Initialize" as both messages act on L1FW, L2FW, and L1CT Note that this is transparent to COOR which never sends the Configure message, and uses the COOR-imposed keyword "init" which was (as far as TRICS is concerned) made into a synonym to "L1FW_Initialize" and is now a synonym to "Full_Initialize". Rename the underlying Master Command file to match. Configure_L1FW.mcf -> Configure_FPGAs.mcf This file is executed when a "Configure_FPGAs" message is received. The Master Command Files associated with "Full_Initialize" haven't changed (Init_Pre_Auxi.mcf and Init_Post_Auxi_L1FW/L1CT.mcf). Also rename the Master Command File associated with SCL_Initialize Init_SCL.mcf -> SCL_Initialize.mcf since it arlready calls a file called SCL_Initialize.rio, and "Initialize SCL" gives the wrong idea as it only sends the "SCL_Init" flag but does not initialize the SCL Hub End (Full_Initialize does that). Update the TRICS menu to provide the correct message templates. Add some header comments to all these files. Master Command File Menu: Rename Buttons: "Configure L1&L2 Frameworks" -> "Configure All FPGAs" "Initialize L1&L2 Frameworks" -> "Initialize L1FW, L2FW, L1CT" Rename config_l1fw.mcf -> config_FPGAs.mcf in \trics\d0_config\ Rename the underlying Master Command files to match. Configure_Frameworks.mcf -> Request_Configure_FPGAs.mcf Init_Frameworks.mcf -> Request_Full_Initialize.mcf Init_SCL_with_Pause_Resume.mcf -> Request_SCL_Initialize.mcf These are the files that get executed to request the message to be sent. The name is changed to make the "request" part more explicit, and to match the command being requested. The former name was also too similar to the commands that get executed during command processing. Add some header comments to all these files Console and Logfile messages: Upgrade the Console Screen output and LogFile output utilities for two real purposes and for generic cleanup: - increase the maximum line length handled Some COOR messages were beeing truncated on the screen and logfile Strings still too long to be handled will get a '?' for the last character - replace the former continuation tag in the logfile ("_$" for the second part of a split line) with enough smarts to copy the original tag (M$, I$, E$, etc) but in lowercase (m$, i$, e$, etc). These two changes will help when using Textpad macros, e.g. to pick out the COOR messages out of a 40 MB logfile. Shorten the text of most messages reporting the actions interpreted and executed from COOR commands: - drop the words "COOR Set" - and abreviate e.g. Exposure Group -> Expo Group L2 Reject: Change the programming of the L2 Reject AONMs. They used to form an AND between the L1 Specific Trigger Fired and the Inverse of the L2 Answer. They now just copy (pipe trhough) the L1 Accept Specific Trigger Fired Mask. Change method of implementation of Force_L2Reject to make it compatible with running with L2 Global Answers. We no longer change (by clearing a bit) the simulated Pattern A in the L2 Answer receiving TRM, but we now use the L2 Accept AONM card to block (Mute) all positive L2 Accept decisions. Note that for all unused Specific Triggers both the L2 Accept and L2 Reject AONMs are programmed to force their output low (Mute). SCL Init: Reset the L2 Answer TRMs FIFOs during SCL Init. cf. www.pa.msu.edu/hep/d0/ftp/tcc/trics_ii/scl_initialization_steps.txt This is done using the Force Scaler Reset Register. All other L2 TRM cards were already reset, but the L2 Answer TRMs were not. Monitoring Data: Fill the Monitoring Information regarding the programming of Geographic Sections (And-Or Terms and GeoSect) and Sped Trig (And-Or Term and L1 Qualifier), as well as L2 Data Path. The space was already reserved. Fill the Monitoring Information flag to report the L2 Global Obey/Ignore Mode. The space was already reserved, the flag was constantly on. Take into account the Transposed order of the TRM Fpgas to fill in the Global Disable Scalers in the Monitoring Information. The symptom was that we were displaying the Decorrelated Disable a second time in place of the Correlated Disable. Fix the typo that was returning the L2 BAD Busy Delay a second time in place of the count of L2 Busys Cycles. COOR Command Parsing: Include an update necessary for L2 Relay Software message parsing: the pound character '#' is the comment flag, and the rest of the command is ignored. New Register Dump Sub-Sub-Dialog: The Register Dump Dialog is accessed via the "Dump..." button at the bottom of the the "Register IO" menu. This feature dumps TRICS' knowledge about one particular -- or a set of -- registers. The user can choose to dump TRICS' register information about - one Register - one FPGA - one Card - the L1FW - the L2FW The following information is presented: - The mother card descriptive name as known to Trics - The card, and/or Fpga Base address - Each Register's Read and Write Bit Mask identifying existing bits - Each Register's last Read and Write IO operation - Each Register's current content e.g. Reg# 2 @0x10020004 IOMask:R=0x1fff/W=0x037f Prev:R=0x007c/W=0x007c Now: 124 The register coordinates are entered via the dialog box, like for the "Register IO" menu. The register dump information is displayed on the dialog box and to the console screen. The dump information can INSTEAD be sent to a Result File (especially useful when dumping a whole card or the whole FW). The result file is automatically named, created and opened following the template: \trics\d0_log\REG_DUMP_Vvv_w_r_yyyymmdd.dmp;n The user may choose to skip read-only registers. L2 Unbiased Sample control programming: The syntax is "L1FW_Spec_Trig [S-S] L2_Unbiased_Sample [R]" cf. http://www.pa.msu.edu/hep/d0/ftp/tcc/coor/coor_to_tcc_l1fw_message_syntax.txt A template is available in the "Send COOR Message" menu. To program a new Unbiased sample N Trics takes the following steps - pick a random number P between 1 and N. - write to the 32 bit Mark and Force Pass Control Reg (reg 72:73) the value P-1 along with the Asynchronous Reset control bit. - clear the Asynchronous Reset bit (leaving the value P-1) - write the value N-1 (without the Asynchronous Reset bit) The default programming for un-allocated SpTrg is to write the maximum value (0x00ffffff) and the Asynchronous reset bit. How this circuitry works is not 100% clear, but this method hopefully keeps the count-down scaler at a non-zero value. Ignore/Obey the L2 Global Answer: The syntax is "L2_Global_Obeyed" "L2_Global_Ignored" A template is available in the "Send COOR Message" menu. The default after initialization is to be in the L2_Global_Ignored mode. TRICS takes the following three steps to switch to the L2_Global_Obeyed (respectively L2_Global_Ignored) mode - clear the Bypass mode bit of the L2 Helper State Engine Control Reg (respectively set the bit) - switch the L2 Answer TRMs to Normal FIFO Mode (respectively to Simu Mode) - execute the master command file \trics\d0_config\L2_Global_Obeyed.mcf (respectively \trics\d0_config\L2_Global_Ignored.mcf) L2 Data Path: The Syntax is "L2_Path_Geo_Sect_List [GG]" A template is available in the "Send COOR Message" menu. When receiving this message Trics takes the following steps for all geographic sections and exposure groups, as this may be a message giving us Less (or no) Geo Sect in the L2 Data Path. - rebuild the derived list of all allocated geogrpahic sections - reprogram the lookup of GeoSect Front-End Busy to Expo Group Front-End Busy. Now we include all the GeoSect explicitely in the Exposure Group *AND* all the GeoSects in the L2 Data Path. That's 2 copies times 8 FOM channels. - reprogram all L1 Ouput FOMs and the L2 Reject FOMs so that Geographic Sections in the L2 Data Path receive a L1 Accept or L2 Reject for All allocated Specific Triggers. Geographic Sections NOT in the L2 Data Path receive the normal programming. - The FOM++ (L1 Qualifiers and all other special channels) and the L2 Accept FOMs are left unchanged. That is only the GeoSect explicitely listed in each SpTrg Exposure Group can participate in their output. - update the L2BAD card to include these GeoSects. The (subsequent) programming of Exposure Groups and Specific Triggers also needs to follow the same receipe. Single Chance Test: Update to follow the new usage of L2 Accept/Reject AONM cards where the L2 Reject AONM card switches from Mute Ouput to Pass thru the L1 Fired and the L2 Accept switches from Mute Ouput to forming the L2 Accept Decision. Trigger Tower Info Files (.TTI) Add support for Sin(Phi) and Cos(Phi) function in slope of Momemtum Lookup PROMs. Method: add an alternate way to specify the Transfer_Slope coefficient by specifying a math function instead of explicit values of each Tower coefficient. Add new Keyword "Transfer_Math:" which can only take a value 0 or 1 0= |Sin(Phi)| 1= |Cos(Phi)| with Phi derived from the TT_Phi Index [1..32] as Phi = (2xPi) x (TT_Phi - 0.5) / 32 The "Transfer_Slope:" and "Transfer_Math:" are mutually exclusive, meaning that they override each other. Specifying a "Transfer_Math:" value will override any previously defined "Transfer_Slope:" value, and vice versa. cf. syntax_rules_trgtwr_info.tti in http://www.pa.msu.edu/hep/d0/ftp/tcc/trics_ii/ Add a warning message when a page is being re-defined. TrgTwr PROM Lookup Dialog: Add/Implement a button to generate one binary PROM file. The file name follows the template: \trics\d0_log\xxseeppva_yyyymmdd_Vvv_v_r.BIN;n with PROM identification information ------------------------------- xx = "EM", "HD", "PX" or "PY" s = "N" for negative eta = "P" for positive eta ee = "01" to "20" is the Trigger Tower Eta Index (note that some of eta 17-20 may receive signals that do not correspond to their "natural" eta value). pp = "01" to "32" is the Trigger Tower Phi Index a = PROM Version Number The first set of prom will be Rev "A" .BIN = File extension for raw binary file File Creation Date ------------------ yyyy = year [2002,2003,...] mm = month [01..12] dd = day [01..31] ;n = file version number default is ";1", but can be a higher number if several files would have the same name Trics Version Identification ---------------------------- vv_v = Trics Major & Minor version number [10.0,10.1,..,11.0,...] r = Trics Revision Number [A..Z] A copy of the final/official/archived set of file will be made with all names truncated (externally, by hand) down to "XXSEEPPV.BIN" for usage in the PROM programmer using legacy DOS 8+3 file name format. e.g. PXN0101A_20020401_V10_0_E.BIN;1 -> PXN0101A.BIN Add/Implement a button to generate All PROM files. This includes generating a checksum file \trics\d0_log\PROM_CheckSum_yyyymmdd_Vvv_v_r.BIN;n This includes checking that all pages of all generated PROM files have been prefiously defined. Internal: New function to ADD requirements to an AONM or FOM pre-programming. This is how we can program the regular Exposure Group Front-End Busy requirements and then ADD the L2_Data_Path requirements. Add a function to pre-programm one AONM/FOM output Low. This is how we can program the L2 Accept AONM to force_reject Update RegBase, FpgaBase, and CardBase. Many small fixes and upgrades to make the chain of registers, fpgas, and cards fully operational for the new register dump feature. Especially in the manner some non-existing registers are deleted, or some default FPGAs types are replaced with other species (Miguel, Shed, L1AL2,..) Modify AONM/FOM common low level programming code to support new functionality needed for L2_Data_Path and Force_L2Reject. Move the f_okDoForceFifoCounterReset function out of the common FpgaTRM and CardTRM code into the L2fwCardTRM code, as this method is specific to the L2 TRM. For the L1 TRM one forces the counter to trip and reset itself, while the L2 TRM needs an explicit reset via the computer controled scaler reset register. Upgrade HandleResultFile.cpp to handle binary files. This requires an additional parameter flag to open the file ('b') otherwise the default is the text ('t' aka "translated") mode which adds some unwanted line control characters. Also added a method WriteBinary to write an array of characters of given length to the already open file. The rest of the methods works unchanged to write binary files. -------------------------------------------------------------------------------- TRICS II Version 9.5 Release Notes ------------------------- 7-Dec-2001: (Rev B) Exposure Group Per Bunch Scaler Un-comment the definition of the expo group #3 upper PBS (slot 14). This scaler card was found sick when first installed in June 2000. Trics had been left skipping this card ever since. SCL Hub End: Remove the kludge that was skipping Trigger Status Concentrator #2, 9, 11. These modules were previously skipped because their registers were not answering VME bus cycles. The bad modules have been replaced, and the missing module was installed. L2 Hardware Scalers: Added 6 SM modules to implement the L2 Hardware Scalers. The L2 Hardware Scaler SM Card #0 (1,..5) is in slot 8 (9,..12) of M123-Bottom. These scalers are served by TCC's Monitoring server as a one-dimensional array of 6*64 scalers with the relative scaler #0 of the Fpga at site #1 (i.e. the first Main Signal Array Fpga) of the SM card #0 (i.e. slot #8). The fpga relative scaler number increments the fastest, and the card number increments the slowest. Note that this one-dimensional array definition [overal_scaler_num] in C is equivalent to a 3-dimenstional array [card_num][fpga_num][scaler_num]. cf. l1_tcc_monit_data_l2hardscalers.hpp in http://www.pa.msu.edu/hep/d0/ftp/tcc/monitoring/ Initialize: Initialize to zero the tick-and-turn scaler tick-select registers. Note that only the tick-select feature of FPGA #16 (the one keeping track of the Bean X processed by the L1FW) are connected to andor Terms. Note that two of these tick-select registers are programmed to a useful value by the init_auxi RIO file. Each L2 Hardware Scaler GS FPGA is initialized so that its relative scaler #n (n=0..3) listens only to the FPGA's private gate #n. Private gate #4 and #5 are thus left unused on each FPGA. To the L2 Helper Fpga class add the Global L2FW Scalers and reset all these scalers during initialize. Add the Mark and Force Pass Scaler to the TDM Fpga and force it in reset (and leave it that way) during Initialize. Nothing else talks to these scalers, still not used, but which will eventually drive one of the L1 Qualifiers. Time Zone Spread: Add a global variable to the L1FW class to remember the current Time Zone Spread. This CL1fw::mg_ubTimeZoneSpread variable is initialized with the constant KiTimeZoneSpreadTotTick (currently 35). This Time Zone Spread is used to initialize the exposure group PBS, specifically to line up each tick select, so that the accelerator bunches appear in their conventional places. This mechanism replaces the hardcoded initialization constants KiPbsExpGroupBaseTickSelectLower/Upper (which was off). CL1fw::mg_ubTimeZoneSpread can be changed with a new COOR-like command "TrgMgr_Time_Zone_Spread ". This command need only be executed once (not once per initialize). Moreover sending the command during initialize would get it executed only after the end of the initialize sequence and thus too late to influence the initialization of the PBS scalers for this initialize. Next Revision: add step BOOT_AUXI.MCF The next revision of Trics should add the new concept of a BOOT_AUXI file to be executed only once when TRICS starts up. Things to go in such a file: - The definition of this Time Zone Spread to setup Expo Group PBS - The tick alignement setup of the Foreign PBS (after adapting the meaning of the existing message from "do it now" to "remember how to do it during initialize") - Global L1CT included/excluded switch. - Coverage of L1CT currently instrumented. - Load a file of Trigger Tower Gain Control values - Load a file of Trigger Tower Pedestal Control values - Load a file of Trigger Tower PROM lookup coefficients Luminosity Server Luminosity server quits serving the per bunch scaler block that was used for an initial test (pull only) but is not used any more. Monitoring Server Upgrade: cf. new doc file 000_l1tcc_monitoring_server.txt in http://www.pa.msu.edu/hep/d0/ftp/tcc/monitoring/ The old file Tcc_Monit_Data.hpp that was describing all the simple Monitoring and Luminosity data was getting out of control. This old file has been replaced with a hierchical structure of many smaller files. All these definition files are available in http://www.pa.msu.edu/hep/d0/ftp/tcc/monitoring/ An official CVS D0 product will be created, called "trigmon", to hold all these header files which are referenced by the DAQ_monitor, and the Luminosity Server. We will eventually add the trigmon application, if people are interested. cf. http://www-d0.fnal.gov/cgi-bin/cvsweb.cgi/trigmon/ The top files which define monitoring block structures are: - The DAQ Monitor program only needs to include the top file L1_Tcc_Monitoring_Data.hpp. To pick up the definition of the block type currently used by the DAQ_MONITOR program, the calling code needs to define the pre-processor constant "TCC_SUPPORT_PHASE3_MONIT_DATA". No new application should use this legacy data, which has been replaced with new blocks with more information. These "obsolete" block types will eventually be abandonned. - The Luminosity Server program only needs to include the top file L1_Tcc_Luminosity_Data.hpp. There has been no change in data definition, just a change in organization of the header files. - Trics and our specialized monitoring programs would additionally include the following definitions, as needed. These are not considered to be of interested outside our group. - L1_Tcc_Monit_Data_CalTrig.hpp this one will eventually be included in L1_Tcc_Monitoring_Data.hpp when it is ready for prime time, (This is not new, while some information has been added to it and programs using this block need to be re-compiled) - L1_Tcc_Monit_Data_Hsro.hpp this is a snapshot of readout data catpured in the monitoring register and rebuilt into a structure identical to what we send to the VRB and read out of the VBD, (This is not new) - L1_Tcc_Monit_Data_Card_Info.hpp this is a block of information about each of our cards, e.g. FPGA revision, VME Interface Status, etc. (This is new) This file defines the request expected by TCC on its Monitoring Server Port. - L1_Tcc_Monit_Data_Request.hpp Definition of the structure to send to TCC's monitoring server to request a monitoring block of a particular type. There are a number of intermediate level definition files: - L1_Tcc_Monit_Data_Frameworks.hpp Definition of the structures holding information about the L1&L2 Frameworks. (There is a "Brief" and a "Full" version of this structure) - L1_Tcc_Monit_Data_CalTrig.hpp (already listed as a top file above, but eventually becoming and intermediate level file) - L1_Tcc_Monit_Data_L2HardScalers.hpp Definition of the structure holding information about the "L2 Hardware Scalers". - L1_Tcc_Monit_Data_Obsolete.hpp Collection of all the legacy (i.e. "obsolete") blocks that will eventually be dropped - Tcc_Block_L1fw_General - Tcc_Block_Per_Bunch_Scaler These files are the lower level building blocks: - L1_Tcc_Monit_Data_Header.hpp Definition of the Header which always comes first and includes a code that the client can use to recognize the block type on the fly (There is a single "new" and an "obsolete" version of this structure) - L1_Tcc_Monit_Data_BeamX.hpp Definition of the sturucture holding the various Beam Crossing and Tick and Turn Scalers qualifying L1 FW data and L2FW data. (There is a "new" expanded version of this structure while the old short version is still used) - L1_Tcc_Monit_Data_PerBunch.hpp Definition of the structure for one per bunch scaler. (There is only a single unchanged version of this structure) - L1_Tcc_Monit_Data_LumBlockNum.hpp Definition of the structure for information related to the Luminosity Block Number. (There is only a single "new" version of this structure) - L1_Tcc_Monit_Data_FwGlobal.hpp Definition of the structure holding L1&L2 Framework-wide global information. (There is a "Brief" and a "Full" and an "obsolete" version of this structure) - L1_Tcc_Monit_Data_AoTerm.hpp Definition of the structure for one Andor Term. (There is a single "new" and an "obsolete" version of this structure) - L1_Tcc_Monit_Data_SpTrg.hpp Definition of the structure for one Specific Trigger. (There is a "Brief" and a "Full" and an "obsolete" version of this structure) - L1_Tcc_Monit_Data_ExpGrp.hpp Definition of the structure for one Exposure Group. (There is a "Brief" and a "Full" and an "obsolete" version of this structure) - L1_Tcc_Monit_Data_GeoSect.hpp Definition of the structure for one Geographic Section. (There is a single "new" and an "obsolete" version of this structure) This defines the 8, 16, 32, 64 bit data types for different platforms - L1_Tcc_Monit_Data_BasicTypes.hpp Definition of the basic data types used in the above structures. Monitoring Information newly defined but not yet filled: Keeping track of an upper longword to serve up 64 bits scaler is not done yet. The monit data block that collects all the card info is not being filled at all (only the header type information). In the new Global Framework-wide information (Brief and Full) the following items are not yet filled: - Tot number of Specific Trigggers currently allocated - Tot number of Exposure Groups currently allocated - Tot number of GEographic Sections currently allocated - The list of Geographic Sections needed for L2 Data Path (Full block only) (this concept has not yet been implemented in Trics) - The time since last COOR Initialize - The time since last FPGA Configure In the Specific Trigger Section (Brief and Full) the following items are not yet filled: - The additional mask of programming info (including the sptrg "force_reject" flag) - The Andor Requirement of the Spec Trig (Full block only) In the Exposure Group Section (Brief and Full) the following items are not yet filled: - The Andor Requirement of the expo group (Full block only) - The set of Geo Section digitized by the Expo group (Full block only) - The Expo Group Andor Fired Scaler (we do not have such a scaler yet) In the Andor Term Section (Brief and Full) the following items are not yet filled: - The Andor Synchronization error count (Trics does not yet look for and count these errors) In the Geographic Sector Section (Brief and Full) the following items are not yet filled: - The latest status mask (from the Hub End status concentrator cards) - L1 and L2 Error Counts (Trics does not yet count these errors) Internal: Add the Scalers to the L2 Helper Fpga and reset them during initialize. Add the Mark and Force Pass Scaler to the TDM Fpga and force it in reset during Initialize Single Chance Test now uses the Time Zone Spread as an initial value for the test. This value can still be overridden via the corresponding edit box. Made the Fifo Depth analysis a generic property by creating a new register class called RegFifoStatus. This class has member functions to collect a histogram of a specified sample size, locate the maximum value, and build an ascii representation. the "Input TRM FIFO Depth" submenu with its Dlg_Test_Trm_Fifo_Depth class now uses this method to probe the andor term fifo depth. modify the TRM, and Tick and Turn FPGA classes to use the new RegFifoStatus register classes for their m_poFifoStatusMonitor register. In the class FpgaGS, add a member function f_okAddIndividualGate to add a given private gate to a given scaler. Rename the constant KiTotForeignExpGrp (weird name) to KiL1fwTotExpoGroup add the file names behind the buttons in the "Master Command Files" sub-dialog to ListOfMasterCommandFiles.h and further annotate this file. Add a number of constants to MonitControl.h indepently set the number of samples per fifo depth histogram for each of our TRMs and TTS. #define KiMonit_AOIT_FifoDepth_SampSiz 5 // to monitor the Andor Input Term Fifo Depth #define KiMonit_TTS_FifoDepth_SampSiz 5 // to monitor the TTN Scaler Fifo Depth #define KiMonit_L1Fired_FifoDepth_SampSiz 5 // to monitor the L2FW L1 Fired Fifo Depth #define KiMonit_AuxL1Data_FifoDepth_SampSiz 5 // to monitor the L2FW L1 Auxiliary Data Fifo Depth #define KiMonit_L2Answer_FifoDepth_SampSiz 5 // to monitor the L2FW L2 Decision Fifo Depth To implement the new monitoring blocks (whose contents overlap between Brief and Full version and with legacy block types) without reading the same data many time, the organization of the collection of all this information has been adapted. We do the substructure common to more than one block first, e.g. the beam Crossing and Tick and Turn structure, then we copy this data to the other blocks. We also fill similar blocks together, e.g. the Spec Trig Struct Brief and Full as well as the legacy phase 3 structure. Separate Programs: All Toy Monitoring programs have been updated to use the new definition of the monitoring structures. Most of it is cosmetic, as the same old information is being received and displayed, with one exception: The only actual change is in the Cal Trig Monitoring data which has more information being served, while the toy cal trig monitoring only displays the same old Trigger Tower information. A new version of this toy monitoring program has been installed a t DZero. The set of Toy Trigmon programs are not going to be developped much further, as we are now switching to a new Run II Trigmon engine that will be much more convenient to maintain and make grow. Trigmon_II V0.3 is already functional: This is the NEW trigmon engine but displaying the OLD monitoring data block type, i.e. the same stuff toy_trigmon and daq_monitor are displaying now. The data in the top/header part of the display is pretty much all fake except for the "triggered" flag, the COOR pause percentage, and the tick and turn number. There is a new shortcut "_TrigMon_II_" on the TCC's screen. Type "F", "G", or "A" to switch between the different display pages, to ask for a new sample. This is already an improvement over toy trigmon, but we will get the real benefit from the upgraded monitoring services when we switch trigmon_II to request and display the new monitoring block types. -------------------------------------------------------------------------------- TRICS II Version 9.4 Release Notes ------------------------- V9.4 was never run at DZero ------------------------- 07-Oct-2001: (Rev A) Exclude Trigger Tower: Implement the COOR Message to Exclude Trigger Tower COOR Message cf. //www.pa.msu.edu/hep/d0/ftp/tcc/coor/coor_to_tcc_l1ct_message_syntax.txt e.g. L1CT_Exclude EM_Tower TT_Eta(20) TT_Phi(23) L1CT_Exclude HD_Tower TT_Eta(20) TT_Phi(1:32) Summary of actions to exclude one trigger tower at the CTFE level: - save a copy of the mask of which of the 8 EM/HD TT are currently updated with the ADC clock (FA 81) - select just the targeted TT for updating (FA 81) - Write 8 to the Test Data Register (FA 82) - Set the Board Control Register to Simulation Mode (128 at FA 80): since the ADC clock is running at 132 or 396 ns, the value 8 gets immediately loaded in this trigger tower's ADC/Simu mux/latch. - restore the mask of Trigger Towers being updated to its original setting but with the bit controlling the targeted tower now cleared (FA 81) - restore the Board Control Register to its original value (FA 80) Pedestal Control DAC and Gain Control DAC: The Trigger Tower Info (.TTI) file syntax has also been extended to ingest information describing the Trigger Energy Tower Gain Control Programming. cf. www.pa.msu.edu/hep/d0/ftp/tcc/trics_ii/syntax_rules_trgtwr_info.tti The keyword "Dac_Value:" has been changed to a more explicit name "Pedestal_Control_DAC:". "Dac_Value:" has been kept as an alias for backwards compatibility, but new files created by "Find_DAC" will use the new keyword. There is a new keyword "Gain_Control_DAC:" to register new Gain Control DAC values for the new Terminator-Attenuator mezzanine cards. Note that the "CTFE DAC Programming" sub-menu can be used to debug individual new-style terminator-attenuator boards, but that Trics currently still expects all L1CT cards to have the old-style front-end electronics. Note that the "Pedestal_Control_DAC" keyword will still cause immediate programming of the old-style DAC resources. Recollect that the current usage is to let "Initialize" load default value in the pedestal DAC registers and that we use L1CT_post_auxi_init to execute a TTI file (generated by FIND_DAC) to overwrite these values. Note that the new "Gain_Control_DAC:" keyword will have no effect for now. Note that the intended future usage of these TTI keywords will be to only register these values with Trics and that the "Initialize" procedure will load both the Pedestal Control Values and the Gain Control Values into the serial DACs. We will use a pre_init_auxi file to execute a TTI file during every "Initialize" or some new kind of "boot_auxi" file to execute only once. The sub-menu "CTFE DAC Programming" now has a button to convert a CTFE card address to a Trigger Tower Coordinate and verify that the proposed CTFE address is valid. Note that when we switch to officially using the terminator-attenuator boards in L1CT, the situation will be reversed, and the user will enter the trigger tower coordinates and will be able to translate to CTFE coordinates. Trics will also then have a button(s) to retrieve the registered Pedestal and Gain Control DAC values from what was specified via the TTI file(s). PROM Programming definition and simulation: The Trigger Tower Info (.TTI) file syntax has been extended to ingest information describing the Trigger Energy Tower Lookup PROM programming. cf. www.pa.msu.edu/hep/d0/ftp/tcc/trics_ii/syntax_rules_trgtwr_info.tti Note that this same syntax is used for both PROM programming and Trigger Tower DAC pedestal control (cf. below). This information can be used to describe the transfer function of all 8 lookup pages of each EM, HD, PX and Py lookup PROM of each of the 1280 Trigger Towers. This description can then be used to (1) simulate the PROMs (e.g. in a future L1CT single chance test), (2) verify the content of individual Lookup PROMs (3) generate files in an apropriate format to use in a prom programmer. These 3 functions are not yet available. Ingesting PROM description files is implemented, and PROM lookup can already be simulated (while there are still some questions about the meaning of Low Energy Cut). Trics uses sanity-check constants to limit the allowed values of Prom coefficients in TTI files. These values may need to be adjusted when we understand what we really want. This is to protect ourselves against operator errors. KfMaxPromSlope 1.0 //max Lookup PROM Slope (typ=1 or sin/cos(phi)) KfMaxPromLowEngCut 4.0 //max Lookup Low Energy Cut (typ=0.. 2.0 GeV) KiMaxPromZeroEng 8 //max Lookup Zero Energy Response (typ=0 or 8) There is a new sub-dialog "TrgTwr PROM Lookup" available from the main Trics dialog box. The user can use this submenu to load a new TTI file into Trics, if there isn't one already. The user then selects a particular Trigger Tower coordinates (eta sign, eta magnitude, phi), a particular PROM type (EM, HD, Px, Py) and a particular Prom Page (0..7). The user can view the coefficients currently registered for this prom page with the button "Show Current Coeffs". The user can change these coefficients on screen and ask Trics to overwrite the registered coefficients with the button "Set Coeffs Current". Manually entering coefficients is not (yet?) restricted to the above limits. After selecting a PROM page, the user can use "Simulate PROM Page for this TT" to simulate the PROM response by entering a PROM input value in the "In" edit field. The read-only "Out" edit field is automatically updated. After selecting a PROM Page, the user can use the "Show Ascii Dump" button to print to the console window an ASCII dump of the whole selected PROM page. After selecting a PROM page, the user can use the "Check PROM" button to ask Trics to check in situ the content (all pages) of the PROM for this L1CT Trigger Tower. This is not yet implemented. This checking will be disruptive of normal L1CT operations as Trics will need to set this Trigger Tower in simulation mode in order to send controlled values to the PROM input. Reading the PROM output will need to happen on the following CAT2 card after CTFE summation of the 4 TT on the card. Trics will thus need to put all the towers on that CTFE in simulation mode. After selecting a PROM, the user can use the "Generate Programmer File" button to create a file suitable for the PROM programmer to burn the selected PROM (all pages). This is not yet implemented as there is no final decision on what programmer and what file format will be useful. All Command Files: In order to allow floating point values for TTI command files (e.g. for momentum prom slopes) the command files now accept floating point values. The parser will properly convert fields with decimal points, and/or exponent values. No space must be present between the mantissa and the exponent. The exponent must use the "e" or "E" notation (and not the "d" of the C syntax for the double type) Keywords that expect a floating point value may be entered in many different ways (some of them useful), e.g. Transfer_Slope: 1 !these are all equivalent representations Transfer_Slope: 0x1 Transfer_Slope: 0b1 Transfer_Slope: 1. Transfer_Slope: 1e0 Transfer_Slope: 1E0 Transfer_Slope: 1.e0 Transfer_Slope: 1.0e0 Transfer_Slope: .1e1 Transfer_Slope: 0.1e1 Transfer_Slope: 0.1e+1 Transfer_Slope: 10e-1 Transfer_Slope: 10.e-1 Transfer_Slope: 10.0e-1 Keywords that expect an integer value can also be entered in many different ways (however probably never very useful), e.g. Zero_Energy_Count: 8 !these are all equivalent representations Zero_Energy_Count: 8. !i.e. integers can be entered as floats Zero_Energy_Count: 8.9 !but the floating point value will be truncated Zero_Energy_Count: 0.8e1 Zero_Energy_Count: 80e-1 Sending Mail Messages: The goal is for TCC to send us a mail message when it detects a failure during an Initialization sequence. The method chosen is for TCC to write a "Result File" with the command success status and use an external utility that will notice the file has been created or updated and automatically mail us the file. An application that seems to do what we need is BEEE http://www.iopus.com/beee.htm and I nave been using it for some weeks at MSU with total success. Create a new directory \Trics\D0_Log\ToMail. Any new file appearing or updated in this directory will automatically be mailed out to us. The file is mailed as a text attachment with a subject line saying something like "TCC Status Report" plus the file name. The original goal was expanded a little bit. Trics will be creating/sending a file at EVERY Initialize message from COOR. We can scale it back in the future if necessary. Initialization from COOR has been happening less than once a day and the multiple occurence of Initialization may already show a sign of trouble. The File content will clearly show Success or Failure and where the eventual failure happened (L1FW, L1CT, SCL, or LBN). This file name is \Trics\D0_Log\ToMail\Status_At_Last_Init.log. Trics will also be sending us a file at system configuration time (=FPGA download) where the message will include how many FPGAs were configured and how many Errors there was. This file name is \Trics\D0_Log\ToMail\Status_At_Last_Config.log. Trics will also send us a file when the Monitoring Data Manager thread declares the system Non-Operational after detecting too many successive failures trying to force a Monit Data Capture. This file name is \Trics\D0_Log\ToMail\Status_Non_Operational.log. Splitting LogFiles: The motivation was to control the size of the Logfiles created by Trics without having to stop/restart the application. This will make the logfiles easier to handle and easier to archive. There is a new "Start a New Logfile" Button in the "System Control/Status" sub-menu to make Trics stop writing to its current logfile and start a new logfile. The new logfile will use the current date in its file name, and may thus have a different name than the original logfile (and not just a different VMS-style version number). Trics will remember and write the name of the orginal Logfile at the beginning of the new logfile. Trics will also write the name of the Logfile continuing (preceding) the current Logfile at the end (beginnin) of each Logfile segment. New Environment Variables: Add %LOG% to point to \Trics\D0_Log (\Trics\MSU_Log at MSU) and use this to create the logfile (this was previously hardcoded). Add %MAIL% to point to \Trics\D0_Log\ToMail (\Trics\MSU_Log\ToMail at MSU) Internal: Add a global variable to CommandFileDownloadFpga.cpp to hold the status string of the last download operation. This string specifies the total number of FPGA downloaded and the toal number of errors. It is then retrieved after the "configure" command has called the master command file. This string is writen to the status file that will be mailed out. The Result File Names (and the LBN file name) are specified in a new header file called ListOfResultFiles.h To help in the management of the many source code files: L1FW_MasterCommandFiles.h has been renamed ListOfMasterCommandFiles.h EnvironmentVariables.h has been renamed ListOfEnvironmentVariables.h IP_PortNumbers.h has been renamed ListOfIPPortNumbers.h L1ctCardAddresses.h has been renamed ListOfL1ctCardAddresses.h L1fwCardAddresses.h has been renamed ListOfL1fwCardAddresses.h L2fwCardAddresses.h has been renamed ListOfL2fwCardAddresses.h SclAddresses.h has been renamed ListOfSclAddresses.h In HandleLogFile.cpp use the %LOG% environment variable to create the logfile path intead of hardcoded reference to \Trics\D0_Log. In UtilsFile.cpp split the environment variable translation functionality out of the FileLocate function to a new function SubstituteEnvVar. Upgrade/fix the ResultFile constructor to allow usage of environment variables (it was only working if a file with same name was already existing). Also add a new CResultFile::ReadyForWrite() member function to be able to test the availibilty of the File before calling WriteLine(). Drop the old style prescaler suport (64 bit circular shift with 24 bit after burner). There was a pre-processor switch to pick between old and new style prescaler. Only the code for new style prescaler is left now. This has no impact on what code gets compiled for the prescaler. The L1ct class now has an array of pointers to 1280 Trigger Tower Objects. -------------------------------------------------------------------------------- TRICS II Version 9.3 Release Notes ------------------------- 13-Sep-2001: (Rev A) General Layout: The main entry dialog box now starts out in the upper right corner of the monitor screen (instead of the center). Trics takes ownership of SCL Hub End Crate: New actions during main Initialize: Now initialize all resources of the Hub Controller and the Status Concentrators of the Hub End Crate during the main initialization sequence. cf. Trics_II_Initialization.txt and Hub_End_Initialization_Steps.txt in http://www.pa.msu.edu/hep/d0/ftp/tcc/trics_ii/ Note that Trics currently skips all VME IO to TSC# 2, 8, 11. SCL Initialize: Now display the status of all GeoSect currently allocated by COOR before (e.g. who claimed L1 Error) and after (e.g. who didn't get out of Init Ack) the SCL_Init command is sent. cf. scl_initialization_steps.txt in http://www.pa.msu.edu/hep/d0/ftp/tcc/trics_ii/ Note that Trics currently skips all VME IO to TSC# 2, 8, 11. New "SCL Hub End Crate" Sub Menu: This is a new sub menu to interact with the SCL Hub End Crate. The upper part of the Dialog interacts with the Trigger Hub Controller: The "Read THC Status" button reads the THC status register and displays its content bit by bit using check boxes. The only box and the only bit that the user can interract with is the "7MHz Enable" control. This bit controls whether the THC will listen to the DAQ commands from the L1FW. Clicking on this box will generate a VME write to the proper Set or Reset register of the THC to flip the state of this bit to ON or OFF, and Trics will also re-read and re-display the register content for verification. Clicking on any other check box of the THC display is ignored and has no effect. The middle part of the Dialog interacts with the Trigger Status Concentrators Cards, one channel (i.e. one GeoSect) at a time, with the user entering the desired GeoSect Number in an Edit Box (the default is GS #31, i.e. the L1FW): The "Read Status" button reads the Status Register for the specified Geo Sect Number. The content of the register is displayed bit by bit with its associated meaning. This is a read only register and the user cannot change its content; Clicking on any of the Channel Status check boxes is ignored and has no effect. The "Read Int Mask" button reads the Interrupt Mask Register for the specified Geo Sect AND reads the corresponding TSC Board Level Status Register. The content of the Int Mask register is displayed bit by bit with its associated meaning. The LSB of the content of the board level status register is displayed right underneath the Interrupt mask register, and is labelled for its meaning: Board Level Interrupt Enable. Clicking on any one of the check boxes for the Interrupt Mask Register will make Trics do a VME Write Cycle to invert (turn ON or OFF) the state of the corresponding bit (leaving other bits unchanged) and Trics will also re-read and re-display the register content for verification. The Board Level Interrupt Enable Bit can be changed in the same manner. The "Read Int Req" button reads the Interrupt Register for the specified Geo Sect Number. The content of the register is displayed bit by bit with its associated meaning. Clicking on any one of the check boxes for the Interrupt Request Register that is currently displayed as a Bit ON will make Trics do a VME Write Cycle to Reset the state of the corresponding bit (leaving other bits unchanged) and Trics will also re-read and re-display the register content for verification. Clicking on any one of the check boxes for the Interrupt Request Register that is currently displayed as a Bit OFF is ignored and has no effect (as these bits cannot be turned ON with VME cycles). Note that Trics currently skips all VME IO to TSC# 2, 8, 11. The lower part of the Dialog has two buttons: The "Initialize the SCL Hub End Crate" Button will call the part of the full initialization sequence that initializes the Hub End Crate. This is (currently) a benign and stateless action that provides a simple way to look at the status of all Geographic Sections. cf. Hub_End_Initialization_Steps.txt The "Request SCL Init" button sends a message to Trics to generate an SCL Initialization. Add ability to disable sending DAQ commands over SCL: There is a new button in the Single Chance Test sub-menu, to disable the 7MHz clock, cf below. There is a check box in the new "SCL Hub End Crate" sub-menu to enable/disable the 7MHz clock. Calorimeter Trigger Initialization: The Cal Trig Initialization now needs to be successful for Trics to return an "Ok" acknowledgement to COOR (we were ignoring the cal trig init status until now). Note that we have the ability to "Totally Ignore L1CT" in the "System Control/Status" dialog. This would skip the L1 CT Initialization (and associated errors). Master Command File Menu: Drop all special buttons to setup various specific triggers. Only kept the "Configure L1&&L2 Frameworks", "Initialize L1&&L2 Frameworks", "SCL Initialize" and the 3x "UnNamed #" buttons. The file button_mapping_master_command_files.txt in www.pa.msu.edu/hep/d0/ftp/tcc/trics_ii/ has been updated Connection to COOR: Increase the maximum size of acknowledgement message to COOR from 256 to 500 char. Find and fix a problem where Trics could become comatose waiting for internal resource locks. The symtoms would be that Trics would ingest the messages but not act on them. This bug was triggered when the system is declared non-operational (after a series of unsuccessful attempts at capturing monitoring data) WHILE an SCL_Init message was being processed at that exact time. This causes the same symptoms as what was observed a few times while the system was turned off, but there is no proof that this was the actual cause. Monitoring Data Server: The Monitoring Server now estimates and displays on the console and in the logfile the L1 Accept Rate integrated over the last 5 sec every time it collects a monitoring data sample. It will display "*****" if the measured increment in beam crossing is negative (e.g. rollover) and will display a positive (or negative in case of problem) rate otherwise. Monit Data -> L1 Accept= 0x00012345 L1 Rate= 10.2 Hz Buf Depth= 0 The monitoring server will now read the L1 Accept and L1AL2 scalers and refresh the LED display on the Per bunch scalers at 10 Hz (while it is not busy pulling the monit data out). This is an attempt to see if this LED display can become more useful if it is updated more often than the 5 second refresh which is nearly useless. Single Chance Test Add a property to the TesterL1fw object to hold the Time Zone Spread between the beam crossing number currently sent to the SCL and the beam crossing being processed by the L1FW. This value is used in the CheckTimeZoneShift routine to verify the Tick and Turn Scalers. The Sub-Menu Dialog has a new Edit box to enter this time zone spread the current default value is 35. There is a new button to disable the 7MHz clock of the SCL Hub End Crate Controller and thus stop sending Trigger commands over SCL. Internal Moved machinery to watch for successive errors requesting monitoring data from L1fwCardL1fwHelper to MonitControl. MonitControl calls the proper routines from L1fwCardL1fwHelper and L2fwCardL2fwHelper and also handles the successive failure machinery to be ready to call the system non-operational during power off. MonitControl has a new ResetFailureDetection routine now called explictely during initialization instead of previously doing the same thing implicitely inside L1fwCardL1fwHelper::Initialize. MonitControl is the high-level handling for RequestMonitData, CheckMonitDataCaptured, and ForceCaptureMonitData. L1fwCardL1fwHelper now calls the same capture monit functions from its helper function fpga with no value added. New SerialCommandLink Object to control Hub End Crate: This is a singleton, meaning there is only one instance of this object in the whole Trics program and all its data members and functions are "static". This object maps bit3 resources to the Trigger Hub Controller address space and the Trigger Status Concentrator Cards. It has member functions to read, set, display the status bits and interrupt masks. It also has an "Initialize" member function to initialize the THC and THC's which is called during main initialization. There is a kludge at the moment to skip reading the registers from TSC #2, #8, and #11 (zero based) as they don't DTACK. -------------------------------------------------------------------------------- TRICS II Version 9.2 Release Notes ------------------------- 9-MAR-2001: (Rev L) General: (Now 80k lines of source code in 336 files). Version 9.2 will include control of the L1 Cal Trig for initial triggering while still using the original Run I CTFE hardware. The Run II serial DAC upgrade is supported for tests (starting with V9.1-F), but not for triggering. Current important limitation: Trics currently doesn't initialize or control any of the Control and Timing signals. In particular the 29525 Read A/B and Write A/B or Latch/Shift signals are not touched. We'll need a separate CBus IO command file to control these signals. Use more Colors on TCC console window: The screen messages received from COOR (or the dialog boxes, command files, etc) are now prefixed with a "M$" and displayed in yellow. This highlights TCC's primary function and helps in following COOR download on the console. The screen messages that correspond to important system events (e.g. L1CT ignored) are now flagged with a "S$" and displayed in purple to highlight transition points. (Note: the total count of Fpga downloaded is now displayed in purple) Calorimeter Trigger: There is a new L1ct object that will include all the L1CT Cards and manipulation functions. This includes the CTFE cards. The idea is to create Card Object for the full coverage, but independently specify the current sign eta, magn eta, and phi coverage in the form of min and max values. Implementa CBusCAT2 class to be able to set correction and comparator registers. Add the Tier#1 EM, HD, Px and Py CAT2 cards to the L1CT Object. These cards are now initialzed cf below. The CHTCR Cards are still not implemented. Add the Tier#2 EM Et and Tot Et RefSet CAT2 cards to the L1CT Object. These cards are now initialzed cf below. Other Tier#2 Cards are still not implemented. Fix the code that reads the 29525 registers. This is a specialized object that saves on VME cycles when reading all 8 time slices. There was a typo that was writing the Function Address to the Card Address port of the Ironics card. This should fix the bad TT_ADC info sent in the monitoring information. New Trigger Tower Info Command File: cf. www.pa.msu.edu/hep/d0/ftp/tcc/trics_ii/syntax_rules_trgtwr_info.tti for syntax. This Command File can be called from the Serial DAC menu, but at the moment it only sets up Run I old-style DAC. This Command File lets the user address a given Trigger Tower or a range of Trigger Towers in Eta Magnitude and Phi as well as its EM or HD type. The user can then specify a new DAC value to load into the corresponding CTFE card(s). At the moment the DAC Value is the only available target item, but any other Trigger Tower related quantity can be added. For example PROM slope and low energy cut, and even a list of towers to exclude. The idea is that such a (or several) command files can be called from the Init_Auxi Master Command file, as desired. Master Command Files: Add the ability to call a Trigger Tower Infor File from a Master Command File. The keyword is "Call_TT_Info:" This new keyword will be used from Init_Post_Auxi_L1CT.mcf to call Init_Post_Auxi_L1CT.tti. New Keyword allowed in Master Command Files. "Ignore_L1CT:" to include/exclude L1 Cal Trig: "Ignore_L1CT: 1" ignores L1CT (we can put this line in the PRE-init-auxi). "Ignore_L1CT: 0" includes L1CT (which is still the default). www.pa.msu.edu/hep/d0/ftp/tcc/trics_ii/syntax_rules_master_command_files.mcf has been updated. Self Message Command File: No longer wait for message execution when sending COOR messages from a command file (previously waited up to 2 sec), as the command file itself may have been called from a COOR message (e.g. initialize) which means the additional messages generated by the command file are queueud up and wait until the original message is done. Note that there is still a 0.1 second systematic wait when TRICS sends any ITC message. This is a precaution to prevent runaway disaster in case of coding problem. Change the keyword to send messages to TCC's ITC port #52160 (to impersonate COOR or send special TRGMGR messages) from the former "COOR_L1fw_Msg:" (mis-named because too specific) to now be "Send_Msg_To_Self:". The former keyword is still accepted, as an alias, but new command files should use the new, more sensible, keyword. The keyword to call a "Send Message Command File" (.msg) from a "Master Command File" (.mcf) hasn't changed ("Call_Self_Msg:"). CBus IO Command Files: Fix the CBUS IO command file handling routine so that it (as advertized) only does a write cycle for the "Write_Value" keyword, and only does read back and verify for the "Write_Verify" keyword. CBUS IO: Deselect the Mother Board Address (i.e. select MBA=0) upon exiting all CBUS IO Cycles. This is a precaution to prevent glitches to corrupt register programming. more intelligent second CBUS write attempt when first attempt failed. Instead of just writing the data again, now re-send the MBA/CA/FA first. Add a Resource Lock around every CBUS IO to prevent collisions between two threads (e.g. executing a coor message, and the Monit Pool Server). The danger is if one thread starts setting part of a CBUS address, and another thread steals the CPU's attention and start selecting a different CBUS address, when the first thread gets to execute again, it continues its CBus cycle but is now aimed at a different CBUS address. New TrgMgr messages: Added the following COOR-like messages to include/exclude the L1 Cal Trig. "TrgMgr_Ignore_L1CT" "TrgMgr_Include_L1CT" Such messages are however not quite sufficient for the Init_PRE_Auxi master command file because the message will be SENT but NOT EXECUTED until the end of the Initialize command and thus the rest of the Initialize Command will not know of the change in status. It is better to use the new command "Ignore_L1CT: 1" in the Init_PRE_Auxi.mcf instead. Confirm Yes/No Pop-Up Dialog: Change Icon from a question mark to a Guillotine. System Control/Status Dialog: The background is now Red, with Yellow text, with new "gun logo". Change the message showing the user is entering this dialog to an Error message so that it appears in Red to help log file analysis. Add fields to enter a new Trigger Tower Eta/Phi Coverage in the form of a min/max Eta and Phi. The new coverage doesn't take effect untill the user clicks on the button "Set This Coverage". There is an additional and separate control to have NO L1 CalTrig at all. Selecting this option take effect instantly, without needing to use "Set This Coverage". This means that NO more CBUS IO will take place, No L1CT message from COOR will be accepted, and no L1CT Monitoring data will be collected (return zeroes). These controls allow Trics to track along regarding which part of the system is currently available and will only accept commands corresponding to this coverage. As currently planned and implmented this means that Trics will complain if a COOR message or a DAC command file specifies a Trigger Tower outside of this coverage. Trics now wakes up thinking the L1 Cal Trig is available (i.e. NOT ignored) and that the Trigger Tower Coverage is TT_Eta(-4:+4),TT_Phi(1:32). This dialog uses the new "System" messages for most actions, and now generates mostly purple messages. Add a button "Debug" to force an access violation and thus allow jumping in the debugger even if the program was not started from the debugger. This button is protected by an "Are you Sure?" pop-up box. L1 Calorimeter Trigger COOR Message Menu: This is a new sub-menu to provide template messages for L1CT COOR commands. This menu is not directly accessible from the Main Menu, but instead via a new "L1 Cal Trig Messages" button in the existing "Send COOR Message" Menu which handles only the L1 Framework Messages. COOR Commands: The commands for setting EM Et, HD Veto and Tot Et Reference Sets are now operational. Implement the messages to deallocate EM Et, HD Veto, and Tot Et Ref Sets. This means the reference sets are reset to full scale (in fact use 1000 GeV which translates to a count of 255). Suppress all informational messages displaying the Referense Set Thresholds applied to each Trigger Tower (there would be too many). Trics will answer "Bad" to COOR when a reference set is specified that overflows the existing Trigger Tower Coverage. When the TT_Eta or TT_Phi range is omitted in a message from COOR (e.g. a "L1CT_Ref_Set" message) Trics will now use the currently defined Trigger Tower coverage (instead of the maximum eta/phi range). This means that a message like "L1CT_Ref_Set HD_Veto_Ref_Set 0 Value 10.0" will automatically adapt and define the threshold over the whole Trigger Tower coverage currently defined without trying to access non-existing Trigger Towers. Implement the "L1CT_Count_Threshold" message for both the "EM_Et_Towers" and the "TOT_Et_Towers". However, instead of trying to program the normal CAT3 cards in Tier #3, TCC always programs the Tier#2 CAT2 for eta (-4:+4). This is how we are currently running with our limited eta coverage, and the output of the comparators of this card are sent to the L1FW as AndOr Terms. L1CT is initialized during (and at the end of) the main initialize sequence. Note that there is still a control flag to totally ignore the L1CT, available in the "System Control/Status Dialog". Add a "L1CT_Initialize" message that initializes ONLY the Cal Trig. At the moment, "L1FW_Initialize" is in fact synonym to "init" which is the system level initialization. Add a template for this L1CT_Initialize message in the "L1 Cal Trig Messages" sub-menu (which one accesses from within "Send COOR Message" sub-menu). This message also asks for user confirmation ("Are you sure?"). Rename the "pre-auxi" master command file from "Init_Pre_Auxi_L1FW.mcf" to "Init_Pre_Auxi.mcf" as the functionality will be common to both L1FW and L1CT. Note that there is one separate "post-auxi" command file for each of the the L1FW and L1CT. Add a call to a new file "D0_Config\Init_Post_Auxi_L1CT.mcf" at the end of the initialization of L1CT. Note that when the L1CT is flagged to be "ignored" the L1CT is NOT initiliazed, and this auxi file not executed. The whole DAC management business needs to change with the new serial DAC mezzanines, but this is the current model: After power off, one must first run L1CT_Init, then one (or L1CT_Init_Auxi automatically) executes the DAC programming TTI file, and TRICS should thus be able to find the last value it wrote (0x00) in the DAC registers. At the moment the TTI file actually writes the DAC registers, but I picture we eventually want the TTI file to only make these values known to Trics so that it can then load them later during CTFE initialization. The "Initialize" sequence now is: 0) Display and Clear any previous Bit3 Errors, if present. 1) If (0) failed and Trics cannot clear bit3 errors (e.g. power off), declare "bad" status, and jump to (9) 2) Execute the Init_Pre_Auxi Master Command File (currently empty, but could receive "magical IOs" needed to guarantee proper initialization, or high level messages to direct the rest of the initialization, e.g. L1CT eta coverage) 3) If (2) failed, declare "bad" status, and jump to (9) (it is not expected that we would encounter errors during the simple Init_Pre_Auxi commands). 4) Display and Clear any previous Bit3 Errors, if present. 5) Call L1FW_Initialize 5.0) declaring the L1FW "non-operational". 5.1) Init L1FW Cards (If failed, return, i.e. jump to (6) ) 5.2) Display and Clear any previous Bit3 Errors, if present. 5.3) Init L2FW Cards (If failed, return, i.e. jump to (6) ) 5.4) Display and Clear any previous Bit3 Errors, if present. 5.5) Init L1FW VRB Readout Crate Cards (If failed, return, i.e. jump to (6) ) 5.6) Display and Clear any previous Bit3 Errors, if present. 5.7) Init_Post_Auxi_L1FW Master Command File (Initializing the SCL hub-end happens in Init_Post_Auxi_L1FW) (If failed, return, i.e. jump to (6) ) 5.8) Display and Clear any previous Bit3 Errors, if present. 5.9) If everything ok this far, the L1FW is declared "operational". (otherwise no subsequent COOR message can be executed). 6) If (5) failed, declare "bad" status, and jump to (9) 7) Call L1CT_Initialize (which is something that can be called directly) 7.1) if the Cal Trig is currently flagged "ignored" return, i.e. jump to (8) 7.2) Init L1CT Cards for current eta/phi coverage (CTFE, Tier#1, Tier#2 CAT2 cards at the moment) (If failed, return, i.e. jump to (8) ) 7.3) Display and Clear any previous Bit3 Errors, if present. 7.4) Init_Post_Auxi_L1FW Master Command File (note that the eta/phi coverage in any .tti file must match the current eta/phi coverage) (If failed, return, i.e. jump to (8) ) 7.5) Display and Clear any previous Bit3 Errors, if present. 8) Even if (7) failed, do NOT declare "bad" status 9) Write the LBN_At_Last_Init.lbn File 10) If the L1FW has been declared operational call the Increment_LBN message handler which will push a Lum Monit Data Block out the door The last two steps are not necessarily in the logical order, but it makes no functional difference. I knew it would work this way because the Increment LBN step has been the last step until now. I would need more tests to verify that I can reverse the last two steps and I ran out of time for releasing this Revision. The Increment LBN step is acomplished by implicitely calling the Increment_LBN message. I know there is no surprises when it happens last and all the acknowledgement messages get tacked on the way they are supposed to. The down side is that the LBN number written down is the one before the initialize, instead of the first LBN number after the initialize, but the LBN recovery functionality is not being affected. cf. http://www.pa.msu.edu/hep/d0/ftp/tcc/trics_ii/trics_ii_initialization.txt COOR-like command: L1 TCC implements a new message "L1FW_ReSynch_L2TS". Trics will - pause data taking (if needed) - call the master command file \d0_config\L1FW_ReSynch_L2TS.mcf - resume data taking (if needed) This is to help the L2 Test Stand flush its buffers and get ready for a clean event. This master command file currently only waits for one second. The L2RS application that will run on the L2 Test Stand PC will know how to send this message. SCL Initialize: When the system is non-operational and we receive an SCL Init request, TRICS now skips the clean up to the FOM++ and L2 TRM to reset scalers, reset FIFO etc. So now, like for other commands, TCC does not try to use the framework when it is non-operational, and will thus paint less red messages. Note that Trics still executes the Init_SCL.mcf command file (which calls SCL_Initialize.rio that actually causes the SCL_Init via 2x register IOs on the SCL Helper) as a "minimum service". Add an explicit reset of the L2 Helper State Engine during the SCL Init process. The L2 Helper State Engine is forced to (and held in) Reset immediately after pausing the L1 FW. The L2 Helper State Engine is released from Reset after the cleanup of the L2 FW input FIFOes and right before resuming the L1FW. Note: The L2 Global Answer TRM FIFO will also need to be drained when L2 decisions are added to the trigger system. This will be added in the next revision of TRICS. http://www.pa.msu.edu/hep/d0/ftp/tcc/trics_ii/scl_initialization_steps.txt contains a detailed description of the current SCL Initialize steps. Monitoring and Luminosity Services: Added a new Block type to hold an array of DAC values for all 8x time slices of all EM & HD Trigger Towers. Additional information passes the current Eta/Phi coverage. Send the Tick and Turn Scaler from Fpga 14 instead of Fpga 15. This is a change that will affect all Monitoring services, but this is thought to be of benefit to all. The only down side is that the Tick and Turn Number will no longer correspond to "The" TTN that was used over SCL for that event... but there is no connection between Monitoring data and full readout. This Tick and Turn Scaler from FPGA #14 is not reset at SCL_Init time, but is still reset by TCC at Initialization time. The motivation is to avoid sending a time base that gets frequently reset and especially to the Luminosity server which is trying to derive trigger rates and live times. When no data is flowing, TRICS, after waiting 2 seconds and not finding that a data block has been capture, pokes at the L1 Helper Function to cause an immediate capture monit data signal. Poking at the L2 Helper to cause an immediate monit data capture was missing and has now been added. When events are flowing, the L2 Helper listens to one of the L1 Qualifiers coming out of the FIFO through the auxiliary data TRM and will capture monitoring information for the SAME event captured by the L1 Helper. When no events are flowing, the L1 qualifier is never set, and the L2 Helper needs to be explicitely told to capture the monitoring data. Note: the number of beam crossings elapsed between the successive L2 FW data samples will NOT match the number of beam crossings elapsed between the successive L1 FW data samples, but that is nothing new anyway, since the L2 FW data is captured after the corresponding L2 Cycle. There is a separate Beam crossing counter available on the L2 Helper to count the crossings specifically in the L2FW monit data sample context. **BUT** this level of detail is not yet part of monitoring, and L2 scalers are displayed using L1FW beam crossing information. This will introduce some fuzziness probably visible only when trying to show 100.00%. Formatted HSRO Event Dump: Find and fix bug that crashed trics when it tried to display a card name for a VRB channel where no THE-Card was expected. HSRO Test Dialog: Add a selection in the "Readout Crate Test Tool Box" to chose between L1FW readout crate and L1CT crate. This will only affect the Tool Box, and not the Readout Test itself. Trics will not initialize or write to the L1CT Readout crate, except from these toolbox buttons. Note that the "Init VRBs" and "Init VBD" buttons are not available when the L1CT readout crate is selected. This is because Trics does not know how many VRBs are in the L1CT Crate. Trics however expects that this crate has a VBD and VRBC. The "Dump N Longwords from VBD" button is available for both L1FW and L1CT with similar straightforward results for both cases. The "Analyze current event in VBD" button is available for both L1FW and L1CT with slightly different results. The L1FW formatted hasn't changed. The L1CT formatted dump is a modified/simplified dump where the THE-Card data is only merged from the two VRB channel pairs, without further formatting of the typical THE-Card data header and trailer. It will dump up to 100 longwords per L1CT THE-Card, and however many Channel pairs are connected to each VRB, for all VRBs found until it runs out of VRB records in the VBD data. New Find_DAC sub-sub-Dialog: This sub-sub-dialog is accessible from a button "Find_DAC" in the sub-dialog "CTFE DAC Programming". The user can select one or more Trigger Towers (EM/HD, Eta Sign, Eta Magn, and Phi) and let TCC hunt for the DAC Value that will generate the desired Zero Energy Response. The nominal target Z.E.R. is 8 counts, but the user can pick a different value. This version of Find_DAC is only compatible with the Run_I CTFE hardware and does not support the new Run II Serial DAC/ADC front-end upgrade. The user may select to generate a "Result File". This file will be created in the Trics\D0_Log directory and named "Find_DAC_Va_b_x_yyyymmdd.tti;n" where "Va_b_x" is the Trics version number, "yyyymmdd" is the current date and ";n" is a version number so that Find_DAC files are never overwritten by Trics. This Result File is in the form of a TTI file and can be executed as a TTI file from a Master command file. The user may also select the option "...with Details" which will generate additional screen messages showing the histograms of ADC counts as Trics is sweeping towards the optimal DAC Value. These extra messages will appear on the console AND in the result file (as comments). Trics still does not manage the L1CT MTG, or the Timing and Control Signals generated by this MTG. The user must thus ensure that the L1CT MTG is programmed so that the 29525 Read_Pipe_AB and Write_Pipe_AB are identical before trying to run Find_DAC. The algorithm is a straight port of what was done in Run I. - determine a min and max DAC byte for the search, as calculated from the empirical spread in values, with additional safety margin. The search range is 19 to 45 for ZER=8 and the algorithm sweeps up until it decides it found the optimal DAC Value. - The initial histogram sample size is 10 (fast serach), and the algorithm switches to 1000 (deep search) when it detects that the median of the histogram is only one count away from the target ZER. The Function Address being histogrammed is in the range [0,8] which corresponds to the oldest am29525 data. The register may be read while the data is being shifted and some of the samples may thus be corrupted. - every time a new DAC value is programmed, the algorithm waits 0.06 seconds (=3 time const) for the ADC output to settle within 5 %. - Once in deep search mode, the algorithm waits until the histogram shows a decline in the bin population of the target ZER. The algorithm concludes that the optimal DAC value was just overshot. New Dialog to Analyze Input TRM FIFO Depth: Add a new sub-menu "Input TRM FIFO Depth" to analyze Andor Input Term TRM Fifo Depth. This test reads the L1 TRM Fifo Status Register a number of times, extracts the Read and Write Fifo Addresses, derives a corresponding fifo depth, and histograms the result. The output is in the form "n ( a@x b@y c@z )" Where 'n' was the most populated histogram bin, and bin#'x' had a total of 'a' hits, bin #'y' had 'b' hits, etc. All non-empty histogram bins are displayed. The test will abort as soon as one of the samples had its read or write fifo address "reset" bit set. In the matching VME_Access version of this utility the user needs to enter the full TRM FPGA coordinates by hand (don't forget the transposed FPGA order), but the TRICS version finds the TRM FPGA given the AOIT num. The user also selects the sample size (default=100). L2 Busy Answer Delay: Fix a bug in the if-then-else structure during programming of the L2BAD card. Programming the L2BAD is done two places: when COOR specifies a new list of geo sect for an exposure group, and when COOR deallocates an exposure group. In both cases, the programming of all geo sect has to be re-evaluated and all L2BAD channels are reprogrammed, as it is not possible to decide just from the last COOR message which geo sect have been added/removed/still used by some other expo group. Add comments in Card and Fpga code for the L2BAD cards to remind that the programming must be repeated for all 16x FPGAS to allow scaler operation, but that only the output from 1x fpga is used. Create a new constant kiBADTotChanPerCtrlReg (=8) and use it instead of kiBADTotChanCtrlRegPerFpga (=8 also) where we determine which Control Register to use for a particular Channel. There is no change in the machine code generated, but the ascii code now makes more logical sense. Non-recurring Luminosity Block Number: This functionality provides non-repeating, ever increasing, Luminosity Block Number with two components 1) at every initialize from COOR, TCC writes down the current LBN to a file on its local disk. 2) at every software restart, TCC reads back that fairly recent value and adds 10^4 = 7 * 24 * 60 = one week's worth of once per mn increment = or 10k of SCL_Init and start/stop/pause_run - if for some reason Trics can't read this file or value, TCC starts off from 0x00000000 The problem (the file) would have to be fixed and the software restarted. This is accomplished by having a new type of Command file that understands only one keyword: "LBN_Value:". Trics automatically writes such a file at every initialize from COOR. Below is an example. The file name is \Trics\D0_config\LBN_At_Last_Init.lbn. !------------------------------------------------------------------------------ ! Do not delete, rename, or modify this file <%CONFIG%\LBN_At_Last_Init.lbn> ! This File was written by Trics_II_V9_2_D at the last System Initialization ! 20-Apr-2001 14:14:31.947 LBN_Value: 0x0000d0d0 !------------------------------------------------------------------------------ The first LBN issued this way was 0x0000d0d0 at 20-Apr-2001 14:14. This file cannot be executed by any other mean than restarting Trics (at the moment, or until we can find a reason to think we need otherwise). There is thus no syntax description document needed for this command file type. (But we still need better documentation of the overall Luminosity Services). The definition of some of the lum block variables has also been updated per Michael Begel's request. cf. http://www.pa.msu.edu/hep/d0/ftp/tcc/monitoring/tcc_monit_data.hpp - The Luminosity Block information has new fields to hold a Run Number (only filled for the LBN data sent after a start/stop/pause/resume_run message from COOR) and a Spec Trig Mask (only filled for LBN sent after a start_run message from COOR). - L1 Errors, L2 Errors, and L1 Event Dumped are now per Expo Group. Note: these are still not scheduled to be implemented yet. - The blocks will now be flagged as "Phase 5" (which is value=4). - also fix the comments that were reversed for uqDeCorrDaqEnable and uqCorrDaqEnable in struct Tcc_L1fw_Specific_Trigger The upgrade to provide the run number and mask of Spec Trig with the LBN data required propagating these new arguments through the many layers of function calls, in many places. Also updates for better control of the Luminosity data when Trics first starts up, or when Trics is told to skip IO and send blank data. Result Files: A new class was also added to handle writing LBN files. The class is called "CResultFile" in HandleResultFile.cpp and it provides a simple interface to open for read/write/append access, close, flush to disk, etc, for a simple text file. (We know we are going to need such result file shortly for writing the output of the Find_Pedestal algorithm). Internal: New CBusCardBase Object Holds the Card MotherBoard and Card Address, a card description, eta and phi offsets (for reference), and a link to a chain of its daughter registers (while the base card doesn't actually have any). New CBusCardCtfe Object Implements the Ctfe Card and includes all registers from both of its two card addresses. It also knows how to set a Trigger Tower Threshold for any of the reference sets given the desired value in GeV. It has an Initialize function. New CBusReg29525 Derived from CBusReg with additional functions to retrieve one given Previous Time Slice, or all Time Slices. Update CBusReg Object to now accept a constructor with a pointer to a Mother Card and keep a linked list of Reg Objects, similar to the FW model. New CommandFileTrigTwrInfo.cpp to handle Trigger Tower Info Command Files. Update Dlg_IO_Ctfe_Dac.cpp to be able to call TTI command files. Create new enumerated types for Eta Sign, Eta Magn, Eta Magn By 4, Phi, Phi By 8, Ref Set Type (EM/HDVeto/Tot), and Trigger Tower Type (EM/HD). New Dlg_Msg_L1ct.cpp file to provide templates for L1 Cal Trig Messages. Add new keywords to HandleCommandFile.cpp, .h for the new Trigger Tower Info Command File. Start using a new Macro to implement straight forward keywords. The new keywords were added this way, but the rest of the file was not retrofitted. The L1ct object has member functions to set a different coverage, check if a Trigger Tower Mask is within current coverage, set the threshold for a Reference Set over a tower sub-range. The Card Addresses for the L1CT are recorded in L1ctCardAddresses.cpp and L1ctCardAddresses.h. Unlike for L1FW, the card addresses are not all recorded as pre-compiler constants, but use a few constants and functions to compute the address of a given card from its eta, phi coordinates. Flip the order of the enumerated values for Sign Eta, now Pos=0. Neg=1. Update L1CT message parsing for phi ranges (e.g. "TT_Phi (1:8)"), as the above change broke the (already questionable) mixing of enumerated types for Asserted/Negated and TT_Eta_Pos/TT_Eta_Neg. Add in Tcc_Monit_Data.hpp new data structure "Tcc_Block_Cal_TT_ADC" to hold info for the new type "eTcc_Block_Type_Cal_TT_ADC". Add member variable and a member function to MonitPoolData.h to record and retrieve Trig Twr ADC info. Add member function to MonitPoolHelper.h to Collect Trig Twr ADC info. Drop unused variables from RegBase, FpgaCommon, and CardBase. Expand the use of Macros in HandleCommandFiles.cpp that was started in an earlier version. This makes the code more compact and clearer with no difference in functionality. Clean up the Initialization message to separate the actions for L1FW, L1CT, writing the LBN file, etc. For this reason there now is a L1CT_Initialize routine that can be called directly (cf. above), and a L1FW_Initialize routine that in fact cannot be called directly but is part of the system level initialization sequence. At the moment, "L1FW_Initialize" is in fact synonym to "init" which is the system level initialization. Create new CBusCardMTG with methods to initialize the card, and to control the Read_AB and Write_AB pipe BUT this is not used presently and until we better understand how we are going to use the MTG and what PALs we want to use. At the moment only the L1CT Init auxi file initializes the MTG card. Add the MTG Card addresses to L1ctCardAddresses.h. Replace all #include "Trics_II.h" with #include "resource.h" in all dialog implementation files and all other files where it is used (except Trics_ii.cpp). "resource.h" is sufficient in all these cases and prevents confusion with all the files shared by TRICS, VME_Access, and/or L2RS. All these projects have their own "resource.h" file created by Visual Studio which will be properly picked up. Tailor CommanFileSelfMsg.cpp to properly connect to the correct Dialog box for TRICS vs L2RS. HandleBit3Adaptor61x.cpp to record a "Warning" status (which is a new value) when a Bit3 Adaptor cannot be initialized (e.g. because it is powered off) which is different than the "Error" status for a non-existent adapter. This is used in L2RS to probe which L2 crates are currently connected and powered. Rename the MessageTccConsumer, MessageTccParser, MessageTccDispatcher, and MessageTccExecuter to MessageL1xxx. There is a new set of MessageL2xxx files. There is no real change to the MessageCoorxxxx which are still used for the real Coor messages. MessageL1xxxx are classes mostly derived from MessageCoorxxx to provide additional messages (e.g. ForeignBaseTickSelect). The MessageL2xxx files will implement all of the L2 message functionality without the MessageCoorxxx equivalent. Note that L2RS will still use the base MessageCoorParser files. MessageCoorParser needed to be tailored for L2RS to skip the part that fills in the trigger tower coordinate ranges when they are omitted in the reference set messages. This requires using information from the L1ct object, which is not desirable for L2RS as it would pull in a lot of code. This is required in Trics in order to follow the current defined coverage for L1CT instead of defaulting to eta(+20:-20). Tailor HandleCoorConnection.cpp which is the top level file for the management of the COOR connection channel. It will now use the MessageL1Consumer for TRICS and MessageL2Consumer for L2RS Tailor IP_PortNumbers.h to use a different set IP Port Number for Trics vs L2RS: Coor Connection (52160 vs 52165), the Remote Console (52161 vs 52166) and Monit Server (52162 vs 52167), while only Trics has a luminosity server (52163) New File Dlg_Test_Find_DAC.cpp/h to implement the new Find_DAC dialog. New File L1ct_TrgTwr.cpp/h: to implement a Trigger Tower with essentially a link to the CTFE cards that handles it, an initialize method (currently not used) and a Find_DAC method, as well as method to display Trigger Tower coordinates and ranges in a uniform manner. HandleLogFile.cpp: Split the Date Tag (e.g. "20010530") to a utility "DateTag()" now in UtilStrings.cpp Split the functionality to figure out which file version number comes next to a utility "AddFileVersion()" now in UtilFiles.cpp. The momtivation was that Find_DAC can now re-use these utilities. Rename the MonitPoolServer, MonitPoolManager, and MonitPoolData to MonitPoolL1xxx, and create new MonitPoolL2xxx for L2RS. Tailor MonitControl.cpp which is the top level file for the management of the monitoring and lum services so that it can use common code for Trics and L2RS while calling a different set of MonitPoolL1xxx, (and MonitLumManager, MonitLumServer) for TRICS vs the new MonitPoolL2xxx files for L2RS. Create Base Class HsroCrate from which HsroL1Fw and HsroL1ct are derived. This separates the generic actions from the specificity of each readout crate. The base class contains the pointers to the various cards in the crate, while it is the derived class that has instantiated the objects behind the pointers. The base class then know how to initialize, etc, all cards with a non-null pointer. Separate Supporting Programs: Create a new program for the Toy Trigmon Suite to display the Cal Trig Trigger Tower ADC Information. One can display any One ADC Time Slice, or the average of the previous 1:7 time slices, or the standard deviation of the previous 1:7 time slices. Update Remote_Console program to accept a different IP port number as a run-time parameter, so that it can connect to the L2RS port. Update the Remote Console application to detect lines that start with a M$ (or S$) and swith to printing the line in yellow (or purple). Update the Luminosity Test Client to display the new Run Number and Specific Trigger Mask data being sent. cf. http://www.pa.msu.edu/hep/d0/ftp/tcc/trics_ii/trics_support_programs.txt for details. Other work: Start a L2RS project. That's "L2 Relay Software", for lack of a better name, for the L2 TCC code. At the moment, it is little more than VME_Access with a remote console. This is a separate Visual Studio "project" in the same "workspace" as Trics's code. Much of L2RS code is in fact re-using of Trics code. - console - logfile - remote console - bit3 interface - COOR command interface (but different messages) - monitoring pool manager (but different data, and collection) - monitoring server (but different data) Made small changes to Trics code, as tailoring or renaming was necessary for better code management. Also started on new L2 specific code - L2 crate (with the ability to detect which crates are online and the crate type from the crate ID read from the DPM). - L2 Trigger (set of crates) - L2 specific monit pool management - L2 specific monit pool server - L2 specific COOR message consumer, parser, dispatcher, executer, printer Overall most of the structure is now in place, but more L2 specific work is needed. Also revive and bring up to date some old Prescaler test code to model the prescale percentage behavior and determine that Dean's divide-the-turn-number-by-512 mode for pulser runs only exposes every third bunch because 512 is not prime with the length of the prescaler shift register. -------------------------------------------------------------------------------- TRICS II Version 9.1 Release Notes ------------------------- 7-MAR-2001: (Rev I) General: The primary goal of V9.1 is to implement the Luminosity Monitoring Server, and improve the general Monitoring Server architecture by using a separate process to collect the data at 5 sec intervals. The VRB+VTM card that was in Slot #8 has moved to Slot #19. The Data Block Format Version.Revision has been updated. cf. HSRO Crate Initialization below. Monit Data Pool and Luminosity Block Management: Add new IP Server Port #52163 for the Luminosity Server (not operational) Make a test Luminosity client to connect to this new Lum Server Port. New Files to manage the different components of the new monitoring model - MonitControl.cpp Start and Stop monitoring services (i.e. start and stop needed threads) Holds variables to control Monitoring Behavior (e.g. Monit_Server_Silenced) - MonitPoolData.cpp Holds the Monitoring Data Pool itself. Routines to update and retrieve this Monit Pool data from different threads without interference. - MonitPoolHelper.cpp Routines to help read and gather the disperse monitoring information. Formerly called HandleMonitData.cpp - MonitPoolManager.cpp Separate thread (sub-process) to collect Fresh Monit Data every 5-10s. First try to capture a triggered event and wait up to 2 sec, then force immediate capture if no event has naturally occured. We verify that the Capture Monitor Data Pending Bit is set in the corresponding L1 Helper Control Register right after the Request to Capture Monit Data is made. (note that there could be a trigger firing during the 5 us window between write and read, but this should still be a useful test for the moment). - MonitPoolServer.cpp Separate thread to field and service Monitoring Requests (i.e. Taka, and Toy TrigMon) Formerly called HandleMonitServer.cpp. - MonitLumManager.cpp Separate thread to increment the Luminosity Block Number every 60 sec Push some data out (simply Per Bunch Monitoring Data for the moment) when the LBN is incremented. - MonitLumServer.cpp Separate thread to field and service connection to Luminosity Database Manager Program on the Host (i.e. Michael Begel's) The data pushed out by the Luminosity Server is the old Per Bunch Scaler Data Block instead of the new data block type(s) needed for luminosity. We started implementation by using a block that already existed and was vaguely related. This will be replaced by the new/different block type(s) with the contents that is outlined elsewhere. Trics however stuffs the LBN in the field normally reserved for format version number. This may be useful to Michael Begel for short term tests (or maybe not). Update the Tcc_Monit_Data.hpp and send it to M.Begel. This file now includes the Luminosity Server information in the form of two structures: A "Full" Luminosity Data Block and a "Brief" Luminosity Data Block. The Brief Block is a truncated version of the Full Block with only the Foreign Per Bunch Scaler information. In the process of creating these new Monitoring Block types, also define a new Tcc_Block_Extended_Header as a superset of the old Tcc_Block_Header with additional fields for new flags: "System non-operational", "Data Not Current", and "Triggered Beam Crossing". To update the L2Accept Field of the Luminosity Data Block Full we use the L2 Accept AONMs (instead of the L2 Answer TRM which would record the global L2 Accept Rate instead of the individual per Spec Trig rate... because we are in L2 Bypass Mode). Timing of Monit Data Manager and Luminosity Block Manager: Trics polls the Monit Data Captured (i.e. capture triggered event) at 10 Hz. Trics also checks the necessary programming of the L1 Helper every time it polls for Monit Data Captured, and reports an eventual error at most once per Request. The Refresh algorithm remembers when the last successful Monit Pool update happened (truncated down to the whole second) then waits 5 seconds before asking for a Monit Data Capture again. Polling to see if an event has been captured, and checking if it is time to get fresh data are both done at 10 Hz. The time measurement used is truncated down to the whole second. Taking this into account, we should see a refresh time of between 4 and 5.1 sec when data is flowing at high rate or up to 2 sec more for low or no rate. Similar thing for Luminosity Block Increment Timing algorithm, but the nominal time between successive increment is 60 sec and this is independent of data flow rate, as it always captures data for an immediate random crossing. Add a second time context to decide when it is time to send another Brief Lumninostiy Data Block. New Safety Net: Implement "Do you really want to do this: Yes No " on critical actions: A two-option Yes/No dialog box pops up whenever the user: - clicks on Exit from the main menu - clicks on "Configure L1&L2 Frameworks" in the Master Command File Menu - clicks on "Initialize L1&L2 Frameworks" in the Master Command File Menu - send a "L1FW Config" message from the "Send COOR Message" Menu - send a "L1FW Init" message from the "Send COOR Message" Menu Monit Data Server: Add a new type of monitoring data: TCC now captures and serves HSRO data (rebuilt from the Monitoring registers and NOT from VBD data) and serves this information as a new monit block type. Add a new program to the Toy TrigMon Suite to display this data in the familiar Formatted Dump format. cf. "_Hsro_Toy_TrigMon" Shortcut on TCC. This is a simple/convenient way to look at Monitoring Data to verify/observe triggered data which is not so obvious in Toy TrigMon. Finding healthy data in this display does NOT prove that Readout to L3 is working properly, as this data is NOT read from the VBD, but from the Monitoring Data Registers of each THE-Card. I have been thinking of adding the ability to retrieve "true" VBD data over the Monitoring path, but this has more complex implementation issues. It will also require mini-pausing the Framework and will have thus to be a controlled access resource (not public knowledge). Upgrade (or kludge) the Geographic Section part of the standard Monitoring structure to stuff in a previously unused/spare/reserved \ field the lower 16 bits of the Geo Sect Start Digitize (i.e. L1 Accept) Scaler as read from the outpu FOM cards. Upgrade the Block of type "L1FW HSRO" to use the new Extended Header. This Monitoring Data Type is not used by Taka or Michael and this non-backwards-compatible upgrade will not affect anybody else. For the development version of Trics, now fill the Tick and Turn Fields with a quantity derived from the current time, which lets the client display the actual elapsed time between samples without having a real Framework Tick and Turn Scaler available. Initialize the Monit Pool Data (to Zeroes) at boot time (this includes the Luminosity data) so that reasonable data is served even before th system is first declared operational. Resource Locks: TricsLocks.cpp holds the resource locks that we now need for full multi-threaded operation. - One lock (Mutex) to prevent monitoring pool data to be updated while it is being read and sent to a Monitoring Client. - One lock to prevent another thread to launch a new Capture Monit Data before another thread is done collecting the data last captured. - One Lock to protect against the Framework being declared non-operational (e.g. by config or init or SCT) at some importunate time (e.g. while Monit Pool Manager programs is in the middle of poking at the L1 Helper in intricate ways). This new Lock and additional checking for this operational state protects the Monit Pool Manager program from disturbance during initialize or SCT AND vice versa. - One Lock for Pause and Resume to protect sections of code from having this resource changed while some critical sequence is executing. This includes every time any AONM/FOM/FOM++ resource is programmed and TCC needs to mini-pause the framework. This also includes when TCC needs to increment the Luminosity Block Number and capture a new Luminosity Data snapshot while guaranteeing no events are flowing. Measure the Lock acquiring+release time penalty at about 0.18 us per pair (asuming the lock is available). This is very small, and makes it possible to add a Lock around every Trigger IO function call. This will be done in a future revision of Trics. System Control/Status Dialog Menu: Global control values in CMonitControl hold the Time between successive Monit Pool Refreshes and the Time between successive Luminosity Block Increments. These control values can be modified through the "System Control/Status" Menu to change the default 5 sec interval for Monit Data Refresh and default 60 sec for Luminosity Block Number increment. Added a global control value to hold the Time between sending successive Brief Luminosity Block. This is in addition to similar global control values above to hold the Time between successive Monit Pool Refreshes and the Time between successive Luminosity Block Increments. All these control values can be modified through the "System Control/Status" Menu to change the default 5 sec interval for Monit Data Refresh, or the default 5 sec for sending a Brief Luminosity Block, or the default 60 sec for Luminosity Block Number increment and sending a Full Luminosity Block. When one of these values is changed in the "System Control/Status" Meny, the corresponding "<- Set" button situated next to the quantity must be pushed for Trics to ingest the new value (this avoids transient values). These quantities are specified in milliseconds but Trics only polls the current time at 10 Hz. There are two reasons why Trics does not use timers to wait and wake up at specific times. Number one is that other independent asynchronous events may change the time the next update is needed (e.g. after an implicit or explicit request to increment the LBN). Number two is that Trics also uses the oportunity to check every .1 second whether the thread was politely requested to gracefully exit. I also haven't figured out how one is supposed to make ACE wait on multiple events, like a timer and/or a mutex. This was straightforward to do in VAXELN, and has to be doable in ACE too. The previous time granularity method used the simple time() function which only gave time measurement truncated to the current second. Upgrading to finer granularity will make the luminosity service cleaner and .1 second is probably sufficient. Note also that this quantity only controls the time when the thread wakes up, but in the case of the monitoring pool the time when the monitoring data ends up being captured will still fluctuate. Single Chance Test: SCT Initialize now declares the L1FW non-operational which will prevent the Monit Pool Manager and the Luminosity Manager from generating any IO while sending blank data to their respective clients. It is not clear to me what I will need to do with LBN; send 0 to emphasize that the data is junk or stick to the last LBN to maintain continuity. The current implementation is to keep sending the last LBN. Declaring the Framework non-operational means that all messages from COOR (except Initialize) are acknowledge with an error and no action. This should actually be a good thing. COOR Commands: Add a new COOR Message: 'force_l2reject': The user sends "L1FW_Spec_Trig 0 force_l2reject" from the COOR Message menu to program the L2FW L2 Answer TRM to simulate a negative decision from the L2 Global for SpTrg #0 and thus generate 100% rejects from SpTrg #0. The user sends "L1FW_Spec_Trig -0 force_l2reject" to return SpTrg #0 to the default 100% accepts. The SpTrg 'Deallocate' message was updated to restore default 100% accept. Update the COOR Message 'Increment_LBN' that was a NO-OP in V9.0 to now cause the LBN to be incremented and push a luminosity block out. Modify action for COOR Message 'L1FW_Spec_Trig [SS] Expo_Group [X]' to change programming of the FOM++ by adding a copy of Start Digitize Geo Sect #31. FOM++ Channel #36,37,38 (decimal, zero-based) *CONTINUE* to be programmed to generate a L1 Strobe, i.e. any allocated SpTrg Firing will generate an asserted output. (note: Channel #38 is currently a spare signal) FOM++ Channel #39 *IS NOW* programmed as a copy of the Start Digitize FOM Channel for Geographic Section #31, i.e. the L1FW Readout Crate. Modify SpTrg 'Deallocate' message accordingly to undo/update the above programming. Increment Logical Block Number on certain requests from COOR: Add implicit "Increment_LBN" to the "Start_Run", "Stop_Run", "Begin_Store", "End_Store", "Pause_Run", "Resume_Run", "SCL_Init", and "L1FW_Init" commands and the new Luminosity Block Number is appended to the acknowledgement message sent back to COOR. Note that "Start_Run" has an implicit "SCL_Init" which in turn also causes the implicit "Increment_LBN". Note that Pause/Resume_Run messages are different from L1Fw_Pause/Resume: Pause/Resume_Run is a notification of overall Run Status, while L1Fw_Pause/Resume is the active control of triggering while COOR programs some resources (e.g. enable/disable SpTrg). L1Fw_Pause/Resume messages are sent only to TCC while Pause/Resume_Run messages are sent to all systems. When the LBN is incremented, a Full Luminosity Data Block is pushed by the luminosity server with the apropriate flag(s) set to specify the reason for the luminosity block increment. This implicit "Increment_LBN" only happens when the system is considered "Operational". The Start/Stop_Run, Pause/Resume_Run, Begin/End_Store messages were until now mostly no-op messages. They are now treated like other messages in the sense that TCC will answer "sorry the system is not operational" if COOR hasn't properly configured and initialized the system. Add two arrays to the L1fw object to remember the current prescaler ratio and percentage of each specific trigger so that it can be sent to the luminosity client. HSRO Crate Initialization Add initialization of VRB's Buffer Starting Address Registers to configure all VRBs for 16x2kB buffer mode instead of the default 8x buffer mode. cf. http://www.pa.msu.edu/hep/d0/ftp/tcc/trics_ii/ Hsro_Crate_Initialization.txt Add a Wait during VRBC Initialization after the reset command and before trying to read the SCL Status register. Wait 50 ms after step #II.c in Hsro_Crate_Initialization.txt Note: the order of initialization VRB,VRBC,VBD has NOT been changed The VRB+VTM card that was in Slot #8 (now empty) has moved to Slot #19 (previously empty). (Slot #8 has a hardware problem). The 4x AOIT TRM cards serviced by this VRB+VTM have moved with it. This VRB card will continue to be the first card read out by the VBD. The VRB slot readout order will now be 19, 9, 10, 11, 12, 13, 16, 17, 18. Other VRB cards have not been affected (not even the order they appear in the readout). The HSRO VBD event dump/analyzer automatically tracks along. The Data Block Format Version.Revision has been updated: its revision number has been incremented; it is now 1.1. This change will not confuse L3 ScriptRunner while it retrieves the SpTrg Fired Mask, LBN, and L1 Accept Number. Send COOR Message Dialog Menu: Add 'force_l2reject' and 'Increment_LBN' message templates. Command Files: Resurrect the "Include_File:" command which makes a recursive call to the specified command file while passing full context into the called file and saving full context when coming out of the call file (unlike the "Call_File:" Keyword which drops all changes made in the called file). This "Include_File:" keyword is useful to call a common file where a list of symbols could be defined to be used in the body of other command files. Serial Programming of CTFE DAC: Create new Menu "CTFE DAC Programming" where the user can program each DAC on a CTFE Card one at a time (later also one channel at a time, or the whole card at a time). We may also later consider to enable command file access. Split part of the former HandleCbusIO.cpp &.h into a new set of files CBusReg.cpp & .h. Create new CBusCtfeDac.cpp, & .h file to manage the Serial Command Programming of the new CTFE DACs. The user can write any logal value into the EM and Had Gain and Zer DACs of any of the CTFE card's four channels. The user can also "Reset Whole Card (=Set Default)" to force the DACs to a known state where they will listen to commands. Add option to trace message and show every IO to the CTFE Card Board CSR Register while sending out the serial command. This option is controlled by a check-box switch on the sub-menu to turn this feature on/off. CBus Random Register Test: There is a new sub-menu called "Rand CBus Reg Test" This is a new sub-menu to implement for CBus Registers the same functionality as is available for THE-Card Random Register Test. Just like for the classic Random Register Test, the user can enter ranges of registers manually or with a command file. cf. http://www.pa.msu.edu/hep/d0/ftp/tcc/trics_ii/ syntax_rules_cbusregtest_range.crt This functionality may also be added to the VME_Access program, but at the moment it is only available as part of TRICS. CBus Register Access: Upgrade the CBus Register class read/write functions to now do Pre-Write Read-Check and Post-Write Read-Check (with 2nd attempt on Post-Write Error). Also Upgrade the CBusReg routines to maintain a pointer to a previous register, have a Read Mask, Write Mask, Remember Last Read, Last Write, and keep track if it was written to at least once. Fix the Cbus IO sub-menu so that the spinner control for the Function Address field has the proper range 0-255 (instead of 0-63). New Time Routine: Make a new TimeMilliseconds() routine that returns the time since 1-JAN-1970 as a 64 bit integer in units of milliseconds much like the time() routine returns the time since 1-JAN-1970 but as a 32 bit integer in units of seconds. This routine is in MonitControl.cpp for the moment. Memory Leaks: Notice a memory leak during fpga download. It has probably been there for a long time, probably from the start. This was a simple (and stupid) omission of deleting a temporary dynimically allocated object in CommandFileDownloadFpga.cpp. Do a systematic manual check for memory leaks by matching all "new" with all "delete" and find a few more minor omissions in Dlg_IO_Load_Fpga.cpp (missing delete temporary generic card in the de-program Fpga), Dlg_Test_Hsro.cpp (missing delete the L2Helper), HsroL1fw.cpp (missing delete VBD card), L2fw.cpp (missing delete the L2Helper), Internal: Skip most of the Fpga Download IOs for the development version of Trics to speed up tests that involve "downloading the fpgas" to pick up the correct FPGA version numbers. In CFpgaL1fwHelper add a function to request Capture Monit Data, f_okRequestMonitData, and a function to check if it happened, f_okCheckMonitDataCaptured. Add similar functions to CL1FwCardL1fwHelper to call the Fpga's functions and keep track of the number of errors to declare the system non-operational if needed. Fix Bug in definition of Read and Write Mask for some L1 Helper Fpga TSS Control Registers. This was causing failure of the new f_okCheckMonitDataCaptured function. HandleMonitData and HandleMonitServer have now become MonitPoolHelper and MonitPoolServer. Declare some important flags as "volatile" so that repeated tests on these variables have no chance to be optimized out. Note that TRICS is still not compiled optimized. This has been applied to g_eynL1fwOperational and mg_eynMonit_Server_Silenced. Notice that FpgaSupport::Initialize was resetting the Fpga's scalers twice in the row. This was a typo and was removed. Fix HandleCbusIO.cpp where the outgoing Ironics data was not inverted in the case of TRICS_IO_BIT3_API. Added the keyword "To_Cbus_FA:" to support CBus Register Range Command Files. Separate Programs: cf. new www.pa.msu.edu/hep/d0/ftp/tcc/trics_ii/trics_support_programs.txt for details on all Trics support programs Increase timeouts of all test client programs to 30 sec. HSRO_Trigmon: This is a new program (with "_Hsro_Toy_Trigmon" shortcut on TCC's screen) added to the Toy_TrigMon Suite to display the new type of Monit Data served by TCC. This shows each THE-Card's HSRO Data in the familiar format of the Formatted Dump format. _Hsro_Toy_TrigMon also displays the new flags available from the extended header. ("System non-operational", "Data Not Current", and "Triggered vs Random Beam Crossing"). (Note: this extended header was not available at the time the main trigmon data was defined and thus cannot be displayed in the classic Toy Trigmon). Toy TrigMon: The classic TrigMon_Test_Client (with "_Toy_TrigMon" shortcut on TCC's screen) now displays Expo Group of each SpTrg, plus a "Disable Mask" which is NOT a straight copy of any TDM reg. cf. http://www.pa.msu.edu/hep/d0/ftp/tcc/monitoring/tcc_monit_data.hpp Update the Toy Trigmon program to show the newly available GeoSect L1 Accept rate. Also update the program to allow user control of how much information is being displayed with each refresh. Type "B" for Brief or "F" for Full (or "Q" to quit) where one previously only typed to get the next sample. Test_Luminosity_Client: This is a new program to connect to the new Lum Server Port and receive Luminosity Monitoring Blocks. It displays the Luminosity Incremented flag and the reason for the LBN increment. It is also watching for consistency and ready to display problems in red. It will display all of the information in the luminosity blocks for all Spec Trig currently defined. This program is used at MSU with the development version of Trics to connect to the Luminosity Server Port. It can also be used at DZero to connect to the Monitoring Server port instead and watch the data being served to the Michael's Luminosity Monitor Program without interfering with this official Luminosity client. Also add the option of automatically asking for a luminosity block at specified intervals. VME Access: Update this separate application originally created for the L2 Test Stand. It used to only offer the 'VME IO" Sub-Menu. It now has the "Register IO", "CBus IO", "Configure FPGA", "Card CSR", and the new "CTFE DAC Programming" Sub-Menus. Find and fix a problem with the CBus IO, where the data was not inverted on its way out to the Ironics Ports. The VME Access program uses the Bit3 API interface (as opposed to memory mapping for Trics). Flipping the outgoing bits was present in the memory mapping method but forgotten in the API method. This had never been tested or used before. -------------------------------------------------------------------------------- TRICS II Version 9.0 Release Notes ------------------------- 30-Nov-2000: (Rev W) General: Rev U,V,W use new TDM FPGA (i.e. new prescaler model) Rev <=T use old TDM FPGA (cf. 000_trics_ii_revision_notes.txt for othe diff) Rev V expects the New TTS Fpga design which reads out Turn LSW first, then Turn MSW, then Tick, then 0x0. Update the Register Address of the Monitor Copy Registers for the Tick and Turn Scalers. This version takes full control of High Speed Readout and VRB Readout Crate. There now is a L1FW Readout Crate Object made of 1x VBD, 1x VRBC and 9x VRBs. Each VRB Card in this crate knows how many of its channels are used and which L1FW Card is attached to each of its channels. Trics V9.0 initializes the VRBs+VRBC+VBD (in this order) either - when COOR (or the TRICS button) says L1FW_initialize - when you click on "Initialize" on the HSRO Test Menu (among other things done during HSRO Test Initialization) The L1FW Readout Crate cards are initialized according to http://www.pa.msu.edu/hep/d0/ftp/l1/framework/hsro/hsro_notes.txt Add Raw and Formatted event dumps read back from VBD (cf. below). Change L1 Helper control of delay between L1 Accept and Capture HSRO (cf. below). New Dialog "System Control/Status" (cf. below) with new flag to prevent Monit Server from generating VME cycles. Expect 8x Miguels in the EG AONM and L1Bz FOM in sites 9-16. (Note the FOM++ remains at 4x Miguels with only 1x slice of data). Expect SM in slot M123-Bot-19 connected to second fiber of VTM in VRB readout Crate Slot #18 Expect L1AL2 Fpga in Site #16 of SM in slot M123-Bot-19. Fix Monit Server Per Bunch Scaler Readout of Tick #159 (cf. below). Note: still uses old TDM Fpga Pre-Scaler model. HSRO Timing sequence: The issue is to align the Readout data with the triggered crossing. This had never been checked, except for the Tick and Turn Scaler. In particular the delay values in the L1 Helper were only a best guess, which proved to be off. SCT was certifying that the BXSHR control values were mutually consistent (except for the Tick and Turn Scaler that cannot be checked in absolute value, only in its increments). SCT is however using a different control of these delays while the L1 Helper is in Test Mode with a programmable canned pattern of timing signals, in contrast with the Normal Mode which uses the stimulus of the L1 Accept Signal. Change L1 Helper Normal Mode Timing: - issue Capture HSRO with delay of 1 Tick after L1 Accept (i.e. load 0x1 in Reg 9 of L1 Helper, instead of 0x4) - issue Capt Monit Data with delay of 1 Tick after L1 Accept and only issued on explicit request from TCC. (i.e. load 0x81 in Reg 10 of L1 Helper) - issue Transport HSRO with delay 1+2=3 Tick after L1 Accept (The previous delay was only 1 tick away from Capture) (i.e. load 3 in Reg 8 of L1 Helper) Change L1 Helper Test Mode Timing: - Issue Maginot Line 1 Tick into the canned pattern (i.e. load 0x0201 in Reg 23 of L1 Helper, meaning up at tick #1, down at tick #2) - Issue Capture HSRO 7 Tick into the canned pattern Note: The value pre-Rev-K was 6. (i.e. load 0x0807 in Reg 21 of L1 Helper) - Issue Capt Monit Data 7 Tick into the canned pattern (i.e. load 0x0807 in Reg 22 of L1 Helper) - Issue Transport HSRO 7+2=9 Tick into the canned pattern (i.e. load 0x0A09 in Reg 20 of L1 Helper) Note: There are thus 6 ticks between Maginot line and Capture Monit Data which seems like quite a LONG delay. Where is it all going? my guess: 1x tick to get into the second slice of processing 1x tick to get through the second slice and into the L1 Helper 1x tick explicit delay in the L1 Helper 3x ticks of implicit delay to build minimum history in all BX Shift Registers Increment every Main array and BSF BXSHR by 1 count for L1FW Cards to keep track of the above changes. - e.g. typical AONM now gets 2, typical TDM or FOM gets 1 - except for TTS Scaler Card which was changed from 4 to 1 - these values apply to both normal running and SCT running But maintain previous BXSHR control values for L2FW TRM, AONM, FOM Cards, as their usage is different in the L2FW where the multiple slices are for successive L2 Decisions instead of successive BeamX. New Dialog "System Control/Status": "System Operational" allows to see and modify this global status. When the system is Non-Operational, COOR messages are returned with an explicit error acknowledgement until the next Initialize. "L1FW Paused" see and modify the current Pause/Resume Status by sending a Pause/Resume message, as needed. "L2 Global Bypassed" Not yet useful, but this is becoming the place to collect all system-wide status information. Let me know if you think of other. (e.g. Total number of Initialize or SCl Init since last Configure ?) "Monit Server Silenced" allow to see and modify a NEW flag that prevents all IO by the Monitoring Server (e.g. for Taka's Global Monitoring, or Toy TrigMon). When this flag is set the Monit Data Server stops requesting Immediate Capture Monit Data, and stops collecting the requested Monitoring Data. Blank Data is returned while the Monit Server is "Silenced". This flag is automatically cleared by an Initialize message from COOR. "Monit Data Every Event" to control this L1 Helper function (so you don't have to go hunting around for the L1 helper addresses) "System Operational" vs "Monit Server Silenced" - "System Operational": When the system is NON-Operational, all COOR messages (issued by COOR or by the Trigger Expert) fail with a bad acknowledgement. - "Monit Server Silenced": When the Monit Server is silenced, normal trigger operation continues, but no asynchronous and uncontrolled IO is generated by the Monit Server. "Refresh" Button. All status information in this display may be changed by events external to this menu (e.g. COOR messages), and this is a request for an update. FPGA Download: We need to figure out each FPGA revision number from the name of the EXO file being loaded during Configuration and furhermore remember these values for later retrieval during Initialization of HSRO BSF Header/Trailer Data. A new piece of information is being printed to the screen along with the EXO file name which shows the Version Number extracted from the file name. The S-record file name requirements are: - there must be a file extension (e.g. ".exo") so that Trics can locate the right most dot. - the version and revision number must appear directly preceding the extension with a single underscore leading each number e.g. "xxxxx_2_3.exo" - this matches our current usage. The Version of each Main Array Fpga is recorded in the 16-word Scratch Memory of the VME Interface Fpga, using one scratch word per Main Array Fpga. The Version Number of the BSF FPGA is recorded in the currently unused Board Interrupter ID Register of the VME Interface Fpga. HSRO Control: Update Board Support Function to use the new BSF FPGA design with the new user defined words in HSRO Header and Trailer and with 4 BSF Data words. Update all FpgaSupport to initialize the new registers, and update all necesary CardXYZ to properly override the initialization of the BSF BXHSHR according to the updated document: www.pa.msu.edu/hep/d0/ftp/l1/framework/hardware/bsf/bsf_fpga_programming.txt Note that the CardLatchFM has a 4013L with a stable older FPGA and thus does NOT have the new registers. Update CardAONMCommon to properly override initialization of unused Aonm/Fom Fpgas so they do not readout. The EG AONMs and the L1Bz FOM cards reads out 2x2x Aonm/Fom Fpgas (#1,2,5,6) at 2 words per Fpga, 4x Miguel Fpgas (#9-12) at 4 words per Fpga (for TT-3, TT-2), 4x Miguel Fpgas (#13-16) at 4 words per Fpga (for TT) for the required fixed total of 32 words. The FOM++ reads out 2x4x FOM Fpgas for L1 Qualifiers, 1x FOM for Skip Next Tick, 1x FOM for the Global L1 Accept Strobe, 1x FOM for Skip Next N, and 4x Miguel Fpgas, all FPGAs readout 2 words per Chip for the required fixed total of 32 words. Update CardTickTurn to include and initialize another 14x FpgaTickTurn. Change Readout Control of Tick and Turn Card. (i.e. the Interim Proposal) - Readout Nothing from the Fpga #1 - Readout 1x Word from Fpgas #2-10 - Readout 4x Words from Fpgas #11-15 - Readout 3x Words from Fpgas #16 - for the required fixed total of 32 words. Fpgas #1-15 are setup for "Current Tick and Turn" Mode. Fpga #16 is setup for the "L1 Accept Tick and Turn" Mode. Update the CardTRM to include and initialize 12 SHED Fpgas for the Global Disable TRM (other TRMS have no SHEDs). All TRM and SHED Fpgas readout 2 words per Fpga for the required fixed total of 32 words. The FPGA Shed registers are initialized as follows: - Fpga #N+1 (N=0x0,0xf) Reg 8 gets 0xN1N2 and Reg 9 gets 0xN3N4 Override the defined SHED Data Words (cf. summary_of_fw_data_readout.txt) - SHED Info 1st Word MSByte TRICS Version compound of two fields MSNibble Major Version ID (0:15) MSNibble Minor Version ID (0:15) LSByte TRICS Revision ID (0:255) The Revision ID is typically expressed as an uppercase letter (0=A, 1=B,... 25=Z) e.g. V9.0-U -> 0x9014 - SHED Info 2nd Word Word of "Operating State Information" e.g. Is L2 FW in bypass mode, ... Format not defined, write 0xcafe for now - SHED Info 3rd & 4th Words 32 bit long "Luminosity Index" Not Implemented, write 0x00000000 - SHED Info 5th Word version-revision of the BSF FPGA used by the 4028XL's Use Tick&Turn Scaler BSF Version Number - SHED Info 6th Word version-revision of the BSF FPGA used by the 4036XLA's Use FOM++ BSF Version Number - SHED Info 7th Word reserved currently not used - SHED Info 8th Word reserved currently not used Write 0x0000 in both words - Note that the upper 8x SHEDs (site #9-16) keep the initialization data 0x8182, 0x8384, 0x9192, 0x9394, etc Create a new HsroChanTheCard class that all L1FW Card Object derive from. i.e. CardAONMCommon (which covers AONM, FOM, FOM++), CardTRM, CardTDM, CardGS, and CardTickTurn. Note that more cards (including some L2fw cards) end up including this base class, but it won't get used or fully constructed. A filter on the card ID is used in the constructor of the derived classes (in particular for CardAONMCommon and CardTRM. The L1FW Readout Crate Object is created first. When the L1FW Object is created, each L1FW card object explicitely calls CHsroChanTheCard::FurtherConstruct and passes a pointer to its BaseCard. FurtherConstruct retrieves the VRB Card Slot Number and Vtm Channel Number as listed in pre-processor constants in L1fwCardAddresses.h. It then locates the corresponding VRB Object in the L1FW VRB Crate and register in the VRB Card Object the pointer to the CardBase Object so that the VRB Card can have access to the text description of the card that it is servicing. Initialize the VRB Header User Info field according to the updated summary_of_fw_data_readout.txt MSNibble - Slot Number that this VRB is in. The value written here is the actual slot number minus 8. Nibble - Trig FW Data Block Version 0:15 LSByte - Trig FW Data Block Revision 0:255 With the Initial L1FW Data Block Version set to 1.0. Fill THE-Card Header Word #0 LSByte with the Card ID according to the updated summary_of_fw_data_readout.txt Bit 7 Vertical Master Number (0 = M122, 1 = M123) Bit 6:5 Vertical Slave Number (0 = Top, 1 = Middle, 2 = Bottom) Bit 4:0 THE-Card Slot Number (2:21) This replaces the now abandonned word count field. Fill in HSRO THE-Card Header Word #1 with the Primary (i.e. most prominent) Main Signal Array Fpga Version Number. Fill in HSRO THE-Card Trailer Word #0 with the Secondary (i.e. less prominent) Main Signal Array Fpga Version Number. Done by retrieving this information from the VME Int FPGA Scratch Memory as it was recorded during the last FPGA download. Note that if there are 8x FPGAs of each type, the FPGA in Site #1 is designated as the primary FPGA type. HSRO Test: There is a new "HSRO Test" Dialog. The old HSRO Test has been renamed "Old HSRO Test" and will be totally retired in a future version. The overall plan is to pick a set of cards (like in SCT) and verify the operation of HSRO by reading the data back from the VBD buffer and comparing it to what can be reconstructed from the Monitoring registers of each card. This can be done a number of times (i.e. loops). The idea is for this part of the test to have the minimum requirements with respect to how the system is programmed and what data is going to be transported. Each CardXYZ which inherits from HsroChanTheCard implements a HsroReadFromMonitReg method that can read the Monit Data registers and rebuild the expected content of THE-Card HSRO. i.e. CCardAONMCommon, CCardTRM, CCardTDM, CCardGS, and CCardTickTurn. Select which card to test via the "Select Cards to Test ..." button. Note that only the cards that readout are available to test (no L2FW). Add TTS Card to HSRO Test (including interim weird readout distribution). Add Gated Scaler Card to HSRO Test (including L1AL2). Note that the Card Select Menu has new buttons for these 2x cards. The "Wait Before Reading VBD" field selects the amount of time each test loop waits for the VBD to present data on VME for read back. The first environment being implemented is to use SCT to bring the system to a state of random simulated input data and random programming, then come in with HSRO Test's "Initialize" and override the programming of the system to guarantee that a clean L1 Accept and L2 Accept are generated while using the KickHelperFunction method from SCT to generate one event at a time with event transfer and capture monit data. HSRO Test after SCT: 1) Run 100-300 loops of SCT on all L1+L2 cards (no scaler checks needed) 2) go into "HSRO Test" 3) "Select cards to test..." 4) "Initialize" (i.e. force L1&L2 Accepts to crate 31, and Init VRB Crate) 5) "Go" HSRO Test without SCT. This is a manual mode, with small impact on other triggers. 1) COOR-level Initialize 2) setup a 1 Hz trigger of any kind (e.g. execute \trics\scratch\SpTrg103_FW_RO_Setup.mcf) 3) Go to the "System Control/Status" Menu Select "Monit Data Every Event" (not needed for SCT method) Select "Monit Server Silenced" (not needed for SCT method) 4) Go into "HSRO Test" a) "Select cards to test..." b) "Pause" c) "Compare Again" d) "Resume" e) wait 1 second (for 1 Hz Trigger) f) back to (b) Another environment (in the future) would be for HSRO Test to be a parasite during normal running and simply manage to pause the trigger after a Capture Monit data and read the VBD before resume-ing. Raw HSRO Event Dump: Available as a "Dump N Longwords from VBD" button in HSRO Test Dialog. The "Dump N Longwords from VBD" button reads the specified number of D32 words from the VBD Data Buffer and presents them in Hex format Truncate length of dump to the amount of memory mapped for VBD Buffer in order to avoid possible access violation. Formatted HSRO Event Dump: Available as a "Analyze Current Event in VBD" button in HSRO Test Dialog. This is both a formatted dump and an event consistency