FESA Properties for DataMaster Class (current version running on vmla03)

Global Interface (Device Name MCS_DM_GLOBAL)

Setting Properties

---

• Command
  • dataMasterCommand: DATAMASTER_GLOBAL_CMD -> Global commands to all DataMaster Cores. For a list, see Global Commands
• Simulation
  • Simu: bool -> turns Simulation mode on or off. Default is true.
• Connection
  • Connect: bool -> establishes etherbone connection to DataMaster, also starts Status poll action once per second. Very first thing to do when you start the class, real or Simulation! Default is false.

Acquisition Properties

---

• Saclay --> This is an evil hack and not how the DataMaster should be controlled! This 'feature' will not be available for CRYRING!
  • pulseStart: int64_t -> Start offset for Magnetron Pulse (note: should be uint64_t, but FESA doesn't support that. WTF)
  • pulseEnd: int64_t -> End offset for Magnetron Pulse
  • period: int64_t -> Period for the minics cycle
• Status
  • DmGlobalState: DATAMASTER_STATE -> State for the whole DataMaster. The rules are still a bit fuzzy, but generally it shows if any core is running or not.
  • SimDmGlobalState: DATAMASTER_STATE -> Same, only for Simulation mode. Would have liked to have used the normal one, but it's tricky to write acquistion properties from server actions

Device Interface (Device Name MCS_DM_CORE_00, ..., MCS_DM_CORE_03)

Setting Properties

---

• DeviceCommand
  • deviceCommand: DATAMASTER_DEVICE_CMD ->Commands to a specific DataMaster Core. For a list, see Device Commands
  • BeamRequest -> not yet implemented
• Setting
  • xmlCfgString: char[65536] -> an xml config string for a DataMaster Core. For Syntax and content, short version can be found below, version can be found here
  • xmlCfgFile: char[128] -> path and filename to an xml config file for a DataMaster Core.

Acquisition Properties

---

• DmState
  • dmState: DATAMASTER_STATE -> State for the whole DataMaster. The rules are still a bit fuzzy, but generally it shows if any core is running or not.
  • simDmState: DATAMASTER_STATE -> Same, only for Simulation mode. Would have liked to have used the normal one, but it's tricky to write acquistion properties from server actions

Enums

DataMaster State

---

• DATAMASTER_STATE
  • DM_ERROR_EB : -2 -> etherbone related error. see error message collection for detailed text message
  • DM_ERROR_UNKNOWN : -1 -> unclassified error. see error message collection for detailed text message
  • DM_S0 : 0 -> initial state of a DataMaster Core after Boot
  • DM_UNINTIALIZED : 1 -> DataMaster Gateware detected
  • DM_INTIALIZED : 2 -> Firmware found / rewritten. Ready for operation
  • DM_ABORTED : 3 -> Core operation was forced to stopped
  • DM_STOPPED : 4 -> Core not running
  • DM_STOP_REQ : 5 -> Core asked to stop, but still busy
  • DM_IDLE : 6 -> Core running idle
  • DM_WAITING : 7 -> Core waiting for a condition to become true
  • DM_RUNNING : 8 -> Core running

---

Global Commands

• DATAMASTER_GLOBAL_CMD
  • DATAMASTER_RESET_FPGA : \t\t -2 -> Does what it says on the box. Beware, PCIe bus does not take kindly to this, you will need to reboot the host system as well.
  • DATAMASTER_RECOVER : \t\t -1 -> toggle core reset line
  • DATAMASTER_RESERVED : \t\t 0 -> nop
  • DATAMASTER_RUN : \t\t 2 -> Run all cores
  • DATAMASTER_STOP : \t\t 3 -> Ask all cores to stop. Will stop when they hit IDLE state.
  • DATAMASTER_ABORT : \t\t 4 -> Force all cores to stop immediately
  • DATAMASTER_IDLE : \t\t 5 -> Ask cores to go to idle at next branchpoint
  • DATAMASTER_LOADFW : \t\t 6 -> Load firmware binary to all cores
  • DATAMASTER_COMMIT : \t\t 7 -> Make all cores commit config data loaded by DATAMASTER_PUT from inactive to active memory page

---

Device Commands

• DATAMASTER_DEVICE_CMD
  • DATAMASTER_RECOVER : -1 -> toggle core reset line
  • DATAMASTER_RESERVED : 0 -> nop
  • DATAMASTER_RUN : 2 -> Run core
  • DATAMASTER_STOP : 3 -> Ask core to stop. Will stop when it hits IDLE state.
  • DATAMASTER_ABORT : 4 -> Force core to stop immediately
  • DATAMASTER_IDLE : 5 -> Ask core to go to idle at next branchpoint
  • DATAMASTER_LOADFW : 6 -> Load firmware binary to core
  • DATAMASTER_COMMIT : 7 -> Commit config data loaded by DATAMASTER_PUT from inactive to active memory page
  • DATAMASTER_PUT : 8 -> Load config data from xml to inactive memory page
  • DATAMASTER_GET : 9 -> Get config data from inactive memory page (not yet implemented)
  • DATAMASTER_DUMP : 10 -> Dump config data from active memory page (not yet implemented, but pollaction does this once per second)
  • DATAMASTER_CONDUMP : 11 -> Make core display its active config data on WR console (this will massivly slow execution, only do this if core is idle or for debug purposes)

---

Description of a Schedule in XML Format

This is described here.

-- MathiasKreider - 18 Sep 2014 (slightly restructured by Dietrich on 29 September 2014)