Proposal for beam-process handling in FESA

Alexander Schwinn

2

Beam Production Chain 1 (BPCID=1)

Beam Production Chain 2 (BPCID=2)

BPID 1 BPID 2 BPID 3 BPID 4

BPCID = 1

3

BPID 55 BPID 56 BPID 57BPID 58

BPCID = 2

BPCID = 567

BPID 47

BPID 1 BPID 2 BPID 3 BPID 4

BPCID = 1

BPID 2.1

BPID2.71

BPID2.72

4

Realtimewrite

Server

read

sync.

4,7 4,7

5,6

1,3

9,7

9,7

6,2

9,7

3,3

9,7

9,7

6,5

9,9

5,0

5,8

3,3

9,79,7

slot

01

FESA – Multiplexingcurrent implementation

- All fields exist x-times, where x is the multiplexing depth

- This depth is allocated at startup, not possible to change depth during runtime.

- It is possible to mark fields as “extra-multiplexed” The multiplexing depth of these fields is:base-depth + extra-mux. depth

slot

02slot

03slot

04

slot

05slot

06

slot

07

slot

08slot

09

5

Problems – Extra-Multiplexing- Lack of flexibility.

The base-cycles of the extra-multiplexing need to have the same names/indexes than the ones for the usual (USER) multiplexing. That’s a blocker for the BeamProcess - approach.

- Complicated set up for extra-multiplexing in instantiation-file.- Additional, optional field-attribute

in the design (@extra-multiplexed)

6

Possible Solution

- Choice of the multiplexing-criteria per field- List of possible choices is lab-specific- Example:

- Additional benefit:- We can get rid of data/timing-domain-data in the class-design- We can get rid of the main-Mux-criterion in the Inst.-File

CERN GSI

7

Cycle2Cycle1

BPID 1.2BPID 1.0 BPID 1.1 BPID 1.3

BPID 1.4

BPID 1.5 BPID 1.6

BPID 2.0 BPID 2.0 BPID 2.0 BPID 2.0

Field: condensator_load- Indizierung per Cycle Depth=2

Field: voltage- Indexing per BPID Depth=11

8

? ? ?

9

Thanks for your attention !