MCS to HPS

The interface from the MCS to the HPS is largely in the form of communication between Tango devices running on either side.

The interface also currently consists of low-level SSH calls from the MCS to the Talon-DX boards, which are used to copy FPGA bitstreams and Tango device server binaries to the boards and start the HPS Master process. This functionality may be moved in the future, but for now it is implemented in the TalonDxComponentManager Class, which is instantiated by the CbfController.

Command Sequence

On Sequence

The sequence diagram below shows the main sequence of calls in MCS when the On command is called. Return calls are not shown.

Prior to On() being called, two pre-requisite steps are expected: 1. Artifacts have been downloaded from CAR and stored under the /mnt directory inside MCS. 2. The Tango database has been configured, including all MCS and HPS devices that are expected to deploy.

@startuml
'https://plantuml.com/sequence-diagram
skinparam backgroundColor #EEEBDC
skinparam sequence {
ParticipantBorderColor DodgerBlue
ParticipantBackgroundColor DeepSkyBlue
ActorBorderColor DarkGreen
ActorBackgroundColor Green
BoxBorderColor LightBlue
BoxBackgroundColor #F0FFFF
}
skinparam collections {
  BackGroundColor LightBlue
  BorderColor DodgerBlue
}
skinparam database {
  BackgroundColor LightGreen
  BorderColor DarkGreen
}
title On Command Sequence - Correlation\n
participant "CSP_Mid\n.LMC" as lmc #Thistle
box "\nMCS\n"
  participant "Mid.CBF\nController" as controller
  participant "Talon\nDX" as tdx
  participant "Talon\nLRU" as lru
  participant "Talon\nBoard" as talon_board
  participant "Power\nSwitch" as ps
  collections "SLIM" as slim
  collections "SLIM\nLink" as slimlink
end box
participant "PDU\n" as pdu #Orange
box "\nHPS\n"
  participant "Linux\nOS" as os #LightGreen
  participant "HPS\nMaster" as hpsmaster
  collections "HPS\nDevices" as hpsdevices
end box

note over controller            : AdminMode: ON\nOpState: OFF
lmc -> controller               : On()

group #LightCyan For each Talon LRU in configuration:
  controller    ->  lru         : On()
  lru           ->  ps          : outlet1_state = GetOutletPowerState(outlet1)
  ps            ->  pdu         : GetOutletPowerState(outlet1)
  group #SeaShell If using single outlet:
    lru         ->  lru         : outlet2_state = outlet1_state
  else using both outlets
    lru         ->  ps          : outlet2_state = GetOutletPowerState(outlet2)
    ps          ->  pdu         : GetOutletPowerState(outlet2)
  end group

  note over lru                 : OpState: UNKNOWN
  group #SeaShell If outlet1_state OR outlet2_state == ON:
    note over lru               : OpState: ON
  else If outlet1_state AND outlet2_state == OFF:
    note over lru               : OpState: OFF
  end group

  lru           ->  ps          : TurnOnOutlet(outlet1)
  ps            ->  pdu         : TurnOnOutlet(outlet1)
  pdu           --> lru         : result1
  group #SeaShell If using both outlets:
    lru         ->  ps          : TurnOnOutlet(outlet2)
    ps          ->  pdu         : TurnOnOutlet(outlet2)
    pdu         --> lru         : result2
  else
    lru         ->  lru         : result2 = result1
  end group

  group #SeaShell If result1 OR result2 == ResultCode.OK:
    note over lru               : OpState: ON
end group

group #LightCyan For each Talon board in configuration:
  controller    ->  tdx         : ConfigureTalons()
  tdx           ->  tdx         : Read config files,\nSetup tango host file
  tdx           ->  os          : Clear processes
  tdx           ->  os          : Configure Talon networking
  tdx           ->  os          : Copy binaries and bitstream
  tdx           ->  os          : Start HPS Master
  note over hpsmaster           : OpState: INIT
  tdx           ->  hpsmaster   : Configure(json_str)
  hpsmaster     ->  hpsmaster   : ConfigureBitstream()
  group #LightCyan For each HPS device server:
    hpsmaster  -> hpsdevices    : SpawnTangoDS()
  end group
  hpsmaster     ->  hpsmaster   : HealthCheck()
  note over hpsmaster           : OpState: ON

  controller    ->  talon_board : Set device properties
  controller    ->  talon_board : Init()
  controller    ->  talon_board : Set SimulationMode
  controller    ->  talon_board : Set AdminMode.ONLINE
  note over talon_board         : OpState: ON
  controller    ->  talon_board : Update dishID, vccID\nattributes from hw_config
end group

group #LightCyan For each SLIM:
  controller      ->  slim      : Set SimulationMode
  controller      ->  slim      : On()
  note over slim                : OpState: ON
  controller      ->  slim      : Configure(yaml_str)
  group #SeaShell If mesh_configured == True
    group #LightCyan For each active SlimLink:
      slimlink    -> hpsdevices : DisconnectTxRx()
    end group
    slim          ->  slim      : mesh_configured = False
  end group

  group #LightCyan For each active SlimLink:
    slim        ->  slimlink    : Set Tx and Rx device FQDNs
    slim        ->  slimlink    : ConnectTxRx()
    slimlink    ->  slimlink    : Sync idle control words
    slimlink    ->  hpsdevices  : InitializeConnection(serial_loopback=False)
    slimlink    ->  slimlink    : ClearCounters(),\nSet linkName
    slim        ->  slimlink    : Start polling VerifyConnection()
  end group
  slim          ->  slim        : mesh_configured = True
end group

note over controller            : OpState: ON

lmc           <--  controller   : Success

@enduml

The interface between the MCS and the HPS Master device server is primarily made up of the ConfigureTalons() command sent from the MCS to the HPS master, which programs the FPGA and spawns the remaining HPS device servers. The parameters used to configure each Talon-DX board come from the “config_commands”-keyed JSON objects in talondx-config.json, which must be staged prior to calling Controller’s On() command in the path indicated by the Controller device’s TalonDxConfigPath property.

An example of such a configuration is provided below:

{
    "config_commands": [
        {
            "description": "Configures Talon DX to run BITE/VCC firmware and devices.",
            "target": "001",
            "talon_first_connect_timeout": 90,
            "ds_hps_master_fqdn": "talondx-001/hpsmaster/hps-1",
            "fpga_path": "/lib/firmware",
            "fpga_dtb_name": "talon_dx-tdc_base-tdc_vcc_processing.dtb",
            "fpga_rbf_name": "talon_dx-tdc_base-tdc_vcc_processing-hps_first.core.rbf",
            "fpga_label": "base",
            "ds_path": "/lib/firmware/hps_software/bite_vcc_test",
            "server_instance": "talon1_test",
            "devices": [
                "ska-mid-cbf-vcc-app"
            ]
        }
    ]
}

Off Sequence

The sequence diagram below shows the main sequence of calls in MCS when the Off command is called. Return calls are not shown.

@startuml
'https://plantuml.com/sequence-diagram
skinparam backgroundColor #EEEBDC
skinparam sequence {
ParticipantBorderColor DodgerBlue
ParticipantBackgroundColor DeepSkyBlue
ActorBorderColor DarkGreen
ActorBackgroundColor Green
BoxBorderColor LightBlue
BoxBackgroundColor #F0FFFF
}
skinparam collections {
  BackGroundColor LightBlue
  BorderColor DodgerBlue
}
skinparam database {
  BackgroundColor LightGreen
  BorderColor DarkGreen
}
title Off Command Sequence - Correlation\n
participant "CSP_Mid\n.LMC" as lmc #Thistle
box "\nMCS\n"
  participant "Mid.CBF\nController" as controller
  participant "Mid.CBF\nSubarray" as subarray
  participant "Talon\nBoard" as talon_board
  participant "Talon\nLRU" as lru
  participant "Talon\nDX" as tdx
  participant "Power\nSwitch" as ps
  collections "SLIM\n" as slim
  collections "SLIM\nLink" as slimlink
end box
participant "PDU\n" as pdu #Orange
box "\nHPS\n"
  participant "Linux\nOS" as os #LightGreen
  participant "HPS\nMaster" as hpsmaster
  collections "HPS\nDevices" as hpsdevices
end box

lmc -> controller : Off()

group #LightCyan For each subarray:
group #SeaShell If ObsState == [RESOURCING, RESTARTING, ABORTING,\n                      READY, RESETTING, SCANNING]:
controller -> subarray        : Abort
end

controller -> subarray        : Restart
note over subarray            : ObsState: EMPTY
end loop

group #LightCyan For each SLIM:
  controller ->  slim         : Off

  group #LightCyan For each active SlimLink:
    slim      ->  slimlink    : Stop polling VerifyConnection()
    slim      ->  slimlink    : DisconnectTxRx()
    slimlink  ->  hpsdevices  : InitializeConnection(serial_loopback=True)
  end 
  note over slim              : OpState: OFF
end group

note over talon_board          : OpState: UNKNOWN
controller  ->  tdx            : Shutdown()
tdx         ->  hpsmaster      : Shutdown(3)
hpsmaster   ->  hpsdevices !!  : kill pid
hpsmaster   ->  os !!          : system "shutdown now"
tdx         ->  tdx            : sleep(4s)

group #LightCyan For each Talon LRU in configuration:
  controller    ->  lru         : Off()
  lru           ->  ps          : outlet1_state = GetOutletPowerState(outlet1)
  ps            ->  pdu         : GetOutletPowerState(outlet1)
  group #SeaShell If using single outlet:
    lru         ->  lru         : outlet2_state = outlet1_state
    else
    lru         ->  ps          : outlet2_state = GetOutletPowerState(outlet2)
    ps          ->  pdu         : GetOutletPowerState(outlet2)
  end group

  note over lru                 : OpState: UNKNOWN
  group #SeaShell If outlet1_state OR outlet2_state == ON:
    note over lru               : OpState: ON
  else If outlet1_state AND outlet2_state == OFF:
    note over lru               : OpState: OFF
  end group

  lru           ->  ps          : TurnOffOutlet(outlet1)
  ps            ->  pdu         : TurnOffOutlet(outlet1)
  group #SeaShell If using both outlets:
    lru         ->  ps          : TurnOffOutlet(outlet2)
    ps          ->  pdu         : TurnOffOutlet(outlet2)
  end group
end group

note over controller           : OpState: OFF
lmc        <--  controller     : Success

@enduml

InitSysParam Sequence

The sequence diagram below shows the main sequence of calls in MCS to initialize the system parameters.

@startuml
'https://plantuml.com/sequence-diagram
skinparam backgroundColor #EEEBDC
skinparam sequence {
ParticipantBorderColor DodgerBlue
ParticipantBackgroundColor DeepSkyBlue
ActorBorderColor DarkGreen
ActorBackgroundColor Green
BoxBorderColor LightBlue
BoxBackgroundColor #F0FFFF
}
skinparam collections {
  BackGroundColor LightBlue
  BorderColor DodgerBlue
}
skinparam responseMessageBelowArrow true

title InitSysParam Command Sequence\n

participant "CSP_Mid\n.LMC" as lmc #Thistle
box "\nMCS\n"
  participant "Mid.CBF\nController" as controller
  collections "Mid.CBF\nSubarray" as subarray
  collections "VCC\n" as vcc
end box
participant "CAR\n" as car #YellowGreen

lmc          -> controller          : InitSysParam(json_str)
controller   -> controller          : Validate JSON against schema

group #SeaShell If JSON is valid:
  group #SeaShell If URI provided:
    controller    -> car            : Retrieve init sys param JSON file
    controller    -> controller     : Validate JSON  against schema
  end group
  controller      -> controller     : Update sysParam
  controller      -> subarray       : Set sysParam
  subarray        -> subarray       : Update sysParam
  controller      -> vcc            : Set dishID
  lmc         <-- controller        : Success
end group


@enduml

AddReceptors Sequence

The sequence diagram below shows the main sequence of calls in MCS to assign resources to a subarray.

@startuml
'https://plantuml.com/sequence-diagram

skinparam backgroundColor #EEEBDC
skinparam sequence {
    ParticipantBorderColor DodgerBlue
    ParticipantBackgroundColor DeepSkyBlue
    ActorBorderColor DarkGreen
    ActorBackgroundColor Green
    BoxBorderColor LightBlue
    BoxBackgroundColor #F0FFFF
}
skinparam collections {
    BackGroundColor LightBlue
    BorderColor DodgerBlue
}

title MCS Correlation Add Receptors\n

participant "TMC\n" as tmc #Gold
participant "CSP_Mid\n.LMC" as lmc #Thistle
box "\nMCS\n"
    participant "Mid.CBF\nSubarray" as subarray
    collections "VCC\n" as vcc
    collections "Talon\nBoard" as talon
end box

note over subarray       : ObsState: EMPTY
lmc         ->  subarray     : AddReceptors(list[str])
note over subarray           : ObsState: RESOURCING
group #LightCyan For each receptor in argin:
    subarray    -> subarray  : Validate receptors in argin
end group

group #SeaShell If len(valid receptors) > 0:
    group #LightCyan For each receptor:
        subarray    -> vcc       : Update simulationMode
        subarray    -> vcc       : AdminMode.ONLINE
        note over vcc            : OpState: ON
        subarray    ->  vcc      : Update subarrayMembership
        subarray    ->  talon    : Update subarrayID
    end group

    subarray    ->  subarray     : Update receptors
    note over subarray       : ObsState: IDLE
else Failure in AddReceptors, ObsState unchanged
    note over subarray       : ObsState: EMPTY
end group


lmc        <--  subarray     : Success

@enduml

RemoveReceptors Sequence

The sequence diagram below shows the main sequence of calls in MCS to release resources from a subarray.

Note that there also exists a RemoveAllReceptors command, which has the same code flow; the only difference is that it takes no argument and instead submits a full copy of the current assigned receptors to the loop that resets the subdevices.

@startuml
'https://plantuml.com/sequence-diagram

skinparam backgroundColor #EEEBDC
skinparam sequence {
    ParticipantBorderColor DodgerBlue
    ParticipantBackgroundColor DeepSkyBlue
    ActorBorderColor DarkGreen
    ActorBackgroundColor Green
    BoxBorderColor LightBlue
    BoxBackgroundColor #F0FFFF
}
skinparam collections {
    BackGroundColor LightBlue
    BorderColor DodgerBlue
}

title MCS Correlation Remove Receptors\n

participant "TMC\n" as tmc #Gold
participant "CSP_Mid\n.LMC" as lmc #Thistle
box "\nMCS\n"
    participant "Mid.CBF\nSubarray" as subarray
    collections "VCC\n" as vcc
    collections "Talon\nBoard" as talon
end box

lmc             ->  subarray    : RemoveReceptors(list[str])
note over subarray              : ObsState: RESOURCING
group #LightCyan For each receptor in argin:
    subarray    -> subarray     : Validate receptors in argin
    subarray    -> vcc          : Reset subarrayMembership to 0
    subarray    -> vcc          : AdminMode.OFFLINE
    note over vcc               : OpState: DISABLE
    subarray    ->  talon       : Reset subarrayID
end group

subarray    ->  subarray        : Update receptors

group #SeaShell If len(receptors) == 0:
    note over subarray          : ObsState: EMPTY
else
    note over subarray          : ObsState: IDLE
end group


lmc        <--  subarray     : Success

@enduml

Configure Scan Sequence

The sequence diagram below shows the main sequence of calls in MCS to configure a correlation scan. Return calls are not shown.

@startuml
'https://plantuml.com/sequence-diagram

skinparam backgroundColor #EEEBDC
skinparam sequence {
    ParticipantBorderColor DodgerBlue
    ParticipantBackgroundColor DeepSkyBlue
    ActorBorderColor DarkGreen
    ActorBackgroundColor Green
    BoxBorderColor LightBlue
    BoxBackgroundColor #F0FFFF
}
skinparam collections {
    BackGroundColor LightBlue
    BorderColor DodgerBlue
}

title MCS Correlation Configure Scan\n

participant "TMC\n" as tmc #Gold
participant "CSP_Mid\n.LMC" as lmc #Thistle
box "\nMCS\n"
    participant "Mid.CBF\nController" as controller
    participant "Mid.CBF\nSubarray" as subarray
    collections "VCC\n" as vcc
    collections "FSP\n" as fsp
    collections "FSP Corr\nSubarray" as fspcorr
    participant "Visibility\nTransport" as vis_trans
end box
box "\nHPS\n" 
    participant "VCC\nController" as vcc_cont
    participant "VCC\nBand1&2" as vcc_band
    participant "FSP\nController" as fsp_cont
    participant "FSP Corr\nController" as fspcorr_cont
end box

lmc         -> subarray     : ConfigureScan(json_str)
subarray    -> subarray     : Validate JSON against schema,\nLoad new configuration

group #LightCyan For each FSP:
    subarray    -> fsp          : RemoveSubarrayMembership
    group #SeaShell If len(subarrayMembership) == 0:
        fsp         -> fspcorr      : AdminMode.OFFLINE
        note over fspcorr           : OpState: DISABLE
        fsp         -> fsp_cont     : Set function mode to IDLE
        note over fsp_cont          : functionMode: IDLE
        note over fsp               : functionMode: IDLE
        subarray    -> fsp          : AdminMode.OFFLINE
        note over fsp             : OpState: DISABLE
    end group
end group

group #LemonChiffon Delay model subscription point
    subarray    -> tmc          : Unsubscribe all events
end group

subarray    -> subarray     : Clear old configuration

group #LemonChiffon Delay model subscription point
    subarray    -> tmc          : Subscribe delay model
end group

group #LightCyan For each assigned receptor:
    subarray    -> vcc          : ConfigureBand(json_str)
    vcc         -> vcc_cont     : ConfigureBand(int)
    vcc         -> vcc_band     : SetInternalParameters(json_str)
    subarray    -> vcc          : ConfigureScan(json_str)
    vcc         -> vcc_band     : ConfigureScan(json_str)
    note over vcc               : ObsState: READY
end group

group #LightCyan For each FSP in use:
    subarray    -> subarray     : Build FSP\nconfiguration

    group #SeaShell If functionMode == IDLE:
        subarray    -> fsp          : Update simulationMode
        subarray    -> fsp          : AdminMode.ONLINE
        note over fsp               : OpState: ON
        subarray    -> fsp          : SetFunctionMode(str)
        fsp         -> fsp          : Validate functionMode
        fsp         -> fsp_cont     : SetFunctionMode(int)
        note over fsp_cont          : functionMode: CORR
        note over fsp               : functionMode: CORR 
    end group

    subarray    -> fsp          : AddSubarrayMembership(int)
    fsp         -> fsp          : Validate subarrayID
    fsp         -> fspcorr      : Update simulationMode
    fsp         -> fspcorr      : AdminMode.ONLINE
    note over fspcorr           : OpState: ON
    fsp         -> fsp          : Update subarrayMembership

    subarray    -> fspcorr      : ConfigureScan(json_str)
    fspcorr     -> fspcorr      : Reset old configuration,\nRelease all VCCs,\nLoad FSP configuration,\nAssign new VCCs,\nBuild HPS FSP CORR configuration
    fspcorr     -> fspcorr_cont : ConfigureScan(json_str)
    note over fspcorr           : ObsState: READY
end group

subarray    -> vis_trans    : Configure(json_str, yaml_str)

note over subarray          : ObsState: READY
lmc        <-- subarray     : Success

@enduml

The sequence diagram below shows additional detail for configuration of the VCC for a correlation scan, following the ConfigureScan call from LMC.

@startuml
'https://plantuml.com/sequence-diagram

skinparam backgroundColor #EEEBDC
skinparam sequence {
    ParticipantBorderColor DodgerBlue
    ParticipantBackgroundColor DeepSkyBlue
    ActorBorderColor DarkGreen
    ActorBackgroundColor Green
    BoxBorderColor LightBlue
    BoxBackgroundColor #F0FFFF
}
skinparam collections {
    BackGroundColor LightBlue
    BorderColor DodgerBlue
}

title MCS Correlation Configure Scan Band 1/2 - VCC Detail\n

box "\nMCS\n"
    participant "Mid.CBF\nSubarray" as subarray
    collections "VCC\n" as vcc
end box
box "\nHPS\n"
    participant "VCC\nController" as hpsvcc
    participant "VCC\nBand1&2" as vccband1
    participant "Circuit\nSwitch" as cs
    participant "VCC\n" as vccdevice
    participant "Wide Band\nInput Buffer" as wb
end box

group #LightCyan For each assigned receptor:
    subarray    -> subarray     : Calculate\ndish_sample_rate
    note right                  : dish_sample_rate (Band 1/2) = 3960 MHz + (1 * K * <U+0394>F)
    subarray    -> vcc          : ConfigureBand(json_str)
    vcc         -> vcc          : Load band configuration
    vcc         -> hpsvcc       : ConfigureBand(int)
    group #SeaShell If FrequencyBand == [1,2]:
        hpsvcc  -> vccband1     : On
    else 
        hpsvcc  -> vccband1     : Disable
    end group
    vcc         -> vccband1     : SetInternalParameters(json_str)
    vccband1    -> vccband1     : Set VCC gains,\nSet sample_rate

    subarray    -> vcc          : ConfigureScan(json_str)
    vcc         -> vccband1     : ConfigureScan(json_str)
    vccband1    -> cs           : Set cs_input_select
    vccband1    -> vccdevice    : Set frame_count
    vccband1    -> wb           : Set stream_rate, packet_rate, etc.
    note over wb                : receiveEnable: True
    vccband1    -> vccband1     : verify_configuration()
    note over vcc               : ObsState: READY
end group


@enduml

When the Subarray calls ConfigureBand, the jsonstr argument contains:

  • “frequency_band”

  • “dish_sample_rate”

  • “samples_per_frame”

When the Subarray calls ConfigureScan, the jsonstr argument contains:

  • “config_id”

  • “frequency_band”

  • “band_5_tuning”

  • “frequency_band_offset_stream1”

  • “frequency_band_offset_stream2”

  • “rfi_flagging_mask”

  • “fsp”

The sequence diagram below shows details of calls to configure a FSP for a correlation scan.

@startuml
'https://plantuml.com/sequence-diagram

skinparam backgroundColor #EEEBDC
skinparam sequence {
    ParticipantBorderColor DodgerBlue
    ParticipantBackgroundColor DeepSkyBlue
    ActorBorderColor DarkGreen
    ActorBackgroundColor Green
    BoxBorderColor LightBlue
    BoxBackgroundColor #F0FFFF
}
skinparam collections {
    BackGroundColor LightBlue
    BorderColor DodgerBlue
}

title HPS Configure FSP for Correlation Scan\n

box "\nMCS\n"
    participant "FSP Corr\nSubarray\n" as fspcorr
end box
box "\nHPS\n"
    participant "FSP Corr\nController\n" as hpsfspcorr
    collections "Packet\nStream\nRepair" as psr
    collections "Resampler\nDelay\nTracker" as rdt
    collections "Fine\nChannelizer\n" as channelizer
    collections "DDR4\nCorner\nTurner" as dct
    participant "Correlator\n\n" as correlator
end box

group #LightCyan For each FSP in use:
    fspcorr     -> hpsfspcorr   : ConfigureScan(json_str)
    note over hpsfspcorr       : ObsState: CONFIGURING

    group #LightCyan For each assigned receptor:
        hpsfspcorr  -> psr         : Write packet rate
        hpsfspcorr  -> rdt         : Stop()
        hpsfspcorr  -> rdt         : Set various attributes
        hpsfspcorr  -> rdt         : Start()
        hpsfspcorr  -> channelizer : Set gains
    end group

    group #LightCyan For each corner turner:
        hpsfspcorr  -> dct  : Write various attributes
        hpsfspcorr  -> dct  : Subscribe to antenna_status
    end group

    hpsfspcorr  -> correlator   : Write various attributes
    hpsfspcorr  -> correlator   : Program long term accumulator (LTA)
    note over hpsfspcorr        : ObsState: READY
    hpsfspcorr  --> fspcorr     : Success
end group

@enduml

Abort Sequence

The sequence diagram below shows the main sequence of calls in MCS to Abort from a correlation scan. Return calls are not shown.

@startuml
'https://plantuml.com/sequence-diagram

skinparam backgroundColor #EEEBDC
skinparam sequence {
  ParticipantBorderColor DodgerBlue
  ParticipantBackgroundColor DeepSkyBlue
  ActorBorderColor DarkGreen
  ActorBackgroundColor Green
  BoxBorderColor LightBlue
  BoxBackgroundColor #F0FFFF
}

skinparam collections {
  BackGroundColor LightBlue
  BorderColor DodgerBlue
}

skinparam database {
  BackgroundColor LightGreen
  BorderColor DarkGreen
}

title Abort Command Sequence - Correlation

participant "CSP_Mid\n.LMC" as lmc #Thistle
box "\nMCS\n"
  participant "Mid.CBF\nSubarray" as subarray
  collections "VCC\n" as vcc
  collections "FSP\n" as fsp
  collections "FSP Corr\nSubarray" as fspsubarray
end box
box "\nHPS\n"
  participant "VCC\nController" as hpsvcc
  participant "VCC\nBand1&2" as hpsvccband
  participant "FSP Corr\nController" as hpsfspcorr
end box

lmc        ->  subarray      : Abort
note over subarray           : ObsState: ABORTING
subarray   ->  vcc           : Abort
note over vcc                : ObsState: ABORTING
vcc        ->  hpsvccband    : Abort (stub) 
note over hpsvccband         : (TBD)
note over vcc                : ObsState: ABORTED
subarray   ->  fspsubarray   : Abort
note over fspsubarray        : ObsState: ABORTING
fspsubarray->  hpsfspcorr    : Abort (stub)
note over hpsfspcorr         : (TBD)
note over fspsubarray        : ObsState: ABORTED
note over subarray           : ObsState: ABORTED

lmc       <--  subarray      : Success

@enduml

ObsReset Sequence

The sequence diagram below shows the main sequence of calls in MCS to return to IDLE via the ObsReset command for a correlation scan. Return calls are not shown.

@startuml
'https://plantuml.com/sequence-diagram

skinparam backgroundColor #EEEBDC
skinparam sequence {
  ParticipantBorderColor DodgerBlue
  ParticipantBackgroundColor DeepSkyBlue
  ActorBorderColor DarkGreen
  ActorBackgroundColor Green
  BoxBorderColor LightBlue
  BoxBackgroundColor #F0FFFF
}
skinparam collections {
  BackGroundColor LightBlue
  BorderColor DodgerBlue
}
skinparam database {
  BackgroundColor LightGreen
  BorderColor DarkGreen
}

title ObsReset Command Sequence - Correlation\n

participant "TMC\n" as tmc #Gold
participant "CSP_Mid\n.LMC" as lmc #Thistle
box "\nMCS\n"
  participant "Mid.CBF\nSubarray" as subarray
  collections "VCC\n" as vcc
  collections "FSP\n" as fsp
  collections "FSP Corr\nSubarray" as fspsubarray
end box
box "\nHPS\n"
  participant "VCC\nController" as hpsvcc
  participant "VCC\nBand1&2" as hpsvccband
  participant "FSP\nController" as hpsfsp_cont  
  participant "FSP Corr\nController" as hpsfsp
end box

lmc         ->  subarray      : ObsReset

group #SeaShell If ObsState == [ABORTED, FAULT]:
  note over subarray           : ObsState: RESETTING
end group

group #SeaShell If ObsState == FAULT:
  subarray    ->  vcc           : Abort
  vcc         ->  hpsvccband    : Abort (stub)
  note over hpsvccband          : (TBD)
  note over vcc                 : ObsState: ABORTED
  subarray    ->  fspsubarray   : Abort
  fspsubarray ->  hpsfsp        : Abort (stub)
  note over hpsfsp              : (TBD)
  note over fspsubarray         : ObsState: ABORTED
end group

subarray    ->  vcc           : ObsReset
note over vcc                 : ObsState: RESETTING
vcc         ->  hpsvccband    : ObsReset (stub)
note over hpsvccband          : (TBD)
vcc         ->  vcc           : Deconfigure scan configuration 
note over vcc                 : ObsState: IDLE

subarray    ->  fspsubarray   : ObsReset
note over fspsubarray         : ObsState: RESETTING
fspsubarray ->  hpsfsp        : ObsReset (stub)
note over hpsfsp              : (TBD)
fspsubarray ->  fspsubarray   : Deconfigure scan configuration
note over fspsubarray         : ObsState: IDLE
subarray    <--  fspsubarray  : Success

group #LightCyan For each FSP:
    subarray    -> fsp        : RemoveSubarrayMembership
    note over hpsfsp_cont     : functionMode: IDLE
    group #SeaShell If len(subarrayMembership) == 0:
      note over fsp           : OpState: UNKNOWN
    end group
end group

group #LemonChiffon Delay model subscription point
    subarray    -> tmc        : Unsubscribe all events
end group

note over subarray            : ObsState: IDLE
lmc        <--  subarray      : Success

@enduml

Restart Sequence

The sequence diagram below shows the main sequence of calls in MCS to return to EMPTY via the Restart command for a correlation scan. Return calls are not shown.

@startuml
'https://plantuml.com/sequence-diagram

skinparam backgroundColor #EEEBDC
skinparam sequence {
  ParticipantBorderColor DodgerBlue
  ParticipantBackgroundColor DeepSkyBlue
  ActorBorderColor DarkGreen
  ActorBackgroundColor Green
  BoxBorderColor LightBlue
  BoxBackgroundColor #F0FFFF
}
skinparam collections {
  BackGroundColor LightBlue
  BorderColor DodgerBlue
}
skinparam database {
  BackgroundColor LightGreen
  BorderColor DarkGreen
}

title Restart Command Sequence - Correlation\n

participant "TMC\n" as tmc #Gold
participant "CSP_Mid\n.LMC" as lmc #Thistle
box "\nMCS\n"
  participant "Mid.CBF\nSubarray" as subarray
  collections "Talon\nBoard" as talonboard
  collections "VCC\n" as vcc
  collections "FSP\n" as fsp
  collections "FSP Corr\nSubarray" as fspsubarray
  
end box
box "\nHPS\n"
  participant "VCC\nController" as hpsvcc
  participant "VCC\nBand1&2" as hpsvccband
  participant "FSP\nController" as hpsfsp
  participant "FSP Corr\nController" as hpsfsp_corr
end box

lmc         ->  subarray      : Restart

group #SeaShell If ObsState == [ABORTED, ABORTED_EMPTY, FAULT, FAULT_EMPTY, EMPTY]:
  note over subarray           : ObsState: RESTARTING
end group

group #SeaShell If ObsState == FAULT:
  subarray    ->  vcc           : Abort
  vcc         ->  hpsvccband    : Abort (stub)
  note over hpsvccband          : (TBD)
  note over vcc                 : ObsState: ABORTED
  subarray    ->  fspsubarray   : Abort
  fspsubarray ->  hpsfsp        : Abort (stub)
  note over hpsfsp              : (TBD)
  note over fspsubarray         : ObsState: ABORTED
end group

subarray    ->  vcc           : ObsReset
note over vcc                 : ObsState: RESETTING
vcc         ->  hpsvccband    : ObsReset (stub)
note over hpsvccband          : (TBD)
vcc         ->  vcc           : Deconfigure scan configuration 
note over vcc                 : ObsState: IDLE

subarray    ->  fspsubarray   : ObsReset
note over fspsubarray         : ObsState: RESETTING
fspsubarray ->  hpsfsp        : ObsReset (stub)
note over hpsfsp              : (TBD)
fspsubarray ->  fspsubarray   : Deconfigure scan configuration
note over fspsubarray         : ObsState: IDLE

group #LightCyan For each FSP:
    subarray    -> fsp        : RemoveSubarrayMembership
    note over hpsfsp_cont     : functionMode: IDLE
    group #SeaShell If len(subarrayMembership) == 0:
      note over fsp           : OpState: UNKNOWN
    end group
end group

group #LemonChiffon Delay model subscription point
    subarray    -> tmc        : Unsubscribe all events
end group

group #LightCyan For each assigned receptor:
  subarray    ->  vcc         : Reset subarrayMembership
  note over vcc               : OpState: UNKNOWN
  subarray    ->  talonboard  : Reset subarrayID
end group

subarray      -> subarray     : Reset scan configuration

note over subarray            : ObsState: EMPTY
lmc         <--  subarray     : Success


@enduml

Serial Lightweight Interconnect Mesh (SLIM) Interface

Refs: SLIM IP Block, Serial Lightweight Interconnect Mesh (SLIM) Design

The Serial Lightweight Interconnect Mesh (SLIM) provides a streaming packet link between two different FPGAs. At its lowest level, a TX and RX IP block are paired together to transfer packetized data across a high-speed serial link. The SLIM architecture consists of three parts: The HPS DsSlimTxRx device server, which provides an interface to the FPGA IP, the MCS SLIM Links, which establish links between Tx and Rx devices, and finally the top level MCS SLIM Mesh (simply called ‘SLIM’), which bundles links into groups for better organization.

The DsSLIMTX and DsSLIMRx are provided together as a multi-class HPS device server to control and monitor the SLIM Links. To provide a link, each TX device server must connect to a corresponding RX device server, based on the SLIM configuration (see next section).

During a SLIM Link’s initialization, the FQDNs of a Tx and Rx device pair are passed as arguments and device proxies are made to each device. Then the connection is monitored by periodically comparing the idle control words (a 55-bit hash of the Tx or Rx’s FQDN) on either side of the link, checking that the bit-error rate remains below an acceptable threshold, and ensuring that clocks on each side of the link remain in sync. Each link uses an enumerated HealthState attribute to summarize these metrics.

At the top of the SLIM hierarchy, sits the SLIM device (sometimes referred to as the ‘mesh’), which is essentially just a list of SLIM Links. Currently there are two SLIM instances, one for the frequency slice (FS) mesh, and the other for the visibility (Vis) mesh. While each SLIM Link is identical to the rest, they are organized into different mesh instances to differentiate between distinct stages in the signal processing chain. The SLIM device parses the SLIM configuration file (discussed next), and is responsible for spawning the appropriate links. It also rolls up all of the links’ HealthState attributes into a single master HealthState attribute to summarize the status of the entire mesh. If any of the links report a degraded HealthState, the mesh also becomes degraded.

SLIM Configuration

../../_images/4-receptor-correlator.png

SLIM Interconnections for AA0.5 CBF

SLIM Configuration Sequence

AA0.5 quantities shown.

@startuml
'https://plantuml.com/sequence-diagram

skinparam backgroundColor #EEEBDC
skinparam sequence {
ParticipantBorderColor DodgerBlue
ParticipantBackgroundColor DeepSkyBlue
ActorBorderColor DarkGreen
ActorBackgroundColor Green
BoxBorderColor LightBlue
BoxBackgroundColor #F0FFFF
}

skinparam collections {
  BackGroundColor LightBlue
  BorderColor DodgerBlue
}

skinparam database {
  BackgroundColor LightGreen
  BorderColor DarkGreen
}

title FS SLIM Configuration Sequence\n


box "MCS"
participant "Mid.CBF\nController" as controller
participant "FS\nMesh" as mesh_fs
participant "Vis\nMesh" as mesh_vis
collections "FS\nLinks\n0-15" as links_fs
collections "Vis\nLinks\n0-3" as links_vis
end box

box "VCC-FSP-1\n(Talon A)"
collections "FS\nTx\n0-3"  as tx_fs_1
collections "FS\nRx\n0-3"  as rx_fs_1
participant "Vis\nTx\n"    as tx_vis_1
collections "Vis\nRx\n0-3" as rx_vis_1
end box

box "VCC-FSP-2\n(Talon B)"
collections "FS\nTx\n0-3"  as tx_fs_2
collections "FS\nRx\n0-3"  as rx_fs_2
participant "Vis\nTx\n"    as tx_vis_2
end box

box "VCC-FSP-3\n(Talon C)"
collections "FS\nTx\n0-3"  as tx_fs_3
collections "FS\nRx\n0-3"  as rx_fs_3
participant "Vis\nTx\n"    as tx_vis_3
end box

box "VCC-FSP-4\n(Talon D)"
collections "FS\nTx\n0-3"  as tx_fs_4
collections "FS\nRx\n0-3"  as rx_fs_4
participant "Vis\nTx\n"    as tx_vis_4
end box

controller -> mesh_fs   : Configure()
mesh_fs    -> links_fs  : Configure() x16

group#Red SLIM Links to FSP 1
links_fs   -> tx_fs_1   : Configure FS-Link0-Tx
links_fs   -> rx_fs_1   : Configure FS-Link0-Rx
links_fs   -> tx_fs_2   : Configure FS-Link1-Tx
links_fs   -> rx_fs_1   : Configure FS-Link1-Rx
links_fs   -> tx_fs_3   : Configure FS-Link2-Tx
links_fs   -> rx_fs_1   : Configure FS-Link2-Rx
links_fs   -> tx_fs_4   : Configure FS-Link3-Tx
links_fs   -> rx_fs_1   : Configure FS-Link3-Rx
end group 

group#LightGreen SLIM Links to FSP 2
links_fs   -> tx_fs_1   : Configure FS-Link4-Tx
links_fs   -> rx_fs_2   : Configure FS-Link4-Rx
links_fs   -> tx_fs_2   : Configure FS-Link5-Tx
links_fs   -> rx_fs_2   : Configure FS-Link5-Rx
links_fs   -> tx_fs_3   : Configure FS-Link6-Tx
links_fs   -> rx_fs_2   : Configure FS-Link6-Rx
links_fs   -> tx_fs_4   : Configure FS-Link7-Tx
links_fs   -> rx_fs_2   : Configure FS-Link7-Rx
end group 

group#DodgerBlue SLIM Links to FSP 3
links_fs   -> tx_fs_1   : Configure FS-Link8-Tx
links_fs   -> rx_fs_3   : Configure FS-Link8-Rx
links_fs   -> tx_fs_2   : Configure FS-Link9-Tx
links_fs   -> rx_fs_3   : Configure FS-Link9-Rx
links_fs   -> tx_fs_3   : Configure FS-Link10-Tx
links_fs   -> rx_fs_3   : Configure FS-Link10-Rx
links_fs   -> tx_fs_4   : Configure FS-Link11-Tx
links_fs   -> rx_fs_3   : Configure FS-Link11-Rx
end group 

group#GoldenRod SLIM Links to FSP 4
links_fs   -> tx_fs_1   : Configure FS-Link12-Tx
links_fs   -> rx_fs_4   : Configure FS-Link12-Rx
links_fs   -> tx_fs_2   : Configure FS-Link13-Tx
links_fs   -> rx_fs_4   : Configure FS-Link13-Rx
links_fs   -> tx_fs_3   : Configure FS-Link14-Tx
links_fs   -> rx_fs_4   : Configure FS-Link14-Rx
links_fs   -> tx_fs_4   : Configure FS-Link15-Tx
links_fs   -> rx_fs_4   : Configure FS-Link15-Rx
end group 

@enduml

@startuml
'https://plantuml.com/sequence-diagram

skinparam backgroundColor #EEEBDC
skinparam sequence {
ParticipantBorderColor DodgerBlue
ParticipantBackgroundColor DeepSkyBlue
ActorBorderColor DarkGreen
ActorBackgroundColor Green
BoxBorderColor LightBlue
BoxBackgroundColor #F0FFFF
}

skinparam collections {
  BackGroundColor LightBlue
  BorderColor DodgerBlue
}

skinparam database {
  BackgroundColor LightGreen
  BorderColor DarkGreen
}

title Visibility SLIM Configuration Sequence\n


box "MCS"
participant "Mid.CBF\nController" as controller
participant "FS\nMesh" as mesh_fs
participant "Vis\nMesh" as mesh_vis
collections "FS\nLinks\n0-15" as links_fs
collections "Vis\nLinks\n0-3" as links_vis
end box

box "VCC-FSP-1\n(Talon A)"
collections "FS\nTx\n0-3"  as tx_fs_1
collections "FS\nRx\n0-3"  as rx_fs_1
participant "Vis\nTx\n"    as tx_vis_1
collections "Vis\nRx\n0-3" as rx_vis_1
end box

box "VCC-FSP-2\n(Talon B)"
collections "FS\nTx\n0-3"  as tx_fs_2
collections "FS\nRx\n0-3"  as rx_fs_2
participant "Vis\nTx\n"    as tx_vis_2
end box

box "VCC-FSP-3\n(Talon C)"
collections "FS\nTx\n0-3"  as tx_fs_3
collections "FS\nRx\n0-3"  as rx_fs_3
participant "Vis\nTx\n"    as tx_vis_3
end box

box "VCC-FSP-4\n(Talon D)"
collections "FS\nTx\n0-3"  as tx_fs_4
collections "FS\nRx\n0-3"  as rx_fs_4
participant "Vis\nTx\n"    as tx_vis_4
end box

controller -> mesh_vis  : Configure()
mesh_vis   -> links_vis : Configure() x4

links_vis   -> tx_vis_1  : Configure Vis-Link0-Tx
links_vis   -> rx_vis_1  : Configure Vis-Link0-Rx
links_vis   -> tx_vis_2  : Configure Vis-Link1-Tx
links_vis   -> rx_vis_1  : Configure Vis-Link1-Rx
links_vis   -> tx_vis_3  : Configure Vis-Link2-Tx
links_vis   -> rx_vis_1  : Configure Vis-Link2-Rx
links_vis   -> tx_vis_4  : Configure Vis-Link3-Tx
links_vis   -> rx_vis_1  : Configure Vis-Link3-Rx 

@enduml

SLIM Tx / Rx Device Servers (HPS)

Note: See SLIM Tx/Rx Documentation for more details.

SLIM Tx

Ref: tx_slim.tango.json

SLIM Rx Ref: rx_slim.tango.json