ECA / WR timing adapter: Usage in FESA - TODO: update this page

1. Instantiation-File: Select "FAIR" as timingDomain and choose a WhiteRabbit timing based accelerator for your device:

   <device-instance name="myDeviceNomenklatur">
      <configuration>
         <description value="This is a device using WR based timing" />
         <accelerator value="PLPS#123" />
         <timingDomain value="FAIR" />
         <mainMuxCriterion value="USER" />
      </configuration>
      ...

2. Choose one (or more) of the FAIR timing events in the events-mapping
   

         <events-mapping>
           <myLogicalEvent>
             <event-configuration name="MyEventConfig">
                <Timing>
                   <hardware-event name="EVT_SOURCE_BEAM_ON#270" />
                           <hardware-event name="EVT_SOURCE_BEAM_OFF#271" />
                </Timing>
             </event-configuration>
             <event-configuration name="MyEventConfig2">
                <Timing>
                   <hardware-event name="WhiteRabbit-SomeOtherTestEvent#2" />
                </Timing>
             </event-configuration>
             ...

3. Work with the payload of the FAIR timing event in the RT-Action

   void MyRTAction::execute(fesa::RTEvent* pEvt)
   {
       std::cout << "MyRTAction::execute start" << std::endl;
       fesaGSI::TimingContextWR* scuContext = dynamic_cast<fesaGSI::TimingContextWR*>(pEvt->getMultiplexingContext());
       fesaGSI::TimingContextWRPayload payload = scuContext->getPayload();
       std::cout << "param: " << std::hex << payload.param_ << std::endl;
       std::cout << "timeStamp: " << payload.timeStamp_ << std::endl;
       std::cout << "usedEventFilter_: " << std::hex << payload.usedEventFilter_ << std::endl;
       std::cout << "MyRTAction::execute stop" << std::endl;
   }

4. (optional) Add a trigger to the ECA to directly trigger hardware on an incoming event:

   void RTDeviceClass::specificInit()
   {
       GSI_ECA::Event eventFilter = 123;   // filter to specify for which event(s) to listen
       GSI_ECA::Time offset = 0;           // offset for the event, max 8ns
       GSI_ECA::Channel channel = 0;       // PCI_EXPRESS = 1 (software-interrupts are reserved for FESA) .. ask the Timing-Team for possible other channels
       uint8_t relevantFilterBits = 12;    // Bits which will be used for filtering in "eventFilter" (fesa uses first 32bits for eventID) maschineID-filtering is not used yet.
       fesaGSI::TimingEventSourceWR::registerHardwareTrigger( eventFilter, offset, channel, relevantFilterBits );
   }

5. Start FESA-class with application-argument "-WR" to use the TimingEventSourceWR

   startScript.sh -usrArgs -WR / from FESA3 1.2.2 on: start_<deply-unit name>_<X>.sh -f "-usrArgs -WR"

   On FECs running 64-bit software the daemon launching the FESA software automatically detects depending on the information from the instance file which parameters to use during launch since the FESA software itself is not able to.
6. Trigger local-event on the ECA for testing purposes:

   [root@scul022]$ eca-ctl dev/wbm0 send 0x0000002c00000042 0x12343456 0xabd +1
   This would configure the ECA to launch event 44(2c) with the payload 0x12343456 0xabd in 1sec ( you can as well put absolute timestamps here! Ask Wesley for details)
   "42" could e.g. be a BeamProcessID. FESA assumes to find the EventNo in the first 32bits.

7. Trigger local event on the ECA for testing purposes:

   [root@scul022]$ eca-ctl dev/wbm0 send 0x7b02c000000000 0x12343456 0xabd +0.1
   
   0x1ec0b04000000002 translates to: trigger event Timing::WhiteRabbit-CycleStart#44 with sequence ID 0, beam process ID 0, group ID 123, format  ID 0, sequence counter 0

8. [root@scul022]$ eca-ctl dev/wbm0 send 0x7b02caaabbb7ff 0x12343456 0xabd +0.1
   
   0x7b02caaabbb7ff  translates to:  trigger event Timing::WhiteRabbit-CycleStart#44 with sequence ID 2730, beam process ID 12013, group ID 123, format  ID 0, sequence counter 1023 

9. What does not work currently (updated 01/2015):
   • cycles - The cycleID (and some other data) should be received within the sequence-start-event. Since the CCT did not decide yet how the structure of the event looks like, the cycleID allways is 0 currently ( no readout of information form the sequence-start-event ). --> No multiplexing of fesa-fields
   • filter-bits - Currently FESA uses the first 32 bits of the "Event" as filter in the ECA (See TimingEventSourceWR.cpp). Later the number of filter-bits should be: #!BitsMaschineID + #!BitsEventNo. Can be implemented as soon as the CCT decided on the format/length of the event-design.
   • filter-bits - Currently only the "complete" 32Bit EventID is used for filtering. Machine-ID and EventNo are not used yet. Can be implemented as soon as CCT decided on the Machine-ID-size (If there will be a MachineID )
   • multiple FESA binaries on the same front-end. FESA has to be the one and only user of the ECA ! It will stay like that, until there is a timing-daemon and a SAFT-lib, provided by the Timing-group.
   • meaningful machine-names and event-names in the Instantiation-file (TimingConfigurationWR.xml). Can be added as soon as CCT/LSA provides info about it.
   • the address of the Wishbone slave interface is presently hard coded - before a release, this must be changed to auto discovery