============================================================================== Trics V10.5 Rev A (24-MAR-2004) Configure FPGA Change initial "Configure FPGA" dialog option setting: Now the "ECL Output Enable" is already set by default CTFE Serial DACs Change default mode of operation: Executing a TTI command files with Serial DAC commands will immediately program the CTFE Gain and/or Pedestal DAC(s) with the specified values. L1CT initialization continues to NOT program the Serial DACs. L1 Calorimeter Trigger System Exercizer Test This is the initial phase of a L1 Cal Tester Usage overview: Click "L1 Cal Trig Test" from the main menu. Click "Select Test coverage" Pick Eta/Phi coverage and EM and/or HD Pick Lookup Page (This must match what L1CT is using) Pick which energy quantities will be exercized EM/HD/Px/Py Pick which Reference Set numbers will be exercized Pick which count quantities will be exercized EM/Tot/HD Veto Click "Ok" Notice that the selected coverage is displayed on the console Click "Initialize" Pick some "Run Time Options" Pick which global quantities should be checked at each loop (attention: The EM/HD Energy CAT cards may not be plugged in Tier 2/3) Enter a number of loops Click "Go" For its Initialization, the test does: For all the Trigger Towers and resources specified in the test coverage: Load 8 as simulated data in all Trigger Towers in coverage and verify in the 29525 that the MUX output is correct Load 200 GeV (which saturates to maximum range) in all Ref Set Comp and verify the state of this Trigger Tower at the CHTCR input For all the Tier#1 and all the selected resources (EM/HD/Px/Py) Verify the partial sum from the CTFEs as input to the CAT2s [The Global energies and counts at Tier #3 are not yet checked) For each loop, the test does: Pick a new Trigger Tower, pos/neg, eta, phi, EM or HD Pick a new Simulated Energy for this tower Pick a new Reference Set Type and Number Pick a new Comparator Threshold Value Before modifying the selected trigger tower, remove its current contribution from the partial and global quantities. Program the selected Trigger Tower with the new Simulated Data Program the selected RefSet Comparator with the new Threshold After modifying the selected trigger tower, add its current contribution to the partial and global quantities. Now Verify The output of this Tower's MUX at the 29525 The output of this CTFE's partial Energy Sums at the Tier #1 CAT2s The output of this Tower's Comparator at the CHTCR L1 Cal Trig Output Module This is an initial support and test for the CTOM card which will form the "Quadrant and Region Terms" and provide readout for Cal Trig. cf. ctom_fpga_description.txt in http://www.pa.msu.edu/hep/d0/ftp/l1/framework/hardware/aonm/ The CTOM card in slot 14 of M101-middle is initialized at every L1CT initialization according to the OR-ing requirements listed in the above file. The CTOM Card is expected to have CTOM Fpgas in the lower 8 sites, and Miguel FPGAs in the upper 8 sites. CBus IO Command Files (also implemented in VME_Access V5.0.F) New keywords to read input operands and output of CAT2, CAT3, and FMLN cards cf. Syntax_Rules_CBus_IO.cio in http://www.pa.msu.edu/hep/d0/ftp/tcc/ ! Read_CAT2_Operand:(Operand Number of CAT2; Range: 0-7) ! Read_CAT3_Operand:(Operand Number of CAT3; Range: 0-5) ! Read_FMLN_Operand:(Operand Number of FMLN; Range: 0=Px 1=Py) ! Seek_CAT2_Output: (Hunt for CAT2 Output; still needs a dummy/unused value) ! Seek_CAT3_Output: (Hunt for CAT3 Output; still needs a dummy/unused value) ! Read_FMLN_Output: (Read FMLN comparator output) Note 1: determining the output of a CAT card requires using one of its output comparators to hunt down and zoom in on the output value. The original comparator programming is restored, BUT this could still cause some transient incorrect triggering if the resource is being used by L1CT. --> do not use during physics running. Note 2: The CAT (and FMLN) inputs are read 6 bits at a time, and this may cause some weird values offset (e.g. by 64) in some cases where the input value is not constant while Trics reads the 2 or 3 bitfields. [Usage: cf. series of Scratch\Dump_Tree_***.cio files to look at the adding and counting trees.] Master Command Files New Keyword "Serial_DAQ_Ctrl:" suitable for usage in Boot_Auxi.mcf cf. Syntax_Rules_Master_Command_Files.Mcf in http://www.pa.msu.edu/hep/d0/ftp/tcc/ ! Serial_DAQ_Ctrl: (Set Serial DAQ Control Method; allowed values are ! 0= Executing .TTI Remembers Values WITHOUT Programming DACs ! Init L1CT Will NOT Program DACs ! 1= Executing .TTI Remembers Values WITHOUT Programming DACs ! Init L1CT Programs DACs Using Remembered Values ! 2= Executing .TTI Remembers Values AND Program DACs ! Init L1CT Will NOT Program DACs ! 3= Executing .TTI Remembers Values AND Program DACs ! Init L1CT Programs DACs Using Remembered Values ! Reminder: The default behavior of Trics V10.5.A is #2 ) Internal For Refence Sets programming, move the location of where the translation is done from GeV to a Byte value. This was done in the CTFE Card Object and now is done in Rename CBusCardFmln to CBusCardFMLN for consistency. Change the usage of the dialog to select L1CT coverage. This dialog is shared between 3 different customers: The Lookup PROM Test, the CHTCR PROM Test, the L1CT Exercizer. The Dialog object now has one method to call for each usage type to prepare the look and range verification of the dialog before it is called. e.g. call CDlg_Select_L1CT_Coverage::SetChtcrPromTest() before calling the DoModal() method to display the dialog. ============================================================================== Trics V10.4 Rev K (24-NOV-2003) Initialization Change FOM++ initialization: The Support Fpga initialization (for this FW card only) enables the drivers for the global IO P5_IO(0:15). This is the path for the 8x TDM partial L2 Unbias Sample to get onto the FOM++ for final OR-ing. The value loaded in the "Direaction and Output Enable Register" is 0x0f10. Change TDM L2 Unbias Sample initialization The default value loaded at initialization is 0x007fffff instead of full scale 0x00ffffff. The initialization keeps this value to be permanently loaded by also leaving the Asynchronous Reload bit set. This should effectively disable the L2 Unbias Sample feature for each SpTrg. COOR Messages Change the minimum value allowed for the Unbias Sample Ratio from 1 to 0. Requesting a ratio value of zero is the official way for COOR to ask TCC to disable the L2 Unbias Smaple feature for a particular SpTrg. e.g. "L1FW_Spec_Trig 1 L2_Unbiased_Sample 0" will prevent SpTrg #1 from ever issuing a L2UBS flag (this only means SpTrg#1 cannot be the cause of the L2UBS flag, while some other SpTrg could still set this L1 Qualifier for a particular event where SpTrg #1 has also fired). Internal: Fix TDM Fpga register definitions: The L2 Unbias Sample Control register had its Read and Write Mask corrected to show the proper location of the Asynchronous Reload bit which is now the MSBit of the upper 16 bit register of this 32 bit register pair. ============================================================================== Trics V10.4 Rev J (02-OCT-2003) Initialization: Andor Input Term TRM Initialization: Restrict the range of which Andor Input Terms are initialized for Direct Input (as opposed to normal Fifo operation). This was reduced from the range 224:255 to 240:255. (Andor Terms 224:239 are now used for the Calorimeter Pulser Synchronization). ============================================================================== Trics V10.4 Rev I (24-JUL-2003) General: Enable and initialize (and expect presence of) P-Term resources in the Andor Input Term and Exposure Groups AONM. ============================================================================== Trics V10.4 Rev H (23-JUN-2003) General Fix bug in the utility to generate a String describing a Trigger Tower coverage. For example, running Find_DAC on |eta|=13:16 would generate a first line in the Find_DAC result file claiming the coverage was "eta(-16:+16)". This is now fixed and will show "eta(-16:-13 & +13:+16)". CHTCR PROM Test Switch the slice of the 29525 that is read for checking that the input tower was set/cleared. This now matches the previously advertised and is the oldest slice (it had mistakenly been the newest one prior to Rev H). This means that, by picking older time slices, Trics gets a chance to look a little closer to the time that the input Trigger Tower programming was changed. It takes Trics about 10 us to read the CHTCR input after changing the CTFE programming, while 8x time slices in the 29525's amount to 8x396ns=3 us. Trics will thus effectively look at the state captured ~7 us after the programming change instead of ~10 us. Changed the High Threshold from 100 GeV (255 counts for EM Et but only about 190 counts for Tot Et) to 200 GeV (255 counts for both EM ant Tot Et). The EM Et and Tot Et Low Threshold is still 0 GeV (7 counts). The EM and HD Et Trigger Tower Simulated value is still 128 counts. The CHTCR is still being very indulgent by leaving a wide margin for the CTFE comparators to properly set/clear a Trigger Tower. Future versions of the CHTCR Test could reduce this margin to a minimum and thus further probe the CTFE card at the same time. The CHTCR test could for example allow the operator to specify an arbitrary simulated value and use comparator thresholds right above and below the specified value. Added an explicit message about giving up if/after 10 errors are found on a single PROM. Also reset the TT inputs in case of error, so that the next PROM has a fair chance of passing its test. Added an additional end error message in case of failure to repeat and make easily visible the CHTCR Trigger tower Coordinates. Missing Et Fix the logic (that was already trying but missed) to skip re-specifying the output data when it hasn't changed (which is 254 times out of 255) while programming the FMLN memory lookup. This will shave off about a third of the programming time, without helping with the verification time. Programming the FMLN will thus take about 2.8 s instead of 3.6 s. Fix a coding weakness which had zero actual impact for several reasons, but could eventually have become a problem in the future. Now always force the data to be re-specified for the first write IO of each of the 4x programming segments (each segment includes verifying the intermediate address generator state). This weakness could only have caused trouble if some other thread (e.g. the monitoring service) would write a different data value elsewhere in between segments, and this would have always been caught by the verification phase following each programming phase. Find_DAC (This applies to VME_Access V5.0 Rev D) Add a progress status bar for Find_DAC. Suppress the flood of messages to the screen reporting each histogram built by Find_DAC. This information is available in the .HST file. Find_DAC now shows only one line per Trigger Tower (asuming there was no error) with the chosen DAC value, the standard deviation, etc. Every time Find_DAC changes the programming of a pedestal DAC, Trics explicitely waits a certain amount of time for the filtered DAC output to settle down. The amount of time necessary was estimated at 2 ms. The NT scheduler however by default doesn't know how to wait 2 ms, and instead always rounds it up to 10 ms. Add a call to timeBeginPeriod( ) right before and to timeEndPeriod() right after each run of Find_DAC. This function specifies as argument a minimum timer resolution, in milliseconds, for the calling application. Calling it with an argument value of 2 indeed reduces the observed waiting time down to the expected value. cf. IO_timing.txt timeBeginPeriod() is defined in and requires Winmm.lib. The current timing breakdown for running Find_DAC is the following: Processing one Channel (EM or HD) involves changing the Pedestal Control value 31 times (Max, Min, Med, Low, 26*Near, Selected) with a CBus Serial Command programming time of ~1 ms (for a total of ~31 ms). Changing the Pedestal Control includes an implicit 2 ms settling wait time (for a total of 62 ms wait time). Processing one Channel involves building 2x 10-point histograms (Max, Min) and 28x 1k-point histograms (Med, Low, 26*Near). The time per histogram is a function of the requested spacing between samples. e.g. Option #0 takes ~2.3 ms without Read/Write Pipe A/B control (for a total of ~65 ms) or Option #2 takes ~11.2 s when skipping every other 396ns sample per pipeful captured (for a total of ~314 ms). For example Option #2, used to take 31+310+314 or ~0.66 s per TT Channel, and it will now take 31+62+314 or ~0.41 s per TT Channel which should translate to about 14 mn for running Find_DAC on eta (-16:16). A future version of Find_DAC could allow the operator to specify the size of the histogram and thus control how long Find_DAC spends on each Trigger Tower. L1CT diagnostics tools Tune the estimation that Trics shows of how long each test is going to take as a function of the coverage and the histogram size. VME_Access (and same thing for L2RS) After relinking VME_Access (with no error), the executable would crash when trying to launching the Find_DAC dialog with some complaint about some resource ID not existing. There was however no clear coding problem. This had to be a confusion caused by VME_Access using Trics's code for this (like most other) dialog. This type of issue had been encountered before, and not truely cured, but more like avoided and only half-understood. Finally understand how to correctly share the Trics code for the common dialog menus. Some dialogs are in the trics directory (/src), some are in the VME_Access directory (/VME_Access) and will thus pick up a different instance of stdafx.h which is ok. A confusion in resource.h (this is the numerical IDs of the various controls) is however the source of the problem. Visual Studio generates separate files for each project, and each source file should be compiled with the project's personal version of this file. The solution is to place the inclusion of resource.h in stdafx.h, and remove it from everywhere else (including its default place in Trics_II.h and VME_Access.h). The VME_Access instance of stdafx can directly include resource.h. The Trics instance of stdafx.h needs to use a pre-processor #if-else structure to pick the right file depending on the existence of the pre-processor definition TAILOR_VME_ACCESS. This is all done in one place and any Trics code included in the VME_Access project will thus automatically pick up the same/correct version of resource.h. At the same time, and in the same manner, stdafx.h is a clean place to define the code version number by including Trics_Version.h, or VME_Access_version.h ============================================================================== Trics V10.4 Rev G (12-JUN-2003) General Trics now starts up with a default L1CT coverage of eta (-16:16). This used to be (-12:12). CHTCR PROM Test Fix the card addresses of the CHTCR's at phi(9:16) and (25:32). This was a global problem, but the CHTCR PROM test was the only evidence of this global problem as this card has no writable register. ============================================================================== Trics V10.4 Rev F (11-JUN-2003) CHTCR PROM Test Fix the computed operand number of the CHTCR output into the Tier#2 CAT2. The order is the same as the EM and HD CAT2 cards described in tier_2_operand_usage_full_system.txt from www.pa.msu.edu/hep/d0/ftp/run1/l1/caltrig/cards/ Return CTFE Trigger Tower comparator outputs to zero at the end of the test. Note that the Trigger Towers are still left in simulated mode at 128 counts. Internal Added a method to the CAT2 object to hunt for its output value using a comparator threshold and watching the available output comparator states (.NE.,.GT.,.LT.). The method tunes the comparator's threshold by dichotomy until it matches the output value. This method was written to help with reading the CHTCR output, but is not currently used. ============================================================================== Trics V10.4 Rev E (11-JUN-2003) CHTCR PROM Test Add informational message to advertize which Tier#2 CAT2 input this CHTCR output is connected to. CTFE PROM Test Fix bug introduced in Rev D that was preventing the poper initialization of the neighboring towers on the CTFE holding the Trigger Tower being tested. The test was initializing the targeted tower multiple times, instead of reaching out to the neighboring towers. ============================================================================== Trics V10.4 Rev D (10-JUN-2003) General Switch to ITC v02-25-01 (from v02-20-00) Missing Pt Fix mask for checking address counter to be 18 bit wide = 0x3ffff Check PROMs Dialog This dialog gives access to test software for checking - CTFE Energy Lookup PROMs - and CHTCR Tower Counting PROMs This dialog is accessible - via the button "Check PROM in situ..." in the "TrgTwr PROM Lookup" dialog - via the "Check PROMs..." button in the "L1 Cal Trig Test" dialog. This dialog only has two buttons to test (1) CTFE PROMs or (2) CHTCR PROMs. Clicking on either button will pull up another sub-dialog to select the desired test coverage. For CTFE PROM test, the user can select - Positive Eta, Negative Eta, or both - A Lower and Upper Eta Magnitude (1:20) with granularity of 1 - A Lower and Upper Phi (1:32) with granularity of 1 - Any combination of EM, HD, Px, or Py PROM For CHTCR PROM test, the user can select - Positive Eta, Negative Eta, or both - A Lower and Upper Eta Magnitude (1:20) with granularity of 4 - A Lower and Upper Phi (1:32) with granularity of 8 - Any combination of EM, or Tot Et Ref Set type - A Lower and Upper Ref Set Number (0:3) with granularity of 1 (note: Trics will guarantee that Eta-Phi granularity matches an integral number of CHTCR cards) Testing CHTCR PROMs is done one RefSet Channel at a time. Each CHTCR Channel includes two layers of PROMs. There are three PROMs in the first pass layer with 11,11, and 10 address line inputs each. There is one PROM in the second pass layer that receives the 4 data outputs of each first layer PROM. The mapping of which input Trigger Tower goes to which PROM address line was dictated by circuit board trace layout, and is thus in no logical order. For each CHTCR Channel the test first tries to zero all the inputs to all the PROMs by setting all corresponding input Trigger Towers to a simulated energy of 128 counts, and setting all TT Tresholds (EM, HD veto, Tot) to full scale for this channel. Then it verifies at the CHTCR input that it finds each tower input bit set to zero, and it verifies the CAT2 operand at Tier#2 is zero for the output of that card for this counting channel. When checking the CHTCR 29525 input registers, Trics uses the newest time slice. As the data should be stable, Trics does NOT control the Read/Write A/B pipes during this test. If this initialization step fails, the test is aborted. For each CHTCR Channel, the test first goes through each of the three first layer PROMs and scans the 2**11 (or 2**10) address space. Instead of going through this address space in decimal order, it uses a gray code type of sequence so that Trics only has to modify the programming of one input tower at each step. This gray code sequence saves almost a factor 2 in IOs to program the input trigger towers (but much less overall). For every new prom address, Trics verifies that the CHTCR input reflects the new Trigger Tower setting, and that the CHTCR output (at the next CAT2) shows the proper tower count. If this first layer PROM test fails, the test is aborted. For each CHTCR Channel, the test goes through a reduced address space of the second layer PROM. This PROM receives 4 bits from each first layer PROM, but each 4-bit input only goes from 0 to 11 (or 10). Instead of going through this address space in decimal order, it uses a generalized gray code type of sequence so that Trics only has to modify the programming of one input tower at each step. This is a gray code in base 12 where each of the 3 input digits is incremented or decremented from 0 to 11 by adding or removing the contribution of one input trigger tower. For every new prom address, Trics verifies that the CHTCR output (at the next CAT2) shows the proper tower count. L1CT Diagnostics Tools Add three new diagnostics tools available in the "L1Cal Trig Test" Dialog. - "List TT above RSs" = List Trigger Towers above each Reference Set - "List Hot TT (RS#0)" = List Hot Trigger Towers above Reference Set #0 - "Check Pedestals" = Check Trigger Tower Pedestals All 3 tools scan all Trigger Towers in the currently defined L1CT coverage. The operator can limit the test tools to a specific coverage by changing the L1CT coverage from the Control/Status menu. "List TT above RSs" ----------------- The main focus of this test is to detect broken CTFE comparator output PALs. This test scans all 4x EM and 4x Tot Reference Sets and reads the state of each Trigger Tower Reference Set State at the input of the CHTCR. The opeartor should program the EM Reference Sets before starting the test, as this test tool does NOT touch the reference set programming. The Reference Sets values should not be chosen too low to avoid false positives. Note also that this test does NOT take Trigger towers out of Excluded state. This test does not control the Read/Write A/B Pipe Timing Signals. This test is non-destructive. The operator has one external parameter accessible named "Max Tries". The default value is "1". Entering a larger number means that Trics will give the Trigger Tower that many chances to be found below threshold before it is reported. If there were a lot of noise in the system, the user could choose to enter a number e.g. "3" and Trics will only report a Trigger Tower after it has been found 3 times in a row above threshold, and Trics would not report any tower as soon as it has been found at least once below threshold. Each Trigger Tower found above any Reference Set will be reported. e.g.: E$ TT Comparator found Asserted at TT(+ 3, 4) EM Et RefSet #1 "List Hot TT (RS#0)" ------------------ The main focus of this test is to try and catch Hot Trigger Towers where the Calorimeter and the BLS cards report erroneous energy deposits, even when there is no beam in the machine. The operator has two check boxes available to direct the test to start looking for towers above EM Et Reference Set #0, or Tot Et Reference Set #0, or both. The user should program the EM and/or Tot Et Reference Set #0 before starting the test, as this test tool does NOT touch the reference set programming. Note also that this test does NOT take Trigger towers out of Excluded state. This test does not control the Read/Write A/B Pipe Timing Signals. This test is non-destructive. The user selects a sample size and the test tool will read that many times each CHTCR input register. The default value is "1000". Note that 8 Trigger towers are being checked at a time, as each CHTCR input register is 8 bit wide. Each Trigger Tower found at least once above RefSet #0 will be reported. e.g.: E$TT(+ 1, 8) was 57 time(s) above EM Et RefSet #0 "Check Pedestals" --------------- The main focus of this test is to verify that the set of Pedestal Control values currently loaded is still apropriate. The operator selects a histogram size and the test tool will read that many times the Trigger Tower EM and HD ADC output, or simulated value, if the tower was previously set in simulation mode. The default Histogram size is "1000" points. This test does NOT take towers out of excluded state. This test does not change the programming of any L1CT resources, specifically it does not touch the programming of the serial DACs. This test does not control the Read/Write A/B Pipe Timing Signals. This test is non-destructive. Several separate tests are made on each collected histogram: - The operator selects a tolerance "Ped Drift" and the test tool will report any TT whose histogram average has departed any further (.GE.) than the specified value, away from the operational value of 8 counts, and in either direction. The default value for "Ped Drift" is "0.5" Each Trigger Tower found with an average further from 8 than specified will be reported in red. e.g.: E$ TT ADC Average is 9.00 for EM_TT(+ 3, 4) - The operator selects "StDev Low" tolerance and the test tool will report any TT whose histogram Standard Deviation is LOWER (.LE.) than the specified value The default value for "StDev Low" is "0.1" Each Trigger Tower found with a Standard Dev lower than the specified value will be reported in bright white. e.g.: W$ TT ADC StdDev found Low 0.00 for EM_TT(+ 3, 4) - The operator selects a "StDev Ratio" tolerance and the test tool will report any TT whose ratio of measured histogram Standard Deviation over expected Standard deviation is GREATER (.GE.) than the specified value. For this feature to be meaningful, the operator must have previously loaded from Trics the TTI file that Find_DAC had created and which corresponds to the set of pedestal control values currently loaded. There is an internal check to only enable this ratio test if the TT's expected Standard Deviation is greater than 0.1, which will effectively turn off this component of the test until a Find_DAC TTI file has been loaded which describes the TT being tested. The default value for "StDev Ratio" is "1.5", meaning that the test will list towers where the measured noise is 50% more than what Find_DAC had measured. Each Trigger Tower found with a Standard Deviation above the specified ratio will be reported in bright white. e.g.: W$ TT ADC StdDev is 2.00 but expected 1.08 for HD_TT(- 5, 6) - The operator selects a "Tail Thresh" tolerance and the test tool will report any TT whose histogram has entries ABOVE (.GE.) this specified value. The default value for "Tail Thresh" is "17" ADC counts, meaning that the test will list towers with any histogram entry at or above 2GeV. Each Trigger Tower found with at least one entry above the specified threhsold will be reported in red. e.g.: E$ TT ADC count found 2 time(s) above 17 for EM_TT(+ 6,23) L1 Qualifiers Trics limits the index of L1 Qualifier specified by COOR to be 0:15 Trics automatically and internally copies the programming of the lower set of L1 Qualifiers (0:15) to the upper set (16:31). The rest of the code thinks there are still 32 L1 Qualifiers. This is thus easy to undo if we ever present to have two explicitely separate subsets of 16 L1 Qualifiers. Pseudo Terms Programming Implement pseudo-term programming. This feature is NOT turned on in this revision. One has to define the pre-processor switch "PTERMS_AVAILABLE" in GlobalConstants.h to enable this feature. When Trics is changed to actually program PseudoTerms, Trics will expect all 4x L1 input AONM cards, and the 2x L1 Exposure Group AONM cards to be populated with AONM FPGAs that implement the additional 3 registers for P-Term programming. (Remember that the EG AONM also has some Miguel Fpgas). The Pseudo Term programming is available for Specific Trigger requirements and for Exposure Group requirements. cf. pseudo_term_functionality.txt in http://www.pa.msu.edu/hep/d0/ftp/l1/framework/andor_terms/ The programming of P-Terms is not yet served by the monitoring server in the L1_Tcc_Fw_Spec_Trig_Full section of L1_Tcc_Block_Fw_Info_Full as it would change the block format. This information is thus not available in the TrigMon page with the details of a Specific Trigger. Only the Hardware And-Or Term programming is displayed at the moment. I believe only Trigmon collects this block type, and changing the format will not require synchronization with other customers. System Control/Status Dialog Remove the "Release Heap Memory" button. Add a new "Log Monitoring Requests" check box to the Monitoring Service area. When/While this option is selected Trics will write which calling program requests what monitoring data block. Trics also logs when it pushes data to the Luminosity Server. This is in an effort to understand (1) how much the monitoring services are actually used, (2) by what applications, (3) which block types are being requested. Luminosity Service Whenever Trics notices that it can't get rid of a "Full Luminosity Block" it dumps this 25 kB block to a local file in raw binary format. Only blocks that can't be delivered to the Luminosity server are dumped. A new file is created only when needed, named like this template D0_Log\Luminosity_Recovery_Vn_m_x_yyymmdd.dat;p. This feature is automatically, and always enabled at the moment. A Control/Status Switch to disable this feature may be added in the future. Copy/Modify one of the old toy trigmon applications code to open such a raw file and start a server port. When a client connects to this port, this new LumRecover helper application will start reading one "Full Luminosity Block" at a time, at 1 Hz, and push them out to the client until the end of the raw data file. This is a failover emergency service to salvage good beam time when the Luminosity Server loses communication to TCC. One hour of beam was lost this way when the network connection to MCH1 was lost on 13-May-2003. Michael Begel first suggested for Trics to keep a circular buffer of old luminosity blocks, but dumping them to a file is much simpler and less restrictive. L2 Unbias Sample Move the Reset bit to the Most Significant Bit of upper control register. Internal To implement P-Terms, we added a method to add the P-Term programming registers as needed. L1fw.cpp calls this method only for the cards that need it. We also added a method to add P-Term programming, separately from the normal AO Term programming. This is in the Pre-Programming step, where Trics builds itself a memory content of what needs to be written to the AONM/FOM card. MessageCoorExecuter.cpp calls this additional method when needed. The code to actually write the AONM/FOM programming automatically adds the P-Term programming only when it notices that the P-Term registers are defined for this FPGA. Try to accentuate in the code the differentiation between the two separate dimensions of Reference Set Types: The comparators at the TT level (EM/HD/Tot) vs. the Reference Set Counting Trees (EM/Tot). Some resources are in one space while other resources use the other space. Rename the enumarated type describing the TT level comparator types from "ETT_Ref_Type" to "ETT_RefCmp_Type" with values like "eTT_RefCmp_EMEt, eTT_RefCmp_HDVeto, and eTT_RefCmp_TotEt". The counting level was unchanged at "ETT_RefSet_Type" with values as "eTT_RefSet_EMEt, and eTT_RefSet_TotEt". ============================================================================== Trics V10.4 Rev C (20-May-2003) Missing Pt While Programming or verifying FMLN content, Trics checks the automatically generated PROM address 4 times during the programming/verifying cycle. Rev B had systematic problems where the automatically generated address was getting ahead of the expected value during verifying cycles only. This was traced to un-intended increment of the on-board counter when set to increment on read cycles. The method suggested in the FMLN documentation is to pulse the direction bit to increment the counter. This method however is not compatible with reading a different CBUS address (e.g. to check the counter, or monitoring) in the middle of the address scan. Reading some other register would generate additional increments every time the FA of the output register is de-selected (FA=4). The method had been changed to de-select/re-select the function address (by selecting FA=0 in between) when Trics wants to explicitely increment the counter. The last time Trics checks the address, the 18-bit counter has just rolled over and the expected address no longer matches the actual value read from the registers. Trics thus needs to take this into account by also masking its expactation value down to only 18bits worth of information. There however was a typo, and Rev C used too big of a mask. Check PROMs Dialog Work on CHTCR PROM test, but see next Rev for details. Internal Add new CBusCardCHTCR object. This card only has rgisters to read back the inputs made of TT above threshold. These are 29529 registers. This object also holds the code to test the CHTCR PROMs. Add Card address support routines for the CHTCR cards. L1Ct now includes a set of CBusCardCHTCR objects. They receive a call to their "initialize" method, which does aboslutely nothing at the moment as the CHTCR only have read-only registers. The L1Ct object no longer directly calls the CBusCardCtfe object to set a reference set or exclude a trigger tower. Both of these methods now go through a new method of L1Ct_TrgTwr. Note that L1Ct_TrgTwr already held a pointer to its mother Ctfe card, which simplifies things. The real motivation was that the CHTCR prom test could more easily access these methods from the Trigger Tower object pointers. Change CBusCardBase to write the variables that hold the base Eta and Phi of each CBus card. This is used by the CHTCR card object to build itself an array of relative Trigger Tower Inputs, and find its output in the Tier#2 CAT2 operand. Rename global constant KiCtfeTotEtaPerCard in CBusCardCTFE.cpp and CBusCtfeDac.cpp with new name KiTotEtaPerCtfeCell and add constant KiTotPhiPerCtfeCell. In CBusReg29525 add a method to return a string with the function address of a specified slice depth. ============================================================================== Trics V10.4 Rev B (8-May-2003) Missing Pt Fix address of FMLN which had incorrect Card Addres. COOR Initialize Notice and fix CAT2 initialization so that it doesn't abort in case of early error. CTFE Lookup PROM Check Move the CTFE Lookup PROM Check to a new "Check PROMs" sub-dialog. The button "Check PROM in situ..." in the "TrgTwr PROM Lookup" dialog now calls this new dialog. New Check PROMs Dialog This new dialog gives access to test software for checking - CTFE Energy Lookup PROMs - and CHTCR Tower Counting PROMs This dialog is accessible - via the button "Check PROM in situ..." in the "TrgTwr PROM Lookup" dialog - via the "Check PROMs..." button in the "L1 Cal Trig Test" dialog. This dialog only has two buttons to test (1) CTFE or (2) CHTCR PROMs. Only the previously existing CTFE Lookup PROM Test is implemented yet. Bit3 API access method Reading or writing VME data using the Bit3 API method was systematically making an additional call to verify the Bit3 status, even when the read or write request was successful. This check is now only done in case the call to Bit3 Read or Write has returned an error. This had no effect on Trics because Trics uses Memory Mapped IO. This will not have an effect on VME_Access because we have switched to Memory Mapped IO starting with V5.0 Older versions of VME_Access were affected, and for example Find_DAC was running twice slower than it could have been. Executing TTI files was also affected. Not much else was IO intensive. ============================================================================== Trics V10.4 Rev A (22-Apr-2003) Note: This version requires an FMLN in Tier#3, but does NOT require or initialize any Px/Py CAT Cards anywhere. L1 Cal Trig Initialization Add a new option for L1CT in the "System Control/Status" dialog. This option is a checkbox labeled "Abort Init On Error". The default value is to have this option checked, i.e. Trics will stop the intialization sequence when it encounters an error during L1CT initialization. When this option is cleared, Trics will continue initializing the L1CT even if one or more CBUS IO fails. Note that Trics will never hide the errors, and always report a failure as "Bad" in the acknowledgement to COOR. Also modify the CTFE card initialization to no longer bail out if the first CBUS IOs fail. Trics will now always continue through the whole CTFE card, and then abort initialization or continue with the next card depending on the new control option above. Also modify the CTFE Intialization to change the default value loaded in the board control register at function address 80. The initialzation value used to be 0x81, i.e. program the input multiplexer to Select Adc Data, and program the Test Data circuitry to use the value loaded in register 82. The new value is 0x99 which also sets the Serial Data Bit and the Serial Clock Low (after being inverted on the card). This initialization value makes more sense, and is the value that is left after writing any command to the Serial DAC. This will also prevent Find_DAC launched from VME_Access to confuse Trics the next time Trics looks at register 80. Also Add to the CTFE initialization a step to force the default programming of the Serial DAC but only when the "L1CT_Init Loads DACs" option is selected. This is to guarantee to regain control of the Serial DAC. This is still NOT the default mode of operation, i.e. Trics does not touch the Serial DACs when COOR asks for system initialization. Missing Et Implement programming of the FMLN cards to program threshold comparison of Missing Et. This was started as a port of the Run I Epascal code, but switched to a more straightforward, brute force, easier to get right, easier to debug approach. The FMLN card is initialized to a threshold of 0 GeV for all 8 comparators. Any time the FMLN card is initialized, or a comparator is programmed the programming of all 8 comparators is verified. This Revision does NOT initialize the Tier #3 CAT3 cards correction registers. We are just testing the ability to write and verify the FMLN RAM. All Comamnd Files Add new Keywords "Error_Tag:", "Warning_Tag:" and "Info_Tag:" accepted in all types of command file. This keyword must be followed by a string within double quotes. e.g. Error_Tag: "Pedestal Control Value Not Found for EM_TT(+ 1, 1)" When Trics executes a command file and encounters such keyword it will print the content of the associated string to the console screen. e.g. E$ Error_Tag: , at Line #304 "Error_Tag:" will generate an error line, in red. "Warning_Tag:" will generate a warning line, in bright white. "Info_Tag:" will generate an info line, in normal white. Find_DAC (and this applies to VME_Access V5.0.C) Fix inversion of the MTG bit2 Pal Control Register Read Mask vs Write mask. Find_DAC de-excludes all trigger towers on the mother CTFE card before starting and leaves all trigger towers NOT excluded when done. Control of Read/Write Pipe during Find_DAC: Implement user option to control the Read/Write Pipe to freeze each pipeful of 29525 data while reading histogram values from these stable snapshots. The user can select how many samples are kept from each pipeful. The most recent sample is always rejected, because switching of the write pipe by Trics is not synchronized with L1CT operation and the last sample may be corrupted. The user can elect to keep every crossing (Option #1), every other crossing (Option #2), or every third/fourth/fifth/sixth/seventh (Option #3/4/5/6/7). The histograming automatically adjusts the number of pipeful needed to collect the required number of samples per histogram. The legacy mode of not controlling the Read and Write Pipes corresponds to Option #0. In the Option #0 mode Trics keep both Read/Write pipes always aimed at Pipe_A. In all modes except option #0 Trics holds the Read_Pipe to Pipe_B, and keeps the Write_Pipe to Pipe_B only while filling the pipe with fresh information, and switches the Write_Pipe to Pipe_A while reading frozen data from Pipe_B. Option# Use Pipe Keep Tot Average Approx Time Keep Slice Number Per Pipe Time per per TT (EM&HD) Every 0 1 2 3 4 5 6 7 Pipe Switch Histo(1k) API/Mem Map 0 - - - - - - - - - - 130ms 7.8s No Pipe Control 1 . Y Y Y Y Y Y Y 7 143 360ms ~20s All slices 2 . Y . Y . Y . Y 4 250 490ms/21ms 29.5/1.2s Skip 1x 396ns 3 . Y . . Y . . Y 3 334 Skip 2 slices 4 . Y . . . Y . . 2 500 Skip 3 slices 5 . Y . . . . Y . 2 500 Skip 4 slices 6 . Y . . . . . Y 2 500 Skip 5 slices 7 . Y . . . . . . 1 1000 1 Slice per Pipe (Note: an un-necessary check for bit3 errors was included with each VME IO in the API access method, and the above numbers are probably 2x larger than they should/could be) Processing one Channel involves changing the Pedestal Control value 31 times (Max, Min, Med, Low, 26*Near, Selected) with a Serial Command time of 1 ms (for a total of 31 ms) and an internal 2 ms settling wait each time (for a desired total of 62 ms wait time), but the NT scheduler's resolution is 10ms (for an actual total wait time of 310 ms). Processing one Channel involves building 2x 10 point histograms (Max, Min) and 28x 1k point histograms (Med, Low, 26*Near). The time per histogram is a function of the requested spacing between samples. Add a sanity check while scanning through successive values of Pedestal control DAC and building histogram: verify that the average is no more than 2 counts away from the target zeresp. This is not a tight requirement, but it would detect a hard failure during the programming of the Serial DACs. Enter failures to find a satisfactory pedestal control values as an "Error_Tag:" line in the Find_DAC TTI result file. This file will thus be directly executable by Trics V10.4.A, or VME_Access V5.0.C or later versions. Executing a Find_DAC TTI result file will thus generate red error lines on the console screen unless the operator edits the file and decides to accept or modify the proposed control value. The operator can then add a comment flag "!" in front of "Error_Tag:" to remove the error message. Find_DAC leaves the Trigger Tower programmed with the selected control value when it is successful. Find_DAC programs the pedestal control DAC with the maximum control value in case of failure, which will produce a Zero Energy response of 0 counts, e.g. in TT_ADC_Trigmon. Change the value writen as "Ped_Deviation:" in the TTI Result file to be the average of standard deviation of the 26 histograms built by Find_DAC (instead of the standard deviation of the chosen histogram, which now appears in the comment at the end of the line). e.g. TT_Phi: 1 Pedestal_Control_DAC: 3522 Ped_Average: 8.00 Ped_Deviation: 0.99 ! EM_TT(+ 1, 1) Selected_Histo_Dev: 0.96 Loosen the requirement of the best histogram to only be within 0.15 ADC count of the target Zero Energy Response instead of the previous value of 0.1. Find_DAC Result Analysis Tools The Analysis of Find_DAC results now writes the total number of reported errors. Formatted L1 Cal Trig VBD dump Minor improvement: fix the line formatting of the columns of VRB words to avoid shifting of the rows. CBus IO Move the macro definitions to implement the elementary CBUS IO sub-steps (i.e. read/write to Ironics ports) from the CBusReg.cpp file to the CBusReg.h file to allow them to be used by derived classes, e.g. CBusReg29525. Add some macros, clean up, rename some macros for improved clarity. Add CCBusReg::f_okPulseBitsHigh/Low method to pulse high or low a specified set of bits in a given CBus Reg. Add a CCBusReg::f_okWriteStreamDitto method to the set of routines handling repeated writing to the same register. This one re-writes the same value as previously set up by just pulsing the Strobe line. This is used for programming the FMLN. Also improve the termination of stream writing by carefully removing the write direction, then de-selecting the MBA. Add CCBusReg::f_okReadStreamSetup, f_okReadStreamItem, and f_okReadStreamDone methods to handle repeated reads from the same address. Reading another item is done by briefly pulsing the direction from Write to read. This is used for programming the FMLN. Add a specialized CCBusReg29525::f_okHistogram method that is smarter than the base CCBusReg::f_okHistogram method. This method knows how to control the read and write pipes, and can pick only a specified subset of each captured pipeful. COOR messages Replace all instance of "L1CT" with "L1CAL" in acknowledgement msessages returned by Trics to COOR. Add a COOR-like message to force Trigger Towers to a simulated value other than the default Zeresp of 8 counts. Recall that the standard COOR command to exclude a Triggr Tower is: L1CT_Exclude HD_Tower TT_Eta(20) TT_Phi(23) Add a new message syntax to force a Trigger Tower to a simulated value other than 8. The simulated vlaue is specified as ADC counts (NOT in GeV): L1CT_Simu_ADC EM_Tower TT_Eta(20) TT_Phi(23) Value 8 L1CT_Simu_ADC HD_Tower TT_Eta(20) TT_Phi(23) Value 8 This should be helpful while commissioning Missing Et threshold programming via the FMLN cards. Both "L1CT_Exclude" and "L1CT_Simu_ADC" messages accept Trigger Tower Ranges. Added templates for "L1CT_Simu_ADC" msg in the "L1 Cal Trig Messages" Dialog. SCL Initialization Add a 0.1 second wait between the time Trics Pauses the L1FW, and the time Trics forces the L2FW helper FPGA to its reset state. This is to give L2 Global a chance to process the last few events. Luminosity Service Add a 0.1 second wait between the time Trics Pauses the L1FW, and the time Trics increments the LBN and captures a monitoring data snapshot to send luminosity information to the luminosity server. This is to give L2 Global a chance to process the last few events. Internal Change arguments to CbusCardCtfe::f_okExcludeTwr: Change the desired simulated value from an optional pointer to a required value. Programming the default Zeresp value of 8 counts is now controlled by the upper level calling functions. ============================================================================== Trics V10.3 Rev B (22-Jan-2003) Switch to ITC V02-20-00 System Control/Status Add two new check boxes to the "System Control/Status" Dialog. "TTI File Loads DACs" when checked/enabled/on allows Trics to write the specified Serial DAC values during the execution of the TTI files. When this box is cleared the values are only remembered for possible later usage. (We don't yet run DAC TTI files from Trics, so this is of little importance). Default = Unchecked/Off "L1CT_Init Loads DACs" when checked/enabled/on allows Trics to use the Pedestal and Gains control DAC values remembered *from a previous* execution of a DAC TTI command file to initialize all trigger towers in the current L1CT coverage during L1CT Initialization. When this box is cleared Trics doesn't touch the Serial DACs during initialization. (We don't yet load TTI files from boot_auxi, so we need to leave this feature turned Off). Default = Unchecked/Off COOR L1CT Reference Sets and TT_Eta 19 & 20 Reminder: When a Reference Set definition does not explicitely include a Trigger Tower Eta Range, Trics fills in with an implicit Eta Range corresponding to the currently instrumented L1CT coverage (specified via the System Control/Status Menu). New behavior: Trics will never implicitely include Trigger Tower Eta +/-19 and 20. Trics will still fill in with an implicit Eta Range, but will skip Eta 19&20. Reason: These Eta indices do not instrument standard Calorimeter coverage. They are used to instrument the Inter-Cryostat Detector (ICD) and the Massless Gap Regions (MG). These regions would not use the same Reference Set Threshold as the rest of the towers, and would need to be specified separately in any case. This new rule prevents these upper towers from making the definition of the lower towers more complicated and coverage-dependent. Usage: Uniform Reference Set Definitions targeting normal Calorimeter Trigger Tower coverage can/should continue to NOT specify an eta range, and this will implicitely define an eta range of TT_Eta(-12:+12) if the current L1CT coverage is set to |eta|=[1:12] or TT_Eta(-18:+18) if the current L1CT coverage is set to |eta|=[1:20] Backup of LBN number Change writing of latest LBN number from happening during a COOR "init" command to happening at every COOR "stop_run" command. The file created is still called LBN_At_Last_Init.lbn to avoid compatibility issues if we have to back out of this revision. Also change Trics to fail starting if the LBN_At_Last_Init.lbn file is not found at startup time: Trics will not create the ITC ports for COOR to send program information and start a run with incorrect LBN numbers. This will allow for a safer renaming of this file in a future revision. (e.g. rename this file LBN_Backup.lbn) Register IO menu and Register IO command file Remove extra "@ " in screen message output before register target address. Register IO *AND* CBUS IO Change the error detection logic such that detecting an error during the post-write check doesn't automatically cause an IO error UNLESS the second write with second post-write check also fails. We will continue having the pre- and post- write errors flagged and logged, but the IO will not be called a failure and the COOR message will not receive a "BAD" acknowledgement, unless the post-write check after the second-try write fails. Find_DAC (and this is also part of VME_Access V4.0, which is where we use it) Rework the search algorithm which was until now a simple port of Run I code. Find_DAC will now start with a sanity check of the pedestal DAC by first loading 0, then full scale and mid scale, and measuring the DAC to ADC ratio. It will then build a series of histograms around the target zeresp and pick the one with average closest to the target value. cf. VME_Access Release notes for details ============================================================================== Trics V10.3 Rev A (22-Jan-2003) New Random Prescaler The single shift register implemented in V10.2 is now replaced with 32x 48-step shift registers. The threshold calculation for a given prescaler value has not changed. The 32x shift registers are initialized with random values while checking that no shift register is initialized with all zeroes. This feature is still controlled by the RANDOM_PRESCALER pre-processor flag. The code for the old style 1-of-N prescaler is still there and would be used if one un-defines the RANDOM_PRESCALER pre-processor flag. CTFE Dac Programming Dialog (also applies to VME_Access) New switch "No Write to DACs" for manually executing TTI files. When selected this tells TRICS not to write to the serial DACs, but instead to only remember the values for later reference. The default is to not write to the DACs. Not yet, but in some future revision of TRICS the DACs will be initialized during the L1CT Initialization. Trigger Tower Info Command File (also applies to VME_Access) Added keywords "Ped_Average:" and "Ped_Deviation:" to read these values reported in the Find_DAC result files. This is later used to analyze and compare the Find_DAC result files. Trics will in fact record the latest value of these two quantities for each Trigger Tower as well as remember the previously given value to allow comparison. Trics also remembers the values of the gain and pedestal control DAC values given in TTI files. These values are not written to the serial DACs when the TTI file is executed, unless explicitely requested from the "CTFE Dac Programming" Dialog. Find_DAC Dialog (also applies to VME_Access) The result file used to write in comment fields the selected Pedestal Average and Standard Deviation. e.g. TT_Phi: 1 Pedestal_Control_DAC: 3710 ! EM_TT(+ 1, 1) Avr = 7.92 Dev = 1.21 It will now use explicit Keywords for these quantities e.g. TT_Phi: 1 Pedestal_Control_DAC: 3710 Ped_Average: 7.92 Ped_Deviation: 1.21 ! EM_TT(+ 1, 1) Add section at bottom of dialog to analyze previously parsed Find_DAC Pedestal Control DAC Result files. The ">> Scan over Range of TrgTwr defined above <<" button will analyze the Pedestal control DAC values over the Trigger Tower Range specified in the top part of the Dialog. Four different analysis tools can be applied independently. "Check Ped Ave within +/- X counts of Z.E.R." This checks that the pedestal average for the histogram selected by Find_DAC falls within the user given X counts of the Zero Energy Response. "Check Ped Std Dev within X % of eta average This checks that the Standard Deviation for the histogram selected by Find_DAC falls within X % of the computed average Standard deviation at this eta value for all the phi values included in the analyzed range. "Check Ped Std Dev within X % of Prev Measur" This checks that the Standard Deviation for the histogram selected by Find_DAC falls within X % of the previously given value. For this test to be meningful two TTI files must have been loaded and the values from the second file are compared to the values from the first file. "Check Ped Ctrl DAC within X of previous value" This checks that the pedestal average for the histogram selected by Find_DAC falls within X counts of the the previously given value. For this test to be meningful two TTI files must have been loaded and the values from the second file are compared to the values from the first file. AONM and FOM card programming Programming AONM and FOM FPGAs requires loading a memory lookup of the desired response for groups of input terms. This is very IO intensive. The worst case is during the deallocation of a Specific Trigger where Trics has to remove the Trigger programming from many places: 2 for L1 And-Or Fired AONM 16 for L1 Qualifier 128 x 3 for L1 Accept, L2 Acc, L2 Rej FOM 12 for FOM++ SpTrg Fired Strobe, Skip Next, Skip Next N 2 for L2 SpTrg Accept, Reject AONM ------ 416 x (8x(16+2)+4 IO per AONM/FOM channel) = 62k FW IO One VME access takes about 5 us, and one full FW write with pre- and post- write checks takes 3 times that much. This adds up to 1 second per SpTrg deallocated. Note that the bulk of the IOs are made to a register that was already declared "volatile" and thus not pre-write checked because these registers are in fact a window into a larger space controlled by a programmable base address. COOR started deallocating SpTrg by ranges, and deallocating N triggers would take N seconds. COOR would eventually give up and time out. This would percolate to subsequent taker actions and cause problems. Because Trigger IO has been rock solid, and we never had IO errors outside of power problems, we choose to drop the systematic post-write check (there already was no pre-write check) for the bulk of the IOs. We keep one full pre+post-write checked IO at the beginning of the stream of IOs to each FPGA in order to always be ready to clearly detect an un-configured FPGA. The net result is that the 1 second per SpTrg has become 0.5 second. This will keep us out of trouble. COOR will also be changed to limit the number of SpTrg deallocated in a single message. Remote Crate VMESYSRESET Figured out that the magical address to write to in order to reset the readout crates was computed incorrectly. This has been fixed, but the Vertical Interconnect in the L1FW readout crate has been COOR messages Fix the string returned with the acknowledgement to a COOR message like "L1FW_Spec_Trig -0 Force_L2Reject" from "" to "" Register IO Change the behavior so that detecting an error during the post-write check doesn't automatically cause an IO error UNLESS the second write with second post-write check also fails. This is actually insufficient, as we should also have removed setting the error flag when the pre-write check. The main intention was to help with L1CT IO errors caused by failing power supplies. However the CBUS IO is handled separately, and this hasn't yet been applied to the CBUS IO code. The plan is to continue having the pre- and post- write errors logged, but the IO would not be called a failure and the COOR message would not receive a "BAD" acknowledgement, until the post-write check after a second-try write fails. This will be finished in the next revision. VME_Access VME_Access didn't use to know anything beyond registers. To execute TTI files, it would just use the mapping of eta-phi into register coordinates. VME_Access would not remember anything that it had done. We now want to use VME_Access to analyze the Find_DAC result files. VME_Access will thus keep a mini version of the L1CT object with just the trigger tower objects. This will give it a place to store the DAC control values, etc. for analysis. ============================================================================== Trics V10.2 Rev B (2-Oct-2002) Switch to ITC v02-19-00 Random Prescaler The layer that executes the messages from COOR now will micro-pause around the action of changing the prescaler control value. COOR seems to disable the SpTriggers before changing the prescale values, when there are several SpTrgs in the run, but seems to directly change prescale values when there is only one SpTrg in the run. One could argue that even if there is a glitch which temporarily sets a very low prescale value for a specific trigger, the built-in mechanisms to skip next crossing, skip next N crossings, and L1 Busy should prevent a burst of L1 Accepts. In any case, it doesn't cost much to micro-pause (~10 us) data taking while changing the prescaler control value. Suppress the screen message showing the control value for a prescale ratio of 1, as it paints a lot of useless messages during COOR_init. Change the initialization of the random pattern for the prescaler from protecting against the value zero to protecting against the illegal value where all the bits are set. This is because an XNOR gate is used instead of an XOR gate to implement the maximum length shift register. Derive the correct formula for calculating comparator threshold. It needs to use 2^n while V10.2 Rev A was using 2^n-1 // "Prescale_Threshold" 4,294,967,296 // i.e. Comparator = 4,294,967,296 - ------------------ // Reference Value Desired Prescale Trigger Tower Info command files: While creating the L1CT PROM files, and in order to make sure the operator knew what was in the PROM TTI file, Trics would complain and bail out if the file tried to overwrite the definition for a page previously defined. Now that the files have been created, we can remove this paranoid test as it interferes with the ability to manually re-execute the boot_auxi file after startup. Remove the requirement that the Trigger Tower Info file only specify Trigger Towers currently in the coverage. Tower coordinates are now only checked against the full coverage TT_Eta (-20:20) and TT_Phi(1:32). This means we don't have to make special falvors of the L1CT PROM files for different L1CT coverages, this also means that we can program DAC values for towers outside of the official coverage. This will be even more useful when/if we start having the TTI files only define the values, and L1CT_init initialize only the Trigger Towers included in the current L1CT coverage. Initialization: Change default Time Zone Spread from 35 ticks to 37 ticks. We should still leave the explicit re-definition in boot_auxi.mcf, but this will now give the correct default in single chance test. The FOM++ Skip Next N resources has been changed from 4x 8-bit comparators controlled by 2x 16-bit registers to now 2x 16-bit comparators controlled via the same registers. The code itself did not have to be changed, only the comments were changed. Default programming of the L1&L2 Framework during Initialization is now to Obey the L2 Global. What needed to be changed: - the L2 Helper FPGA is initialized to obey L2 write 0x0000 (instead of 0x0001) at reg address 16 - the L2 TRM receiving the L2 Global Answer are in normal (FIFO) mode (instead of Simulation mode) - initialize the flag that remembers that L2 Global is not ignored New Message to specify L1CT Coverage Add new special TrgMgr (i.e. not used by COOR) message to set the current L1CT coverage. The keyword is "TrgMgr_L1CT_Coverage" and the coverage is specified with a syntax identical to reference sets. The Phi range may be skipped to mean full phi coverage. e.g. TrgMgr_L1CT_Coverage TT_Eta(-12:12) TT_Phi(1:32) TrgMgr_L1CT_Coverage TT_Eta(-20:20) From a Master Command file this looks like: ! Set Current L1CT eta coverage -12:+12 !------------------------------------------------------ ! Send_Msg_To_Self: "TrgMgr_L1CT_Coverage TT_Eta(-12:12)" L1CT PROM Check: Switch order of do-loops between eta and phi so that successive eta values (i.e. same CTFE card) are scanned before the next phi value is explored. Add a "Done with PROM Check" message when task is completed Add more code to ensure that the user does not enter a range of PROM pages. (Reminder: The current test does not scan nor select the test page, and the operator is expected to simply enter the current hardwired value). Repeat the PROM Page being tested when an error is encountered. ============================================================================== Trics V10.2 Rev A (25-Sep-2002) Handle the new pseudo-random prescaler - Initialize the pseudo-random number at coor_init with a random number and make sure it can't be zero. - Accept COOR messages of both types standard prescaler values and percentages - Display to the screen the comparator value computed for the requested prescaler value - When COOR says prescale by 1, the compator is loaded with 0 (which is not an illegal value) but the prescaler is also disabled anyway. The comparator output being used is ">" and the value "0" does not guarantee a - I noticed that prescale by 2 computes 0x80000000 wile prescaler by 50% comes up with 0x7fffffff (and I didn't forget to add 0.5 before truncating the floating point number) Shorten the message that shows L1 Accept rate and L1AL2 depth every 5 sec ============================================================================== Trics V10.1 Rev B (17-Sep-2002) General: Switch from ITC v02-18-01 to v02-18-03 Change the initial coverage from eta (-4:+4) to (-12:+12) Create a button on the main menu for the future L1CT test/exercizer. Initialization: No longer force the Serial DACs to their default state during initialization of the CTFE cards. (See release notes for Rev A) Trigger Tower Info Command Files (.TTI): Trics (like VME_Access) now immediately writes Serial DAC values when executing a .TTI file and encountering a keyword "Gain_Control_DAC:" or "Pedestal_Control_DAC:". (See release notes for Rev A) Lookup PROM Test: Add a "Select L1CT Test Coverage" pop-up dialog that appears after clicking on "Check PROM page in situ". The user can select the range of trigger tower coordinates and the types of PROMs that will be tested. This pop-up dialog box is pre-loaded with the coordinates already selected on the "Trigger Tower PROM Lookup" Dialog box to check just that one page of that one PROM. Clicking on the "Cancel" button in this pop-up dialog box aborts the test. Clicking on the "All Set" button will start the test. The "Are you sure you want to do this? Yes/No" box appears - before the test actually starts, - and after each PROM page tested if an error was detected before the next PROM is tested. This lets us bail out of a long test and (10**9 errror messages) in case of serious problem. Suppress the informational messages identifying the target CTFE and CAT card. ============================================================================== Trics V10.1 Rev A (05-Sep-2002) Note: This is not a good version to run at fermilab as it resets the serial DACs during initialize but does not restore them to a useful value. General: Switch from ITC v02-14-00 to v02-18-01 Add BOOT_AUXI step The file d0_Config\Boot_Auxi.mcf is automatically executed (only once) when TRICS starts up. Things meant to go in such a file: - The definition of this Time Zone Spread to setup Expo Group PBS - Global L1CT system included/excluded switch. - Coverage of L1CT currently instrumented. - Execute a TTI file of Trigger Tower Gain Control values. - Execute a TTI file of Trigger Tower Pedestal Control values. - Load a file of Trigger Tower PROM lookup coefficients. - The tick alignement setup of the Foreign PBS (but we will first need to change the meaning of the existing message from "do it now" to "remember the value for the next initialize") During the execution of command files, suppress the screen/log messages that were advertizing the definition of each command file symbol. Fix the Monitoring data reporting the number of L1 Awaiting L2 Decisions. The value read from the L1AL2 FPGA needed to be truncated to the lower 5 bits in order to mask off the upper bits reporting if the L1AL2 count exceed varios thresholds. Event Dump: Skip 1 longword of alignment in the SBC's emulation of the VBD readout buffer. This longword appears at the beginning of every VRB section. (this has been available in VME_Access for a while) Trigger Tower Info Command Files (.TTI): Rename .TTI file keywords "Gain_Control:" --> "Gain_Control_DAC:" "Pedestal_Control:" --> "Pedestal_Control_DAC:" Add new keyword ! Legacy_AFE: (Special Flag to specify that a Trigger Tower) ! (is using the Run I Legacy Analog Front End Circuitry.) ! (This property can be skipped for Run II hardware.) ! (0= Run II [default], 1= Run I hardware) The syntax doc file Syntax_Rules_TrgTwr_Info.Tti has been updated in http://www.pa.msu.edu/hep/d0/ftp/tcc/trics_ii/ Keep track and report separately how many of each resource were defined or programmed: - Pedestal Dac Control values - Gain Dac control values - Towers flagged as Legacy towers (we will probably not use this) - Prom Pages Update maximum allowed value for pedestal control DAC, 0xff -> 0xfff VME_Access is tailored to immediately write the Pedestal and Gain control values, while TRICS (in this version) is tailored to only remember this value, with no IO taking place. This will be changed in the next version to have Trics also immediately write the value. Run II Serial DAC: The new Serial DACs are cleared during CTFE card initialization by sending the "default" command to guarantee control after any communication issue. Note: This Zeroeing/Initialization of the Serial DAC was left by mistake as the initialization of the DACs with the proper Pedestal and Gain Control value during the initialization of the Trigger Towers that follows is actually commented out. This initial step of clearing the DACs should have been commented out too. The current idea is for Trics not to interact (yet, or ever) with the serial DACs during Initialization because it would take some two minutes. The operator needs to explicitely load the values via a .TTI file(s) using VME_Access or (a recent enough version of) Trics after every PowerUp. Upgrade the writing of the Serial Dac to acquire the CBus IO Lock and speed up writing the stream of serial bits by only changing the data and plusing the data strobe and thus avoiding a full CBus IO (i.e. skip setting up MBA, CA, FA, direction for every bit) Lookup PROM Test: Add a new test of a single page of a single Lookup PROM. This test is called via the previously un-implemented "Check PROM" button (renamed "Check PROM page in situ") of the "TrgTwr PROM Lookup" dialog. This test does not control the lookup PROM page (hardware not ready) and the operator must tell Trics which page is being used. Note: the Tier#1 CAT's are only being clocked for the first lookup, and the PROM test program can only see data from the first lookup (and we thus do not need to "lock down" on a fixed lookup page). Here are the steps: - PROM type, eta, phi, page all are read from dialog box - ask "are you sure" you want to mess up the L1CT - no page selection done in test, expect operator to have it set up - locate the CTFE card holding this prom - locate the nearest place we can read the contribution of this prom i.e. the EM, HD, Px or Py Tier #1 Cat2 card in the CTFE cell - force all trigger towers on this ctfe to use simulated data EM and HD ADC = 0 counts - compute the expected output of this prom and of the whole CTFE - read the observed ctfe sum as an operand of the cat2 card - compare the two and complain in case of discrepency (not fatal) - take the observed value and use that as the base contribution of the neighbor towers on the CTFE card - loop/ramp over the 256 input value of the PROM by writing the same number to the EM and HD simulated values (i.e. Momentum Proms also see same input). - read observed ctfe output=cat2 input - deduce the observed prom output - compute expected prom output - compute expected ctfe output - compare expected ctfe output to observed and complain, e.g.: PX Tier#1 CAT2 input xxx instead of yyy ==> expect PROM(6)->8 but seems ->6 - scan through all 256 values even in case of error Initialization: Add a new step that calls an initialization function for each Trigger Tower. This is done after the CTFE card initialization. This step currently does exactly nothing. This is where we thought we would load the Gain and Pedestal DACs, but this version of Trics does not load the DACs as it would take a minute or more. We instead rely on the operator loading the values once after power up and trust the serial DACs not to deprogram themselves, and Trics not to generate erratic CBus cycles that could mimic the complex programming sequence. Find_DAC: (these are additions to Trics that have been available for some time in VME_Access V3.1-H) Adapt the Run I Find_DAC search algorithm to be able to run on the Run II serial DAC hardware. The algorithm uses some hardcoded search ranges and systematically scans through the DAC control values until it decides that it just passed the optimal value. It first uses a reduced sample size of 10 entries per histogram, until decides that it is getting close and switches to collecting 1000 samples per histogram. There is a lot of room for improvement in speed, in initial sanity checks, and even in overall method. The ability to find_DAC values for legacy Run I hardware was retained but not tested. Separate the recording of the histogram from the recording of the DAC values found. The operator can ask to create two independent output files: - Enabling the check-box "For Results" will create a file with a name like D0_Log\Find_DAC_V3_1_G_20020524.tti;6 This is the file that VME_Access or Trics can ingest and execute. There will no longer be a line length issue when executing the file. There may still be some "Failed" lines that Trics/VME_Access are intentionnally supposed to choke on and wake up the operator. This TTI file will still include as end-of-line comments the values of the computed average and the standard deviations of the histogram selected for each trigger tower. - Enabling the check-box "For Histograms" will create a file with a name like D0_Log\Find_DAC_V3_1_G_20020524.hst;4 This is the (big) file that will have all the histograms. Internal: Modified the method to Exclude Trigger Tower (CCBusCardCTFE::f_okExcludeTwr) to accept a specific value to force the Trigger Tower to something else than the default 8 counts and remove the associated screen message. Add f_okReadOperand method to CCbusCardCAT2 to read the CAT2 input latches. Note these are 6-bit latched registers. New file: UtilsMisc.cpp, .h This file currently includes only the already existing TimeMilliSeconds Return the 64-bit number of milliseconds since midnight (00:00:00), January 1, 1970 (coordinated universal time). This is an extension of the 32-bit _ftime routine. In CCbusReg, added routines for writing a stream of bytes (while only 1 bit is used for Serial Dac): f_okWriteStreamSetup, f_okWriteStreamItem, f_okWriteStreamDone In CCbusCardCTFE rename member variable m_apoDac to m_apoLegacyDac The CDlg_IO_Ctfe_Dac and CDlg_IO_Prom_Lookup classes are declared dynamic so that we can use CObject::IsKindOf to differentiate Dlg_IO_Ctfe_Dac and Dlg_IO_Prom_Lookup from CommandFileTrigTwrInfo.cpp and correctly update the dialog box to show the coordinates while executing a .tti file. ============================================================================== Trics V10.0 Rev K (12-Jun-2002) Initialize all 8x Tier#3 CAT2 Counter Cards (4x for EM and Tot Et) Initialize the Tier#2 CAT2 Counter Cards corresponding to current Trigger Tower coverage only. ***NO LONGER*** initialize Tier#1 Energy and Momentum CAT2 Cards (so that these cards may be pulled out for the sake of reducing power load) Set the Trigger Tower Count Thresholds requested by COOR on the Tier#3 CAT2 Counter Cards. Fix for missing Geographic Section problem: DAQ shifters noticed that Geographic Sections would sometime be flagged as unused and thus not be displayed by Taka's DAQ monitoring program. The bug could would zap out *ALL* GeoSect above the first GeoSect in the L2_Data_Path, which is typically GS#32 when L2 is used. It would in practice not necessarily ZAP everybody above 32, given how COOR programs the system, but QUIT UPDATING everybody above 32. This means that after defining a L2_Data_Path including 32, and then specifying another Exposure Group with more (or less) GS than before, the flags in the monitoring data specifying which GeoSect are currently used would NOT get updated to match the new set of GeoSect. ============================================================================== Trics V10.0 Rev J (23-May-2002) Intialize the CTFE CSR to 0x81 instead of 0x01 This allows the data from the test data register to be used as simulated data into the multiplexer. ============================================================================== Trics V10.0 Rev I (18-Apr-2002) This is the version that was used to generate the L1CT Lookup PROMs but it was never used online Add sanity checks to make sure all PROM coefficients were assigned before writing the 5k files The TTI source file is on our web server, plus a zip file. The zip file contains four smaller zip files, one for each prom type, and a checksum file (for LaPaz). http://www.pa.msu.edu/hep/d0/ftp/l1/cal_trig/hardware/prog_dev/ctfe_lookup/ runii_l1ct_ctfe_proms_reva_18apr02.txt runii_l1ct_ctfe_proms_reva_18apr02.zip The PROM file names have already been truncated to the official 8-dot-3 naming convention. There is also a link to this directory nearby the "CTFE" link in http://www.pa.msu.edu/hep/d0/l1/cal_trig/index.html ============================================================================== Trics V10.0 Rev H (11-Apr-2002) 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 V9.5 Rev D (14-Dec-2001) Monitoring Data Bug Fixes: Fix Bug that was branding all the four new blocks as type "4" instead of their correct individual types. Fix (minor impact) the order of the L2 Helper scalers (6) Number of BX Spent Waiting in L2 BAD State (7) Number of BX Spent Waiting with L2 Busies ============================================================================== Trics V9.5 Rev C (12-Dec-2001) Monitoring Data Bug Fixes: Fix Typo that was sending zeroes in lieu of correct Exposure Group Number for each Specfic Trigger. This was affecting the old-style monitoring data too, since V9.5.A. Fix Typo that was sending the Prescaler Percentage in lieu of Ratio (and vice versa, with 32 bit ratio truncated into 8 bit percentage location). Monitoring Data Update: Name the 32 bit word formerly left "reserved" in the Geographic Section sub-structure of the new monitoring data to now hold the scaler out of the "L2 Reject" Geo Sect FOM card. Remember that this signal is actually set (and the conunter increments) whenever the Geo Sect is Rejected OR ACCEPTED, which makes it a good L2FW reference number to compute the Geo Sect L2 Accept/Reject percentages. ============================================================================== Trics V9.5 Rev B (7-Dec-2001) L2 Hardware Scalers Fix typo that was preventing L2 hardware scalers from being initialized to listen to their respective gate. 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. 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. Errors during setup of L2 hardware scalers during initialize will now be considered fatal Monitoring Data now being filled: Implement the time stamps for last Initialize and fill this information in monitoring data Implement the time stamps for last Configure and fill this information in monitoring data Reset the dedicated Tick and Turn scaler from FPGA #13 at every SCL Init. This scaler is served as monitoring data. Reset the dedicated Tick and Turn scaler from FPGA #12 at every LBN Increment. This scaler is served as monitoring data. Keep track of the total number of expo group total number of spec trig total number of allocated geo sect currently allocated and fill this information in the monitoring data. Keep track of which spec trig is "Force_L2Reject" and fill this information in the monitoring data Cosmetic rename of all monitoring data stuctures from Tcc_Block_*** to L1_Tcc_Block_*** (to better differentiate with what L2 Tcc will serve) Read the status concentrators for each geographic section and fill this information in the monitoring data. The SerialCommandLink class now knows (hardcoded) which set of crates are "non-readout" so that it can compute a binary "good/bad" summary to report in the monitoring information. Following http://www.pa.msu.edu/hep/d0/ftp/scl/crate_list.txt Trics will consider that a GeoSect is non-readout if its GS_number is <= 14, == 79, or >= 120) The file 000_l1tcc_monitoring_server.txt has been updated in http://www.pa.msu.edu/hep/d0/ftp/tcc/monitoring/ Monitoring Data definition changed: Add the count of Spec Trig Processed by L2 FW (ulL2fwProcessed) to the "Brief" version of the general monitoring data. This number is essential to compute an accurate L2 Reject percentage. Change the size of the geo sect status (uwStatusMask) in the monitoring data from 8 bits to 16 bits to match what is returned by the TSC. TCC computes a binary good/bad status and adds it in as the MSB A Geographic Section will be considered "good" if it is one of the non-readout crates (which may not even have a status cable) or if none of the following signals is found asserted - L1 Error - L2 Error - Init Ack - GS Sync Err - Cable Disconnected Add the programming of the L1 Qualifiers to the new "Full" block type 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. ============================================================================== Trics V9.5 Rev A (29-Nov-2001) 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: 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 Monitoring Server Upgrade: 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 V9.4 Rev A (07-Oct-2001) 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 V9.3 Rev A (13-Sep-2001) 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 V9.2 Rev L (22-Aug-2001) Force Monit Data Capture: 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%. SCL Initialize: 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. cf. hep/d0/ftp/tcc/trics_ii/scl_initialization_steps.txt on the web. 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. ============================================================================== Trics V9.2 Rev K (09-Aug-2001) 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. ============================================================================== Trics V9.2 Rev J (11-JUL-2001) CBus Write: 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. Find_DAC: don't still try to write the histogram to the non-existing file when the user said "no result file". That was the cause of the crashes in Rev I. don't abort the whole test when Find_DAC fails on one tower, instead now finish cycling through the other towers in the range. Find_DAC aborts looking for a particular tower if a CBUS IO fails and gives up if no maximum can be found within the search range. fixed truncation problem when user asks Find_DAC for a very small or very large target ZER. (but we have only been using ZER=8). explicitely close the Result File when a fatal error was encountered. (but we no longer stop on failure for one TT). fix so now can display details to the screen only (i.e. without result file). [The above fixes were part of VME_Access V2.2.B] System Control/Status Menu: The background is now Red, with Yellow text, and new gun logo. Confirm Yes/No Pop-Up Dialog: Change Icon from a question mark to a Guillotine. 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. COOR-like message: 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. Internal: 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. ============================================================================== Trics V9.2 Rev I (30-MAY-2001) 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) System Control/Status Dialog: 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. Master Command Files: 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). 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. COOR Messages: Remove the non-applicable "GeV" in the screen line advertizing the reception of a COOR message regarding programming the global count threshold of the towers above a reference set. L1 Cal Trig Initialization: Bail out when there are IO problems initializing the Cal Trig. Abort early into the first card being initialized e.g. when power is off in L1CT. 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". 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. Send Message Command File (and Master Command Files): 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:"). 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. Internal: 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. Separate Programs: 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). Other work: Continue work on the L2RS (L2 Relay Software) application. 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 V9.2 Rev H (27-APR-2001) L1 Cal Trig: 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). 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. Suppress all informational messages displaying the Referense Set Thresholds applied to each Trigger Tower. Trics will now answer "Bad" to COOR when a reference set is specified that overflows the existing Trigger Tower Coverage. Initialize: Initialize the new Tier#1 and Tier#2 CAT2 cards (cf. above) by writing Zero to the Correction register (via the 6-bit fields) and Zero in all Comparator Registers (via the 6-bit fields). Writing Zero in the correction registers allows the CAT2 LED display to properly present the total count of the Card. Writing Zero in the comparator registers means that the comparator output is guaranteed HIGH after initialization, since the comparison is inclusive. Only the Tier#1 and #2 CAT2 Cards that belong to the currently defined Trigger Tower Coverage are initialized. COOR Messages: 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. Monitoring and Luminosity Services: 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. ============================================================================== Trics V9.2 Rev G (26-APR-2001) CBUS IO: 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. ============================================================================== Trics V9.2 Rev F (26-APR-2001) L1 Cal Trig: Start implementing a CBusCAT2 class to be able to set correction and comparator registers. The Card objects are being created, the register objects are being created, but no other code is currently executed (no initialization and no CBUS IO) at the moment. COOR Messages: 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). 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. 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. 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. ============================================================================== Trics V9.2 Rev E (25-APR-2001) L1 Cal Trig: Fix typo in the CTFE card object that was giving the same address to the HD DAC channels as to the EM DAC channels. Fix the CTFE initialization so that it clears all the "register modified flags" so that the first writes to the registers during initialization will skip the pre-write data check (while still doing post-write data check). Add zeroeing of the DAC registers during CTFE initialization. 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. 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. Initialize: 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. 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 (only CTFE 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. http://www.pa.msu.edu/hep/d0/ftp/tcc/trics_ii/trics_ii_initialization.txt will be updated. 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. www.pa.msu.edu/hep/d0/ftp/tcc/trics_ii/syntax_rules_master_command_files.mcf has been updated. 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. Luminosity Block Number: Fix the LBN Command file handling routine so that it properly counts the number of LBN values read (it was always saying zero). This is only of cosmetic importance, since this is not how Trics can tell that a value had been read. Internal: 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. ============================================================================== Trics V9.2 Rev D (20-APR-2001) 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). L1 Cal Trig: Trics now wakes up thinking that the L1 CT is to be ignored until told otherwise via the "System Control/Status" sub-menu. Add a call to a new file "D0_Config\Init_Post_Auxi_L1CT.mcf" at the end of the initialization of L1CT. Note that L1CT is not initiliazed, and this auxi file not executed when the L1CT is flagged to be "ignored". Internal: 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. Separate programs: 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. 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 Luminosity Test Client to display the new Run Number and Specific Trigger Mask data being sent. ============================================================================== Trics V9.2 Rev C (5-APR-2001) 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). Initialize: 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". ============================================================================== Trics V9.2 Rev B (9-MAR-2001) General: Include the update of V9.1 Rev I (i.e. VRB Slot #8 moved to SLot #19). and update http://www.pa.msu.edu/hep/d0/ftp/l1/framework/hsro/ summary_of_fw_data_readout.txt 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. ============================================================================== Trics V9.2 Rev A (1-MAR-2001) (Now 80k lines of source code in 336 files) Important: V9.2 Rev A does NOT have the update of V9.1 Rev I (VRB Slot #8->19) General: 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. Calorimeter Trigger: There is a new L1ct object that will include all the L1CT Cards and manipulation functions. At the moment it only 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. 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. System Control/Status Dialog: 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. 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. Monitoring: 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. 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. 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. cf. http://www.pa.msu.edu/hep/d0/ftp/tcc/trics_ii/trics_support_programs.txt for details. ============================================================================== Trics V9.1 Rev I (7-MAR-2001) HSRO Crate Initialization The VRB+VTM card that was in Slot #8 (now empty) has moved to Slot #19 (previously empty). 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 will track along. The Data Block Format Version.Revision has been updated. The revision number has been incremented. It is now 1.1. This change is NOT expected to confuse L3 ScriptRunner when it tries to retrieve the SpTrg Fired Mask, LBN, and L1 Accept Number. ============================================================================== Trics V9.1 Rev H (1-FEB-2001) 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 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). CBus Random Register Test: This is a new sub-menu to implement for CBus Registers the same functionality available in the existing THE-Card Random Register Test. This functionality can/will be merged into the VME_Access program, but at the moment it is only available as part of TRICS. There is a new sub-menu called "Rand CBus Reg 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 Serial Programming of CTFE DAC: Outputing trace message showing every IO while writing out the serial command now has switch on the sub-menu to turn this feature on/off. Change the code to use Pre-Processor Macros, and implement the Set Gain, and Set Zer for all EM and HD Channels #1-4. Fix the spinner buttons to increment/decrement the Card Address fields. Internal: Added the keyword "To_Cbus_FA:" to support CBus Register Range Command Files. ============================================================================== Trics V9.1 Rev G (25-JAN-2001) Monit Data Pool and Luminosity Block Management: Change the scalers used to update the L2Accept Field of the Luminosity Data Block Full to come from the L2 Accept AONMs (was the L2 Answer TRM). This will solve the problem where the L2 Accept Scalers were recording the global L2 Accept Rate instead of the individual per Spec Trig rate because we are in L2 Bypass Mode. Split the internal buffering for the Luminosity Block Full and Brief: Trics was maintaining only one block of type Full and was handling the Block Brief as a truncated version of the Block Full. This was all fine for normal Luminosity Server business. But Trics also serves the last instance of the Luminosity Block Full and Block Brief over the regular Monitoring Data Server. Using only one buffer meant sending Full Blocks where the part corresponding to the Brief Block was often more recent than the rest of the block. Now there are two separate buffers, and there is no more confusion about what fraction of the data was captured when. Suppress the "Could Not Deliver Luminosity Data (Brief)" message (every 5 sec when no client is connected), but Trics continues to display the "Could Not Deliver Luminosity Data (Full)" message (every 60 sec). Serial Programming of CTFE DAC: Add trace message showing every IO while writing out the serial command. There will later be a switch to turn this feature on/off. Fix the address of the CTFE Board CSR from 80(hex) to 80(dec). Implement the "Reset Whole Card (=Set Default)" action. ITC Server: Increase timeout value on send to 5 sec. Separate programs: Update the Luminosity Client Test Program to display the rest of the information in the luminosity blocks for all Spec Trig currently defined. Also add the option to connect to the Monit Data Port instead of the Luminosity Server Port so that it can be used without interfering with the official Luminosity client. Also add the option of automatically asking for a luminosity block at specified intervals. Increase timeouts of all test client programs to 30 sec. ============================================================================== Trics V9.1 Rev F (18-JAN-2001) Monit Data Pool and Luminosity Block Management: 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". Add a second time context to decide when it is time to send another Brief Lumninostiy Data Block. 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. Monitoring Server: 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. 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 running on TCC. COOR Commands: 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" already had an implicit "SCL_Init" which in turn now 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. System Control/Status Dialog Menu: Added a global control value to hold the Time between sending successive Brief Luminosity Block. This is in addition to similar global control values introduced in Rev E 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. 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), 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. Serial Programming of CTFE DAC: Create new Menu "CTFE DAC Programming" where the user will be able to program each DAC one at a time, one channel at a time, or the whole card at a time. There are also plans to be able to write command file. 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. At the moment, only writing EM and Had Gain and Zer to the Card's first channel is available, but it hasn't been tested. 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 for used in the body of other command files. Internal: 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. Separate Supporting Programs: Update the Luminosity Client Test Program to display the Luminosity Incremented flag and the reason for the LBN increment. It is also watching for consistency and ready to display problems in red. This program is only used at MSU with the development version of Trics. 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. Update the the _Hsro_Toy_TrigMon Client to display the new flags 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 Toy Trigmon). 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 V9.1 Rev E (14-DEC-2000) Monit Data Pool and Luminosity Block Management: Improve the Monit Pool Refresh Timing algorithm. The Refresh algorithm was based on crude fixed waits to guarantee a minimum time of 5 sec between updates. When events were not flowing this could fluctuate up to 10 sec. The Refresh algorithm now remembers when the last update happened and waits 5 seconds (rounded down) to try again. Polling to see if an event has been captured, and noticing that it is time to get a new sample are both done at 10 Hz. The time measurement used is truncated to the 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. Same 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. The Luminosity Server is still pushing the old Per Bunch Scaler Data Block instead of the new data block type needed for luminosity, but now kludge-stuff the LBN in the field reserved for format version number. This may be useful to Michael Begel for short term tests, or maybe not. I'll let Michael know. System Control/Status Dialog Menu: Added global control values to 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. Resource Locks: 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. Add a 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. COOR Commands: Add a new COOR Message: 'force_l2reject' Send "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 for SpTrg #0. Send "L1FW_Spec_Trig -0 force_l2reject" to return SpTrg #0 to the default 100% accepts. Update the COOR Message 'Increment_LBN' that was a NO-OP to now cause the LBN to be incremented and push a luminosity block out. Update the COOR Message 'SCL_Init' to now also cause the LBN to be incremented and push a luminosity block out. Update the COOR Message 'Start_Run' to now explicitely call the 'SCL_Init' message handler (while it was previously only repeating the same SCL Init actions). Start_Run will thus now also cause an LBN Increment. Modify action for COOR Message 'L1FW_Spec_Trig [SS] Expo_Group [X]': Modify Programming of FOM++ to add a copy of Start Digitize Geo Sect #31. FOM++ Channel #36, 37 and 38 (decimal, zero-based) *KEEP BEING* programmed to generate a L1 Strobe, i.e. any allocated SpTrg Firing will generate an asserted output. 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. Send COOR Message Dialog Menu: Add 'force_l2reject' and 'Increment_LBN' message templates. ============================================================================== Trics V9.1 Rev D (07-DEC-2000) SCT Init 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 the last LBN to maintain continuity. 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. Add a new Resource Lock to protect against the Framework being declared non-operational (e.g. by config or init or SCT) at some importunate times (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 now protect the Monit Pool Manager program from disturbance during initialize or SCT AND vice versa. Poll for Monit Data Captured (i.e. triggered event) only 10 times per second (instead of 100). While checking for Captured event flag errors regarding the programming of the Capture Monit Data only once per Request. (This was happening in Rev C, and should no longer happen anyways). Fix a bug in the management of the L1 Helper control bits while trying to Request or Force a Capture Monit Data. When No events were flowing, the Request Capture Bit never had a chance to be reset low, and would thus not see a rising edge next time TCC set the bit high again (in fact every other time). This should now be fixed. Fix ITC Server code to correctly verify that the last connecting process is indeed still connected. 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. ============================================================================== Trics V9.1 Rev C (06-DEC-2000) Undo tentative/incorrect fix made for Rev B. Fix Bug in definition of Read and Write Mask for some L1 Helper TSS Control Registers. This should fix the problem of not refreshing the monit data when no SpTrg is firing. Add more sanity checking. Verify that the Capture Monitor Data Pending is set right after the Request is made. (note that there could be a trigger firing during the 5 us window between write and read, but this may still be a useful test for the moment). Continue the implementation of the luminosity server. Now push some data out (Per Bunch Monitoring Data for starter) when the LBN is incremented. Make a test Luminosity client. Add a new type of monitoring data. TCC now captures the HSRO data rebuilt from the Monitoring registers (NOT from VBD data) and serves this information as a new monit block type. Add a new progrom to the Toy TrigMon Suite to display this data in the familiar Formatted Dump format. cf. "_Hsro_Toy_TrigMon" Shortcut. This is a simple/convenient way to look at Monitoring Data to verify/observe triggered data which is not so obvious in Toy TrigMon. TCC Desktop cleanup: -------------------- Deleted some obsolete V9.0 and V9.1 Shortcuts. Older executables (including trigmon set) available via "Older Trics_II Executables". Updated shortcuts names to various Toy TrigMon programs. - Rename all shortcuts with a leading "_" for maintenance convenience. - New "_Hsro_Toy_Trigmon" shortcut. - new "_Toy_TrigMon" now displays Expo Group of each SpTrg, plus a "Disable Mask" that is NOT a straight copy of any TDM reg. ////////////////////////////////////////////////////////////////////////////// // constants to use to parse the uwObeyDisableMask field of // the Tcc_L1fw_Specific_Trigger structure above // if the AND of one of these constants with the uwObeyDisableMask field is not Zero, // the Specific Trigger is programmed to obey the corresponding source of disable #define kTcc_SpTrg_Coor_Disable 0x0001 // Spec Trig is currently disabled by COOR #define kTcc_SpTrg_Obey_Prescaler 0x0002 // Spec Trig is Prescaled #define kTcc_SpTrg_Obey_AutoDis 0x0004 // Spec Trig is Auto Disabled #define kTcc_SpTrg_Obey_IndivDis0 0x0010 // Spec Trig Obey Indiv Disable #0 #define kTcc_SpTrg_Obey_IndivDis1 0x0020 // Spec Trig Obey Indiv Disable #1 #define kTcc_SpTrg_Obey_CorrGlobDis0 0x0100 // Spec Trig Obey Global Correlated Disable #0 #define kTcc_SpTrg_Obey_CorrGlobDis1 0x0200 // Spec Trig Obey Global Correlated Disable #1 #define kTcc_SpTrg_Obey_CorrGlobDis2 0x0400 // Spec Trig Obey Global Correlated Disable #2 #define kTcc_SpTrg_Obey_CorrGlobDis3 0x0800 // Spec Trig Obey Global Correlated Disable #3 #define kTcc_SpTrg_Obey_DeCorrGlobDis0 0x1000 // Spec Trig Obey Global DeCorrelated Disable #0 #define kTcc_SpTrg_Obey_DeCorrGlobDis1 0x2000 // Spec Trig Obey Global DeCorrelated Disable #1 #define kTcc_SpTrg_Obey_DeCorrGlobDis2 0x4000 // Spec Trig Obey Global DeCorrelated Disable #2 #define kTcc_SpTrg_Obey_DeCorrGlobDis3 0x8000 // Spec Trig Obey Global DeCorrelated Disable #3 ============================================================================== Trics V9.1 Rev B (01-DEC-2000) Switch L1 Helper Mode back and forth between requesting Capture NEXT Triggered Beam X and Capture IMMEDIATE Beam X. ============================================================================== Trics V9.1 Rev A (30-NOV-2000) 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. Add new IP Server Port #52163 for the Luminosity Server (not operational) New Files to manage the different components of the monitoring services - MonitControl.cpp Start and Stop monitoring services (i.e. start and stop needed threads) Hold variables to control Monitoring Behavior (e.g. Monit_Server_Silenced) - MonitPoolData.cpp Holds the Monitoring Data Pool itself Routines to update and retrieve this data from different threads without interference - MonitPoolHelper.cpp Routines to help read and gather the disperse monitoring information - MonitPoolManager.cpp Separate thread (sub-process) to collect Fresh Monit Data every 5-10sec First try to capture a triggered event and wait up to 5 sec, then force immediate capture. - MonitPoolServer.cpp Separate thread to field and service Monitoring Requests (i.e. Taka, and Toy TrigMon) - MonitLumManager.cpp Separate thread to increment the Luminosity Block Number every 60 sec It doesn't yet try to send any luminosity information out - MonitLumServer.cpp Separate thread to field and service connection to Luminosity Database Manager Program on the Host (i.e. Michael Begel's) - TricsLocks.cpp Hold the needed resource locks. One lock (Mutex) to prevent monitoring pool data to be updates 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. 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 in the "Send COOR Message" Menu - send a "L1FW Init" message in the "Send COOR Message" Menu Internal: Skip most of the Fpga Download IOs for the development version of Trics. 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. HandleMonitData and HandleMonitServer have now become MonitPoolHelper and MonitPoolServer. ============================================================================== Trics V9.0 Rev W (30-NOV-2000) Change Gated Scaler default BXSHR control value: Update the FpgaGS Initialization to load 0 (instead of 1) at Initialize Implement the new FOM++ V3.1: Update fpgaFOMPP to move the address of the Monitor Copy of the L3XferNum. Update CardAONMCommon to no longer provide HsroReadFromMonitReg for the FOM++, and add a new HsroReadFromMonitReg to the derived CardFOM. Note that the function of the derived class only fully handles the case of the FOM++ and defers to the function from the base class for all other FOM cards. This change was needed because only the CardFOM can access the m_apoMaFpgaFOMPP FOM++ FPGA object. No longer try to initialize the LED Line-ups at Trics Startup time. This would fail if the FPGAs haven't yet been configured. The LED Line-ups will start being displayed as soon as Monitoring Service starts up. Also skip updating display when the system is non-operational. Accept "L2Script " Coor Command: The command is acknowledged while the content of is not parsed and no action is taken. ============================================================================== Trics V9.0 Rev V (15-NOV-2000) These notes are available on the web in \tcc\trics_ii area as 000_Trics_II_Revision_Notes.Txt The full release notes are in 000_Trics_II_Release_Notes.Txt Tick and Turn Scaler: 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. Update the Readout Word per Fpga control Values - Fpga #1-2 read 0x word - Fpga #3-10 read 1x word - Fpga #11-16 read 4x word - Total 32x words Update the expected HSRO output of the TTS Card for HSRO Test purpose Prescaler Percentage (i.e. Circular Shift Register) Fix the array of hardcoded values prepared to load into the 7 Circular Shift Pattern Registers to produce each of the 101 possible patterns (0-100%, but 0% and 100% are not actually used). These values were listed in reverse order, which matters because the seventh register only has 4 bits of the Circular Pattern. LED Lineup: Fix LED Scaler display corruption after L1FW Init: Remove the tests that were skipping updating bits that are left unchanged. The issue addressed is that Initialize will turn on ALL the LEDs. Then the Monit Server would otherwise only reset the bits that were remembered to have been set before the Initialize. Fix by always writing all bits, at least until we decide what we want to display with the LedLineUp and we can implement the full service which will make these LedLineup objects part of Initialize. VBD Address Lists Setup Fix Typo that was causing Trics to use an incorrect base address on the VBD for where Trics must load the list of wordcounts and data to be transferred with each event. The reason we have missed this problem until now is that the VBD kept using an old list loaded manually during earlier tests and survived power cycling because of battery backup on the VBD. Raw HSRO Event Dump: Added protection: Truncate length of dump to the amount of memory mapped for VBD Buffer in order to avoid possible access violation. COOR Messages Implement 'Increment_LBN' Message. - to which TCC will answer 'ok ' - including the <> brackets - NNNNN is the decimal representation of the 32 bit LBN after it has been incremented - Return <000000> for the moment. Also improve tags in the logfile showing the COOR commands received and processed. e.g.: I$COOR Msg # 10 : 000000000000010227 L1FW_Spec_Trig 0 And_Or_List 2 255 -247 expo_group 0 prescale 5000 I$COOR Msg Command : I$COOR Msg Status : I$COOR Msg Command : I$COOR Msg Status : I$COOR Msg Command : I$COOR Msg Status : I$COOR Msg # 11 : 000000000000010228 configure I$COOR Msg # 12 : 000000000000010229 l1fw_pause I$COOR Msg Command : I$COOR Msg Status : Internal Added protection: Update CRegBase::WriteReg and WriteOnly methods to declare the value to write passed as argument (via pointer) as a "const". In fact WriteOnly was ANDing the write value with the write mask which was modifying the data to be written. This happened not to be an issue anywhere, but it could have been, or could have become in the future. ============================================================================== Trics V9.0 Rev U (6-NOV-2000) Main reason for this Revision: ------------------------------ - Use new TDM FPGA (i.e. new prescaler model) Change encoding of Version Numbers in readout: ---------------------------------------------- - Using ASCII code for some of the fields was a weird/stupid idea. It was introducing a new type of format, used nowhere else. It couldn't even be made consistant between - data block format = version.revision - fpga = version.revision - Trics = MajorVersion.MinorVersion-Revision. - Change Trics Revision Number field and Data Block Format Revision Number FROM ascii encoding TO plain number. - Summary_of_fw_data_readout.txt has been updated in http://www.pa.msu.edu/hep/d0/ftp/tcc/trics_ii/ 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) Formatted Dump: --------------- - Add decoding of THE-Card ID field into Rack/Crate/Slot - Add Explicit naming and formatting of all Version Number fields from VRB Header, THE-Card Header and Trailer (not from SHED Data). e.g. I$ VRB # 3 : Tot LongWord= 0x44 I$ VRB Header : Tot Byte= 0x110 Event Num= 0x00 Slot= 0x0a I$ : Slot #10 Format V1.0 Config= 0x0002 Firmware= 0x0828 ... I$ Ch#4&5 : I$ HSRO Header : THE-Card M122-Top-20vent Num= 0xae Primary FPGA V1.1 I$ FPGA 1- 4 : 0x0000 0x0000 0x0000 0x0000 0x9014 0xcafe 0x0000 0x0000 I$ FPGA 5- 8 : 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000 I$ FPGA 9-12 : 0x8182 0x8384 0x9192 0x9394 0xa1a2 0xa3a4 0xb1b2 0xb3b4 I$ FPGA 13-16 : 0xc1c2 0xc3c4 0xd1d2 0xd3d4 0xe1e2 0xe3e4 0xf1f2 0xf3f4 I$ BSF Data : P5 I/O= 0x0000ffff Global I/O= 0x00000000 I$ HSRO Trailer : Status Flags= 0x03 Event Num= 0xae Secondary FPGA V0.0 ------------ P.S. The Revision update notes (i.e. THESE notes) are now saved as 000_trics_ii_revision_notes.txt in http://www.pa.msu.edu/hep/d0/ftp/tcc/trics_ii/ P.S.2. ...while the full Version release notes continue to be available as 000_trics_ii_release_notes.txt in http://www.pa.msu.edu/hep/d0/ftp/tcc/trics_ii/ =============================================================================== Trics V9.0 Rev T (26-OCT-2000) Important: all FPGAs must be re-configured after installing Trics 9.0-T to allow Trics to record the FPGA Version Numbers in the VME Interface Scratch Memory (and the BSF Version Number in the unused Board Interrupter ID REgister). This data will remain there until the next power off, so that restarting a new version of Trics will (in the future) NOT require re-configuring all FPGAs (except for this first time). If you don't, you will get some (non-fatal) warnings during Initialization. HSRO Data (cf. summary_of_fw_data_readout.txt) ---------- - 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. Note that if there are 8x FPGAs of each type, the FPGA in Site #1 is designated as the primary FPGA type. - Fill in the SHED Data > 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 > The Revision ID is an uppercase letter > in the range A:Z > and ASCII encoded (i.e. 0x41 to 0x5A) e.g. V9.0-T -> 0x9054 > 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 still get the test data 0x8182, 0x8384, 0x9192, 0x9394, etc Initialization -------------- - Reset the Board Support Function Scalers during Initialize (one card at a time). This will reset the local one-byte Event Number (and it will also reset the HSRO Status Flags). - change the VRBC Error (Red) Message to a Warning (bright White) when reading 0x01 from the Status Register to make it less worrisome for the non-expert. FPGA Download ------------- - You will notice a new piece of information being displayed along with the EXO file name and showing 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-register 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. SCL Initialize -------------- - add reset of the FIFO Read and Write Counters of the L2FW Auxiliary Data TRM. =============================================================================== Trics V9.0 Rev S (25-OCT-2000) - SCL Initialize Now reset the Read and Write FIFO of the L2FW TRM Spec Trig Fired. (oops, I forgot the Auxiliary Data L2FW TRM in this Rev S) Now reset the L1AL2 Scaler. - Fix SCT. Restore BXSHR control values for L2FW TRM, AONM, FOM Cards - HSRO setup Initialize the VRB Header User Info field according to the updated summary_of_fw_data_readout.txt With the Initial L1FW Data Block Version set to 1.A. This replaces the fixed data 0xcafe. Initialize THE-Card Header Word #0 LSByte with the Card ID according to the updated summary_of_fw_data_readout.txt This replaces the now abandonned word count field. - HSRO formatted dump Verify the VRB User Info field Verify the Card ID in THE-Card Header Word #0 Verify that the one-byte event numbers from all THE-Card BSF match - Monit Server Display the lower 20 bits of the L1 Accept Number on the 20x Foreign Per Bunch Scaler Cards in M122-Top (i.e. on the TCC-controlled LED of each card) with LSB on Slot #21. (note that this scaler is not yet wired or debugged) Display the 5 bit L1AL2 Number on the upmost 5x Expo Group Per Bunch Scalers in M122-Mid with LSB in Slot #21. This is just an initial random choice. We should all start thinking about what we want to display for scalers and/or states of any width on a contiguous set of slots of any of our THE-cards. =============================================================================== Trics V9.0 Rev R (20-OCT-2000) - Fix register addresses in Gated Scaler Fpga =============================================================================== Trics V9.0 Rev Q (19-OCT-2000) Requirements - 8x Miguels in the EG AONM and L1Bz FOM in sites 9-16. - L1AL2 Fpga in Site #16 of SM in slot M123-Bot-19 - SM in slot M123-Bot-19 connected to second fiber of VTM in VRB readout Crate Slot #18 - Move to 8x Miguels in the EG AONM and L1Bz FOM. (Note the FOM++ remains at 4x Miguels with only 1x slice of data). Add the Gated Scaler Card in Slot $19. - The L1AL2 FPGA is expected in site #16 The thresholds are initialized to 1, 5, 10 and 15. - All other sites are expected to have Gated Scaler FPGAs - All gated scalers channels are initialized to be disabled by writing 0x0000 in all gate and load control registers - Except for the Scaler Channel #0 of Fpga #1, 2, 3 which are enabled to listen to Individual Gate #0 by writing 0x8008 to reg 130 - All Fpgas on this card are setup to read 2x words - All Fpgas and all channels on this card are setup with a BXSHR control value of 0x0001. HSRO Test: - Add sanity tests to avoid going past the amount of memory mapped to VBD buffer space in case of junk data. - 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 new cards to test. SCT: - One now needs to explicitely select the TTN card if the option "Include L1 Scalers" is selected. - Only the Miguels in Sites 13-16 are tested at the moment - The Gated Scaler Card is not part of SCT. Monit Server: - Monit Server mow reads and displays the L1 Accept Number and Depth whenever a Phase III request comes in. Expected issues: - Still don't know what's wrong with SCT - BXHSR control values may need to be adjusted - Gated Scaler Channel setup was just a guess, and may need adjusting - L1AL2 thresholds were just a guess, and may need adjusting =============================================================================== Trics V9.0 Rev P (13-OCT-2000) - Add "Monit Data Every Event" to System Control/Status Dialog (now you don't have to go hunting around for L1 helper addresses) - SCT Initialize - After forcing the needed 3x extra L1+L2 cycles to fill all L2FW TRM/AONM/FOM time slices, SCT Initialize now verifies there is no more L2 cycle waiting, and if there is, just complain and flush them (up to 4x L2 cycles). That won't explain why we are having a problem, but it it will prove we are thinking in the right direction, and let us move forward. =============================================================================== Trics V9.0 Rev O (13-OCT-2000) - HSRO Test - Fix expected HSRO for FOM++ to take into account that every FOM++ FPGA readout is twice the same word - Force expectation of Transport Flag to 0x03 - SCT Test - repair the initialization of L1 Helper that ended up causing one extra and unexcpted SCT cycle during SCT Init. - Rev O and P also reset *ALL* TTS FPGAs synchronously on the TTS Card. =============================================================================== Trics V9.0 Rev N (13-OCT-2000) - fix bug that was overwriting proper readout count for TTS FPGA #16 =============================================================================== Trics V9.0 Rev M (12-OCT-2000) - fix Number of word to readout in L1Bz FOM to skip FPGAs 3,4, 7-12 - Change L1 Helper Test Mode Timing (for SCT) - Issue Maginot Line Flip 1 Tick into the canned pattern (i.e. load 0x0201 in Reg 23 of L1 Helper) (i.e. 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: 6 ticks between Maginot line and Capture Monit Data seems like quite a LONG delay. Where is it all going? 1x tick to get into the second slice of processing 1x tick to get into the L1 Helper 1x tick explicit delay in the L1 Helper ...? - Change Readout Control of Tick and Turn Card. (i.e. the Interim Proposal) - Readout Nothing from the first Fpga - Readout 1x Word from Fpgas #2-10 - Readout 4x Words from Fpgas #11-15 - Readout 3x Words from Fpgas #16 (no change of what FPGA gets loaded is required) - Fix HSRO Test problem. You have tho be very careful doing pointer arithmetic in C... This pointer math is necessary to scoot along from VRB to VRB and from Card Channel to Channel. C tries to be smart and does not just add the value $28 to the pointer, it first multiplies $28 by the size of whatever variable (or complex structure) that you are pointing at. I have known that all along, but of course I first fell in the trap. I noticed the bug in the formatted dump fairly quickly last week, but it seems I forgot to fix the same bug when the HSRO Test hunts around for a particular card in the VBD. -------------------- Trics V9.0 Rev L (12-OCT-2000) - Synchronous reset of all Per Bunch Scalers. Checksums for Foreign Scaler should now be correct. I have an updated per-bunch trigmon program to test this. Expos Group Per Bunch scalers quietly remained at zero while Trics was resetting them one FPGA at a time, but Foreign Scalers do not remain quite during Initialize. Now **ALL** per bunch scalers are reset together at the end of Initialize. - Expect 4x Miguel Fpgas in L1 Busy FOM sites 13, 14, 15, 16. - EG AONM and L1 Busy Miguels get the BXHSHR control value = 3 - FOM++ Miguels get the BXHSHR control value = 0 - SCT now checks "Triggered Tick" (i.e. pattern B) data from register pair 33/34 for the FOM++ Miguels and 27/38 for EG AONM and L1 Busy Miguels Note: I am not sure of what is going on with HSRO Test crashing Rev K. If this continues with Rev L, please send me the program counter at the time of the crash. -------------------- Trics V9.0 Rev K (11-OCT-2000) 1) SCL Initialize - Remove the explicit Initialization of VRBs during SCL Init. No Card from the Readout crate is explicitely touched. The VRBC will receive the SCL Init signal and clear up the crate. 2) HSRO Timing - Change L1 Helper Normal Mode Timing - issue Capture HSRO with delay of 1 Tick after L1 Accept (i.e. load 1 in Reg 9 of L1 Helper) - 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 Flip 1 Tick into the canned pattern (i.e. load 0x0201 in Reg 23 of L1 Helper) (i.e. up at tick #1, down at tick #2) - Issue Capture HSRO 3 Tick into the canned pattern Remember it also takes one tick to percolate through (i.e. load 0x0403 in Reg 21 of L1 Helper) - Issue Capt Monit Data 3 Tick into the canned pattern (i.e. load 0x0403 in Reg 22 of L1 Helper) - Issue Transport HSRO 3+2=5 Tick into the canned pattern (i.e. load 0x0605 in Reg 20 of L1 Helper) - Increment every Main array and BSF BXSHR by 1 count - 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 3) HSRO Test Menu - New Misc "ToolBox" Buttons - "Pause" \ - "Resume" > Send corresponding Coor Command - "SCL Init" / - New Test Button - "Compare Again" will not try to cause an event, but just read the monit data, the VBD data, and compare the two. Only the Card selected in the "Select Card to Test..." are compared. The idea is that there may already be an event in the VBD, and you just want to check its data. - "Compare Again" vs "Analyze Current Event in VBD" - The two actions are complementary. - "Compare Again" will only look at the THE Card Monit Data and compare it to the actual data in the VBD. It does not try to check for sanity, nor does it makes the distinction between header and main array data. It only checks the specified cards. - "Analyze Current Event in VBD" analyze the structure of the WHOLE event (as explained earlier) and provide a formatted dump of the event data. - Add more checking that the Analyze Event Dump does not take us past the amount of data mapped for the VBD Event Buffer. 4) 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. - "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 requests to the Monitoring Server (e.g. Taka's Global Monitoring, or Toy TrigMon) to generate IO in the Framework (both by requesting an immediate Capture Monit Data, and by collecting the requested Monitoring Data). Blank Data is returned when the Monit Server is "Silenced". This flag is automatically cleared by an Initialize message from COOR. - "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 (namely COOR messages), and this is a request for an update. ------------------------ This covers the Updates for Trics II V9.0 Rev H, I, J. (10-OCT-2000) - Change of approach: The special cases of cards with non-uniform FPGAs (i.e. TRM with SHED, AONM with Miguel, FOM with Miguels, and FOM++ with Miguels) are no longer handled with derived classes from the base vanilla Card classes. The TRM and AONMCommon (i.e. the common part of AONM, FOM, FOM++) are now able to support a variable number of SHEDs (for the TRM) or Miguel (for AONMCommon). Nearly all the special case code is in the constructor and in the Initialize methods. This approach limits the number of files needed to handle the special cases (dropped 14x files). This approach also limits the number of special cases in SCT and the amount of duplicated code. - Implement the method to rebuild HSRO from Monit Reg for ALL cards that readout. - In HSRO Test, now have control of which card to test via the "Select Cards to Test ..." button. Note that only the cards that readout are available to test. - In HSRO Test Dialog, add the option to select the amount of time each test loop waits for the VBD to present data for readout. - In HSRO Test Dialog, present buttons to separately initialize the VBD, VRBC, and VRBs. The "VME SYSReset" button writes to 0xFFFF181A which seems to not be successful in resetting the Readout Crate. - In HSRO Test, remove the kludge that was fixing the HSRO Event Number read from the Board Support Function, now that the BSF has been updated - Improve the formatted event dump. It now fully adapts to the ACTUAL lenghts of data in each VRB Channel. This means that problems in reading out some cards should NOT polute the dump for the following cards. No matter how many words may be present in a VRB channel the formatted dump will unpack what should be the normal 40 words (i.e. possibly more or less than what was readout in case of problem) which is thought to be a good choice for diagnostics. This does not affect the ability to ALWAYS flag incorrect lengths. - Fix Monit Data Served to now fill in Tick #159 that was previously left at zero. The checksum for the Exposure Groups is now correct. The checksum for the foreign scalers will remain wrong until Trics does a synchronous reset of the whole card. -------------------- Trics V9.0 Rev G (4-OCT-2000) - fix the HSRO Formatted Event Dump (was dumping 4 times the first THE Card on each VRB).