-- BorislavMilanovic - 27 Jul 2009

TRBnet Monitoring System

On this page, the new monitoring facility for the TrbNet will be presented. Any user may feel free to contribute to the topic, to state his/her own requirements and to extend the functionality until the desired degree of freedom has been reached.

The newest version is currently beeing tested and optimized in the IKF labs (Goethe University). It is by far not the final version, as the monitoring system is intended to be extensible to fit all the future TRBnet experiments (HADES, FAIR, CBM).

There are also lots of configuration possibilities open, so please let me know - what do You want/need?

Requirements

Following aspects of a universal monitoring system were in the center of attention during the design phase:

• Simplicity (low ressources)
• Extensibility
• Flexibility
• Real-time access and configuration

HW Architecture

The whole monitoring system has been redesigned lately to meet all the future requirements. TrbNetRegIO is used to provide access to the monitoring facility, hence read and write signals can be used directly on the 4-th channel of the TRBnet, not interfering with other more critical low level signals.

There are 2 types of monitoring cells by now:

• Registers (Address 3000 - 3FFF)
• FIFOs (Address 2000 - 20FF)

Every cell may be configured extensively by the user. Width, depth, frequency and ringbuffer-mode are just a few possibilities. An online configuration can also be performed, even during beamtime, using the config-cells. The register cells are simple, use almost no ressources and allow a direct peek into the FPGA-driven hardware (like temperature, voltages, etc.).

The FIFOs can be used to track time-sensitive events. There are big FIFOs which use one or more Block-RAMs and the small LUT-FIFOs, using logic cells only. They both insert new data only at a given frequency. If the frequency is high enough, even logic analyser output can be monitored. Current tests have confirmed that data can be written to the FIFO every clock-cycle, i.e. every 10ns. All information about the FIFO-types is stored in a ROM on each FPGA. On the first start, the monitoring system simply reads out the entire ROMs and knows exactly which addresses, sizes and types of cells it has to deal with.

More information will follow soon.

Data packing

This figure illustrates the contents of a FIFO cell. It is possible to tagg any signal comming from the detector with a timestamp and the event-number. There are 3 different timer domains:

• Global time - is the same on all TRBs
• Local time - provides higher accuracy (no sync)
• Time since last trigger

Together with some FIFO-generics like timer-resolution and time-width it is possible to adjust the timestamp exactly to the FIFO type beeing used. Different signals need different timer resolutions, as they do not provide raw detector data with same frequencies.

Possibilities

All FIFOs are predesigned to suit every experiment in near future. Each one can be used in a ringbuffer mode. Usually, when a FIFO is full, it discards all the new data packets trying to be written. In ringbuffer mode, it discards the oldest packet, when near full. Therefore only newest and freshest values are kept inside. When the ringbuffer mode is being used, it can be turned off. However, if a FIFO is built to not support the ringbuffer mode, it can not be turned on again (but the FIFO will spare some resources). Following FIFO sizes were specified:

Fifo list	Type
8 x 16	LUT
8 x 32	LUT
16 x 16	LUT
16 x 32	LUT
32 x 16	LUT
32 x 32	LUT
64 x 16	LUT
64 x 32	LUT
16 x 1024	1 BRAM
16 x 2048	2 BRAM
16 x 4096	4 BRAM
32 x 512	1 BRAM
32 x 1024	2 BRAM
32 x 2048	4 BRAM
64 x 512	2 BRAM
64 x 1024	4 BRAM

Every FIFO has following configurations:

Config
..	..	3	2	1	0
..	..	halt	input checking	ringbuffer mode	reset

Software Part

Soon, an EPICS implementation will follow. However until then, the user can control the entire monitoring procedure over a command-line interface. A client is connected via Ethernet (TCP/IP) with a server. The server is synthesized in one FPGA anywhere on the TRBnet. The client (outside the TRBnet) can read out FIFOs, Registers, ROMs and write to the config cells. The server awaits instructions and uses 'trbcmd' classes to gain access to the TRBnet over the ETRAX interface. The server is a daemon. Once started on one ETRAX chip with Linux, it listens for incomming TCP/IP instructions. The client can then first acquire all ROM information and configure itself, and afterwards this configuration (addresses, FIFOs, etc...) can be used for precise user control. The client should soon support an EPICS interface for a fine GUI control and signal visualization.

Due to 'trbcmd', the user can specify one single FIFO address the should be read out, and since all FPGAs on a particular sub-detector are built alike, the user receives this monitoring signal (from the FIFO) for every sub-detector node at once.

Discussion

Current topic - EPICS integration

• MonitoringDiscussionForum

---

-- BorislavMilanovic - 31 Jul 2009