FE Software Emulator Progress Nikola Whallon University of - - PowerPoint PPT Presentation

fe software emulator progress
SMART_READER_LITE
LIVE PREVIEW

FE Software Emulator Progress Nikola Whallon University of - - PowerPoint PPT Presentation

FE Software Emulator Progress Nikola Whallon University of Washington April 14, 2017, LBNL Instrumentation Meeting 1 / 12 Current Emulator Flow Chart a lot of work has gone into refactoring the emulator to expand functionality and flexibility


slide-1
SLIDE 1

FE Software Emulator Progress

Nikola Whallon

University of Washington

April 14, 2017, LBNL Instrumentation Meeting

1 / 12

slide-2
SLIDE 2

Current Emulator Flow Chart

a lot of work has gone into refactoring the emulator to expand functionality and flexibility

YARR EmuManager Fei4Emu m fei4Pixels m fei4Cfg m fei4PixelModelCfg m pixelIterator Emu Fei4Pixel m fei4Cfg m fei4PixelModelCfg Pixel Fei4Cfg Fei4PixelModelCfg PixelIterator<Fei4Pixel> shm shm ClipBoard ClipBoard data flow pointer shared ptr inheritance x FE Num

not shown here:

◮ EmuManager runs 2 functions in their own threads: txLoop and rxLoop ◮ each Fei4Emu runs 1 function in its own thread: executeLoop ◮ txLoop waits until all Fei4Emu objects are ready for new commands (controlled by a mutex) before sending any new commands

2 / 12

slide-3
SLIDE 3

Further Refactoring

some further refactoring can still be done, but the design has converged quite nicely

YARR EmuManager Emu Fei4Emu m fei4Pixels m fei4Cfg m fei4PixelModelCfg m pixelIterator Fei4Pixel m fei4Cfg m fei4PixelModelCfg Pixel Fei4Cfg Fei4PixelModelCfg PixelIterator<Fei4Pixel> shm shm ClipBoard ClipBoard data flow pointer shared ptr inheritance x FE Num

3 / 12

slide-4
SLIDE 4

Adapting the Emulator for RD53A

with the new design, only a handful of classes need to be adapted for new FE types, and most of the classes are trivial to adapt

YARR EmuManager Emu RD53AEmu m rd53aPixels m rd53aCfg m rd53aPixelModelCfg m pixelIterator RD53APixel m rd53aCfg m rd53aPixelModelCfg Pixel RD53ACfg RD53APixelModelCfg PixelIterator<RD53APixel> shm shm ClipBoard ClipBoard data flow pointer shared ptr inheritance x FE Num

4 / 12

slide-5
SLIDE 5

RD53APixel

This class must implement a constructor, as well as the following virtual methods defined in Pixel.h:

v i r t u a l bool i s E n a b l e d ( ) = 0 ; v i r t u a l void i n i t N o i s e D i s t r i b u t i o n ( ) = 0; v i r t u a l f l o a t c a l c u l a t e T h r e s h o l d ( ) = 0; v i r t u a l f l o a t c a l c u l a t e N o i s e () = 0 ; v i r t u a l u i n t 3 2 t calculateToT ( f l o a t charge ) = 0 ;

Like with Fei4Pixel objects, the implementation of these methods will likely require pointers to the following objects:

std : : s h a r e d p t r<RD53ACfg> m rd53aCfg ; std : : s h a r e d p t r<RD53APixelModelCfg> m rd53aPixelModelCfg ;

this class is simple and straightforward, but will require 3 versions

  • f modeling functions for RD53A’s 3 analog frontends

5 / 12

slide-6
SLIDE 6

RD53APixelModelCfg

like Fei4PixelModelCfg, simple class to hold an array of variables for pixel modeling, initialized with a json file:

c l a s s Fei4PixelModelCfg { p u b l i c : RD53APixelModelCfg ( std : : s t r i n g j s o n f i l e p a t h ) ; ˜ RD53APixelModelCfg ( ) ; // 80 and 336 would change to whatever // the number

  • f

rows and columns i s f l o a t noise sigma mean [ 8 0 ] [ 3 3 6 ] ; f l o a t n o i s e s i g m a s i g m a [ 8 0 ] [ 3 3 6 ] ; f l o a t n o i s e s i g m a g a u s s [ 8 0 ] [ 3 3 6 ] ; //

  • ther

v a r i a b l e s which may need modeling // f o r example , g l o b a l t h r e s h o l d s

  • r TDAC v a l u e s

. . . };

this class is simple and straightforward, but will require 3 versions

  • f modeling variables for RD53A’s 3 analog frontends

6 / 12

slide-7
SLIDE 7

RD53ACfg

This class should be analogous to Fei4Cfg, which is a class defined in YARR. It is not a class specific to the emulator.

7 / 12

slide-8
SLIDE 8

RD53AEmu

This class will inherit the following from Emu.h:

// we use ClipBoard

  • b j e c t s

to communicate with the EmuManager ClipBoard<u i n t 3 2 t >∗ m txClipBoard ; ClipBoard<u i n t 3 2 t >∗ m rxClipBoard ; // f u n c t i o n s f o r sending data to the EmuManager void pushOutput ( u i n t 3 2 t v a l u e ) ; // use a mutex to make s u r e the emulator i s ready to r e c e i v e commands std : : mutex m mutex ;

and will have to implement a minimum of the following virtual methods declared in Emu.h:

// the main loop which r e c i e v e s commands from y a r r v i r t u a l void executeLoop ( ) = 0; // f u n c t i o n s f o r h a n d l i n g the r e c i e v e d commands v i r t u a l void h a n d l e T r i g g e r ( ) = 0 ;

the bulk of the work to adapt the emulator for RD53A is in this class

8 / 12

slide-9
SLIDE 9

PixelIterator<RD53A>

PixelIterator is a class template, so it is simple to make PixelIterator<RD53A>. However, the following methods need specialization for RD53A:

P i x e l I t e r a t o r& o p e r a t o r ++(); P i x e l I t e r a t o r begin ( ) ; P i x e l I t e r a t o r end ( ) ;

along the lines of:

template< > P i x e l I t e r a t o r <RD53APixel> & P i x e l I t e r a t o r <RD53APixel >:: o p e r a t o r ++(); template< > P i x e l I t e r a t o r <RD53APixel> P i x e l I t e r a t o r <RD53APixel >:: begin ( ) ; template< > P i x e l I t e r a t o r <RD53APixel> P i x e l I t e r a t o r <RD53APixel >:: end ( ) ;

this class is simple and straightforward

9 / 12

slide-10
SLIDE 10

Current Issues

◮ the emulator is slower than it used to be when emulating 1 FE ◮ the emulator becomes even slower with increasing number of FE ◮ errors in reading the data back in YARR are now occuring ◮ gridlock occurs after the scan finishes due to the YARR read-back errors ◮ there are several minor inefficiencies, such as the creation and deletion of pointers when transferring data via ClipBoard objects

10 / 12

slide-11
SLIDE 11

Some Timing Performances

Some timings (in seconds) are shown here for running a simple digital scan on an lxplus node (which has 16 cores). The timings for function calls are given per FE. Scan handleTrigger m_rxClipBoard->pushData 1 FE 224 510 24 2 FE 365 801 40 3 FE 326 1455 46 4 FE 473 2239 79 5 FE 713 2519 135 There is a serious problem when digital scans take this long - the less savory hardcoded emulator only required 1 second. Lot’s of profiling and investigation is underway.

11 / 12

slide-12
SLIDE 12

Summary

The emulator has been greatly refactored to add functionality and flexibility. This has come at a large performance cost which is under investigation. If the performance issues can be overcome, the current design lends itself to easy adaptation for RD53A or any other new frontend.

12 / 12