For the commissioning phase (and to ensure that the teststands will run the same software as IR2), it wouls be nice to be able to modify the easily the slot to sector map as well as the slot mask. Those quantities are for the moment hard coded in the online software. 2 options exists for the slot mask : 1)having an automatic detection of the board at boot time. This detection will define what the slot mask is. pros : - no need to make a new configuration when we move a board. cons : - we can't hide boards. The only way to avoid discussing with a board is to physically remove it from the crate. - How do we link the obtained slot mask with the slot to sector map? 2) Put the slot mask in the configuration database pros: - we can assure that the 2 configuration objects slot mask and slot to sector map are coherent. - We can hide boards without physically moving them cons: - we need a new key each time we move a board -------------------------------------------------------------------------------------------------------------------------------------------------------------- current status of the slot mask. we have the following classes : odfLinks -------- ^ | | L1DctLinks ---------- ^ | | ----------------------------------------------------------------------- ^ ^ ^ ^ ^ ^ | | | | | | L1DctVarLinks L1DTsfxLinks L1DTsfyLinks L1DPtdLinks L1DBltLinks L1DBltPtdLinks (setable) (0xffff) (0xaaaa) (0x1fe0) (0x0004) (0x1fe4) For the TSFs, L1DTsfxLinks and L1DTsfyLinks are contained by their respective FEX engine. Thes engines have a L1DctLinks& links() method. Those engines are owned by the L1DTsfAction class and used tio drive the Configuration, BeginMinor and L1Accept transitions. The FEX engines contains a L1DTsfCommand object (which actually does the real communications with the trigger boards). The links are transfered to the L1DTsfCommand at the beginning of the configure transition. They are not modified after that. The L1DBltLinks and L1DPtdLinks are used by the L1DBltPtdConfigure action through the L1DBltPtdCommand this action contains The L1DBltPtdLinks is used by the L1DBltPtdBeginMinor action which just set the slot mask. ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- The slot to sector map : TSF : this map is stored in L1DTsfMap objects. L1DTsfMap objects are contained by the FEX engines. They are given to the L1DTsfCommand at the configure transition to download the correct LUT in the correct trigger board memory. They are also used at the L1Accept transition to fill correctly the XTC. BLTPTD : there is no dedicated class to perform this slot to sector connexion. The slot number is used only in the L1DBltPtdElement (which inherits from odfElemnt) to determine which odfElement contains the BLT data and which ones contain the PTD data. Except for that, it is not used at all. It doesn't seem to be stored in the BltPtdMpduleTC. This would mean that every software that used the BltPtd TC, determines the PTD sector by the position of the PTD data in the TC. That's OK when you have 8 PTD in the crate but when you have less, what happened. ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ Idea for the slot mask automatic detection : Having a class which is able to detect the presence of boards and identifying them. (it is not possible to distinguish old TSFX from old TSFY). this class would then have accessors returning something deriving from odfLinks : tsfLinks(); (or tsfxLinks() and tsfyLinks() but how to separate the 2? see below) ptdLinks(); bltLinks(); zpdLinks(); newtsfxLinks(); newtsfyLinks(); This class could also read a mask and an oldTsf mask pattern from the configuration. The mask would allow to hide boards with every ....Links() method returning detected_slot_mask & mask or (detected_slot_mask & ! mask) the oldTsf mask (one per ROM) is used to distinguish old tsf X from Y : tsfxLinks() returns detected_oldtsf_slot_mask & oldTsf_mask and tsfyLinks() returns detected_oldtsf_slot_mask & ! oldTsf_mask All piece of the current code that need a L1DctLinks would then used this new class for getting the slot mask. ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- How to handle the slot to sector map if there is no more fixed slot mask? What should happen if we have a slot in the map which contain no board? What should happen if we have an occupied slot but this slot is not in the map? How do we do for not screwing everything? The map could be stored has a list of sectors. The board in the most left slot would be assigned the first sector in the list. The next board on the right would be assigned the second sector in the list up to the end of the list. The number of element in the list should match the number of detected boards. Should we authorize exceptions to the previous statement? As an example, the current IR2 tsfy map would be : 0,7,1,6,2,5,3,4 For the BLT-PTD, there is maybe information in the read L1Accept element data to distinguish between the 2. If the header is the CSR1 word for example. Maybe with the size of the element? For the PTD slot to sector mapping, we can use the same method as for the TSF. But how is it done today? ----------------------------------------------------------------------------------------- Last update october 18 2002 Gerald Grenier The University of Iowa.