\documentstyle[11pt]{article} \title{EUROGAM software meeting\\ CRN Strasbourg 17-18 october1990} \author{} \date{} \begin{document} \maketitle \section{Resource Manager VXI} \subsection{ Summary of general meeting held before} The general meeting held in front of this meeting defined "mandatory features in VXI structures" as {\it dynamic configurable and register based} to allow for further implementations. Besides,the following mapping was also agreed:\\ - offset 0: manufacturer ID ( IN2P3 has one (H.Harroch in charge))\\ - offset 2: device type register:\\ rev level (4 bits); board type (8 bits)\\ - offset 8: serial number (16 bits) unique for a given board type ( combination of board type,rev level and manufacturer id)\\ - offset 10: modification level (16 bits user defined)\\ Answer to hardware:A24 is sufficient for EUROGAM, this manage 0 to 16Mbyte address field. However the Resource Manager must allow A32:{\it a bit in configuration register option in RM board will be set for A24, bit reset means A32} It was recalled that in Start up VXI procedure A above 16 is not looked at, A24 and A32 are only a second step startup. \subsection{ Basic VXI crate Resource Manager functions} C.Ender reports on a VXI crate controler and resource manager (see EDOC0xx) in a more general context than EUROGAM (message based RM). It was said that EUROGAM requested a register based configuration and that there was no need to stick to the VXI spec " 5 seconds to setup VXI" at powerup. The basic Resource Manager software to be written for the EUROGAM VXI RM should have: - a permanent setup task which builds a configuration table and gives a table map of all units in the VXI crate. - the RM {\it waits} then for a RPC from the Acquisition software. - the initialisation procedure can be restarted any time (to be sure we start at a given state) - this procedure is a register server towards the contol and acquisition software. {\bf Action: {\it C.Ender to write code and implement {\it under VxWorks} with B.Humbert as coordinator at CRN}. Schedule: code ready end November 90.} \section{ Vxworks} Everything is set now and the licenses are agreed both in France and UK. The last release due in November will support SCSI driver and a source level debugger. The GNU compiler will be used for cross compiling from Sparc SUN stations to 680xx targets CPUs. \section{VXI diagnostics monitoring and tests} A "EUROGAM diagnostic software" basic document is presented by MM.Aleonard. Diagnostics and test can be set at 3 levels: card tests from design ingeniors, tests including some other parts of the EUROGAM boards (i.e GE+BGO boards and detectors) and finaly tests in situ with all the equipment. Software people are waiting for the written software specifications of all boards involved: Ge (nearly complete), BGO, ROCO, Trigger (nearly complete), histogrammer, and Resource Manager (nearly complete). {\bf Actions: D.Brightly to get specs for trigger. C.Ender for Resource Manager, MM.Aleonard for ROCO, H.Harroch for Ge, B.Humbert for BGO. B.Humbert to write specifications and code of a script langage for ingeniors to test cards }. Request for synchronised pulsers for detail checkings of simulated correlated events was forwarded to hardware ingeniors. Agreed. It was recalled that {\it somebody had to count the number or Resource Manager boards needed, even beyond EUROGAM (development for example), and check with P.Coleman-Smith for availability with Struck} \section{Communication and network} A RPC tape server has been developed at Daresbury, with a GEC as a server and Sun as client. S.Letts has written documents available on the info-server. Transcription of this software may be some help for the Sun version in Strasbourg. It was noted that the standard RPC library has limitations ( time out selectable but fixed for all calls, use of Portmapper for small messages is time consuming (it is best to define a UDP port number),..). RPC procedures will be written for each server involved. New asynchronous RPC library was supplied to Strasbourg on Exabyte tape using raw TAR format. \section{Event formats} A small group (hardware and sofware) reconsider the event format output from the VXI crates to the Event Builder. Agreed.{\it New format to be included in revision of S.Kossionides document}.(last note: a slight modification has been proposed latter by J.Alexander to take account of error handling). Event format out of the Event Builder not changed; see revised S.Kossionides document. The two possibilities are:group format or 32 bits DT32 format. A compact output format is necessary to spare tapes. \section{Tape format} Use of ANSI label agreed.{\it Action: The structure of the tape format for event by event collection has to be fixed between V.Pucknell and G.Zehnacker for the next PSC}. \section{Spectrum format} One file per spectrum was agreed. In memory the spectrum label will not be contiguous to the spectrum.{\it Action: V.Pucknell to comment J.Zen document}. A matrix storage algorithm was proposed by S.Kossionides. It should be studied by off-line group software.(No action). V.Pucknell presents a RPC spectrum server. Document to be completed. \section{Event Builder} Availability of the Motorola MVME165 CPU delayed to 1st quarter 91. Part of the software to be implemented can be checked without these CPU. {\it J.Cresswell/MM.Aleonard to follow evolution}. Data output from the Event Builder goes to the Sorter in phase I. In phase II it was pointed out that the output of the Event builder could go directly to tape and so the group definition ID allowed in Event Builder should manage that.{\it Ask physicists which kinds of tape streams needed}. The software manipulation of qualification bits arise a {\it question to physicists: what will be the use of these qualification bits by users?} {\it Action: simulated test data records for the Event Builder will be produced at CENBG (Bordeaux) for end March 1992.} \section{Sorter} No major comment about sort langage except that it should leaves the possibility of adding new procedures. The sort system has the same structure as the Event Builder. All CPU will support VxWorks kernel. The 64Mbyte space available for spectra and matrices was approved as a basic version by physicists. \section{Tape server} G.Zehnacker presented the preliminary schematics of the tape server for phase II. It will be based on VME CPU supporting a SCSI bus, and use, probably Exabytes. Each CPU will support VxWorks as a Kernel. The Tape server will be accessible from the Event Builder and the Sorter via a fast data tranfer (not yet chosen). Access to the acquisition software will proceed via Ethernet. \section{User test, setup} MM.Aleonard reports shortly on "Eurogam diagnostic and sofware". {\it B.Humbert in charge to write simple procedures to allow ingeniors to test VXI cards through VxWorks.} B.Humbert and MMAleonard to define tests procedures for each card. Waits for detailed software specifications of each card.{\it Action:C.Ender to collect infos for the Resource Manager, B.Humbert for BGO card, H.Harroch for Ge card MM Aleonard for the ROCO card.} \section{Spectrum server } Spectra are of two kinds and each have specifications to be detailed for a RPC server:\\ - histogrammer,sorter spectra; D.Brightly in charge to write specifications of spectra\\ - disk or tape spectra: J.Zen to write specifications. The need for a common set of routines for RPC spectrum calls, via a spectrum header identification was agreed. \section{Graphics} {\bf Agreed}: graphics frames for spectrum analysis are to be designed from a merging from Daresbury, Orsay, CRN software practices.{\it Action}: Frames to be presented for discussion end of 1990. Graphic software will be based on X-Windows.{\it Agreed} {\it Not yet agreed: } Tools to be used: Motif and Openlook were in balance. Openlook is supported by SUN, Motif is not a SUN standard but may be a more open software which can be runned on SUN, VAX's... UK ingeniors support Open look,French Motif. {\bf Action: MM.Aleonard and V.Pucknell to coordinate.} {\it Agreed: need of a common tool for sofware compatibility.} \section{H.V} VME interface available (in principle) early 91. {\it J.Cresswell in charge with Honsi to follow this.} No software writtable without board availability. \section{Autofill} To be converted from OS9 to VxWorks but also need more tests on exceptional circumstances (powerfail,...) No specifications written yet. Would be autonomous but have registers displayable for remote control only. Report to an exception handler server (via ethernet ) is to be included.{\bf Action: Honsi to write specs}. \section{On line, Off line software} On line sorter and analysis is to provide a control of the experiment on gain shift, pic to background... These processes are not necessarily using all the stored events. Typical analysis need a minimum 64Mbyte to check all spectra. J.Sampson sort langage seems to fit general requests. Standard gain matching, as well as Doppler corrected gain matching are needed. The 2-dim {\it (small) matrices needed for control will be managed through the space avail able. Checkings of data quality each 2 hours is needed for gain control. Automatic fitting procedures are needed to insure checks consistancy. {\it End report} \end{document}