n2kbod7 - need to know Body, chapter 7

last updated 18 oct 97 - mjh

8) testing

We test what we build. Most of it takes place at the test stand in the computer room, although some is done right there on the bench during assembly.

Since everything that we do is unique to a particular experiment or task, the testing procedures are equally unique. Refer to the all-important (2.2.5) 3 ring notebooks for the details of the testing. The balance of this section will address the resources involved.

8.1) the test stand

The test stand is located in the middle of the computer room, across from the printers. It has its own AC power distribution, distinct from the rest of the equipment in that room, and derives benefit from the cooling facilities which otherwise exist for the sake of the computers.

A large portion of the test stand is currently designed to support (2.4.2) FASTBUS, which is the IEEE 960 standard for high speed data acquisition and control. We are moving away from FASTBUS and into VME as our primary design target, but we still have a lot of FASTBUS infrastructure in place.

The FASTBUS crates can be controlled from a MicroVax via an I/O Registered FASTBUS Interface (IORFI). In overly simplistic terms, the IORFI allows a parallel port on the MicroVax to control individual lines on the FASTBUS backplane, effectively creating FASTBUS signals and cycles (albeit somewhat slowly). We have a collection of FASTBUS-specific routines that are available to our in-house software-test environment (a language named DDL, which only coincidentally are the initials of the author). Thus DDL code is written, on a design-by-design basis, to exercise FASTBUS boards via the backplane. DDL test procedures are typically kept in an appropriately named directory on the VMS/Vax system, so as to be accessible to the MicroVax.

Surrounding the FASTBUS crates are so-called "black box" crates, filled with "black box" or "logic element (LE) modules. These crates and modules are also controllable from the MicroVax, and through the DDL software. The LE modules are intended to provide external stimuli to, and examine module outputs from the FASTBUS module under test. The LE modules are building blocks, and are inexpensive enough that it makes sense to "archive" whole crates of modules, complete with their cable interconnections, as "test fixtures" for future use in debugging returned boards.

Documentation can be found ... (someday I hope to be able to finish this sentence)

8.2) LE modules

The LE or "black box" modules are a marvelous tinker-toy set of modules, including registers, counters, gates, signal sources, etc. An index of these can be found in indices\drawings_lec.txt but you will need to refer to the (2.2.3) file cabinets to look at the drawings, as almost all of the LE modules predate our CAE toolset.

In many cases, a pc board was made for one particular application, and assigned a bare board number (LExx-Byy). The assembled module was then assigned a front panel name. But, by a little creative surgery, the same bare board could be changed to provide a different function. While the bare board kept its name, a different front panel was created, and hence a different front panel name was assigned. We have many front panel names, but a significantly smaller number of underlying bare boards. A great deal of cost-effectiveness was achieved this way.

Surprisingly, though, there are only two more-or-less general purpose (sea of holes) LE modules at this time, but both incorporate features that make them less than attractive for use with today's high pin count or small pin pitch integrated circuits.

Although not a commercial product, our LE/black box design has become so popular that crates of electronics are to be found (still in use) at Fermi, SLAC, and several other places! The flexibility of the modules, and the computer controllability of the backplane make for a simple yet powerful combination.

8.3) the future of VME and/or IP's

As a group, we are undergoing a number of significant changes over a very short period of time. FASTBUS is giving way to VME (or, to be precise, (2.4.3) VME-P, the high energy physics extensions to VME64x). And the majority of our long-term personnel are retiring. Very quickly we will have a lot of FASTBUS and LE electronics which no one currently employed really understands, and a lot of VME electronics with very little supporting infrastructure.

The current "plan" is to employ VME processors to control VME crates (for many years, there was no "FASTBUS processor", and to my knowledge there still is no "LE processor". Both were remotely controlled via some other computer). Since commercial VME processors are not expensive, and since commercial VME-processor-software is available, we can move away from our do-it-yourself mentality and buy more often than build.

Of course, we will still have to write software. The most likely combination is C (or C++ for the hackers) and VxWorks as the underlying real-time kernel. By adding parallel ports, either in the form of IP modules riding on a processor board, or stand alone parallel ports, we can interface to the LE crates (just as the MicroVax did), as well as the FASTBUS crates (if a reason arises). This will cost a fair amount of software development effort, but it is better than trying to keep one MicroVax, running VMS, alive amid a sea of NT boxes.

Another possibility for FASTBUS (again, as per need) is the use of the FRC (FASTBUS readout controller), which is a DSP-engine on a FASTBUS card, with VxWorks kernel support. While it will cost in "people" more than in money to maintain an effective environment for programming the FRC, it may prove more viable than the VME-IP-IORFI approach.