Busy Box and related
Contact info
The Busy Box Hardware and Firmware is developed at the Department of Physics and Technology, University of Bergen. For questions and enquiries please contact Attiq Rehman and Kjetil Ullaland.
Overview
ALICE is one of four large detectors situated at the collision points in the Large Hadron Collider (LHC) at CERN. The BusyBox is used by four of ALICE’s sub-detectors: Time Projection Chamber (TPC), Photon Spectrometer (PHOS), Forward Multiplicity Detector (FMD) and Electromagnetic Calorimeter (EMCal)
Triggers initiate data readout from ALICE’s sub-detectors and are received by the DCS board via an optical cable interface. The triggers and associated data are routed from the TTCrx ASIC on the DCS board to the BusyBox FPGA(s). Here, the L1a and Serial B line raw data is decoded by the Trigger Receiver firmware module.
Every time a trigger sequence starts the Fee starts buffering data, i.e. a buffer in the Fee is used. A valid trigger sequence ends with an L2a trigger and the event data along with the event ID is sent to the D-RORCs.
The purpose of BusyBox is to let the Central Trigger Processor (CTP) know when the Fee’s buffers are full by asserting a busy signal which prevents further issuing of triggers. The BusyBox and D-RORCs receives a unique event ID from the Fee after an event. After a valid trigger sequence ends the BusyBox will ask the D-RORCs if they have received the same event ID as the BusyBox did. If they do not reply with the same ID it means data has not been shipped from the Fee to the D-RORC, hence, the buffer in the Fee still holds event data.
The Fee buffers can hold 4 or 8 events and the BusyBox keeps track of free buffers. The busy is asserted if the buffers are full.
Interaction with the BusyBox is done through the DCS board, either via Ethernet or UART.
The BusyBoxes are located in the DAQ counting room.
BusyBox Hardware overview
The BusyBox uses the Virtex-4 LX-40 FPGAs with the ff1148 package from Xilinx. Each device has 640 user programmable I/O pins that support LVDS 2.5 standard used to communicate with the D-RORCs. The Virtex-4 can run on clock speeds up to 500 MHz, store 18 kbits in 96 BRAM modules and has DCM to provide flexible clocking and synchronization.
BusyBox Hardware tests at UiB
In one of our labs at UiB we have a setup for testing new BusyBox firmware in hardware before releasing it. The setup features a full readout chain for one channel of the ALICE TPC.
Components in LAB setup :
- Local Trigger Crate (LTU)
- Readout Control Unit (RCU) with Front End Cards (FEC)
- Local Data Concentrator (LDC) with 3 DAQ ReadOut Receiver Cards (DRORC) and date software.
- BusyBox with 2 FPGAs but only 1U rack.
See Also How to run the RCU - DRORC - Busybox setup
BusyBox Firmware
Busy Box Registers
See BusyBox Registers for latest updated information on firmware registers.
Source Code Repositories
BusyBox FPGAs
There are two versions of the BusyBox. One with two FPGAs and the other with only one FPGA. If only one FPGA is present it should be programmed with 'busybox_fpga1_solo.bit'. If two FPGAs are present then use 'busybox_fpga1.bit' and 'busybox_fpga2.bit'. From version 65 only one FPGA is in use. Make sure to program the second FPGA with 'fpga2_dummy.bit', else the FPGAs can not be accessed from the DCS card.
Compiled BusyBox Firmware Versions
Versioning
The busybox version number is now the same as the revision number of the source in SVN it was generated from. This should make it possible to get the original source files for any programming file. A register for the version number exists in the ctrl_regs module.
Revision 41
Non functional FW changes
- Signal names used globally in the design have been renamed: clocka => clk200, clockb => clk40, areset => rst40 /rst200
- All processes in all VHDL files used in the design, except for the trigger receiver module, have been updated to implement a synchronous reset.
- Since a stable clock is required for to perform a proper synchronous reset, a new module that implements reset logic has been added to the design in busylogic_top module. The reset logic will assert reset for as long as the DCM has not locked on the incoming clock. The reset will be released synchronously about 10 cycles after the DCM has asserted its locked signal.
- Since the actual clock of the LHC is 40.08 MHz and not the nominal 40 MHz the constraints for the implementation tools has been set 41 MHz. (85 degrees celsius, 41 MHz, 1.14 V)
Event verification module (event_validator_top)
This module has been modified so that the event ID queue now also contains the event info and event errors in addition to the event ID. The event info and event errors for the newest and current events are made available as registers. This extra info about the trigger sequence can be helpful when debugging. The event info contains the payload bit which is forwarded to the busy_controller. It is used in the process of calculating used MEBs.
Serial decoder
The serial decoder has been changed to reduce the resource usage. This module is replicated many times in the design so any improvement is significant. The old architecture used a shift register long enough to hold all bit-samples for one data frame (about 100 samples). The frame was captured in one go when a valid capture condition was found in the samples. The new architecture uses shorter shift register (about 10 samples) and only looks at a few samples at a time. Once the start condition is found it will capture the bits of the frame sequentially, bit by bit. The new architecture of this module has led to great improvements in resource usage. BusyBox firmware with 96 channels used to occupy approximately 96% of the FPGA. This number has been reduced to approximately 66%. Reduced resource usage makes it easier for the implementation tools to generate the programming file and it should also reduce the TDP of the device under operation.
DCS arbiter and address decoder
The architecture of this module has been updated to make it more readable and to register inputs such as address and data from the DCS bus master.
Registers
Extra registers has been added:
- Number of implemented channels. This number is actually the same as the generic g_num_channels.
- Current Trigger Event Info
- Current Trigger Event Error
- Newest Trigger Event Info
- Newest Trigger Event Error
Download
Revision 49
Free Buffer counting scheme
The buffer counter is now incremented on L2A only, and decremented as before on Valid Event signal (meaning that all DRORCs have received the current event). In previous versions the buffer counter was incremented on L1A and decremented on L2R, time-outs and valid events.
Trigger burst interlock
A new feature has been added. The purpose is to prevent long bursts of trigger. A maximum number of triggers in a burst can be defined in the burst size register. A counter ("leaky bucket") counts up until a the maximum value is reached for every L0 trigger received. It counts down on pulses from a pulse generator until minimum (0). The interval of these "leak-pulses" is programmable from 0 to 200 ms in 10 us steps. We are busy when the "leaky bucket" is full. This feature can be disabled by setting the burst size to 0 (default value).
Two new registers are added:
- Burst Size (address 0x2017)
- Burst Leak Time (address (0x2018)
A new status bit has been added to the Busy condition register to indicate Burst Bucket Full as the reason for Busy State.
Download
Revision 54
New Sparse mode
A new semi-multiple event buffer scheme is allowed. This allows a second event to be captured in the multi-event buffers even if sparse mode is enabled. Special care has to be taken to configure the number of buffers and the dead-time following the first of the possible two consecutive events.
A new registers has been added:
- Trigger Mode (address 0x2019)
A new status bit has been added to the Busy condition register to indicate that two events happened, and are now being read-out.
The use of this feature requires proper setting of registers, as described in the following:
- Set the no of multi-event buffers to 2 (rcu-sh w 0x2009 0x02)
- Set the L0 trigger time-out large enough to cover drift-time and SCEVL (for example to 200 us) (rcu-sh w 0x2008 0x14)
- Enable the new sparse mode (rcu-sh w 0x2019 0x02)
Other changes
- The buffers-in-use count of the Busy Condidion Register is now updated correctly in busy_controller.vhd.
- bb_bus_read now works correctly in busybox_tb_pkg.
- Fixed R/W bug of register 0x2008 (introduced in rev. 49)
Download
Revision 55
L1 time
RCU firmware with the bug fix related to reading and writing the event FIFO has been tested and used at P2 for a number of test done to check the multi event buffer functionality. Erroneous behaviour of trigger receiver module is no more observed neither at P2 nor in the RCU - Lab.
Download
Revision 57
Trigger Receiver L1 timer
The programmable time-out following the start of a trigger sequence now starts on L1A instead of Trigger module busy output (L0 trigger time-out).
Download
Revision 58
Using Trigger Receiver Module v 1.6 (20.01.2012)
- Single l2 messages does not generate CDH
- Added Extended L2 time window to allow for CDH+payload if L2 message comes in boundary regions of the legal l2 window. This includes new register.
This BusyBox firmware version has been compiled with ISE version 13.2
Download
Revision 63
Using Trigger Receiver Module v 1.9 (17.08.2014)
- New trigger classes with additional words for Alice CDH version 3
- Event FIFO is changed from Xilinx core IP to a generic component (inferred memory)
This BusyBox firmware version has been compiled with ISE version 13.2
Download
Revision 65
Using Trigger Receiver Module v 1.9 (30.06.2015)
- New trigger classes with additional words for Alice CDH version 3
- Register map is set according to RCU2:Old trigger address map is not valid. New address map is found hereFile:TTCrx_receiver_v2.0.2.pdf.
- Reduced number of links on Busy box to comply with new DAQ architect (40 Links). TPC has 36 links (18x2=36), 4 additional links are kept for EMCAL.
- There is only one FPGA needed to work so FPGA1 will be programmed.
- -- Hardware note: In this release busy signal from FPGA2 is not used and related I/Os are disabled in Xilinx constraint file.
Logical address mapping to physical connectors on busy-box
- Reference point is GREEN LIGHT on connector side of the busy box (set at LEFT): D: Down, U: Up, L: Left.
0x2100:DL1 0x2101:DL2 0x2102:DL3 0x2103:DL4
0x2104:UL1 0x2105:UL2 0x2106:UL3 0x2107:UL4
0x2108:DL5 0x2109:DL6 0x210A:DL7 0x210B:DL8
0x210C:UL5 0x210D:UL6 0x210E:UL7 0x210F:UL8
0x2110:DL9 0x2111:DL10 0x2112:DL11 0x2113:DL12
0x2114:UL9 0x2115:UL10 0x2116:UL11 0x2117:UL12
0x2118:DL13 0x2119:DL14 0x211A:DL15 0x211B:DL16
0x211C:UL13 0x211D:UL14 0x211E:UL15 0x211F:UL16
0x2120:DL17 0x2121:DL18 0x2122:DL19 0x2123:DL20
0x2124:UL17 0x2125:UL18 0x2126:UL19 0x2127:UL20
This BusyBox firmware version has been compiled with ISE version 13.2
Download
Revision 66
Using Trigger Receiver Module v 2.1 (06.06.2016)
Click for Trigger Receiver updates
- This release only updates the trigger receiver module and firmware is tested to receive all valid trigger sequences.
- Please perform a complete integration (DAQ+RCU+BusyBox) test in lab before using it at experiment.
This BusyBox firmware version has been compiled with ISE version 13.2
Download
DCS board firmware for BusyBox
The DCS board in the BusyBox uses special firmware. See Electronics for the TPC
Generating FPGA configuration files from source code
- Check out the desired revision from the SVN repository.
- Navigate to .../busybox_firmware/trunk/ISE_projects
- Run the TCL script named bbiseproject.tcl with Xilinx' TCL interpreter. The script takes three commandline arguments :
- fpga_version - see #BusyBox FPGAs
- source_dir - where the source code is located. Including constraints and cores.
- project_dir - location where project is created. Note folder has to exist and should not already contain an ISE project.
- Example:
D:\busybox_firmware\trunk\ISE_projects>xtclsh bbiseproject.tcl busybox_fpga1_solo ..\source test
- Generate the cores with CoreGen (If it not already done)
- This can be done by using the CoreGen GUI or by invoking coregen in batch mode from the commandline. To use the GUI; start coregen while in .../busybox_firmware/trunk/source/cores.
- For batch mode : .../busybox_firmware/trunk/source/cores/coregen -b 'core'.xco replace 'core' with real name for all *.xco-files.
- Example with DOS for loop: D:\busybox_firmware\trunk\source\cores>FOR %i IN (*.xco) DO coregen -b %i
- Open the project with ISE Project Navigator.
- Run process 'Generate Programming File'
