Difference between revisions of "MLU Programming"

From Hall A Wiki
Jump to: navigation, search
(How to select the MLU programming)
Line 7: Line 7:
 
=== How to select the MLU programming ===
 
=== How to select the MLU programming ===
  
The L-HRS and R-HRS have MLUs deployed.  At the moment (as I write this) only the L-HRS MLU is being
+
The L-HRS and R-HRS have MLUs deployed.  The MLUs are controlled by the VME-based PCs:  on L-HRS it is intelha3
used in the trigger, though.. The MLUs are controlled by the VME-based PCs:  on L-HRS it is intelha3
+
 
and on the R-HRS it is halladaq8.  All the following instructions work for both MLUs.
 
and on the R-HRS it is halladaq8.  All the following instructions work for both MLUs.
  

Revision as of 13:53, 21 March 2014

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

Picture of MLU

http://userweb.jlab.org/~rom/mlu.xfig.png

How to select the MLU programming

The L-HRS and R-HRS have MLUs deployed. The MLUs are controlled by the VME-based PCs: on L-HRS it is intelha3 and on the R-HRS it is halladaq8. All the following instructions work for both MLUs.

To setup the MLU, login to intelha3 (unfortunately, you can only login as root as the moment) and type "setmlu" and answer the obvious question.

When that PC reboots it puts the MLU into the state defined in /root/mlu/modefile. This file is modified by setmlu, and the code that writes to the mlu is invoked. That code is /mlu/initmlu. 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

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

  Default programming desired by GMp  (per Bogdan W.)

     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 

  Alternative MLU -- software selectable.
     (normally not used, but might be used by DVCS)

     Outputs
       1. S0 
       2. S0 
       3. GC
       4. SH
       5. S0 || S2
       6. (S0 & S2) || (S0 & GC) || (S2 & GC)    2/3 trigger
       7. EDTM 
       8. Clock 

Notes from Testing

Here are some notes from testing the setup in the TEDF building. The MLU will be deployed on the L-HRS. We'll need to obtain more CAEN 1495 boards to instrument the R-HRS

   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 are 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.
       We don't use it, though.  We should get spare cards.

       The delay through the 1495 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 will arrange to initialize the MLU with software 
       whenever the VME board is rebooted.