AtlasRODFormatter

Introduction

The AtlasRODFormatter is a VHDL-entity which formats data according to the ATLAS ROD - format proposed in "The event format in the ATLAS DAQ/EF prototype-1" (Atlas Daq note 50: ATL-DAQ-98-129). Data is formatted in order to be sent via an SLINK. It is put here because it could be of use for other developers who have to implement a ROD on their cards.

The AtlasRODFormatter has been developed for the ALTERA FLEX 10K series (it is acutally used with a 10K50V). It is used in the MIROD which is the Processor interfacing the LVL1 trigger system with LVL2 and the Data Aquisition. The MIROD is part of the MUCTPI (MUon to CTP Interface).

The code is using LPMs but NO Altera-specific generics or features. Therefore it should be easy to port the code to FPGAs of another vendor.

Features

The following restrictions hold for the entity (but can be modified if needed for other applications:)

• The format is "hardcoded" to have exactly 2 status words (but variable length data section ).
• The status words are sent after the data words.
• The Format version number, Source Identifier and the Detector Event type are defined by generics.

The entity offers the following features:

• The number of data elements which is inserted into the trailor can be provided by an internal counter or externally.
• The Formatter can be told to ignore the SLINK flow control lines. This allows for tests without functional SLINK hardware connected to the board.
• The Formatter can be forced to generate an empty event containing only Header, status words, and trailor. This can be useful to suppress the transfer of corrupted data.
• It is possible to implement a SLINK-Bus-Analyzer. It monitors the Bus (data lines and control lines) to the SLINK. Data being transfered to the SLINK are written in parallel to an internal Fifo which can be readout afterwards to analyze the activity on the Bus-lines. Two modes are possible:
  • "Valid-Data-Only-Mode" writes only words into the Fifo which have the uwen = '0'.
  • "Bus-Analyzer-Mode" samples all Bus-lines every clock period. (Typical clock frequency for Atlas is 40MHz).

  Software (for unix) is provided which turns a formatted dump of the Fifo into a formatted table and into a ps-file which contains a graphical representation of the Bus-Analyzer. In addition a fig-file is produced which can be read in by the xfig-program (unix) and allows you to edit the graphical output for example for presentations. Here is an example of the graphical output:

  

Documentation

The if you download the package you will be provided with this documentation and with the vhdldoc documentation generated with the vhdldoc package. You can browse the vhdldoc - documentation also online. In addition you can look at two examples where the AtlasRODFormatter is actually used. In the DaqProcessor and in the Lvl2Processor an AtlasRODFormatter is used.

Software

If you download the package you will get

• The VHDL soure code for the AtlasRODFormatter
• The complete documentation
• The program to convert a dump of the Bus-Analyzer Fifo into a graphical output
• An example of how to generate a Bus-Analyzer dump of with the correct format. The example is a C++ method which shows how to format the data. You need to provide functions to access your hardware in order to use it. It is given here only for showing how to format the data.

Download

Click here to download the package into a directory of your choice. Then type (on unix)

• gunzip AtlasRODFormatter.tar.gz
• tar -xvf AtlasRODFormatter.tar

You will find a directory AtlasRODFormatter with the following subdirectories:

• CSLIB, PRIM : contain the vhdl-code
• documentation : contains the documentation
• software : the code example and the program SlinkAnalyzerFormatter to format the fifo dump

Remarks

This entity has been developed for the MIROD which is part of the MUCTPI. It is used in the interface to the LVL2 ROI-Builder and in the ROD of the MUCTPI (both units are implemented in the MIROD module.) Tests have been exccecuted (in particular to test the flow-control with the S-LINK lff signal) but it is not excluded that some "features" have not yet been discovered, since the MIROD has not yet been tested in a system with a complete SLINK connected to it. (The tests have been performed with the SLIDAD). Also not yet implemented is the possibility to drive the utest line low. But this is a very easy task to do.