THE DAQ COOKBOOK

Charis Quay Huei Li

Mount Holyoke College

July 23, 1999

Comments/Suggestions/Complaints/Hot Coals??

Send to: chquay@mtholyoke.edu OR bishai@fnal.gov

HOW TO RUN THE DAQ SYSTEM

THE BASICS

• Make sure that everything is hooked up right.
• You might want to cover the SVX device, be it chip card, hybrid or ladder. (If it is none of the above, you might have messed up on the previous step.) We have found that light sometimes has adverse effects on these things.
• Switch on the power supply. This must be done in the right order.
  1. 2V DOIM
  2. 5V DOIM
  3. AVDD (6V, unless regulator on port card blown; then 5V and bypass port card, i.e. feed power directly to chip.)
  4. DVDD (5V)
  5. VC204 (2.5V)
  There should be numbers or labels stuck on/near the various switches. If not, ask someone.

• If you are using an NT machine, start up Xstart. The icon should be on the desktop or under the program group Exceed. If it’s not on the desktop, when you find it, do everyone a favour and put it there.
• Connect to either fndaub, fndao2 (slaughte, david791), harv4, harv5 (svxii, harv_svxii) or svxiib (fccdaq, svxii_user). The first 2 machines are SGI’s. The other machines are Linux.
• At the prompt, type:
  cd ~/fccdaqX/rundaq (X = 1, 2, 3, 4; depending on your system.)
  source setup.csh (Sometimes you have to go to cd ~/devel to do this.)
• Check the file system.cfg (Figure 8) to make sure that the correct crates are in it. These usually look like <crate_name>.crate If they are not, run the perl script cfgsys or edit system.cfg. The necessary crate files should be sitting in the same directory. If they are non-existent, run cfgcrate to create them. The crate names are the MVME processor names. For more about cfg files, scroll down to the ‘Configuration Files’ section.
• Check the crate files to make sure that the modules are correctly set up. Again, if they are not, run cfgcrate. In some cases it might be necessary to also edit the cfg files of the modules (Figure 9). E.g. if the VRB is reading out channels you have nothing plugged into.

• At the prompt: svxdaq &

• The above window should pop up. This can take anywhere from no time at all to forever, depending on the state of the network connection.
• See the tabs at the top of the DAQ Control window? Click on DAQ => Init System. Lots of gibberish will scroll through both the xterm and DAQ windows. If all goes well, at the end, your x-term window will look like the one on the next page. See where it says ‘Total Chip Count: X’? X should be the number of chips you think you have hooked up to the system. Also, check in the DAQ window to see if it reports any errors. The most common complaint is that the system did not receive what it expected from the chip. If you see gibberish in your xterm window that seems more gibberishy than usual, with the word ‘java’ liberally interspersed throughout, it’s probably a configuration problem. Go back and check your system, crate and module configuration files.
  The long rows of hex numbers: Each is 197 bits packed in groups of 8 into 25 integers. The first row corresponds to the chip parameters on the FIB chip page, which are downloaded to the chip. The other 2 rows are read out from the chip. The 2nd row is what was in the chip before initialising and is pushed out first. Then the3rd row, which is what was downloaded. So if your first and third rows agree, you are in good shape. The picture below is for 1 chip.

Figure 2: X-term Window After Initialisation.

• When you have finally initialised the system, in the DAQ Control window, click on: File => Start Hist; File => Update Hist.
• In the grey (sometimes it’s blue) histogram window, pick your favourite histograms. E.g. Laser => Open; RHS window fills up with stuff.
  Pick histo types in RHS window, and click on any of the View buttons at the bottom. View opens each graph in a separate window. View Overlaid puts all the histograms in the same graph in the same window. With View Multiple, the histograms are tiled in a big window.
  This step is optional because the histo window is supposed to appear on its own. However, like LinAlg for physics majors, it’s strongly recommended. You get the idea.

• In the DAQ Control window: DAQ => Run DAQ. Pick a Run Type.
  The Histo Only radio button will output to histos only. The SRC generates triggers in this mode (and most others) and it’s what’s most commonly used.
  Laser will write the data to a file so it can be analysed later. Triggers are also SRC-generated. BTW, it is a good idea to retype the file name in the box on the right before laser runs. (The system is attention-deprived and likes you to do this. Sometimes it throws tantrums if you don’t.)
  Cal Inject is for when you inject charge into the chip. To do this, you also need to change things under the DAC tab in the FIB Status Page. You enter a 4-bit number there, the magnitude of which is directly proportional to the voltage ( and therefore the ‘charge injected’) on a 47fF capacitor. The voltage goes from 0-9V on the DPC. Not sure about the CPC.
  In Dead Timeless mode, the chip can handle new Level One Accepts (it queues them) at the same time as it is digitising and reading out. (Usually, you have to wait for it to digitise and read out before it can take another L1A. This is called dead time. Hence dead timeless.)
  I’ve never used any of the other runs. Cosmic/Beam is for when you are triggering on cosmic rays.
  Pedestal is a subset of the Histo Only run type. It analyses the data and outputs - I believe - Noise, Dnoise and a maybe a couple of other things to a file. It’s not used very much.
  SEU (Single Event Upset) Test was used for a one week test now shrouded in the mists of time that I know nought about. You probably don’t need to use it. If you are curious, go ask someone who’s been here longer than I have.
• Clicking on Error Handler brings up a window that tallies various kinds of errors (as specified by the user) as they occur.
• Then click on Begin Run.
• To end the run, click on End Run.

CONFIGURING MODULES

• There are (at least) 2 ways to configure modules, and it is best to know both, so that if you get screwed up one way, you can try the other.
• Let’s do FIB’s first. Go to the DAQ Control Window, and click on FIB at the left. You get the FIB status page (Figure 4).
• The thing we change most often is the Channel Enables. Click on the channels that you have HDI’s plugged into. Then click on WRITE at the bottom of the page. This saves your settings for that run only. If you want to permanently modify the file in the File: box (in this case std_chan0.fib) click on the disk icon labelled Save.
• You can also do the same thing in the UNIX window. Each of the options on the status page corresponds to several lines of code in std_chan0.fib, or whichever cfg file you are using. E.g. the line true Pipeline enable, Chan0 enables channel 0. If you edit the file, changing true to false, channel 0 is disabled.
• The other thing you want to look out for is that the G-links you’ve got coming out of the FIB are enabled. Table 1 shows which G-links correspond to which channels on the FIB and VRB.
• Note the bright green hemispheres scattered about the page. If they turn red, it means something is wrong, except for ‘132ns clock’ which is always red, for reasons unbeknownst to your truly.
• If you have more than one FIB set up, you can toggle between FIB’s by clicking on the arrows that say Next and Previous.

Figure 4: FIB Status Page.

Figure 5: FIB Status Page, Chip Section.

• Figure 5 on the previous page is the Chip section of the FIB status page, which we also frequently do stuff to.
• Mostly, we use this page when we want to initialise the chips only, not the whole system. You do this by clicking on either Write or Write All next to the pictures of the disks. In real life, they are supposed to do different things, but now there’s no difference. You can also do pretty much the same thing by initialising the FIB, i.e. clicking on FIB => Initialise FIB => OK in the DAQ control window. It takes fewer clicks.
• Pipe Depth corresponds to Pipeline Latency on the SRC Status page. It is the number of cells between an event and the corresponding Level One Accept. If you change Pipe Depth on the Chip page, also change Pipeline Latency on the SRC page. If you don’t the SRC pipe cap emulator and chip will disagree on which Cell ID they think was for which event. Also, when changing the Pipe Depth, remember to write to the chips (the write beside the diskette pix), not the FIB!

• Again, enable the channels you want to read out. You must enable both the Channel and the Data Link. If only the Channel is enabled, the VRB will make up fake data for that channel, and you will potentially spend days debugging it.

CONFIGURATION FILES EXPLAINED

Figure 8: system.cfg

• This is an example of what the file system.cfg can look like. There are 2 crates in it, cdfppc01 and daesw1.
• To change this file, you can either edit it manually, or run the script cfgsys.

Figure 9: daesw1.crate

• This is an example of a crate file, in this case, daesw1.crate We’ll go through a few of the modules.
• Let’s look at the FIB. It’s in slot 9. The base address is the slot number divided by 2, multiplied by 10000000 in hex. SVID has no meaning as far as I know/have been able to find out. The cfg file for this FIB is std.fib
• A // at the beginning of a line means it has been commented out.
• A note on HDI. It stands for High Density Interface, and I am told originally meant the cables that run from port card to chip, hybrid and ladder. However, it is now used variously for the cables, the channels on the port card that the cables plug into and even the SVX devices (the stuff on the port card).
• The section labelled [SVX] contains all the things on the port cards hooked up to the FIB. This FIB has 3 ‘SVX devices’ of 1, 1 and 4 chips respectively, on HDI’s 0, 2 and 3 on a port card. Since there is only 1 port card on this FIB, the HDI numbers go from 0 to 4. With 2 port cards, the second one has numbers from 5 to 9 - at least in the crate file. The slot number of the HDI device is the slot number of the FIB it’s plugged into. Chip objects of various sizes have different cfg files. 1chip.svx is used for single chips.
• This is a typical FIB cfg file.

Figure 10: std.fib

SCRIPTS

• cfgcrate (my masterpiece this summer) will allow you to add, remove and modify modules. It’ll change slot numbers and cfg files, calculate base addresses (automatically, you don’t have to tell it to) and add 1, 2, 4, 5, 6, 7, 10 and 14 chip objects to HDI's. It’s also been properly trained to squeal if you try to do illegal things like putting more than one module in a slot or inventing non-existent slot numbers.
• cfgsys is a very simple script that asks you for the names of your crates and writes them to system.cfg
• multichip is based on the single chip cfg file, 1chip.svx It allows changes to propagate rapidly through all the multichip cfg files. E.g. if you want to change the pipe depth, instead of changing it for every single chip in every file, merely change the number next to Pipe Depth in this script, save it, and then run. You have to mess with the actual script, so be careful not to delete important things like brackets and quotation marks.
• The scripts are by no means complete, but there are beta versions in ~/fccdaq3/rundaq and ~/fccdaq4/rundaq. It would be great if you could use them and tell me if you find any bugs or loose ends. Also if there is anything else you would like to see cfgcrate do, email me at chquay@mtholyoke.edu