VME Equipment Behavior at the DFEL and Saskatoon Laboratories
Contents
1. Once the firmware version has been updated from v8 01 to v8 9 for the v775 and v792 CAEN modules in Crate2 CBLT64 functionality should be tested again If the results of the CBLT64 tests are positive the user may elect to implement CBLT64 as the default block transfer mechanism in place of the current A32 D32 CBLT scheme It should be again noted that for small event sizes the bandwidth advantage of CBLT64 is lost and the gain over CBLT D32 is negligible Users of the Crate2 and Crate3 systems must be made aware that the issuance of a SYSRES signal may not affect the VME modules exactly as documented in their re spective User Manuals Additional testing should be performed to fully investigate the extent to which the effects of a SYSRES signal differ from the documented response This type of testing should be performed both before and after the suggested firmware replacement of the Crate2 VME modules Oscilloscope observations of the v775 and v792 modules ECL signals corresponding to the BUSY DRDY LEDs should also be made both before and after the suggested firmware upgrade These ECL signals correspond directly to the LED signals and will provide details of the signal Note that no adverse effects were directly attributable to the lack of module LED activity The impact of the effects described in this report should be minimal both to the sys tem s performance and to the end users provided users are aware of the problems and lim2. mode and while the board is configuring at power up This LED will remain ON if the Multi Event Buffer MEB is full DRDY data ready LED Active if at least one event is present in the MEB Also active while the board is configuring at power up TERM indicates the electrical termination status of the Control Bus lines Also active orange while the board is configuring during power up OVC PWR activated when the board is powered ON The following description applies to Crate2 The v792 module in slot 10 and the v862 module in slot 19 were the only modules to display LED behavior consistent with the above description taken from the v792 User s Manual That is the BUSY and DRDY LEDs were activated upon crate power on module self configuration All other QDC and TDC modules showed zero activity from their DRDY and BUSY LEDs during crate power up This lack of activity was also present during data acquisition when the BUSY and DRDY LEDs should be indi cating the status of the MEB and during issuance of aSYSRES signal when the BUSY LED should flash The TERM and OVC PWR LEDs seemed to operate according to the User s Manual i e the above description The BUSY and DRDY signals are available as ECL level outputs from the CONTROL connector present on the front of each v775 v792 and v862 module Unfortunately the ECL signal outputs corresponding to the BUSY and DRDY LED signals were not investigated during this visit to Duk
3. VME Equipment Behavior at the DFEL and Saskatoon Laboratories U of S Subatomic Physics Internal Report SPIR 133 Daron Chabot 3rd November 2004 Introduction This report outlines several VME related problems that were encountered during a July 25th to August 7th visit to DFELL Duke Free Electron Laser Laboratory Durham N C The purpose of this trip was to perform system integration and testing of the PC based data acquisition system DAQ and the gain monitoring system Both com ponents are used with the Lucid Acquisition and Analysis system in conjunction with the Blowfish neutron detector The University of Saskatchewan U of S SPIN and TUNL research groups form the end users of these systems This report will focus on problems encountered during the testing phase of the new PC based system VME Equipment The VME equipment in use during the integration and testing phases of the DFELL trip consisted of the following e Two W IE NE R UEV 6023 VME crates One of these referred to as Crate1 was discovered to function incorrectly and was exchanged for a similar unit while at DFELL referred to as Crate2 Details given below e Three CAEN v775 TDC modules firmware version 8 1 e Six CAEN v792 QDC modules firmware version 8 1 e One CAEN v862 individually gated QDC firmware version 8 9 e One CAEN v513 I O module version serial number 0x7B manufacturer num ber module type 0x832 e One Struck Innovative System
4. d consumes the majority of the Block Transfer s duration 3 Non standard SYSRES response According to the CAEN User s Manuals for the v775 v792 and v862 modules a SYS RES signal also known as a Hard Reset issued via the VME bus should cause a reset of the values defined in the Thresholds Memory register see section 4 40 of the v792 User s Manual for example presumably to a value of zero as that is what the thresh old values are initialized to at crate power up However testing with Crate2 indicated that values written to the Thresholds Memory region of the relevant modules persisted across a SYSRES signal issuance This behavior is also present in the Saskatoon test bench Crate3 However the issuance of a SYSRES signal has the as documented effect on the lone v513 I O module present in both the Duke and Saskatoon configurations i e the module s I O ports are reset to their default power on values by a SYSRES signal See the v513 User s Manual for the specific default values The abnormal response of the VME modules in Crate2 and Crate3 to a SYSRES signal was also manifest in the modules LED activity discussed below 4 Non standard Module LED activity All v775 v792 v862 modules are equipped with the following five Light Emitting Diodes LEDs DTACK activated upon each VME access to the module BUSY activated upon each analog to digital conversion analog section reset when in memory TEST
5. dules comprising the chain such that they occupied consecutive slots was not tested for CBLT MCST failure Consultation with W IE NE R staff Andreas Ruben indicated that Cratel may have been of a particular type that was produced for a short time and later discovered to have Unless otherwise specified all CBLT and BLT operations refer to reading data from the VME module s 2The module used here was the v862 QDC residing in slot 19 The address and data size used was A24 D32 automatic daisy chaining that did not support CBLT MCST operations Therefore Crate 1 was exchanged for Crate2 which was known to have the correct daisy chaining circuitry After the crate exchange CBLT operations were found to function correctly in A32 D32 mode It was Crate2 that was used for the remainder of the system integration and test ing at DFELL and is the crate in place at the time of this writing 2 Failure of CBLT64 Operations The VME64 specification introduced a new block transfer protocol where the address lines of the bus are used to multiplex an additional 32 bits of data resulting in a 64 bit data transfer during BLT operations This operation is known as an MBLT Multi plexed BLock Transfer With the addition of the Physics Extensions to the VME64 specification VME64xP a 64 bit CBLT operation was also defined This transfer mode is known as CBLT64 Testing of CBLT64 operations A32 D64 with Crate2 revealed the followin
6. e University Perhaps on the next trip these ECL signals could be studied for proper operation This would at least indicate if the problem were as simple as LEDs that do not function correctly as opposed to some deeper electronic problem Two short film clips were taken of the LED activity present during a test of Crate2 s re sponse to software issued VME SYSRES signals The signals were issued repeatedly with a frequency of once per several seconds i e less than one Hertz These film clips may be obtained via the following URLs http nucleus usask ca pub media mov vme_lights vme_lights01 mpg http nucleus usask ca pub media mov vme_lights vme_lights02 mpg A third film clip was also produced The clip illustrates the behavior observed at the Saskatoon laboratory Crate3 using the same SYSRES loop as described above This video file may also be obtained at http nucleus usask ca pub media mov vme_lights vme_lights34 mpg The important details to note while observing the film clips is the lack of BUSY LED activity from the majority of modules in Crate2 and the participation of all modules BUSY LEDs in Crate3 Conclusions Chain Block Transfers are fully functional in A32 D32 mode for Crate2 and Crate3 However A32 D64 operations CBLT64 caused frequent readout errors when tested with Crate2 and their use should be avoided with that system However no problems were encountered while testing CBLT64 operations with Crate3
7. e following list is in no particular order 1 Lack of support for CBLT operations Chain Block Transfers are an essential characteristic of the PC based DAQ This fea ture lacking in the previous MVME167 based system contributes signifigantly to the performance gains of the newer DAQ The VME crate that was in place upon arrival at DFELL Crate1 did not provide support for Chain Block Transfer operations CBLT While Block Transfers BLT operated correctly when applied to a single module a CBLT applied to the chain object composed of the six v792 QDCs and the lone v862 QDC returned data from only the first module in the chain i e data from the v792 module residing in slot 9 When this problem was discovered Multicast MCST command cycles were not tested Their failure seems assured by the failure of the CBLT commands as the MCST and CBLT operations share the same signal transfer scheme use of the IACKIN OUT daisy chain for token passing between modules comprising the chain According to the CAEN v792 User s Manual pg 31 if the VME crate does not support auto matic daisy chaining then modules comprising a chain must occupy consecutive slots within the crate there must be no vacant slots between chain members Crate 1 was labeled as supporting automatic daisy chaining so the inter module gaps see Figure 1 were not thought to be suspect in the CBLT failure Therefore relocating the mo
8. g failure mode If any module of which the Chain was comprised converted an odd number of four byte words which were then subsequently read out during a CBLT64 transfer the CBLT operation terminated in a way that caused the VME PCI driver to report a fatal error This would cause a system reboot The failure occurred in the driver software due to a missing End of Transfer EOT signal which normally terminates a Block Transfer The lack of EOT signal was interpreted correctly as a transmission error by the driver This failure mode was not observed when using CBLT64 with Crate3 Saskatoon lab The Chain used here consisted of 2 v792 QDCs one with firmware version 8 9 the other with firmware version 9 0 and one v775 TDC firmware version 8 9 This would seem to suggest that perhaps it is an issue with the particular version of firmware in place in the modules present in Crate2 The recommended test would be to swap the firmware ICs in the modules of Crate2 v8 01 with the latest versions on hand at Duke v8 9 and repeat the CBLT64 tests Note however that the CBLT64 functionality is not essential to the system at Duke In fact for small event sizes low data volume the performance gain of using CBLT64 over CBLT 32 bit would be hardly noticeable This is because the overhead required by software in order to initiate a block transfer operation BLT is the same for 32 bit and 64 bit operations and this overhea
9. itations of the equipment
10. s SIS sis1100 3100 VME PCI interface The sis3100 acts as both the VME System Controller SC and a VME bus master One CBD8210 CAMAC branch driver version unknown 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 CBD8210 SIS3100 CAMAC VME System Branch Controller 7 Driver v513 I O Module v862 QDC v775 TDC v792 QDC short GATE v775 TDC v792 QDC long GATE v775 TDC v792 QDC short GATE v792 QDC long GATE v792 QDC short GATE v792 QDC long GATE Figure 1 VME module position and type as used throughout the testing phase of the PC based DAQ while at DFELL The layout of the modules within the crate is illustrated in Figure 1 Note the vacancies in slots 4 6 8 11 14 17 18 and 20 These vacancies were present in an attempt to mitigate any thermal effects that may arise due to module heating density In addition to the two crates used at DFELL the operation of a third VME crate will also be discussed Crate3 This third system is the development testing platform used at the U of S The naming convention used in this report will be be to refer to the different VME crates as 1 Cratel the VME crate in place upon arrival at DFELL 2 Crate2 the VME crate shipped to DFELL to replace Crate1 3 Crate3 the VME crate used at the University of Saskatchewan Description of VME Equipment Problems Th
Download Pdf Manuals
Related Search