-- MichaelReese - 22 Aug 2017

Vetar2a: VME-WB bridge direct access mode

The normal mode of operation (after reset) of the Vetar2a card uses a VME-wishbone bridge. It means, that the ehterbone API has low-level control of a wishbone transaction. The details of the transaction are communicated over the host bus (VME bus in this case). A single cycle wisbone access (assert CYC, set SEL bits, set ADDR bits, assert STB, read ACK, release CYC) results in many VME transactions. These VME transactions read/write to/from some registers in the Vetar2a card using A24 (24-bit) addressing mode (VME address modifier AM=0x39).

By writing to a special register (direct access control register, DACTL) in the Vetar2a A24 address space (with address modifier AM=0x39), the Vetar2a card can be switched into a wishbone direct access mode. In the direct access mode, the normal bridge operation will not work anymore. Consequently no wishbone access via etherbone is possible in direct access mode. If saftd was running while switching into direct access mode it will die.

The address of the DACTL is 0x400*slot+0x4. The value of slot is given by the rotary switches on the Vetar2a card. The default value (in normal bridge mode) in DACTL is 0xffffffff. the Vetar2a module can be switched back from direct access mode into normal bridge mode by writing the value 0xffffffff into the DACTL register. Writing any other value into the DACTL register will immediately switch the module into direct access mode. The value written into DACTL (lets call this value WB_base_address) will be used as wishbone base address. In direct access mode any VME read/write access with address modifier AM=0x09 in the VME A32-address range [0x10000000*slot,0x01ffffff*slot] will be mapped into one single wishbone read/write access: WB_address = VME_address - 0x10000000*slot + WB_base_address.

The use case for this mode is low-latency access to wishbone devices in VME systems, such as data acquisition systems for experiments.

Example

For a DAQ appication, a NIM trigger signal should be timestamped with the ECA:TLU. The timestamp will be read by the host platform using the ECA:QUEUE (WB-address 0x40000c0) via VME direct access

1. Configure ECA:TLU using saftlib tools (Vetar2a card is /dev/wbm0)
   • start saft daemon: saftd vme0:dev/wbm0
   • configure ECA:TLU on input "IN": saft-io-ctl vme0 -b -n IN
   • configure ECA:QUEUE: saft-ecpu-ctl vme0 -c 0xfffe000000000005 0xffffffffffffffff 0 0 -d (the number 0xfffe000000000005 can be found with saft-io-ctl vme0 -s which will show input level changes on all inputs)
2. Switch into VME direct access mode (write value 0x40000c0 into VME address 0x400*slot+0x4 using address modifier AM=0x39). The saft daemon will die, but the ECA configuration will stay. Etherbone will not work anymore. The address 0x40000c0 is the base address of the Device "ECA_UNIT:QUEUE" and can be found out with eb-ls dev/wbm0.
3. Read the latched ECA timestamp from the ECA:QUEUE using VME address modifier AM=0x09. VME base address is 0x10000000*slot. The relevant registers have the following offsets
   • Check queue (read) : 0x08 (bit 4 is set for a valid event in the queue)
   • Timestamp-hi (read) : 0x28
   • Timestamp-lo (read) : 0x2c
   • Pop queue (write 0xffffffff) : 0x04

Known Bugs

It was observed that writing to register 0x04 will pop 2 values if present. If only one value is in the queue, only one value will be popped. For the current use case in DAQ this is not relevant, since only one value will ever be in the queue.