MLU Programming
The CAEN 1495 is programmed as an MLU to form triggers.
Picture of MLU
http://userweb.jlab.org/~rom/mlu.xfig.png
GUI used for control
Picture
http://userweb.jlab.org/~rom/mlugui.png
Instructions: Login to "atrig" an adaq computer and type "trigsetup". The GUI is obvious but if you need help press "HELP" on it for more info.
Some related technical info follows
The MLUs are CAEN 1495 boards with specific FPGA programming (explained below) deployed on both the L-HRS and R-HRS. The MLUs are set up by VME-based IntelPCs: on L-HRS it is intelha3 and on the R-HRS it is halladaq8. All the following instructions work for both MLUs.
The trigsetup GUI invokes scripts on the intel PCs.
New as of April 15, 2014: the outputs can be disabled. This is fairly obvious with both "trigsetup" GUI.
When that PC reboots it puts the MLU into the state defined in /root/mlu/modefile. The code /mlu/initmlu which writes to the mlu is invoked. This code is also called every 4 minutes under cron, just to ensure that the MLU is always in the right state (does no harm). Finally, the code is called when the PC reboots, using an entry in /etc/rc.local The trigsetup GUI interacts with the MLU by talking to a server which writes to /root/mlu/modefile and then does a system call to invoke /mlu/initmlu
Programming Details
MLU programming.
Feb 5 2014 R. Michaels
Note, channel #1 is at the bottom.
There are 3 inputs
A and B - 32 chan ECL -- to be ignored
E - 8 chan NIM -- to be used
There are 3 outputs
C - 32 chan LVDS (converted to ECL with another board)
F - 8 chan NIM
A ||
||
B || * E NIM input
|| *
LVDS output C || * F NIM output
|| *
The outputs are arranged so that (with indices starting at 1):
C(1-8), C(9-16), C(17-23), C(24-32), and F(1-8)
are identical.
This provides 5 copies of the trigger signals.
Inputs on E
1. S0 scintillator
2. S2 scintillator
3. GC gas cherenkov
4. SH shower
5. EDTM
6. Clock
GMp Standard Triggers
Outputs
1. S0 & S2 (logical "and")
2. S0 & GC
3. S2 & GC
4. S0 & SH
5. S2 & SH
6. GC & SH
7. EDTM
8. Clock
Single Detector Triggers and other triggers
Single Detector Triggers -- Alternative MLU -- software selectable.
(normally not used, but might be used by DVCS)
Outputs
1. S0
2. S2
3. GC
4. SH
5. S0 || S2
6. (S0 & S2) || (S0 & GC) || (S2 & GC) 2/3 trigger
7. EDTM
8. Clock
Detailed Notes
Here are some notes from testing the setup in the TEDF building.
Notes from testing
All the NIM outputs have appropriate polarity.
One must take care to select the jumpers so that NIM inputs
have 50 ohm termination -- otherwise you get reflections.
There were a couple channels that didn't have 50 ohm even
with the jumpers set right; Bill Gunning fixed it.
The ECL outputs 7 and 8 are flipped polarity.
This could affect some timing.
For the LVDS to ECL converter I have, 4 channels were bad
(index starting at 1): 7, 9, 23, and 32.
We'll also need to ask for more converters.
Input pin #8 on the NIM mezzanine E is broken on L-HRS MLU.
We don't use it, though. We should get spare cards.
The delay through the 149/adaqfs/home/atrig/mlu5 to NIM output is 20 nsec.
The logic follows the timing of the inputs. Jitter
is negligible.
If the power is turned off
-- the FPGA programming is preserved
-- but the module must be initialized with
software, or there is no output.
We have arranged to initialize the MLU with software
whenever the VME board is rebooted.
=== Even more Programming Details (added April 10, 2017) === Since some people want to make a new MLU and since I have trouble remembering, here is a core dump of more details. The FPGA file used by GMp is mlu_14apr14.rbf which was copied to a generic name gmp_mlu.rbf because the code that writes to the FPGA looks for that file. The rbf file was compiled on atedf3 using Quartus. To get to the executible On atedf3: cd ~adaq/altera/10.1sp1/quartus/linux and then ./quartus The project was "bobdev" atedf3:~adaq/altera/bobdev/Development1/SRC I used the Demo from CAEN. ./v1495usr_demo and I hacked coin_reference.vhd. The main action is the mapping of E and F. E are NIM inputs and F are NIM outputs. There is also some mapping of LVDS but they were generally not used. The "operator" bit drives the mode; there were 2 modes for GMp as explained above : GMp Standard Triggers and Single Detector Triggers. Also, the outputs could be disabled by using a mask. These data (mode bit and mask) were written to the MLU by way of software, a GUI and a client/server, see below. On halladaq8 and intelha3 there are two areas: /mlu and /root/mlu. I don't quite remember why but it had to do with write permissions that we had to split it that way. Warning: the sources on /mlu are not be up-to-date (but the executibles are). I'm pretty sure that the most recent sources / executibles are in adaq1:/adaqfs/home/atrig/mlu v1495.c -- a library to write to the MLU fpga.c -- a main code that uses the library to write the the MLU. Issue: since halladaq8 and intelha3 were 32-bit machines I was compiling on adaql1 (note the "l") which was an old 32-bit machine, now defunct. This will need to be ported to adaq1 (without the "l") or somewhere else. If you're interested in using the client/server it is in adaq1: /adaqfs/home/atrig/tcp. This is a classic Linux-to-Linux TCP/IP client/server code using BSD sockets. If you're interested in the GUI that controls the mode and mask, then it's in adaq1:/adaqfs/home/atrig/trigmang. I recall that the way I developed this was to first write scripts "setmlu" and "getmlu" which interacted with the client/server code. Then I wrote the ROOT GUI HaTrigGui.C / trig_main.C which calls these scripts using system commands. Splitting it this way separates the debugging / development. However, if you don't need configurability by Users, you can maybe skip using a GUI or a client/server. Hopefully it's obvious that you should not modify codes in place (although we do have backups). Instead, make a copy.
