##### THE DAQ COOKBOOK

# Charis [Quay]{.underline} Huei Li

# Mount Holyoke College

July 23, 1999

# Comments/Suggestions/Complaints/Hot Coals??

Send to: [chquay@mtholyoke.edu]{.underline}

OR [bishai@fnal.gov]{.underline}

HOW TO RUN THE DAQ SYSTEM

### THE BASICS

#### Preliminaries

 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.

#### Start the Code

 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 edit the cfg files of the modules (Figure 9). E.g. if the
VRB is reading out channels you have nothing plugged into.

#### Run DAQ

 At the prompt: svxdaq &

![](media/image1.png){width="6.011111111111111in" height="3.2625in"}

[Figure 1: DAQ Control Window]{.underline}

 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.

![](media/image2.png){width="5.997222222222222in"
height="3.5444444444444443in"}

[Figure 2: X-term Window After Initialisation.]{.underline}

 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 2^nd^ row is what was in the chip before
initialising and is pushed out first. Then the 3^rd^ 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.

 When you have 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 (Figure 3), 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.

![](media/image3.png){width="4.249305555555556in"
height="4.384722222222222in"}

[Figure 3: Histogram Window]{.underline}

 In the DAQ Control window: DAQ  Run DAQ.

In the Run DAQ window (Figure 4), 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.

![](media/image4.png){width="5.436805555555556in"
height="4.468055555555556in"}

[Figure 4: Run DAQ Window]{.underline}

# 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.

+-----------------------+-----------------------+-----------------------+
| FIB Channel           | via G-link            | VRB Channel           |
+-----------------------+-----------------------+-----------------------+
| 0                     | 0                     | 0                     |
|                       |                       |                       |
| 1                     | 0                     | 1                     |
|                       |                       |                       |
| 2                     | 1                     | 2                     |
|                       |                       |                       |
| 3                     | 1                     | 3                     |
|                       |                       |                       |
| 4                     | 0 and 1               | 8                     |
|                       |                       |                       |
| 5                     | 2                     | 4                     |
|                       |                       |                       |
| 6                     | 2                     | 5                     |
|                       |                       |                       |
| 7                     | 3                     | 6                     |
|                       |                       |                       |
| 8                     | 3                     | 7                     |
|                       |                       |                       |
| 9                     | 2 and 3               | 9                     |
+-----------------------+-----------------------+-----------------------+

[Table 1: FIB/VRB/G-link Correspondence]{.underline}

![](media/image5.png){width="5.990972222222222in"
height="7.961111111111111in"}

[Figure 5: FIB Status Page.]{.underline}

![](media/image6.png){width="5.990972222222222in"
height="7.961111111111111in"}

[Figure 6: FIB Status Page, Chip Section]{.underline}

 Figure 6 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[^1], 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!

![](media/image7.png){width="5.020138888888889in"
height="6.831944444444445in"}

[Figure 7: VRB Status Page]{.underline}

 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

![](media/image8.png){width="5.997222222222222in"
height="0.6152777777777778in"}

[Figure 8: system.cfg]{.underline}

 This is an example of what the file system.cfg can look like. There
are 2 crates in it, cdfppc01 and daesw1. We have \_9 tacked on because
this is the version of daesw1 with FIB 9 enabled. This was before the
cfg script was widely used. ;-)

 To change this file, you can either edit it manually, or run the
script cfgsys.

![](media/image9.png){width="5.997222222222222in" height="3.8375in"}

[Figure 9: daesw1.crate]{.underline}

 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 part of a typical FIB cfg file.

## ![](media/image10.png)Figure 10: std.fib

# SCRIPTS

 cfgcrate (my masterpiece this summer) as its name suggests, modifies
crates. It 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

[^1]: In this document, 'real life' means Run II.