Resource Manager VXI meeting

Marie Madeleine Aléonard

Strasbourg, 31-July-1990

Présents: M.M. Aléonard, Ch. Ender, B. Humbert, P. Kadionic, F. Köck, Ch. Ring.

This meeting was held to coordinate software development for the Resource Manager VXI card, following the 17th july Daresbury meeting.

It was first recalled, according to PSC documents, that for the RM software B. Humbert in France and V. Pucknell in UK are the responsible persons; while for the hardware these are respectively Ch. Ring and P.J. Coleman-Smith.

The collaboration and contribution of both Ch. Ender and Frank Köck from Heidelberg were greatly welcomed and this meeting was the starting point of a detailed collaboration.

1 VXI ”scope” functionality :

As a result of the Darebury meeting (july 17th) Ch. Ender is in charge of developping flash ADC for pulse analysis of some VXI lines. It was agreed that Ch. Ender would be also in charge of developping the appropriate software. But we are first expecting a full specifications document by mid-august. The prototype is expected end of year.

2 Software for the Resource Manager and VXI crate controller board:

This VXI board has 2 functions:

• Slot 0 RM function related to standard VXI definitions. In this respect only the mandatory and needed spec for EUROGAM (i.e. Register based RM function) would be implemented.

• Crate controller functions.

2.1 Resouce Manager subset sofware

A document will be produced on all startup procedures, keeping in mind that for development, VxWorks will be available both in France and UK and some of its features will be very usefull. The aim is to have an autoboot configuration. For this a PROM autoboot will be needed. To manage a wide kind of situations the minimum VXI configuration will be Promed: the RM autoconf and test(?) and the autoconfiguration of the VXI boards located in the crate, this the first step of a start up phase (≤ 5s).

The second phase is in relation with the data base for further diagnostics. In principle the VXI card do not undergo an autotest since they are processorless, hence the RM software should provide boards’tests in relation with the data base where all the parameters of the configuration are stored. At this point 2 solutions are in view:

• the RM (now a crate controller) waits for a ”claim crate” procedure from any acquisition software which should provide it. Appropriate bits will be set in the ”status report” register for the claim crate procedure. A document will be provided; bits will range from ”power crate” to ”crate available and fully in function”.

• the RM sends to the ”acquisition system” a broadcast-all-RPC ”i am awake” with an appropriate status. Repeat it for some time and goes asleep.

Some feedback is needed on this aspect: both ways may be implemented (?). Some aspects of the first exchange on the ethernet may be dependent of the local network and acquisition software.Some of us feeled that the ”Acquisition system” should always remain the master, and some view the other aspect.

2.2 Database software aspects

The data base is related in several ways to the RM. Through the desciption of the VXI boards (module type, characteristics... ) needed for tests at start up, and through the parameters needed to be loaded to start an acquisition whichever the complexity of the setup. Other aspects such as on line checkings, tuning ... are also to be managed.

It was feeled that this aspect needed a discussion with David Brightly in charge of the Data Base. A document will be submitted for discussion.

2.3 Crate contoller VXI functions

As soon as the first phase of the VXI autoconfiguration is done the RM can be viewed as a crate controller with the following VXI functionnalities.

• Diagnostics : This need to know the local structure of the data base in each VXI crate. Checks of consistancy of module type, ... ,check of parameters loaded in card versus the data base.

• In tuning phase: change parameters... At least have specific processes i.e bloc transfers r/w ... need ad hoc RPC or file management or agreed procedure. need to use the appropriate spectrum structure, may use the NFS ? for spectrum transfers it is during tuning.

• Test phase: allows all manipulations of registers and memories via the network (this is already provided by VxWorks), builds spectrum in memory. All calculations or graphics display are performed on a remote station (at least in a fisrt stage).

• RM procedures: some crate controller procedures typical of th VXI carte controller may be: initialise module, read module configuration, write module configuration, get module description, error handling(?), ... . A document will be provided for that.

2.4 RPC software

¿From the previous remarks some specific VXI procedures may be needed and document will be provided for. It is under study at CRN to explore the possibilities of Sun RPC and VxWorks for task management and file transferts. We are relying on Daresbury for specific RPC and design of the data base

3 Summary: priorities and responsabilities

1. Document of software specifications for RM and VXI crate controller:

C Ender to provide spec mid august.

2. test code for first level autoconfiguration in RM (no PROM yet):

Ch. Ender in corelation with B.Humbert for checkings (several CPU are used, it would be good to have in the future some other VXI cards ). Checkings of the RM boards from Struck: end september in Strasbourg.

3. Basic diagnostics (registers,memories..):B.Humbert

4. Full data base specifications. Need feedback with D.Brightly.

Some document to be forwarded for discussion by C.Ender . Expected final spec end of 1990.

5. Full diagnostics B.Humbert and P.Kadionik. With or witout the data base specs a preliminary release IS NEEDED end of 1990!

6. Specifications of flash ADC: Document provided by Ch. Ender mid august.

7. Prototype for ”scope functionality” of RM: end of the year for hard and software.

Note: although noted 6 and 7 in the priorities these points are of great interest and will be needed for boards testing as soon as the VXI cards are ready.