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 YARR data flow pointer shm shm shared ptr EmuManager inheritance ClipBoard ClipBoard Fei4Emu m fei4Pixels Fei4Pixel m fei4Cfg m fei4Cfg Emu Pixel m fei4PixelModelCfg m fei4PixelModelCfg m pixelIterator Fei4Cfg PixelIterator < Fei4Pixel > Fei4PixelModelCfg 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
Further Refactoring some further refactoring can still be done, but the design has converged quite nicely YARR data flow pointer shm shm shared ptr EmuManager inheritance ClipBoard ClipBoard Emu Fei4Emu m fei4Pixels Fei4Pixel m fei4Cfg m fei4Cfg Pixel m fei4PixelModelCfg m fei4PixelModelCfg m pixelIterator Fei4Cfg PixelIterator < Fei4Pixel > Fei4PixelModelCfg x FE Num 3 / 12
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 data flow pointer shm shm shared ptr EmuManager inheritance ClipBoard ClipBoard Emu RD53AEmu m rd53aPixels RD53APixel m rd53aCfg m rd53aCfg Pixel m rd53aPixelModelCfg m rd53aPixelModelCfg m pixelIterator RD53ACfg PixelIterator < RD53APixel > RD53APixelModelCfg x FE Num 4 / 12
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 of modeling functions for RD53A’s 3 analog frontends 5 / 12
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 of 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 ] ; // other 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 or TDAC v a l u e s . . . } ; this class is simple and straightforward, but will require 3 versions of modeling variables for RD53A’s 3 analog frontends 6 / 12
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
RD53AEmu This class will inherit the following from Emu.h : // we use ClipBoard o 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
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
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
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
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
Recommend
More recommend
