UNILAC Chopper - Firmware and Monitoring

Introduction

The main documentation about the (new) UNILAC chopper can be found here.

This wiki page only describes some aspects of the lm32 firmware and related monitoring, a dedicated how-to can be found here.

Setup and Procedure

Figure: Setup of the chopper control. Boxes: Components. Green-filled boxes: Components that are described on this wiki page. 3d-boxes: Components inside the same SCU. Other components like the data master are not shown.

The figure above depicts the setup of the chopper control.

The central component on the frontends host is the 'chopper control interface' CCI FESA class. It receives settings and commands from LSA and (mini)masp. Furthermore it receives timing messages from the White Rabbit network via the ECA and saftlib (blue arrows). For each UNILAC cycle the CCI calculates three 16bit words relevant for the chopper control unit. To transport this data to the lm32 firmware, the CCI injects one timing message into the saftlib (red arrows).

The central component for the frontends FPGA is the 'lm32 firmware'. This firmware is the only component that talks to the chopper control unit via the MIL device bus. The firmware receives data from the CCI and timing messages from the White Rabbit network (red + blue = magenta arrows). The firmware writes the relevant data to the chopper control unit. Moreover, the firmware reads the status from the chopper control unit and writes the status information as a timing message to the ECA (yellow arrow).

For monitoring purposes, a dedicated monitoring server process is used on the frontends host. It receives timing messages from the White Rabbit network as well as the timing messages with status data from the lm32 (yellow + blue = green arrows). The monitoring servers does some simple sorting and statistics and then publishes monitoring data to the ACC network to connected monitoring apps.

A monitoring app receives and displays monitoring data. Please note, that the multiple instances of the monitoring app may exist. The app can be started via the 'Launcher'.

The chopper control unit does the control of the chopper itself in hard real time. Only the choppers for the 'Hochladungsinjektor' (HLI) and the 'Hochstrominjektor' (HSI) are controlled. The unit contains several FPGA units and so-called 'Rahmenpulsgeneratoren' RPGs. The RPGs receive on-time information for each UNILAC cycle as MIL telegrams via MIL events buses. There are four RPGs, one each for the 'Quelle Links', 'Quelle Rechts', 'HLI' and 'HSI'. Relevant for the chopper control unit itself are the RPGs for HLI and HSI only. The RPGs are relevant for precise timing of the chopper control unit. Further input to the chopper control unit are hardware signals for 'fast interlocks' and target stations (caves). Thus the chopper control unit has multiple input sources.

• timing signals from the RPGs (HLI, HSI)
• settings data from the chopper control interface (FESA)
• hardware input signals

In case everything is ok, the chopper control unit will trigger the chopper itself via hardware signals (TTL?). Upon each chopper trigger, the unit will listen to hardware input signals from the chopper. Thus, the chopper control unit detects if the chopper has actually 'chopped' or not. The result is written to status registers which are read by the lm32 firmware after each cycle.

Firmware Activity

As the input from the host and the status information to the host is transmitted as timing messages via the ECA, the firmware is basically a simple timing message <-> MIL Devicebus gateway.

To this simple gateways chopper specific functionality has been added:

• Write 'Strahlweg Maske', 'Strahlweg Register' and 'Anfordermaske' to the chopper control unit.
• Read status information from the chopper control unit

Figure: Actions performed by the lm32 firmware. Actions are driven by events received via the ECA. Shown are three actions that are typically executed during one cycle (from top to bottom).

The figure above sketches activities that are executed by the firmware during one UNILAC cycle.

Start of Cycle
Every time EVT_COMMAND is received at HLI or HSI, it is assumed that a new UNILAC cycle has started. This initializes some internal data for book keeping. This is triggered twice (HLI and HSI). The order does not matter.

Write Set-Value to the the Chopper Control Unit
When set-values for the chopper control unit are received as a timing message, the deadline of the timing message dictates til when the values must be written to the chopper control unit. Here, also the firmware takes into account the time it takes for the transactions on the MIL Devicebus. There are two distinct cases:

• If the message is received too late, no data is written to the chopper control unit and an error flag is raised. In this case, neither the HSI nor the HLI chopper will chop.
• If the message is received timely, data it written to the chopper control unit. Moreover, the RPGs for HSI and HLI are enabled.

NB: Writing set-values is done for HLI and HSI simultaneously.

End of Cycle
Every time EVT_BEAM_OFF is received, value and status of the chopper activity will be read from the chopper control interface. This is done for HLI and HSI separately. The result(s) are sent to the input of the ECA. Interested users can receive the data and process them further. An example is the monitor server process on the host. Last but not least, the relevant RPG (HLI or HSI) will be disabled.

Write Standard MIL
This is not shown in the graph above. If this is received, the message contains information on

• MIL interface (= MIL piggy or SIO number)
• MIL slave address
• Module address (if applicable)
• Submodule address (= register inside module)
• data (16 bit)

The firmware will execute the relevant writing of data to the specified destination.

Read Standard MIL
This is not shown in the graph above. If this is received, the message contains similar information as in the case of 'Write Standard MIL'. The firmware will execute the relevant reading of data from the specified destination. The result will be written as a timing message to the input of the ECA.

Firmware Details

The firmware itself is quite simple. Like a couple of other firmware projects, it uses ('inherits') code provided in bel_projects/modules/common-libs:

• state machine
• common properties (DP RAM ...)
• communication with the ECA
• communication with MIL Devicebus
• ...

The firmware uses only the native MIL write (or read) procedure. It does not use the feature of function codes available in MIL IFA (slave) modules. Remark: 'Function codes' allow faster write/read operations on the MIL bus but have the disadvantage the they require additional configuration of the IFA modules.

Monitoring

Monitoring is implemented via a client (=app) and server approach.

The server is a process on the host. It receives relevant timing messages from the Data Master as well as 'local' timing messages sent by the firmware. The messages are received via saftlib. It performs simple book keeping and statistics. 32 sets of data are published: Data on 16 virtual accelerators (Sequence IDs) for HLI and 16 for HSI. Data are published as DIM services (IP/TCP). Data is updated 'on change'. Monitoring clients may subscribe and display the data. The monitoring client is an extremely simple app that is available from the 'ACO Launcher'.

-- DietrichBeck - 13 Nov 2024