1 / 7

Status of Group E2

Status of Group E2. Short term goal: define the S-Link data format and firmware specs for all Level-2 data paths. We would like to standardize the format as much as possible. What have we done so far: we have been focusing on understanding the data

lester-luna
Download Presentation

Status of Group E2

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Status of Group E2 Short term goal: define the S-Link data format and firmware specs for all Level-2 data paths. We would like to standardize the format as much as possible. What have we done so far: we have been focusing on understanding the data input format for the Level-2 interface boards and addressing some issues concerning Level-2 data bandwidth. Average Input Data Size for L2 Interface Boards With sparsification, we can easily reduce the muon data size by at least a factor of 10 (see Shawn/Mel’s talk). Now RECES has the largest contribution to the Level-2 bandwidth. Pulsar WG Meeting (C-J Lin)

  2. RECES Data Format • There are 48 fibers (one for each CAL wedge) from the SMXR crates in the • collision hall to the Level-2 RECES boards. • Each fiber sends 40 bits of data to the RECES interface board in 5 time slices. • - Time slice 0 ‘000000XX’, where XX is the buffer number, • - Time slice 1 bits 0-7 of SMXR data • - Time slice 2 bits 8-15 of SMXR data • - Time slice 3 bits 16-23 of SMXR data • - Time slice 4 bits 24-31 of SMXR data • 32 data bits are defined as: • - If a 4-wire sum exceeds a certain threshold (high or low), the • corresponding bit is set. • - Bits 0-15 are for high eta modules |z|>121cm, • Bits 16-32 are for low eta modules |z|<121cm. Pulsar WG Meeting (C-J Lin)

  3. Compressing RECES Data • Looking at occupancy in the RECES data using HIGH_PT_ELECTRON • sample (results from J/psiee, plug electron, and hadronic data are fairly similar). # of non-zero word (32-bit) # of non-zero high/low Eta word (16-bit)  No strong correlation between high and low |z| bits. Pulsar WG Meeting (C-J Lin)

  4. RECES Data Reduction • If we only send the non-zero high or low |z| words (16bits) to L2 CPU, • factor in addressing bits: • - Average data size ~200 bits/event • - Tail (3xRMS) data size ~500 bits/event • - Maximum data size 3Kbits/event • The current Pulsar L2 design should be able to handle 1.5Kbits/evt for • the RECES data. If needed or desired, significant reduction in RECES • data is achievable. • Will explore XTRP – RECES matching in the Pulsar pre-processor. • Not for data reduction, but to reduce the load from the L2 CPU. Pulsar WG Meeting (C-J Lin)

  5. Ted’s Mid-Term Tasks for E2 • Document All L2 data format (by the end of Feb): • - Muon : the muon data and timing specs are well understood • - RECES : data format is well understood, some timing issues • still need to be resolved with the experts. • - IsoList: we have the overall data flow and timing specs for • IsoList. Still need to confirm some data bits assignments. • - Clist: we have essentially all the information we need from Monica. • - TrkList and SVTList: well documented in CdfNote 4578. • What’s missing: • - I would like to have people actually looking at the data for each path • and not just know the specs. So far, we have only done that for • muon and RECES. • - Need to consolidate all the information on a website. Pulsar WG Meeting (C-J Lin)

  6. Ted’s Mid-Term Tasks for E2 • Software ready to derive real data patterns for EACH data path (March): • - We have software for the muon and RECES data. We have • been using it to study those two data paths. • - The same framework can be easily expanded for the remaining • data paths (within a day’s work). Again, it would be good to have • people actually looking at the data from the various paths (especially • for the people who will be writing the firmware). • Initial pass (documentation) for each data path based on algorithm • specifications (April): • I believe we are still on schedule for this item. We need to do • the exercise for the remaining data paths (as what we have done • for RECES and muon) and then we will be ready to specify • the algorithms. Pulsar WG Meeting (C-J Lin)

  7. Ted’s Mid-Term Tasks for E2 • Software modeling for each data path based on algorithm specification (May): • - Software modeling should be simple to implement when we have • the specifications. • - I hope by this time, we will have a clear picture of who’s working • on what path. This is the picture at the moment: • * Muon  Shawn and Mel, • * RECES  Cheng-Ju, • * CLIST  Cheng-Ju, • * ISOLIST  Cheng-Ju, • * SVT/TRKLIST Cheng-Ju. • (Not a pretty picture) • Finalize algorithm specification and system firmware specification. • Document everything!!! (June and July): • Too far down the road for my crystal ball to make any prediction. Pulsar WG Meeting (C-J Lin)

More Related