stack -- Compose and configure VM-USB readout stacks.


stack create name

stack config name option value...

stack cget name


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 -modules 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 name . name 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.


-trigger nim1 | 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.

scaler 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 -period option defined below must be configured as well to define the periodicity of the scaler stack.

interrupt indicates the stack will be interrupt triggered. This can be used for stacks 2 through 7 as defined by the -stack 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 -vector configuration parameter.

The default value for -trigger is nim1.

-period seconds

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.

-stack stacknum

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.

-vector status-id

For interrupt -trigger-ed 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 status-id must be a value between 0 and 0xffff inclusive.

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

This defaults to 0.

-ipl priority

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 priority as part of the trigger condition for an interrupt -trigger-ed stack. When an acknowledged interrupt matches both the -ipl, and the -vector configuration parameters of a stack the stack is triggered.

The default value is 6.

-delay microseconds

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.

The 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 -delay option is ignored for all stacks that are not nim1 -trigger-ed.

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

The default -delay value is 0

-modules module-list

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.

The default -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