This paper describes a system which uses a commercial spreadsheet program and commercial hardware on an IBM PC to develop and test a track finding system for the D Zero Level 1 scintillating fiber trigger. The trigger system resides in a VME crate. This system allows the user to generate test input, write the pattern to the hardware, simulate the results in software, read the hardware result, compare the results and inform the user of any differences.
The D Zero (D0) Detector is located at Fermilab near Batavia, Illinois. It is undergoing a major upgrade for higher luminosity runs with the new Main Injector. Most new systems require software for engineering development, board testing and repair, and system debugging. An important requirement is that these engineering tools are flexible and easy to modify so that prototypes can quickly be converted to finished designs. We have developed a test system which uses an Excel spreadsheet to do all the testing for a level one trigger system for D0.
Most of the digital electronics in D0 reside in VME-bus crates. A VME bus may be connected to a Personal Computer with a commercial interface board set. This allows the PC to be used to test the VME hardware.
Microsoft's, MS, Excel V5.x includes Visual Basic for Applications, VB. It does not support "peek" and "poke" operations to physical PC memory directly. Unfortunately the PC Bit3 board requires this feature. The 16 low-address bits are output directly to a 64 Kbytes address space and the higher address byte(s) are output through input output PC ports.
One way to access physical memory under the MS Windows operating system is to use the DOS Protected Mode Interface or DPMI[1]. This is a low-level interface requiring the use of assembler or the ability to use assembler code Inline. We used Borland C to write a "Library" of Bit3 interface routines. These were made into a Window's Dynamic Link Library, DLL. Any of the functions in this library may then be called from VB, and even directly from an Excel cell once the function is "registered". Registering tells Excel and VB where to find the function and to load it into memory. Although Excel Version 4.x macro language also allows "registering", Version 5.x's VB provides a more useful and relatively robust wrapper as well as a real programming language.
Once the DLL is created and the Functions are "registered", a worksheet may be constructed so that user- entered data is written directly to the hardware under test. Excel provides a user interface for input. Excel, VB and the DLL transfer information to the Device Under Test, DUT, read the results from the VME crate and present the results on the display. In parallel, VB and Excel simulate the DUT and display any differences to the user. See Fig. 1.
Fig. 1. Functional diagram of Test System. Simulation and hardware test occur in the Excel Spreadsheet, the BIT3.DLL drives the Bit3 hardware. The VME crate contains the system under test.
Fig. 2. An Excel Worksheet set up to represent the
fibers of one wedge of a Detector upgrade study.
Figure 2 is a worksheet representing one wedge of the proposed detector upgrade. The small squares with numbers on them are VB "Textboxes" which represent ~480 round scintillating fibers arranged in sixteen layers, logically grouped into four Superlayers. Superlayer "A" has four layers with 16 fibers per layer; "B" has four layers of 24 fibers per layer; C has four layers of 32 fibers per layer; and "D" has four layers of 40 fibers per layer.
The present prototype D0 Level 1.0 Trigger Electronics consists of a VME board with several Altera "Flex" field programmable gate arrays, FPGA's.
A particle hitting a fiber is represented as a yellow "Textbox" on the color screen and as a lighter gray box in Figure 2. It is represented as a "1" in the underlying cell and the VME hardware. Similarly a blue "Textbox" on the screen (a dark box in Figure 2) means a fiber was not "hit" and is represented everywhere by a "0". Adjacent fiber layers overlap. Each overlapping pair is called a "doublet". The logical OR operation is carried out on the individual fibers of a doublet pair and is stored in the first row of cells immediately below the dark "Textboxes" The next lower row of cells show the OR'd results of adjacent doublets in the same layer. The third lower row displays a logical AND with the other doublet in the Superlayer. Eight "centroids" can be formed in this Superlayer. The number of doublets OR'd together increases from two in the "A" Superlayer to five in the "D" Superlayer. This provides data reduction and holds the number of "centroids" constant: eight per Superlayer.
The binary values representing each fiber are packed into words and mapped into VME address space which the FPGA's use in place of real detector hits. Results of the hardware computation are read back from VME and compared to the Excel simulation results. Differences are shown as a "1" in the spreadsheet.
Test patterns may be generated by 1) clicking the right mouse button on individual textboxes to toggle individual fibers, 2) click the right mouse button on the "Make 1 track" button which prompts for an energy and direction, or 3) input Particle "Events" from an externally generated file. Other options exist to set all of the fibers to "1" or all to "0" and for explicit control of the Bit3 card and the VME crate.
Much has been written about the speed of Excel and VB as a Rapid Windows application development environment. It is not an exaggeration to realize a "hundred times improvement in productivity."[4] This is largely due to reusable code in the form of standard Windows interface objects such as "Buttons", "Textboxes", "Dialogue boxes" which are incorporated into Excel V5.0 and above.[5][6][7]
This was indeed found to be the case in this instance. Excluding writing the Bit3 DLL, a usable version was completed in one week with several more iterations and features added in the next three weeks. Each stage and major feature, such as generating a track and reading in a file, took about one week including conception, design, implementation, testing, debugging, refining and some slight performance tuning.
Having VB and Excel so tightly coupled is an empowering technology. It gives an implementor a choice of doing things in either the traditional linear programming method in a procedural language VB, C via a DLL and FORTRAN via DLL with restrictions, or using Excel to hold data in cells that would normally be held in internal arrays. By using a combination of both techniques one can literally build applications in a day. The VB syntax, "Cells(iRow,iCol).Value = myVariable" puts whatever is in myVarible in the cell specified by "iRow" and "iCol" of the active worksheet. (The converse is also true.) Thus data may be collected and inserted directly into a cell with a procedural language. Once the data is in the cells the user may view and further manipulate it with any Excel or user written function.
Alternatively one may read and write directly from and to a cell by placing the VME peek or poke function into the cell on the sheet. However in this method one relinquishes some control as to when the data is actually obtained. After the first or second time the sheet is re-calculated Excel stops accessing the VME crate because it does not know that it is External! An individual cell may be explicitly updated by clicking on the edit box and then clicking on the little check box of the active cell, which is like re-entering the formula and pressing the "Enter" key. This is tedious.
A work-around to force the VME bus access to take place is to change either the cell containing the address and/or value of the read or write function(s). Thus if all of the cells containing VME addresses are referenced to a cell containing a "base address", the VME I/O will take place when the base address is changed. A macro may read and temporarily store the base address, turn off automatic re-calculation, write a dummy VME address in the cell that all of the VME functions are referenced to; restore the original address, and finally turn on automatic re-calculation. Excel's recalculation algorithm recalculates all of the dependent cells so that the desired actual external VME bus cycle(s) take place.
VB syntax is object.method format which also may be chained: object1.object2...objectn.method. An object may be a single object or a collection of like objects indicated by plural suffix, "s". Thus objects is a collection and object refers to only one object while objects("an_object_name") or objects(indexNumber) refers to one member of a collection. The programming paradigm for the most part becomes "find the right object and method for what is desired" and then use it. There are a lot of objects and methods to try to sort through but a very useful "record macro" feature is provided that allows one to record a segment and then edit it.
In Booch's terminology[8], VB is "Object-Based" and not truly OOP, or Object Oriented Programming because VB does not support "inheritance". VB does not allow objects or the classes to which they belong to "inherit attributes from" other classes. Fortunately there are a rather large number of pre-defined and useful classes of objects included. Also other libraries of VB "Custom Controls", "Controls" or "VBX" file(s) which may be purchased from other vendors or written by the user in C.
All timing was obtained visually by observing a light emitting diode, LED, on the VME hardware. The LED showed when the module was being accessed by the Gateway 2000 Model "4DX2-66E" with eight Mbytes RAM. This is an Intel 486 externally clocked at 33 MHz with the CPU doubled to 66 MHz on internal 8K byte cache hits. The "E" indicates this is an EISA bus for enhanced ISA and is backward compatible with ISA cards. (Recall that the Bit3 Models 403 and 406 are ISA cards.) Three runs were averaged after the extremes were discarded using a manual electronic stop watch displaying seconds in hundredths.
The algorithm used was a simple do loop with a VME read or write call the only statement in the loop. The length of the loop varied from 3000 Excel cells to 100,000 for the VB and C loops to keep the loops long enough to minimize human timing error (5 to 13 seconds).
Initially all C code was functionally equivalent to Reference 1. This produced (unpublished) times uniformly slower by 22 to 25 s than Tables 1 and 2. Performance gains were made by not calling two Windows Functions", "AllocSelector" and "FreeSelector", each time a VME read or write operation was performed. Instead the address "Selector" was obtained at DLL and program initialization and released at termination. Although this is contrary to recommended Windows programming practice due to the relatively small number of available Windows "Selectors", performance gains make it worth while in this instance.
All Table timings are in s. Table 1 is with the Bit3 Base Address in Protected Address Space. Table 2 is with the Bit3 set in Real Address Space. The difference between Table 1 and Table 2 is that ~ 25 s worth of DPMI code is not executed each VME read or write operation.
Table 1 Bit3 Base
Address at $800000. Timings in s.
Table 2 Bit3 Base
Address at $D0000. Timings in s
Table 3 timings are included as baselines. Item 4 of this table is published in the Bit3 manual and is faster because it excludes arbitrating for the VME bus by going to dual-ported memory on the Bit3 card in the VME crate. All other times were obtained using the Bit3 as VME bus arbitrator to access the same module over the VME bus as in previous tables.
Timing 1 of Table 3 is included as a reference point. It cannot be directly compared to Table 2, Line 4 because it is implemented is DOS Turbo Pascal code rather than C. It might be used to estimate similar DOS based C code without some Windows overhead. Both timings contain similar error handling logic and both compilers are by the same vendor with optimization off.
Bit3 writes are two-stage pipelined and are intrinsically faster than the one-stage read as Line 4 of Table 3 shows. This advantage falls out and even degrades differently on different call stacks: Table 1 and 2 timings reflect that Read functions have only one long word argument: the VME address. Write functions have an additional argument: the value to be written to VME. Both functions return an integer used as error reporting.
The first two tables indicate that Excel's overhead for cell recalculation is on the order of approximately 3.5 ms. One sheet has an estimated 2,520 cells with data and/or functions in them. Recalculation time varied between 8 and 9 seconds. Doing the division gives a cell time of 3.17 to 3.57 ms per cell for the 486 described above. The large variance in time can be attributed to the non-deterministic Excel recalculation algorithm. Using the overlapping region of the two measurements gives about 3.5 ms per cell.
Excel and Visual Basic for Applications are enabling technologies providing excellent and inexpensive tools for rapid application development. Besides being relatively easy to use they are programmable and extensible. If interface bandwidth is not paramount then they can be a complete solution.
Windows performance penalties to external interfaces via DLL calls can be mitigated with care as Tables 1 through 3 show. In cases where bandwidth is paramount they may provide a quick intermediate solution as a prototype until a faster application using other methods can be developed.
Increased throughput could be obtained by using direct
memory accesses. Other Windows schemes including Dynamic Data
Exchange, DDE, and Object Linking and Embedding, OLE, are expected
to be slower but were not directly investigated.
Special thanks go to D. Huffman and L. Rasmussen, both of Fermilab, for invaluable assistance with the DPMI code.
[1] D.L. Huffman, "Reaching Physical Board Addresses In a PC From Windows Protected Mode" IEEE Nuclear Science Symposium & Medical Imaging Conference Record, 1994 Vol. 2, pp. 620. (D0 Note 2589)
[2] F. Borcherding, "Level 1 Trigger Design for the D0 Upgrade Central Fiber Detector", (D0 Note 2359) , Nov. 21,1994.
[3] D.E.Y. Sarna and G.J. Febish, Windows Rapid Application Development, Ziff-Davis Press, 1993.
[4] Electronic Engineering Times CMP Publication, March 13,1995 Issue 839, pp. 1.
[5] D.Arlt, K. Steele, G. Anderson, "Two Methods of Data Acquisition and Instrument Control in the Molecular Science Research Center", RT-93 Conference Record published in TRIUMF tech report: TRI-93-1, pp. 246.
[6] P. Reinhart, M.A. Ashour, K.D. Müller, F. Rongen, W. Tenten, Th. Oyevaar, H.F. Tammen, "Introducing the EISA-PC into an Existing Real Time Architecture", RT-93 Conference Record op. cit.., pp. 239.
[7] G. Di Pirro, C. Milardi, A. Stecchi, L. Trasatti, "DANTE: Control System for DANE Based on Personal Computers and High Level Tools", RT-93 Conference Record op. cit., pp. 250.
[8] G. Booch, Object-Oriented Analysis and Design , The Benjamin/Cummings Publishing Company, Inc., 1991, pp. 38.
[9] J.Webb, Using Visual Basic for Applications, Que Corporation, 1994.
[10] Microsoft Press, Microsoft Excel Software Development Kit Version 4, (this is a book with a disk.) Microsoft, 1993.