- 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?
Following aspects of a universal monitoring system were in the center of attention during the
- Simplicity (low ressources)
- Real-time access and configuration
The whole monitoring system has been redesigned lately to meet all the future requirements.
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.
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.
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
| 8 x 16
| 8 x 32
| 16 x 16
| 16 x 32
| 32 x 16
| 32 x 32
| 64 x 16
| 64 x 32
| 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:
|| input checking
|| ringbuffer mode
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.
Current topic - EPICS integration
-- BorislavMilanovic - 31 Jul 2009