Technical Discussion: UNILAC Request for Booster Mode (Lite)

Date: 2021-07-15 // Follow up: 2021-07-16

Participants: Dietrich Beck, Hanno Hüther, Mathias Kreider, Raphael Müller, Andreas Schaller

Minutes: Andreas Schaller

Status: In Review

0 Preliminary Work

See meeting minutes from the initial CCT meeting on "UNILAC Request for Booster Mode (Lite)".

1 Questions on Topic:

• Wie werden die "UNILAC-synchronen" Blöcke im DOT-Graph modelliert?
• Wie stößt das UNIPZ-Gateway diese Blöcke an?
• Wie wird die Information transportiert, welchen Timing-Block das Gateway für welche Injektion anstoßen soll?
• Wird es im Graph visuell ersichtlich sein, welcher "UNILAC-synchrone" Block zu welchem "SIS-synchronen" Block gehört (hier war eine "NOP-Kante" im Gespräch, falls es sonst nicht ersichtlich wäre)?
• Brauchen wir zusätzliche Events für diesen Betriebsmodus? Wenn ja, welche?

2 Discussion

When using commands, Mathias shows, that the amount of information needed to transfer the adress and time to start a thread is too high for a single command. He proposes to change the internal layout to reduce the amount of repetition bits from 20 to 19 to use the free bit for the adressing part. Withoud the usage of commands to start threads, this is not needed.

Andreas Mentioned, that this would mean to change all wait loops for e.g. UNILAC-SIS18 and SIS18-ESR wait loops which use the minimal block length repeated by the maximum number of bits to archieve the 10 seconds waiting window.

3 Possible solutions

Dietrich prefers to introduce a new event number to distinguish between legacy unilac injection and booster mode unilac injections. The unilac has an internal wait time for the source in legacy mode which we do not want in booster mode.

During the discussion two possible solutions were pointed out how the injection thread can be started.

3.1 Gateway starts thread - mechanism without explicit wait blocks

• BReq provides core and thread addresses
• Gateway sends absolute starttime to thread
• Gateway starts thread

3.2 Graph starts thread - mechanism as in legacy mode using a wait loop and flex wait block

• BReq provides LoopBlock und FlexWait -Adresses like TcReq in legacy mode
• Graph starts thread
• Thread waits in LoopBlock
• Gateway set FlexWait time
• Gateway flushes LoopBlock

Technical Discussion: UNILAC Request for Booster Mode (Lite) [follow up // 16.07.2021]

To get an overview how the graphs below should be interpreted, please have a look here. The gray boxes groups the events by thread.

The old Unilac-Request mechanism should be replaced by the one that fits both, MultiMulti and Booster Mode Injection.

example scheduling graph for solution 3.1 for MultiMulti Injection instead of Booster Mode

The main difference between the old mechanism and the new one is the replacement of the "DMBlk_FlexWait" block with a separate thread. The "dynpar0" edge (in pink from TcReq to DmBlk_WaitLoop) remains but the "dynpar1" edge is no longer needed. Instead there is a new "Thr_Origin" node to tell the DataMaster that a thread should start on a specific node (represented by the orange edge). The BReq event now has the CPU and Thread-Number as parameter so that the Unilac-Gateway knows which thread to start. When the beam from unilac is ready for injection into SIS18, the unilac gateway flushes the "!DMBlk_WaitLoop", in other word it stops the wait loop, to that the SIS18 thread continues to play events. The gateway also starts the injection thread with an absolut time stamp, so that the injection events are played in the correct time frame.

example scheduling graph for solution 3.1 for Booster Mode

The first injection is identical to the MultiMulti Injection. However instead of sending the TcRel-Event, the next booster injection is started immediately. Beginning with the second injection, there is a new BReqNoWait event (EvtNo 354, to be created). This event also sends the CPU and thread number as parameter. This allows the Unilac-Gateway to distinguish between Booster Mode and MultiMulti Injection so that there is no need for further synchronizations or wait loops. At this point, there is also no wait loop involved, the unilac gateway just starts the injection threads with an absolute time, so that the injection windows is matched. The SIS thread however keeps running and may play events that are not injection relevant. At the end of each injection there is the InjectionEnd block that forsees enough time for the unilac and the injection thread to do their work. After the last injection, the TcRel event is scheduled and the injection is done.