Architecture validation and physics performance
Download
1 / 24

Architecture validation and Physics performance - PowerPoint PPT Presentation


  • 55 Views
  • Uploaded on

Architecture validation and Physics performance. Carlo Schiavi. Purpose of this study. The purpose of the analyses presented here is:

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' Architecture validation and Physics performance' - onaona


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

Purpose of this study
Purpose of this study

The purpose of the analyses presented here is:

  • to validate MCC-DSM architecture, studying its performance and robustness under nominal conditions, and comparing them with the ones obtainable from the MCC-D2 that was implemented using a less dense technology (DMILL);

  • to evaluate inefficiencies of the MCC in pessimistic working conditions but with a realistic physical content of data and to estimate their impact on the analysis and reconstruction of interesting physical channels.


Architecture validation layout
Architecture validation: layout

Insertable layout:

  • Barrel: 3 layers with 5.05, 8.75 and 12.25 cm radius.

  • End-Caps: 3 disks placed at 49.5, 58.0 and 65.0 cm along Z axis.

  • Pixel size: 50x300µm2 for the b-layer and 50x400µm2 in the others modules.


Architecture validation event sample
Architecture validation: event sample

Physical conditions:

  • event sample: 1500 b-jets from Higgs decays (mH=100GeV/c2);

  • average pile-up events: 24;

  • LEV1 selection rate: 100 kHz;

  • electronic noise occupancy: 10-5Hit/Pixel/BCO.

    Front-End configuration:

  • ideal model, no inefficiencies.

    SimPix simulation scope:

  • single b-layer module at =0.

Worst case conditions for the MCC at nominal occupancy


Architecture validation mcc set up
Architecture validation: MCC set-up

MCC parameter ranges:

  • Receiver FIFO depth: from 32 to 128 words.

  • Output serial line bandwidth: 40, 80 and 160 Mbit/s.

    MCC description:

  • reconstruction algorithm was not yet updated (MCC-D2)…

  • …but the output data format used was the MCC-DSM one, with the correct word sizes;

  • all hits contained ToTinformation.


Architecture validation performance
Architecture validation: performance

40 Mbit/s output rate

  • every configuration shows a1520% inefficiency;

  • using small ReceiverFIFOs, hits are lost due to Receiver FIFO overflows;

  • with bigger Receiver FIFOs, LEVEL1 triggers (i.e. entire events) are lost due to PendingLev1FIFO overflows;

  • both these inefficiencies are connected to output link saturation.


Architecture validation performance1
Architecture validation: performance

40 Mbit/s output rate

  • every configuration shows a 1520% inefficiency;

  • using small ReceiverFIFOs, hits are lost due to Receiver FIFO overflows;

  • with bigger Receiver FIFOs, LEVEL1 triggers (i.e. entire events) are lost due to PendingLev1FIFO overflows;

  • both these inefficiencies are connected to output link saturation.


Architecture validation performance2
Architecture validation: performance

40 Mbit/s output rate

  • every configuration shows a1520% inefficiency;

  • using small Receiver FIFOs, hits are lost due to Receiver FIFO overflows;

  • with bigger Receiver FIFOs, LEVEL1 triggers (i.e. entire events) are lost due to PendingLev1FIFO overflows;

  • both these inefficiencies are connected to output link saturation.


Architecture validation performance3
Architecture validation: performance

40 Mbit/s output rate

  • every configuration shows a1520% inefficiency;

  • using small ReceiverFIFOs, hits are lost due to Receiver FIFO overflows;

  • with bigger Receiver FIFOs, LEVEL1 triggers (i.e. entire events) are lost due to PendingLev1FIFO overflows;

  • both these inefficiencies are connected to output link saturation.


Architecture validation performance4
Architecture validation: performance

40 Mbit/s output rate

  • every configuration shows a1520% inefficiency;

  • using small ReceiverFIFOs, hits are lost due to Receiver FIFO overflows;

  • with bigger Receiver FIFOs, LEVEL1 triggers (i.e. entire events) are lost due to PendingLev1FIFO overflows;

  • both these inefficiencies are connected to output link saturation.


Architecture validation performance5
Architecture validation: performance

80/160 Mbit/s output rate

  • MCC-DSM (128 words) is perfectly efficientin nominal load conditions, as every set-up with more than 32 words;

  • MCC-D2 (32 words) is nearly critical: hits are lost both with 80 (0.3%) and 160 (0.015%) Mbit/s output rate;

  • Receiver FIFO occupancy is almost 5 times lower for the MCC-DSM (128 words) than than for the MCC-D2 (32 words).


Architecture validation performance6
Architecture validation: performance

80/160 Mbit/s output rate

  • MCC-DSM (128 words) is perfectly efficient in nominal load conditions, as every set-up with more than 32 words;

  • MCC-D2 (32 words) is nearly critical: hits are lost both with 80 (0.3%) and 160 (0.015%) Mbit/s output rate;

  • Receiver FIFO occupancy is almost 5 times lower for the MCC-DSM (128 words) than than for the MCC-D2 (32 words).


Architecture validation performance7
Architecture validation: performance

80/160 Mbit/s output rate

  • MCC-DSM (128 words) is perfectly efficientin nominal load conditions, as every set-up with more than 32 words;

  • MCC-D2 (32 words) is nearly critical: hits are lost both with 80 (0.3%) and 160 (0.015%) Mbit/s output rate;

  • Receiver FIFO occupancy is almost 5 times lower for the MCC-DSM (128 words) than than for the MCC-D2 (32 words).


Architecture validation robustness
Architecture validation: robustness

MCC-DSM b-layer set-up:

  • Receiver FIFO: 128 words;

  • output transfer rate: 160 Mbit/s.

    Robustness:

  • up to occupancies 4 times greater than the nominal one;

  • to possible problems on one output link;

  • up to trigger rates 2 times higher than the nominal maximum one;

  • to different detector geometries.


Architecture validation robustness1
Architecture validation: robustness

MCC-DSM b-layer set-up:

  • Receiver FIFO: 128 words;

  • output transfer rate: 160 Mbit/s.

    Robustness:

  • up to occupancies 4 times greater than the nominal one;

  • to possible problems on one output link;

  • up to trigger rates 2 times higher than the nominal maximum one;

  • to different detector geometries.


Architecture validation robustness2
Architecture validation: robustness

MCC-DSM b-layer set-up:

  • Receiver FIFO: 128 words;

  • output transfer rate: 160 Mbit/s.

    Robustness:

  • up to occupancies 4 times greater than the nominal one;

  • to possible problems on one output link;

  • up to trigger rates 2 times higher than the nominal maximum one;

  • to different detector geometries.


Architecture validation robustness3
Architecture validation: robustness

MCC-DSM b-layer set-up:

  • Receiver FIFO: 128 words;

  • output transfer rate: 160 Mbit/s.

    Robustness:

  • up to occupancies 4 times greater than the nominal one;

  • to possible problems on one output link;

  • up to trigger rates 2 times higher than the nominal maximum one;

  • to different detector geometries.

No hits nor triggers lost at nominal pile-up level, even working with a LEVEL1 selection rate of 200 kHz.


Architecture validation robustness4
Architecture validation: robustness

MCC-DSM b-layer set-up:

  • Receiver FIFO: 128 words;

  • output transfer rate: 160 Mbit/s.

    Robustness:

  • up to occupancies 4 times greater than the nominal one;

  • to possible problems on one output link;

  • up to trigger rates 2 times higher than the nominal maximum one;

  • to different detector geometries.

No hits nor triggers lost at nominal pile-up level, even simulating the TDRlayout, where the b-layer had a radius of ~4 cm.


Physics performance event sample

MCC configuration:

similar to MCC-D2, not to MCC-DSM, which would have shown no inefficiencies;

Receiver FIFO: 32 words;

output transfer rate: 80 Mbit/s.

Front-End configuration:

ideal model, no inefficiencies.

Simulation scope:entire detector.

Physical conditions:

event sample: 500 b-jet and 1000 u-jet events;

three different pile-up conditions, giving detector occupancies equal to the nominal one, or 1.5 and 2 times higher;

electronic noise occupancy: 10-5Hit/Pixel/BCO;

LEV1 selection rate: 100 kHz.

Physics performance: event sample


Physics performance inefficiencies
Physics performance: inefficiencies

Results:

  • lost hits percentage grows with average detector occupancy;

  • inefficiencies are peaked on the b-layer; loss of space-points which mainly contribute to give a better resolution on impact parameter: we can expect an efficiency loss for track reconstruction and b-tagging algorithms.

Maximum inefficiency: 3%

Occupancy: equal to nominal one


Physics performance inefficiencies1
Physics performance: inefficiencies

Results:

  • lost hits percentage grows with average detector occupancy;

  • inefficiencies are peaked on the b-layer; loss of space-points which mainly contribute to give a better resolution on impact parameter: we can expect an efficiency loss for track reconstruction and b-tagging algorithms.

Maximum inefficiency: 12%

Occupancy: 1.5 times higher than nominal one


Physics performance inefficiencies2
Physics performance: inefficiencies

Results:

  • lost hits percentage grows with average detector occupancy;

  • inefficiencies are peaked on the b-layer; loss of space-points which mainly contribute to give a better resolution on impact parameter: we can expect an efficiency loss for track reconstruction and b-tagging algorithms.

Maximum inefficiency: 40%

Occupancy: 2 times higher than nominal one


After words
After words

MCC-DSM performance:

  • the solution developed by the Genoa team for the MCC-DSM implementation is fully efficient in nominal conditions and very robust to increases in detector load and to possible problems on one output link;

  • the previous DMILL implementation (MCC-D2) wouldn’t have been as robust, being in critical conditions even at its maximum output rate.

    Impact on interesting events reconstruction:

  • inefficiencies are peaked on the b-layer;

  • that means losing those space-points which mainly contribute to the impact parameter resolution, with consequent efficiency loss for track reconstruction and b-tagging algorithms based on pixel detector data.


What s next
What’s next

  • Correctly evaluate Front-End inefficiencies and their impact: an up-to-date model of FE must be developed, to estimate the percentage of hit lost before they are transferred to the MCC;

  • repeat this kind of study using an updated model for MCC behaviour:new Receiver and EventBuilder algorithms must be correctly simulated…

    …anyway…

    the new features shouldn’t affect the results for MCC performance as:

  • FE inefficiencies can only reduce MCC load;

  • Receiver and EventBuilder new algorithms should prove more efficient than the old ones.


ad