Difference between revisions of "Output data structure in CODA"

From PolWiki
Jump to navigationJump to search
 
(8 intermediate revisions by the same user not shown)
Line 1: Line 1:
−
The electron detector readout boards(v1495) are currently outputting data in the following format:
+
The electron detector ROC reads out data from v1495 slave boards and puts it in various subbanks based on the source and type of the incoming data. This section elaborates the format and structure in which this data is written.
  
 
== Event types defined ==
 
== Event types defined ==
Line 6: Line 6:
 
   Event type 3 : electron single events
 
   Event type 3 : electron single events
 
   Event type 4 : coincidence of electron and photon single events
 
   Event type 4 : coincidence of electron and photon single events
 +
  
 
== Sub banks used ==
 
== Sub banks used ==
Line 20: Line 21:
 
   Parameter information about Slave-3 : 0x209
 
   Parameter information about Slave-3 : 0x209
  
−
If the TS2 did not receive either of the type-1 or type-4 triggers then the message logger will start printing "Event type and number are:" followed by the value assigned to the variable event_ty
+
  Scaler Data from Slave-1 : 0x20A
 +
  Scaler Data from Slave-2 : 0x20B
 +
  Scaler Data from Slave-3 : 0x20C
 +
 
 +
  Scaler module 3801 in ROC2 : 0x210
 +
 
 +
  redundant, if an event type different from defined values is encountered : 0x211
 +
 
 +
== Format of electron detector data ==
 +
On every helicity reversal trigger(MPS), the contents of the Buffer with single event patterns is read out along with the contents of the accumulation counter for each strip. Each of these triggers will result in creation of the subbanks for the the event and accum data of the slaves used. (currently we are using 2 slaves, since we consider only the first 64 strips to have relevant information) Hence we have a total of 4 subbanks relevant to electron detector readout on each MPS trigger. Following diagram shows a typical view of the data structure as seen through XCEFDMP.
 +
 
 +
[[Image:DataWithCalibInput 17.png]]
 +
 
 +
Next subsection elaborates the contents of the individual subbanks
 +
 
 +
=== Structure inside subbank '''0x201''' and '''0x202'''===
 +
 
 +
The single event data from v1495 slave-1 and slave-2 goes into 0x201 0x202 respectively.
 +
 
 +
The subbank has five 32 bit words.
 +
1st word: hit-map on plane-1 for strip 1 through 32
 +
2nd word: hit-map on plane-2 for strip 1 through 32
 +
3rd word: hit-map on plane-3 for strip 1 through 32
 +
4th word: hit-map on plane-4 for strip 1 through 32
 +
5th word: self-check info for the respective slave:
 +
  "0"| buf_RD_EMPTY | buf_FULL_ERR | buf_BUSY | buf_RD_COUNT(8bits) |"0000" | raw_trig_CNT(12bits) | "000"| Helicity
 +
  |<------------- 1st hex digit ------------->|<---- 2nd & 3rd ---->|<-4th->|<---5th, 6th & 7th--->|<-8th hex digit->|
 +
 
 +
For the last firmware revision, the 5th word is in the following format:
 +
  "0000"| "0" | buf_RD_EMPTY | buf_FULL_ERR | buf_BUSY | buf_RD_COUNT(8bits) | raw_trig_CNT(12bits) | "000"| Helicity
 +
  |<1st>|<--------------- 2nd hex digit -------------->|<---- 3rd & 4th ---->|<---5th, 6th & 7th--->|<-8th hex digit->|
  
−
== Structure inside Accumulation sub-bank ==
+
Details:
 +
* The above snapshot displays the 32 bits in hexadecimal format.
 +
* The least significant bit(bit 1) of the hit-map carries the hit-information of strip-1
 +
* Successively, the higher order bits represent hit-information for each next strip. Thus the 32 bits word has the hit-information of the 32 strips from that part of the detector.
 +
* The 5th word has the event buffer status information and the total number of triggers that were received during the previous helicity period. The information stored in this word is in the following order
 +
** Trigger Info
 +
*** least significant bit: the delayed Helicity
 +
*** next 3 bits: currently "000"
 +
*** next 12 bits: raw_trig_CNT1(11 downto 0)
 +
***
 +
** Buffer Status
 +
*** next 4 bits: currently "0000"
 +
*** next 8 bits: buf_RD_COUNT1(7 downto 0)
 +
*** next bit: buf_BUSY 
 +
*** next bit: buf_FULL_ERR
 +
*** next bit: buf_RD_EMPTY
 +
*** most significant bit: currently "0"
  
−
The accumulation data from electron detector goes into three sub-banks
+
=== Structure inside subbank '''0x204''' & '''0x205''' ===
−
  0x204: accumulation from slave-1
+
The accumulation mode data from v1495 slave 1 & 2 are written into subbank 0x204 and 0x205 respectively
−
  0x205: accumulation from slave-2
 
−
  0x206: accumulation from slave-3
 
  
−
Each sub-bank has thirty-two words of 32 bits. Each word has the following format.
+
The subbank has thirty-two words of depth 32 bits. Each word has the following format.
 
  Most significant byte(bits 32-23): no.of hits in plane-1
 
  Most significant byte(bits 32-23): no.of hits in plane-1
 
  Next significant byte(bits 24-17): no.of hits in plane-2
 
  Next significant byte(bits 24-17): no.of hits in plane-2
Line 35: Line 80:
 
  Least significant byte(bits 01-08): no.of hits in plane-4
 
  Least significant byte(bits 01-08): no.of hits in plane-4
  
−
The words are organized in order of increasing strips. For example in the following snapshot displaying data from bank 0x205(slave-2)
+
The words are organized in order of increasing strips. For example in the above snapshot displaying data from bank 0x205(slave-2)
 
  1st word has accumulation data of strip-1,
 
  1st word has accumulation data of strip-1,
 
  2nd word has accumulation data of strip-2,
 
  2nd word has accumulation data of strip-2,
 
  ... and so on
 
  ... and so on
−
For this run, a dummy input was given to pin numbers which correspond to strip # 1, 3 and 5 of patch-2 at a rate of 2.4kHz, the MPS was @1 kHz.
 
  
−
[[Image:EDet_accum_format.png‎]]
 
  
−
Hence you see 32 words, because each bank has information from each slave. Each slave carries information of 32 strips from all 4 planes.
+
=== '''Structure inside Parameter info sub-bank''' ===
 +
  0x207: parameter information about slave-1
 +
  0x208: parameter information about slave-2
 +
  0x209: parameter information about slave-3
  
−
== Structure inside single-event subbank==
+
Each sub-bank has nine words, each 32 bit in the following order
−
The single event data from electron detector goes into three subbank
+
''Identifier beginning word''
−
  0x201: singles from slave-1
+
Firmware Revision Number
−
  0x202: singles from slave-2
+
A mask
−
  0x203: singles from slave-3
+
B mask
 +
D mask
 +
E mask
 +
PWTL(8 bits) | PWDL(8 bits) | HOLDOFF(8 bits) | PL_Delay(8 bits)
 +
Rejection Width(16 bits) | Accum trigger condition(8 bits) | Event trigger condition(8 bits)
 +
''Identifier ending word'' (commented out in the current format)
  
−
Each sub-bank has five 32 bit words in the following format.
+
The respective slave identifier words are:
−
1st word: hit-map on plane-1 for strip 1 through 32
+
  '''slave #    beginning        ending'''
−
2nd word: hit-map on plane-2 for strip 1 through 32
+
  slave 1   0xb1000000      0xb100000f
−
3rd word: hit-map on plane-3 for strip 1 through 32
+
  slave 2   0xb2000000      0xb200000f
−
4th word: hit-map on plane-4 for strip 1 through 32
+
  slave 3   0xb3000000      0xb300000f
−
5th word: (some redundant information) 0x00000(20 bits) | Helicity(1 bit) | raw_trig_CNT (11 bits)
 
  
−
Following is a snapshot of the data bank as seen through xcefdmp.
+
As a visual example, the sub-bank parameter information as saved in run # 4042(taken Feb 2011) is shown in the following image.
  
−
[[Image:EDet_singles_format.png]]
+
[[Image:EDet parameterInfo format.PNG]]
  
−
Details:
+
=== '''Structure inside Scalar sub-bank''' ===
−
* The above snapshot displays the 32 bits in hexadecimal format. In the first 4 words, the least significant bit represent hit-information of strip-1 for all the 4 planes.
+
The structure in the Scalar subbank is an exact duplicate of the Accumulation subbank
−
* Successively, the higher order bits represent hit-information for each next strip. Thus the 32 bits word has the hit-information of the 32 strips in this patch of data.
 
−
* The 5th word (currently) has the information whether this data correspond to positive or negative helicity. followed by the total number of trigger that were received during the previous helicity period.
 
−
* (I intend to add the buffer status in the 5th word, which now has zero's)
 
  
 
----
 
----
  
−
Similarly, data from s2 and s3 contains the hit map of strip 33-64 and 65-96 on all planes respectively in the above order.
+
Similarly, data from slave-2 and slave-3 contains the hit map of strip 33-64 and 65-96 on all planes respectively in the above order.
−
 
 
−
 
 
−
This pattern can be changed with ease, but this is the format in which the most recent data files are found.
 

Latest revision as of 02:45, 14 December 2012

The electron detector ROC reads out data from v1495 slave boards and puts it in various subbanks based on the source and type of the incoming data. This section elaborates the format and structure in which this data is written.

Event types defined

 Event type 1 : Helicity Reversal events
 Event type 2 : photon single events
 Event type 3 : electron single events
 Event type 4 : coincidence of electron and photon single events


Sub banks used

 Single Event Data from Slave-1: 0x201
 Single Event Data from Slave-2: 0x202
 Single Event Data from Slave-3: 0x203

 Accumulation Data from Slave-1 : 0x204
 Accumulation Data from Slave-2 : 0x205
 Accumulation Data from Slave-3 : 0x206

 Parameter information about Slave-1 : 0x207
 Parameter information about Slave-2 : 0x208
 Parameter information about Slave-3 : 0x209

 Scaler Data from Slave-1 : 0x20A
 Scaler Data from Slave-2 : 0x20B
 Scaler Data from Slave-3 : 0x20C

 Scaler module 3801 in ROC2 : 0x210 

 redundant, if an event type different from defined values is encountered : 0x211

Format of electron detector data

On every helicity reversal trigger(MPS), the contents of the Buffer with single event patterns is read out along with the contents of the accumulation counter for each strip. Each of these triggers will result in creation of the subbanks for the the event and accum data of the slaves used. (currently we are using 2 slaves, since we consider only the first 64 strips to have relevant information) Hence we have a total of 4 subbanks relevant to electron detector readout on each MPS trigger. Following diagram shows a typical view of the data structure as seen through XCEFDMP.

DataWithCalibInput 17.png

Next subsection elaborates the contents of the individual subbanks

Structure inside subbank 0x201 and 0x202

The single event data from v1495 slave-1 and slave-2 goes into 0x201 0x202 respectively.

The subbank has five 32 bit words. 

1st word: hit-map on plane-1 for strip 1 through 32
2nd word: hit-map on plane-2 for strip 1 through 32
3rd word: hit-map on plane-3 for strip 1 through 32 
4th word: hit-map on plane-4 for strip 1 through 32
5th word: self-check info for the respective slave: 
 "0"| buf_RD_EMPTY | buf_FULL_ERR | buf_BUSY | buf_RD_COUNT(8bits) |"0000" | raw_trig_CNT(12bits) | "000"| Helicity	
 |<------------- 1st hex digit ------------->|<---- 2nd & 3rd ---->|<-4th->|<---5th, 6th & 7th--->|<-8th hex digit->|

For the last firmware revision, the 5th word is in the following format: 

 "0000"| "0" | buf_RD_EMPTY | buf_FULL_ERR | buf_BUSY | buf_RD_COUNT(8bits) | raw_trig_CNT(12bits) | "000"| Helicity	
 |<1st>|<--------------- 2nd hex digit -------------->|<---- 3rd & 4th ---->|<---5th, 6th & 7th--->|<-8th hex digit->|

Details:

  • The above snapshot displays the 32 bits in hexadecimal format.
  • The least significant bit(bit 1) of the hit-map carries the hit-information of strip-1
  • Successively, the higher order bits represent hit-information for each next strip. Thus the 32 bits word has the hit-information of the 32 strips from that part of the detector.
  • The 5th word has the event buffer status information and the total number of triggers that were received during the previous helicity period. The information stored in this word is in the following order
    • Trigger Info
      • least significant bit: the delayed Helicity
      • next 3 bits: currently "000"
      • next 12 bits: raw_trig_CNT1(11 downto 0)
    • Buffer Status
      • next 4 bits: currently "0000"
      • next 8 bits: buf_RD_COUNT1(7 downto 0)
      • next bit: buf_BUSY
      • next bit: buf_FULL_ERR
      • next bit: buf_RD_EMPTY
      • most significant bit: currently "0"

Structure inside subbank 0x204 & 0x205

The accumulation mode data from v1495 slave 1 & 2 are written into subbank 0x204 and 0x205 respectively

The subbank has thirty-two words of depth 32 bits. Each word has the following format. 

Most significant byte(bits 32-23): no.of hits in plane-1
Next significant byte(bits 24-17): no.of hits in plane-2
Next significant byte(bits 16-09): no.of hits in plane-3
Least significant byte(bits 01-08): no.of hits in plane-4

The words are organized in order of increasing strips. For example in the above snapshot displaying data from bank 0x205(slave-2) 

1st word has accumulation data of strip-1,
2nd word has accumulation data of strip-2,
... and so on


Structure inside Parameter info sub-bank

 0x207: parameter information about slave-1
 0x208: parameter information about slave-2
 0x209: parameter information about slave-3

Each sub-bank has nine words, each 32 bit in the following order 

Identifier beginning word
Firmware Revision Number
A mask
B mask
D mask
E mask
PWTL(8 bits) | PWDL(8 bits) | HOLDOFF(8 bits) | PL_Delay(8 bits)
Rejection Width(16 bits) | Accum trigger condition(8 bits) | Event trigger condition(8 bits)
Identifier ending word (commented out in the current format)

The respective slave identifier words are: 

 slave #    beginning         ending
 slave 1    0xb1000000       0xb100000f 
 slave 2    0xb2000000       0xb200000f 
 slave 3    0xb3000000       0xb300000f

As a visual example, the sub-bank parameter information as saved in run # 4042(taken Feb 2011) is shown in the following image.

EDet parameterInfo format.PNG

Structure inside Scalar sub-bank

The structure in the Scalar subbank is an exact duplicate of the Accumulation subbank

Similarly, data from slave-2 and slave-3 contains the hit map of strip 33-64 and 65-96 on all planes respectively in the above order.

Retrieved from "https://hallcweb-2024.jlab.org/polwiki/index.php?title=Output_data_structure_in_CODA&oldid=1254"