MLU Programming

The CAEN 1495 is programmed as an MLU to form triggers.

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

First, here are some notes from testing the setup in the TEDF building. Also, I've added more technical details of programming below such that one could reproduce the RBF files.

   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 we
split it into to those areas but it had to do with write permissions.
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

You will probably need these:

v1495.c -- a library to write to the MLU
fpga.c -- a main code that uses the library to write the the MLU.

Typically there is a README file in most directories; see that file.

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.

Tritium Era and Beyond (2017-)

The MLU-related source codes are available via github: https://github.com/JeffersonLab/HallA-MLU

driver/ contains the c programs that control of the v1495
mlu_design/SRC/v1495usr_demo/ contains the source vhdl files for the v1495 firmware
mlu_design/SIM contains vhdl source files, vhdl test-benches, and python programs for simulating the vhdl source files

The MLU now has three independent functions:

Clock Counter
- A simple counter that counts clock cycles of an external fast clock (port E(0))
- The count is reset by the VME read-out list in the CODA "Go" section
- The current count is recorded at read-out time for each physics event
- (Note: if using CODA in buffered mode, there can be a difference between trigger time and readout time for each event)

High-Rate Pseudo-Random Pulser
- https://wiki.jlab.org/tegwiki/index.php/File:McClellan_v1495.pdf
- Four output ports (F(0), F(1), F(2), F(3)) are driven by independent LFSR random pulsers
- A control GUI is available: execute "mlurand R" or "mlurand L" on an adaq machine to start the communication server and launch the GUI
- The minimum average rate is ~36 Hz, the maximum average rate is ~2.4 MHz
- NOTE: The output will get significantly less random as the average rate approaches maximum

BCM Digital Readout
- Final Implementation in Progress
- This function reads digital words from the E(2) port (connected to the BCM receiver)
- Interpreting the words as BCM values, this function keeps a running sum (reset at CODA "Go")
- At readout time for each event, the current value of the running sum is reported

MLU Programming

Contents

Picture of MLU

GUI used for control

Programming Details

Detailed Notes

Tritium Era and Beyond (2017-)

Navigation menu

Views

Personal tools

Navigation

Search

Tools