The VM-USB supports eight readout stacks. A stack can be thought of as a set of VME operations the VM-USB should perform in response to some trigger condition. Reads performed by a stack are placed in an event buffer. Writes occure but result in no data. At appropriate times, the VM-USB transmits buffers of read events to the host computer over its USB interface. Stacks provide avoid the high latency of the USB bus by pushing the readout intelligence for events into the VM-USB, and out of the host.
The VM-USB supports 8 stacks, and three kinds of triggers for stacks. While all stacks can be interrupt triggered, we simplify the VM-USB usage by only allowing stacks 2-7 to accept interrupt triggers, defining stack 0 to be only triggerable on the NIM1 input, and stack 1 to only be triggered with some time periodicity.
The stack command allows you to compose stacks
and specify their trigger conditions. When data taking is
enabled, all defined stacks are loaded into the VM-USB and
their triggers set up. Stacks are composed by specifying the
set of modules they should read via the
configuration option. All modules in a stack are initialized
at stack load time and read when the stack is triggered, in the
order in which they were specified.
The create subcommand creates a stack named
will be used by you in future config and
cget subcommands to refer to this stack.
The config subcommand allows you to configure
the stack contents and trigger conditions of the stack.
name determines which stack will be configured.
The configuration is specified via a set of option value
pairs. These are described in OPTIONS below.
The cget command returns the configuration of the stack as a well formed Tcl list of option value pairs.
-triggernim1 | scaler | interrupt
Defines the strigger source for the stack. When the designated trigger is present, the stack will execute. nim1 triggers the stack on a nim logic true pulse to the IN1 input of the VM-USB. This forces the stack to be VM-USB stack number zero as that is the only stack that can be triggered by the IN1.
triggers the stack on the periodic scaler. This forces the stack
to be stack number 1 as that is the only peridically triggerable stack.
We restrict periodic triggers to time based periodicity rather than
event division periodicity. The
defined below must be configured as well to define the periodicity
of the scaler stack.
indicates the stack will be interrupt triggered. This can be
used for stacks 2 through 7 as defined by the
configuration parameter. The actual VME interrupt that will trigger
the stack is defined by both its interrupt priority level
-ipl and the status id the interrupt source
places on the backplane in response to the interrupt acknowledge
cycle, and specified with the
The default value for
Defines the number of seconds (integer) between scaler stack triggers.
This is ignored for all stacks that are not scaler
-trigger-ed. The VM-USB manual defines the range of legal
values for this option.
Defaults to 2.
Defines the stack number for interrupt
-trigger-ed stacks. This is an integer value
in the range 2-7 inclusive. This will also select the
interrupt register used to define the trigger for the stack.
Defaults to 2, the first interrupt driven stack. Note that each stack must have a unique stack number. The nim1 triggered stack will be stack 0, the scaler stack will be stack 1.
stacks, this defines the status Id that must be presented by
the interrupt source in response to an interrupt acknowledge
to trigger the list. This taken together with the value of the
-ipl configuration option defines the trigger
condition for these stacks. The
must be a value between 0 and 0xffff
Note that while the
-vector parameter is
a 16 bit value, all modules we have produce 8 bit vectors.
The VME standard is ambiguous about how the top bits of
an 8 bit vector are returned when read by a 16 bit wide
statusID cycle. The standard allows these bits to either
be set or clear. Where we know what individual modules
do, we have documented that. If what your module
does is not documented, we have not charted what the module
does. Try either setting those bits to 1 or 0 and please
let us know what you find so that we can improve
This defaults to 0.
Defines the interrupt priority level that of the interrupt that will trigger the stack. An iterrupter places a 3 bit interrupt priority level (IPL) on the VME bus when it requests an interrupt. The IPL must be nonzero and is intended to reflect the priority of the interrupt (7 highest, 1 lowest), although, in fact, the VME standard allows interrupt responders to treat this value in any way they want.
The VM-USB uses the specified
part of the trigger condition for an interrupt
-trigger-ed stack. When an acknowledged interrupt
matches both the
-ipl, and the
configuration parameters of a stack the stack is triggered.
The default value is 6.
The VM-USB allows you to define a delay between the stack trigger condition and the actual start of stack execution. This is normally intended to be used with stacks that are triggered on nim1, as there may be a significant time between the generation of an external trigger and the conversion of the digitizers associated with the trigger. As I read the VM-USB manual, however this delay applies to all stacks.
microseconds is the number of microseconds to delay
(0-255) between triggers and stack executions. Because of my understanding of the
intent of this delay, the
is ignored for all stacks that are not nim1
In the very unlikely event that you need to apply a trigger delay
to interrupt triggered stacks (most hardware interrupts when data
are ready not on a trigger), and you are not using nim1
triggered stacks, simply build a non-empty nim1 triggered
stack, set it's
-delay option to the required delay and never trigger
that stack (don't cable anything to the IN1 input).
Otherwise you can insert delay modules in
The default -delay value is 0
Defines the set of modules that will be read out. This can be a valid Tcl list of any set of modules that have been defined so far. The modules are specified in the order in which readout commands for them will be added to the stack. If you have built a caenchain add that to the stack rather than adding the individual modules.
Lists of modules must be valid Tcl lists thus:
stack config astack -modules adc1 adc2 adc3 ; # Incorrect stack config astack -modules [list adc1 adc2 adc3]; # Correct.
-modules value is an empty
list. Since an empty lsit is not allowed,
you will need to explicitly configure this option.
The example below is a rather complete demonstration of how to define a set of modules, adc's and scalers, aggregate the three adc's into a caenchain, and read that chain as a stack triggered on NIM1, and read a pair of scalers triggered every two seconds.
Example 1. Building Stacks
adc create adc1 0x04000000 adc config adc1 -geo 12 -supressrange off -ipl 0 -vector 0 adc create adc2 0x05000000 adc config adc2 -geo 13 -supressrange off -ipl 0 -vector 0 adc create adc3 0x06000000 adc config adc3 -geo 14 -supressrange off -ipl 0 -vector 0 caenchain create chain caenchain config chain -base 0x10000000 -modules [list adc1 adc2 adc3] sis3820 create scaler1 0x35000000 v830 create scaler2 0x80000000 sis3804 create scaler3 -base 0x38383800 stack create events stack config events -trigger nim1 -modules chain -delay 12 set scalers [list scaler1 scaler2 scaler3] stack create scalers stack config scalers -trigger scaler -modules $scalers -period 2