From f3c96258b4b244f555fdd4e5cd71e77e9566a8d9 Mon Sep 17 00:00:00 2001 From: Michael Traxler Date: Fri, 24 Aug 2018 15:48:58 +0200 Subject: [PATCH] added warning for delayed data sending from TRB3 to eventbuilder, mt --- trb3/GbeDataReadout.tex | 28 +++++++++++++++++++++++++++- 1 file changed, 27 insertions(+), 1 deletion(-) diff --git a/trb3/GbeDataReadout.tex b/trb3/GbeDataReadout.tex index 91ad40f..26ecc87 100644 --- a/trb3/GbeDataReadout.tex +++ b/trb3/GbeDataReadout.tex @@ -24,7 +24,33 @@ Default buffer depths allow the following data sizes configuration: \end{table} \subsection{Data Readout} -TrbNetData module constructs Hades data packets out of the fragments received from the TrbNet endpoints. In standard case, those are the edge FPGAs, but it's possible to use the TRB3 board as a HUB and collect also data from "slave" boards. A Hades packet is formed as an entity called HadesTransportUnitQueue and there are several ways of constructing it. In general event fragments from all the connected endpoints are buffered one after the other, encapsulated with proper headers on several levels: subevent headers, queue headers, UDP headers, IP headers and Ethernet as a final step. +TrbNetData module constructs Hades data packets out of the fragments received +from the TrbNet endpoints. In standard case, those are the edge FPGAs, but +it's possible to use the TRB3 board as a HUB and collect also data from +"slave" boards. A Hades packet is formed as an entity called +HadesTransportUnitQueue and there are several ways of constructing it. In +general event fragments from all the connected endpoints are buffered one +after the other, encapsulated with proper headers on several levels: subevent +headers, queue headers, UDP headers, IP headers and Ethernet as a final step. + +The GbE-part is made for highest performance, so it allows you to store many +events, until the internal buffer is full and then send the data away via UDP, +to save the overhead and more important to save the number of interrupts on +the receiver machine. This allows us to increase the trigger rate to >100kHz. + +\begin{warning} +But this has the following consequence: The UDP data is always delayed by one +trigger, so for each trigger the data is sent from the previous event. This +warning is only intesting for users who don't use DABC as the event-builder. +\end{warning} + +For the standard user this is hidden: the trigger is synchronous but the data +arrives, as we use an asynchronous LVL2 DAQ system, at different times at the +Evenbuilder for each module in the system. The DABC-eventbuilder +takes care that the data is then sorted again via the trigger-number (24 +sequential number + 8 bit random number from the CTS). This way we are sure +that there is no mixing. + \subsection{Addressing} Each TRB3 board has a unique MAC address which is constructed in following way: \newline 02:00:BE:UNIQUE$\_$ID(31 downto 8), where UNIQUE$\_$ID(31 downto 8) is a value read out from the temperature sensor and differs between boards, the first part is constant. This address is used only for the network and SlowControl packets. Data readout addressing is stored in a block memory under base address 0x8100 and has to be configured manually. As there is a way to distribute packets to several event building machines or processes, all of those addresses need to be written into this memory with the following structure: -- 2.43.0