Minutes of the 5-20-96 SVX3 Diagnostic Software Meeting

Present: Ed Barsotti, Mark Bowden, Mingshen Gao, Wayne Koska , Jim Pangburn,
Jim Patrick, Vince Pavlicek, Jon Streets, Don Walsh 

Jim Pangburn, reporting on vmeaccess, stated that it should be possible to
use the Microsoft WinSock socket API.  It does not use file descriptors or
support read/write functions, so a layer of code will need to be written to
use the equivalent supported functions.   A special start-up procedure will
also be needed.  Jim said he does not have the most up to date documentation
on WinSock, but is trying to get it.  He also said that Windows 3.0, 3.1 and
Windows for Workgroups pose too many restrictions on the API and so will not
be supported by vmeaccess.  He thinks that perhaps Windows95 can be
supported, but still needs to check this out.  He also noted that Winsock
v2.0 is coming soon.

Jim is also trying to speed up certain operations that take a long time in
vmeaccess, such as crate mapping (~0.5 sec/slot).  The applications for
which vmeaccess was originally designed were thought to require a small
number of open calls and large data transfers. So the API was made session
based - it spawns a new process for each open, which is slow.  He will have
to think about how to redo this.  Perhaps the cpu could map the crate at
boot time, so it would only have to be done once.  

The next release of vmeaccess will support all Motorola boards, the PowerPC
and the Synergy board.  The master access API will give access to hardware
features (e.g. how a master appears on the bus, etc.).  He also said that he
is aware that the API has some holes in it, such as the need for a bus
reset, that he is working on.

Don Walsh said that he has looked at Colin's SVX2 test stand code, which is
RPC based.  It is hardware specific.  The memory read/write functions should
be easy to port, the fifo addressing code will take some work.  He does not
think it will be difficult to integrate it with vmeaccess.  

Jon asked Don how slow the code might be if integrated with vmeaccess.  Don
thought certain operations would be quite slow.  For example, resets of
certain modules would require several calls.  It would be best to let the
server do most of the work.  It was stated that it would be nice if
vmeaccess could support being given a list of commands to perform, so that a
single RPC call could be made to vmeaccess running on the bus master, with
the list.  Jim said this is part of the API, but he hasn't started on it
yet.  He considers it the most difficult part of the package, since there
may be dependencies (e.g. should processing of the list stop if a command
fails?, should there be retries? etc.).  The former Pig group also would
like a command list sequencer built into the API.  They have the added
requirement of a fixed time period for the completion of an operation.  Don
was asked to look at Colin's code to see if retries were built into his code.  

Jon reported on news from Colin.  He will not be at Fermilab for the next 3
weeks.  E-mail should be sent to him @fnald.gov.

Mark stated that D0 wants to keep the 1394 bus driver on the VRB.  The board
will be kluged so that the same data that will be sent on this bus can also
be read out through vme (control and data words will therefore go across the
same bus) for the short term, probably through the beam test.  Mark said
that he assumes that someone from D0 will write the drivers and other
requisite code to operate the 1394 bus.  He also said that the VRB will use
the 68030 as the on-board processor.

Wayne said that he would like to make it easy to put SVX3 documentation
generated by members of OLS onto the ESESERVER so that it can be stored with
the rest of the SVX3 documentation.  He would also like to be able to set up
pointers from the SVX3 web page to the documentation.  He suggested setting
up a trust relationship similar to that between OLS and ESD.  There were no
objections and it was suggested that he talk to the ESESERVER manager, Ken
Treptow.  Wayne will follow up on this.

Mingshen Gao passed out a document and described his idea for writing an
instruction list generator for the GSTM module.  Kerry Woodbury's plans to
generate an instruction list graphically using a program he wrote to
translate the output of a commercial package was briefly discussed.  Kerry
will be asked to describe this method at the next meeting in two weeks.
Questions raised were:  Is the commercial package used by Kerry platform
independent?  Is there a version that runs on UNIX?  Could the output format
generated by Ming be the same as that generated by the commercial package,
or could the output of the commercial package be translated into Ming's
format?  More discussion will take place after everyone has had a chance to
read and digest Ming's document.

Ed asked that Jon and Wayne produce a document in the next few weeks stating
what they perceive their goals are and a time-line for achieving those goals.