Getting Started with the UCI DSP System: I. Card Description The UCI DSP assembly consists of three main cards: the VME card, the DSP card, and the LL card. LL cards vary with the application, e.g., SLL is the UCSC silicon strips LL card, PLL is the LBL pixel LL card, OLL is the Oxford silicon strips LL card. Boards designed by UCI can be identified by the part number printed on the boards' silkscreens. E.g., UCI-VME-1.0 is the part number of the VME card. Except for purposes of repair, there is no need to separate the VME card from the DSP card. LEDs: The three LEDs near the front edge of the DSP/VME assembly are called 'forward LEDs'. They are under DSP software control. Once the DSP's system code is downloaded, they may have a variety of meanings. Before the download, they mean the following: Flashing green LED: the DSP is testing its memory and has detected no errors. Flashing yellow LED: the DSP is testing its memory and has detected one error. Flashing red LED: the DSP is testing its memory and has detected more than one error. It is normal for the flash rate to be irregular. Steady yellow LED: the system download process has begun. The duration of this condition depends on the size of the system, how many downloads are occurring simultaneously (if more than one DSP was targeted for the download) and the speed of the VME host. A few seconds is typical. Steady red LED: the download failed. The host-resident software will log an error. All LEDs on: the download is complete and control has been transferred to the downloaded system. The downloaded system typically changes the LED state immediately, so the all-LED-on condition will not normally be seen. The four LEDs in the interior of the DSP/VME assembly are called 'aft LEDs'. The green LED lights whenever the VME card acknowledges a VMEbus transfer. The yellow LED lights briefly at power-up and indicates that programmable logic (the Xilinx chip) is not yet configured. If this LED stays on, the board may need repair. One red LED, marked D1, is controlled by DSP software. The DSP turns this light off at reset; it will turn it on if there is an error during the system download (see below). The other red LED, D2, is controlled by the VME host processor. Its state is undefined at power-up. During the download process, the DSP initialization software running in the host turns the LED off, but will turn it on again if there is an error during system download. A note on LEDs and DSP reset: By writing a special value to the first location in the DSP's dual-port RAM, the VME host can pause a DSP immediately after the DSP is reset. This mechanism is used to insure orderly initialization of the download and messaging systems. While the DSP is paused, the forward LEDs will be in an unknown state, as will be a red aft LED, D1. This state of affairs will not normally persist more than a few seconds. Pushbuttons: The RESET pushbutton (SW1 on the DSP card) resets the DSP. DSP reset may also be initiated by host software, so there will rarely be a need to use the RESET pushbutton. SW1 on the VME card re-configures the Xilinx chip on the VME card. There should never be a need to press this pushbutton, hence it may not even be installed. DIP Switches: Note: ignore any lettering on the switches themselves. Refer to the switch numbers on the silkscreen. S5 on the DSP card is a four-bit DIP switch. Its meaning is determined by DSP software and is TBD. S1 on the VME card is an eight-bit DIP switch. The entire DIP switch may be read by DSP software. The five switches labeled 4-0 are hardwired as VME address selects. The card is selected when the five bits on the DIP switch match the five most significant bits of the VMEbus address. E.g., if 32-bit VMEbus addressing is used, the card is selected when switches 4-0 match address bits 31-27, respectively. The card only responds to 24-bit and 32-bit VMEbus addressing. It ignores 16-bit addressing. Jumpers: The DSP card is shipped with no jumpers installed. The VME card is shipped with only one jumper, JP6, installed in the '7905' position. This jumper determines the source of the -5V supply voltage: '7905': -5V is derived from the VMEbus -12V supply by the LM7905 (U24) 'AS6': -5V is derived from the VMEbus +5V supply by the optional AS6-5-5 (U25) no jumper: -5V is supplied via an auxiliary power connector, e.g., H1 If the 7905 cannot safely provide sufficient -5V supply current for the particular LL card installed, change the JP6 jumper to the AS6 position and install a Lamda AS6-5-5 DC-DC converter. II. Hardware self-tests 1. If an LL card is installed, remove it. The operations below do not require an LL card. 2. Check that VME connectors P1 and P2 have no bent pins. 3. Install the DSP/VME card assembly into a powered-down VME rack. Power up the rack. You should see a flashing green LED near the front of the rack. The D2 aft LED may or may not be on. All other LEDs should be off. 4. Power down the rack. It will probably take a while for you to get the software described below to work on your system. III. Software acquisition 1. Use your UCI account to ftp to your local computer all of the files from the directory: /tmp_mnt/u/demon/atlas/dsp/dsphost All of the files are text files. 2. Become familiar with the files you ftp'ed: vtest.c stand-alone VME card DPRAM test program Makefile make file for hostsam hostsam.c a sample host application, see below hos_init.c host-specific functions hostspec.h host-specific definitions --- do not modify any of the files listed below --- --- consult UCI if changes are desired --- dsp_init.c DSP initialization code (including system download) v_com.c VME host communication eboot.h definitions used by dsp_init.c and the DSP's boot code sys_gen.h definitions common to DSP system and host sys_pub.h public communication definitions sys_priv.h private communication definitions sys_main.asc an ASCII-formatted version of the DSP's operating system This version of sys_main.asc is for use with the SLL board, but it may be used for all of the tests described herein. If you need a sys_main.asc file for use with another type of LL board, consult UCI. Only vtest.c and Makefile, hostsam.c are not intended for use in the final system. IV. VME card dual-port RAM test 1. Modify your copy of the file vtest.c to work with your VME host (the version at UCI works with VxWorks on a 680xx CPU). You will need to calculate appropriate base addresses (base_24 and/or base_32) for your system and set the VME card DIP switches as needed (see the DIP switch discussion above). If your C compiler does not use 32- bit integers, you will have to change some things. Because this program was not originally intended for wide use, it was not coded for easy porting to other systems. You may use base_24=base_32. The two different base addresses were originally used to verify VME card operation. Note that your operating system probably maps VMEbus addresses onto other addresses in the host's memory space. VxWorks provides a function for translating VMEbus addresses to local addresses. Your operating system may provide a similar function. 2. Run the program on your host. If all goes well, it will print out messages that tell you total accesses, total errors, etc. The green aft LED will stay on or flash, indicating that the board is being selected by the VMEbus. The D2 red aft LED will flash randomly (this is important). This program does not affect the boot code running on the DSP, so the green forward LED should continue flashing. See the note in the vtest.c source file about how the boot code uses the first 24 words of the dual-port RAM. This note explains how you can purposely generate vtest errors by pressing the DSP's reset button. Note: Because vtest.c only interacts with the DSP's dual-port RAM, it can be tested by substituting for the DSP any VMEbus card having at least 2049x32 bits of RAM. V. DSP initialization and ECHO test The goal here is to get the 'hostsam' program running on your system. This program initializes the DSP (which includes resetting it and downloading the system) and then repeatedly sends ECHO messages having random length and random parameters to the DSP. The DSP responds by exporting one ECHO_REPLY message to the host for each received ECHO message. The ECHO_REPLY message length and parameters are copied from the corresponding ECHO message. The host compares the message sent with the message received and reports any discrepancies. Once this program works, the theory goes, all future communication between the host and the DSP should work as well. 1. Study hostspec.h and make modifications appropriate for your system. Make sure that int32 and u_int32 are defined as appropriate for your compiler. For these first tests, do not change how CLOCK() works. CLOCK() is used to watch for timeouts. Once the tests work, modify CLOCK() to use a more sophisticated timekeeping function, if available on your system. 2. If necessary, add your own functions in hos_init.c. This will probably not be necessary initially. Eventually you may want to override the error reporting system in dsp_init.c by coding functions of your own and redefining LOG_ERR() and LOG_BOOT() to use your own functions. For these first tests, do not change simp_clock(); it is used to check for timeouts. 3. Modify hostsam.c to use the same VME base address you used for vtest. See the function com_init(). Also make sure that the path (char* filnam) specified in the call to send_sys_ech() points to your copy of sys_main.asc. The hostsam program runs on VxWorks as is. If you are creating a standalone program for another system, add a main() function that calls send_sys_ech(). If you are merging hostsam with an existing program, make a call to send_sys_ech(). The send_sys_ech() function never returns--if there is an error, exit() is called. 4. All of the .c files you acquired from UCI, except vtest.c, should now be compiled and linked into a single executable to be run on the host. You may find 'Makefile' useful for this. You may need to modify Makefile to work with your system. Run the executable. 5. If there are problems, you should see printed error messages. If an error message does not include a dump of the boot structure, then the problem is probably confined to the host. If the boot structure is printed out, then the problem could be the host, the DSP or the interface between them. Print out the file eboot.h to help you diagnose problems. The eboot.h file describes boot structure contents, error codes, and the boot process. VI. Other host software Examples of host software can be found in: /tmp_mnt/u/demon/atlas/dsp/old_host The h8_1995 subdirectory contains the host software for the binary detectors as used at the 1995 beam test at H8 (CERN). The code in this directory violates the '--- do not modify any of the files listed below ---' requirement (above). It should not be used as the basis for new software, but it can provide insight into host/DSP interaction. VII. Current state of software development No one currently manages DSP or host software development. The following issues should be addressed: 1. The DSP has no run-time memory allocation routines. This will cause problems if end-of-burst readout mode is ever used. 2. The message protocol is not well-defined. Though message formats are precisely detailed, there are no rules regulating the conditions under which the DSP or host may send a message. There are no rules for exception handling. 3. A design flaw in the SLL user code will limit the maximum trigger rate. The code currently zeroes data memory at start-of-burst. The SLL input FIFO's will overflow if several triggers arrive while the DSP is zeroing memory--a certainty at high trigger rates. VIII. DSP software documentation The latest DSP software documentation is available on UCI's SUN in directory $DSPDOC: /u/demon/atlas/dsp/dspdoc files: dspdoc.ps complete document dspdoc_contents.ps table of contents dspdoc_concept.ps chapter concept dspdoc_system.ps chapter system code dspdoc_user.ps chapter user code dspdoc_ucsc_strips.ps chapter strips user code dspdoc_lbl_pixels.ps chapter pixels user code dspdoc_user_instr.ps instructions for DSP code developers using the UCI SUN dspdoc_index.ps index dspdoc_sys_mess.ps definitions of messages, action id's, flags, error codes: system dspdoc_ucsc_mess.ps definitions of messages, action id's, flags, error codes, and data format: strips dspdoc_lbl_mess.ps definitions of messages, action id's, flags, error codes, and data format: pixels The document mainly describes DSP code (running on the DSP). The name 'user' refers to LL card software developers. The files dspdoc_concept.ps and dspdoc_xxx_mess.ps contain information which is vital for the DAQ software developers. For LL card DSP software developers: the files *_codelist.ps contain the codelistings in postscript format: sys_codelist.ps system code ucsc_codelist.ps Santa Cruz strips code lbl_codelist.ps LBL pixel code LL_user_codelist.ps LL user code skeleton See the README file in /u/demon/atlas/dsp/dsphost for more about host-side software written at UCI. IX. Closing notes 1. The 'int32' and 'u_int32' types are defined in hostspec.h. They are 32-bit signed and unsigned integers, respectively. These types are necessary to insure that the host interprets values passed through the dual-port RAM in the same way that the DSP does. Examples of such values are message members, flags, and boot structure members. 2. The DSP+VME+LL assembly extends out of the rack about eight inches. UCI supplies a card guide extender; it supports several DSP assemblies and helps protect them from physical damage. 3. A memory expansion card, which increases the DSP's RAM from 256k x 32 to 512 k x 32, is available if needed. 4. UCI contacts Steve Pier: pier@nucleus.uci.ps.edu 714-824-3162 Department of Physics University of California, Irvine Irvine, California 92717-4574