1 / 20

Events for the SPS Legacy & Common

Events for the SPS Legacy & Common. Implications. Motivation for common events. Ability to use the same hardware and software on different accelerators. In particular FESA CTR & CTG over GMT Save on exploitation costs. Save on development costs.

billy
Download Presentation

Events for the SPS Legacy & Common

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Events for the SPSLegacy & Common Implications

  2. Motivation for common events • Ability to use the same hardware and software on different accelerators. • In particular FESA • CTR & CTG over GMT • Save on exploitation costs. • Save on development costs. • Common approach for operations for all machines in the CCC. • High precision UTC time stamping. • Ability to mix events from different accelerators. on the same timing cable.

  3. Attitude for Legacy SPS events • Keep the strict minimum going so that legacy applications continue to work. • Don’t use them for new developments. • Remove restrictive hardware that blocks us. • such as Tg3 (Old payloads, 4 Ev per Ms) • update existing hardware like the Pulse Gaters as a temporary solution

  4. Multiple timing cables • Normally users NEVER see events, only CTIM equipments. This has worked well in the past, however… • All accelerators at CERN are controlled via general machine timing (GMT) cables: 6 for the LHC Injector Chain (LIC) network, and 1 for CTF network • CTF, • LINAC-II & PSB, LINAC-III & LEIR, CPS, ADE, SPS, LHC • Some events must be sent over many cables, so we need some standards for event layout… <Machine:4><Type:4><Code:8><Payload:16> 0xMTCCPPPP

  5. Machine IDs and events • 0: Not a machine event • 1: Is the LHC, was LEP • 2: Is the SPS • 3: Is the CPS and SCT • 4: Is the PSB and FCT • 5: Is LEIR, was the LPI • 6: Is ADE • 7-8: Reserved for future use

  6. Event types X = Machine ID, 1..8 • 20 Legacy SPS SSC, followed by super-cycle number • 01 Millisecond, lots of different modulo formats • 21 Legacy SPS Machine event e.g. 0x21B60101 • 22 SPS Start super-cycle, no payload • 2F SPS Ancient events • X3 Telegram event, followed by number and value • X4 Same as 1, machine event, but CYTAG payload • X5 Telegram description event, followed by number and type for TSU modules • 02,03,04 SPS Second, Minute, Hour • 05,06,07 SPS Day, Month, Year • 08 PS Day, Month, Year • 09 PS Hour, Minute, Second • 0A Cable ID, followed by GMT cable code • B5,B6 UTC Second, MSW, LSW

  7. 4 events per millisecond * [02,03,04] Time [05,06,07] Date [01] 8-Bit millisecond modulo [20] Super-cycle number [22] Start super-cycle [21] Machine events Event payload is: Type, Number [2F] Ancient events 8 events per millisecond UTC Second 32-Bits via [B5,B6] [01] 16-Bit millisecond modulo [23] Telegrams [24] Machine events Event payload is: Cycle Tag Legacy support Legacy and Common events

  8. Incorporated the SPS in the CBCM in 2004 • Extended the idea of cycle, containing an integer number of basic periods towards the SPS. • Incorporate these cycles in the Beam descriptions used by the MTG. SPS FIXED TARGET CPS SFTPRO CPS SFTPRO PSB SFTPRO PSB SFTPRO

  9. Basic Period Cycle Boundary Beam Cycle Boundary Why Cycle Tags ? Beam-in Beam-out Field Fixed Target MD-26 1 2 3 4 5 6 7 8 9 10 11 12 Time 1.2 (0.9) S periods [X n] Beam-In CPS F( cycle ) CPS Beam-Out W-Start Cycle Master Inject (Virtual Event)

  10. Implication SPS Timing Layout • Work needs to be done to define how the new 24 events will be laid out, its not just a change from 1 to 4 in the header and replacing 0101 payloads with Cycle Tags. • A small band of experts will start work very soon… • Lars Jensen, Gabriel Metral, Markus Albert, Lasse Norman, Delphine Jacquet, Andy Butterworth, and HT people. • Adjusting the timing twice should be avoided • This is an ongoing light activity, it will need the basics complete for the Faraday cage

  11. Conclusion • We will be able to continue with both Legacy and 24 headers on the SPS cable, there will be some other machine events. More than twice the bandwidth, 7 events instead of 3. • 24-Bit Payloads are illegal, implications for 20 SPS-SSC event. • UTC time stamps will be available. • SPS Telegrams are available, and others. • This approach will be used in the RF cage with new CTRV hardware, hence must be ready. • The Old SL Tg8 modules must work with the new events, UTC and Telegrams, they would be too expensive to replace. • The PS events will carry CYTAG payloads to, so modifications of the PS Tg8s are also needed.

  12. Implication SPS-TG8 Old Firmware • Old modules running on old style DSCs will be mostly unaffected. There are two small differences… • The super-cycle number is 16 bit Big Endian instead of 24 bit little Endian. • There are no Tg3 Date Time events any more, so the date is garbage. • During the tests 8 events per millisecond was very close to the limit with 3 wild cards • We can down load the new firmware on old crates if needed….

  13. Implication SPS-TG8 New Firmware • The SPS-Tg8 is accessible across TimLib. In this case new Tg8 firmware is downloaded automatically when the library is initialized. This library supports the FESA API. Some points… • UTC events and time support backwards compatible. • The SUPER-CYCLE number returned by the firmware is the 32 bit UTC time of the event, namely the Super-Cycle stamp. • SPS Telegrams work correctly. • Connecting to 21 headers gives a warning and soon will give an error. • 24 and 21 headers are supported simultaneously • Firmware runs/is ~30% faster/shorter due to O3 option • It is possible for old stuff and FESA to coexist on the same module, but I don’t recommended it. • Mostly finished all this, seems to work so far.

  14. Implication PS-TG8 • Due to the extra loading on processing events with payloads there will be more loading of the PS-TG8 firmware which may cause problems. • A new version needs to be made that simply ignores payloads in triggers. No big problem as the firmware is downloaded at DSC start-up.

  15. Implication CBCM • Event payloads will be turned on everywhere. New SPS event layout. Ongoing occasional meetings as needed. • Introduction of reflective memory for multiple system synchronization. Handling LIC during an LHC Fill requires a hard look at the CBCM especially for the number of batches, target bucket and ring. Some of these features will be required in 2006; • There is a need for hard synchronization in the business layer at least. This needs to be implemented, no matter what. There is a debate going on with CPS operators and CO. They use two tiers not three and want reliable synchronization too. • Soft synchronization needs working on. A more reliable version of DTM is nearly ready

  16. SPS Super-Cycles 2006 FT OK MD 16.8 seconds

  17. SPS Super-Cycles 2006 LHC pilot +3CNGS Ouch ! 22.8 sec.

  18. SPS Super-Cycles 2006 LHC filling OK 21.6 sec

  19. SPS Super-cycles 2006 CNGS FT MD Big Ouch !! 34.8 sec

  20. SPS Super-Cycles 2006 • Some of these SC’s are breaking new ground, never tried before on the SPS • Modifications of CBCM FIDO needed • Even legacy stuff needs testing • Serious discussions needed on • External conditions • Economy modes • Legacy payloads • Some discussions still needed on economy mode switching

More Related