AVED Management Controller (AMC) - Architecture and Design

Overview

The AVED Management Controller (AMC) provides management and control of the Alveo RPU. Its basic features include, but are not limited to:

In addition, the AMC is fully abstracted from:

Event driven architecture is provided by the Event Library (EVL).

Layered Architecture

image1

Firmware Interface Abstraction Layer (FAL)

Firmware Interface (FW_IF) Abstraction Layer - Data Center Group - Xilinx Enterprise Wiki

The FAL allows the hardware and associated drivers to be swapped out without requiring a change to the higher level data formatting and behavior.

It also allows Proxy Drivers to be modified to use a different interface with minimal changes.

Operating System Abstraction Layer (OSAL)

Operating System Abstraction Layer (OSAL) - Data Center Group - Xilinx Enterprise Wiki

The OSAL allows the AMC to be ported to a different OS without requiring code changes in the AMC or its layers.

A common osal.h API is provided with a generic API. FreeRTOS and Linux implementations of this API are released with the AMC - however, a user can provide their own RTOS implementation if they prefer (e.g. osal_FreeRTOS.c can be replaced with a user-written osal_UCOS.c).

Common definitions and Core Libraries

Core Libs

Core Libraries are modules that:

  1. Are NOT BOUND to a specific proxy driver or application’s behavior

  2. Are REUSABLE across any other module

The Core Library layer exists within the Common layer, which holds all system-common includes and definitions.

Event Library (EVL)

The EVL allows event signaling to ‘higher’ layers. It is predominantly used for proxy drivers to communicate to the application layer whilst maintaining agnosticism and abstraction.

See Events and Signals for more information.

Debug Access Library (DAL)

The DAL provides an API to create and maintain a dynamic menu structure that sits above STDIN, providing a debug interface for calling into any API in the AMC.

Note - the debug interface is provided for development and debugging purposes only; it is not supported nor maintained, and incorrect usage may have unintended consequences to both firmware and hardware.

Printing and Logging Library (PLL)

The PLL provides an API to handle all thread-safe printing and logging. This core library sits above STDOUT/STDIN, and allows for multiple output streams (stdout/ PCIe etc), at different logging levels (ALL, DEBUG, INFO, ERROR).

Common Includes

Standard definitions

The standard.h header file provides project-wide definitions for regular use - return codes, typedefs, etc.

Utility definitions

The util.h header file provides project-wide utility definitions and macros for regular use - printing macros, common calculations, etc.

Event ID

The event_id.h header file contains definitions of unique event ids for each proxy driver within AMC.

Device Drivers

Device drivers provide an API over some BSP-provided drivers and utilities as well as APIs to interact with other hardware devices.

EEPROM

The EEPROM driver implements functions to access the manufacturing EEPROM (using the I2C driver).

EMMC (IN_PROGRESS)

The EMMC driver allows simple reading and writing, of eMMC flash memory.

GCQ

The GCQ driver has been implemented as a standalone driver (submodule).

I2C

The I2C driver allows simple I2C reading, writing, and write-read combinations (over the Xilinx Xiic driver). This allows the sensors, QSFP layer, etc, to perform I2C transactions without having to initialise or maintain an I2C instance.

OSPI

The OSPI driver allows simple reading and writing, of flash devices (over the Xilinx OSPIPSV device driver).

Sensors

cat34ts02

The cat34ts02 driver provides temperature reading (using the I2C driver) from the cat34ts02 sensor.

ina3221

The ina3221 driver provides voltage, current and power readings (using the I2C driver) from the ina3221 sensor.

isl68221

The isl68221 driver provides voltage, current and temperature readings (using the I2C driver) from the isl68221 sensor.

SysMon

The SysMon (system monitor) driver allows temperature reading (using the Xilinx xSysMonPsv driver) from the FPGA.

Profiles

The Profiles hold all profile-specific (board-specific) includes and definitions, allowing AMC to be ported to different target hardware without requiring code changes in the AMC or its layers.

See Profiles and CMake build process#Profiles for a more detailed description of how profiles are used to port AMC across different platforms.

Proxy Drivers

The Proxy drivers abstract a capability’s behavior away from it’s functionality. In other words, a proxy driver allows the application layer to consider AMC capabilities (e.g. clock control, host communications, sensor handling) as abstract concepts, rather than requiring them to understand the inner workings and behavior of these parts of the AMC.

Inter-Proxy communication

Proxy drivers do not communicate with other proxy drivers, as this would break their independence from behavioral design.

In the event where a proxy driver requires a call into another (this should never be more than a simple read/write, or status return) it should done via the EVL.

E.g.:


image2


Note - in many cases, a “Get” API for a proxy will be called within the EVL Record signaled by the proxy driver task itself. In that case, the data mutexing is redundant.

However, the purpose of a “Get” API is to expose data to any application call, and so in theory a “Get” function can be called from multiple concurrent tasks at any time.

E.g.:

  1. Proxy_A stores data (grabs and releases its mutex) and raises the appropriate event.

    1. The application’s event_callback A (still within the context of Proxy_A’s task) calls Proxy_A’s “Get” function.

    2. Proxy’s A’s “Get” function waits for the mutex, grabs it, copies the data, and releases the mutex.

  2. At the same time, proxy B raises an event. In this example, the corresponding event callback requires retrieving data from Proxy_A.

    1. The application’s event_callback B (within the context of Proxy_B’s task) calls Proxy_A’s “Get” function.

    2. Proxy’s B’s “Get” function waits for the mutex, grabs it, copies the data, and releases the mutex.

Applications

The Application layers provides control of the overall AMC, while still allowing a logical separation of different parts of the overall control.

Main application (AMC)

The main AMC application provides the initialization of all other layers and modules within the system.

It also is the first event handler for each proxy driver event raised, passing any AMI Host commands to the relevant submodule (excluding telemetry).

In-Band Telemetry

The In-Band Telemetry application handles the events and communication between the Host and the Sensors.

Out-Of-Band Telemetry (IN_PROGRESS)

The Out-Of-Band Telemetry application handles the events and communication between the Remote Management Interface (RMI) and the Sensors.

Alveo Sensor Data Model (ASDM)

The ASDM app defines the ASDM structure for the specific version of the ASDM used by the AMC.

AMC is designed to be as separated from the ASDM as much as possible. If the ASDM definition is changed or a new version is required, all that should change is the ASDM application, and any references to it in the In-Band Telemetry/Out-Of-Band Telemetry applications.

Built-In-Monitoring Application (BIM)

The Built-In-Monitoring Application (BIM) monitors all events throughout AMC and logs errors accordingly

Tasks

With the exception of the AMC Main Task, each task handles RX’ing and TX’ing:

image3

Note: In the above example, Proxy N can be the same proxy as Proxy X.

AMC (main task)

Description

  • Initialized from the project’s main entry point.

  • “Top-layer” task that allows communication between other tasks.

Responsibilities

  • Initialize other tasks.

  • Create global resources.

  • Bind proxy driver callbacks (and maintain responsibility for those callbacks).

  • Handle proxy driver events (via the afore-mentioned callbacks) and pass data to relevant tasks.

Initialisation

image4

  1. fw_if_XXX_init calls.

  2. fw_if_XXX_create calls.

    • FW_IF_CFG structures held locally in the AMC application level.

  3. XXX_PROXY_DRIVER_Initialise calls.

    • FW_IF_CFG handle and Proxy ID

  4. XXX_PROXY_DRIVER_BindCallback calls.

    • Event-handling callback passed in.

  5. Do nothing - keep alive task.

    • If available, can flash an LED or kick a watchdog to show signs of life.

AVED Management Interface (AMI) Proxy Driver

Description

  • Initialized from the AMC task.

  • Handles communication to/from the Host (AMI).

  • The only part of the AMC that needs to know about the GCQ message format and contents.

Responsibilities

  • Monitors the FW_IF data for requests from AMI including:

    • PDI download request

    • PDI copy request

    • Sensor request

    • Identity request

    • Boot Select request

    • Heartbeat request

    • EEPROM read/write request

    • Module read/write request

  • Provides “Get” APIs to the AMC application for messages Rx’d from the AMI. These include APIs to:

    • Get the PDI download request

    • Get the PDI copy request

    • Get the Sensor request

    • Get the Boot Select request

    • Get the eeprom read write request

    • Get the module read write request

    • Print all the stats gathered by the application

    • Clear all the stats in the application

  • Provides “Set” APIs to the AMC application for messages to Tx to the AMI. These include APIs to:

    • Set the response after the PDI download has completed

    • Set the response after the PDI copy has completed

    • Set the response after the sensor request has completed

    • Set the identity request response

    • Set the response after the Boot select has completed

    • Set the response after the EEPROM read/write has completed

    • Set the response after the module read/write has completed

AVED Programming Control (APC) Proxy Driver

Description

  • Initialized from the AMC task.

  • Handles flash-programming related commands.

  • Provides a single interface to the flash memory for the application.

Responsibilities

  • Provides “Get” APIs to the AMC application for retrieving information on the flash memory. These include APIs to:

    • Get the Flash Partition Table (FPT) Header

    • Get a Flash Partition Table (FPT) Partition

    • Print all the stats gathered by the proxy driver

    • Clear all the stats in the proxy driver

  • Provides “Set” APIs to the AMC application for writing/committing to flash memory. These include APIs to:

    • Download an image to a location in non volatile memory

    • Download an image with an FPT to a location in NV memory

    • Copy an image from one partition to another

    • Select which partition to boot from

    • Enable the hot reset capability

AVED Clock Control (ACC) Proxy Driver

Description

  • Initialized from the AMC task.

  • Handles clock related commands (throttling, shutdown, etc.).

  • Provides a single interface to any clock control for the application.

Responsibilities

  • Provide “Get” API to the AMC application for retrieving information on the clocks. These include APIs to:

    • Print all the stats gathered in this driver

    • Clear all the stats in this driver

  • Provide “Set” API to the AMC application for managing and controlling the clocks. These include APIs to:

    • Enable Clock Shutdown for threshold crossing

    • Disable Clock Shutdown for threshold crossing

    • Report to ACC that a sensor has exceeded fatal limit

    • Report to ACC that a sensor has exceeded critical limit

    • Report to ACC that a sensor has exceeded warning limit

    • Re-enable the clock if previously shutdown

AVED External Device Control (AXC) Proxy Driver

Description

  • Initialized from the AMC task.

  • Handles external device related commands.

  • Provides a single interface to any external device control for the application.

  • Provides a simple callback for other tasks (e.g. the ASC) to read sensor data.

Responsibilities

  • Provide “Get” API to the AMC application for retrieving information on the QSFP and other external devices. These include APIs to:

    • Read real-time byte value from desired external device memory map

    • Read real-time memory map from desired QSFP

    • Read single status from QSFP IO Expander

    • Read all statuses from QSFP IO Expander

    • Read real-time temperature value from desired external device memory map

    • Print all the stats gathered by the application

    • Clear all the stats in the application

    • Check if a device exists and the page/byte offset are valid

  • Provide “Set” API to the AMC application for managing and controlling the QSFP devices. These include APIs to:

    • Write byte value to desired external device memory map

  • Provide simple “Get” function typedef to be used as a callback by an sensor-reading applications or processes.

AVED Sensor Control (ASC) Proxy Driver

Description

  • Initialized from the AMC task.

  • Handles sensor related commands (including ASDM).

  • Provides a single interface to any sensor control for the application.

Responsibilities

  • Provide “Get” API to the AMC application for retrieving information on the sensors (including ASDM data). These include APIs to:

    • Get all sensor data

    • Get single sensor data by ID

    • Get single sensor data by name

    • Print all of the stats gathered by the application

    • Clear all of the stats in the application

  • Provide “Set” API to the AMC application for managing and controlling the sensors. These include APIs to:

    • Reset current, average, max and status values for all sensors

    • Reset current, average, max and status values for a single sensor by ID

    • Reset current, average, max and status values for a single sensor by name

RMI Handler (IN_PROGRESS)

Description

  • Initialized from the AMC task.

  • Handles RMI control.

  • Provides a single interface to the RMI for the application.

Responsibilities

  • Provide “Get” API to the AMC application for retrieving information on the RMI.

  • Provide “Set” API to the AMC application for managing and updating the RMI.

Scheduling

The AMC shall use Round-Robin scheduling.

Event-driven architecture

Overview

Proxy Drivers provide specified behavior and control for a particular aspect of the system. They allow the applications (e.g. AMC) to view a subsystem (e.g. sensor control, host communications, etc.) as an API reduced to Sets and Gets, and to react to the proxy driver based upon real-time events.

This functionality is provided by the Event Library (EVL). This library provides a common API for any module wishing to provide callback binding and event raising to another module.

Data flow

Initialization

  1. Application initializes local data.

  2. Proxy Driver stores proxy ID and callback function pointer from the application.

  3. Proxy Driver initializes/creates firmware interfaces and drivers (where applicable).

  4. Proxy driver creates task.


image5

Getting Data

  1. Proxy driver (1) task receives data from a firmware interface or driver, etc.

  2. Proxy driver (1) task stores data in thread-safe (mutex-protected) local data struct.

  3. Proxy driver (1) task raises event via the callback function pointer.

  4. Application callback function (in the task context) calls proxy driver (1) API “Get” function to retrieve data.

  5. Another Proxy driver (2) raises an event that requires retrieving the same data.

  6. Application callback function (in the task context) calls proxy driver (1) API “Get” function to retrieve data.


image6

The proxy driver’s “Get” API functions provide a public exposure of its data.

As it is possible for multiple tasks to raise events requesting the same data, the “Get” API functions must mutex the retrieved data.

E.g.:

Example data getting

int AMI_PROXY_DRIVER_GetRequest( AMI_PROXY_DRIVER_REQUEST_TYPE *pxRequestType )
{
    int iStatus = ERROR;

    if( NULL != pxRequestType )
    {
        /* data is mtx protected to allow API to be called from concurrent tasks */
        if( GRAB_RX_MUTEX )
        {
            *pxRequestType = localData->pxRxData->xLastRequest;
            RELEASE_RX_MUTEX;
        }

        iStatus = OK;
    }

    return iStatus;
}

Setting Data

  1. Application passes data to the proxy driver.

  2. Proxy driver stores data for the proxy task driver task, either by:

    1. Posting data in a mailbox which the task will pend on, OR

    2. Storing the data to the local data structure (within a mutex guard).

  3. Proxy driver task writes data to a firmware interface or driver, etc.


image7

  • Option A (mailbox posting) is best used when the data must be acted upon in as real-time as possible (e.g. writing out to a driver).

  • Option B (mutexed storing) is best used when the data will be picked up in the next loop iteration or a subsequent action (e.g. an algorithm input).

Note - the “Setting” mutex should be a separate mutex from the “Getting mutex”.

The proxy driver’s “Set” API functions allow public setting of its data.

Option A e.g.:

Example data setting (A)

/* structure used post message to the proxy task */
typedef struct _AMI_MSG_Q
{  AMI_PROXY_DRIVER_MSG_TYPE    xCmd;
    union
    {    AMI_PROXY_DRIVER_SENSOR_UPDATE xSensorUpdate;
        /* etc */
    };

} AMI_MSG_Q;

int AMI_PROXY_DRIVER_SetSensorUpdates( AMI_PROXY_DRIVER_SENSOR_UPDATE *pxSensorUpdate )
{
    int iStatus = ERROR;

    if( NULL != pxSensorUpdate )
    {      AMI_MSG_Q xMsgData = { 0 };

        /* set message type and copy new data */
        xMsgData.xCmd = AMI_PROXY_DRIVER_MSG_SENSOR_UPDATE;
        memcpy( &xMsgData.xSensorUpdate, pxSensorUpdate, sizeof( AMI_PROXY_DRIVER_SENSOR_UPDATE ) );

        /* post to the queue */
        if( OK == iOSAL_mailbox_post( &localData->pxQHandle, ( void * )&xMsgData, sizeof( AMI_MSG_Q ), OSAL_NO_WAIT ) )
        {
            iStatus = OK;
        }
    }

    return iStatus;
}

Option B e.g.:

Example data setting (B)

int AMI_PROXY_DRIVER_SetRequest( AMI_PROXY_DRIVER_SENSOR_UPDATE *pxSensorUpdate )
{
    int iStatus = ERROR;

    if( NULL != pxSensorUpdate  )
    {
        /* data is mtx protected to allow API to be called from concurrent tasks */
        if( GRAB_TX_MUTEX )
        {
            localData->pxRxData->xLastRequest = *pxSensorUpdate ;
            RELEASE_TX_MUTEX;
        }

        iStatus = OK;
    }

    return iStatus;
}

Events and Signals

Events

Each proxy driver defines a list of events (i.e. as an enum) that are publicly available to the application layer above.

An example list for the AMI Proxy Driver might be:

AMI Proxy Driver events

typedef enum AMI_PROXY_DRIVER_EVENTS
{
    AMI_PROXY_DRIVER_E_SENSOR_READ_REQUEST = 0,
    AMI_PROXY_DRIVER_E_SENSOR_RESET_REQUEST,
    AMI_PROXY_DRIVER_E_CLOCK_SHUTDOWN_REQUEST,

    /* etc... */

    AMI_PROXY_DRIVER_E_RX_MSG_FAILURE,
    AMI_PROXY_DRIVER_E_TX_MSG_FAILURE,

    MAX_AMI_PROXY_DRIVER_EVENT

} AMI_PROXY_DRIVER_EVENTS;

(This is only an example and is not indicative of what’s in the code)

Each proxy driver holds an EVL (Event Library) record. The record holds a pool of function pointers, defined as:

eventCallback

typedef int ( EVL_CALLBACK )( uint8_t ucModuleId, uint8_t ucEventId, uint8_t ucInstance );

Event binding

Each proxy driver also holds a local uint8_t variable to store their “Proxy ID” (a single byte unique to that that proxy driver).

During initialization, the proxy driver takes in a unit8_t variable that the proxy driver stores as their proxy ID.

E.g.:

Example initialisation

int iAMI_PROXY_DRIVER_Initialise( uint8_t ucProxyID, FW_IF_CFG *pxFwIf )
{
    int iStatus = ERROR;

    if( ( FALSE == pLocalData->iInitialised ) && ( NULL != pxFwIf ) )
    {
        pLocalData->ucMyID          = ucProxyID;
        pLocalData->pxFwIf          = pxFwIf;

        pLocalData->pxFwIf->open( localData->pxFwIf->open );

        /* additional setup... */

        pLocalData->iInitialised = TRUE;
        iStatus = OK;
    }

    return iStatus;
}

The proxy also provides an API to take in a function pointer (up to EVL_MAX_BINDINGS amount), defined by the application layer, that the proxy driver’s EVL record stores.

E.g.:

Example initialisation

int iAMI_PROXY_DRIVER_BindCallback( xAMI_PROXY_DRIVER_EVENT_CALLBACK *pxEventCallback )
{
    int iStatus = ERROR;

    if( ( TRUE == pLocalData->iInitialised ) && ( NULL != xpEventCallback ) )
    {
        iStatus = iEVL_BindCallback( &pLocalData->xEVLRecord, xpEventCallback );
    }

    return iStatus;
}

The application maintains a list (e.g. enum) of the different Proxy IDs. E.g.:

Example initialisation call

typedef enum AMC_PROXY_DRIVER_IDS
{
    AMC_PROXY_DRIVER_ID_AMI = 0x01,
    AMC_PROXY_DRIVER_ID_ASC = 0x02,
    AMC_PROXY_DRIVER_ID_AFC = 0x03,

    /* etc... */

    MAX_AMC_PROXY_DRIVER_ID

} AMC_PROXY_DRIVER_IDS;

void vInitialiseLayer_FAL( void )
{
    /* FW_IF initialisations and creations */
}

void vInitialiseLayer_ProxyDrivers( void )
{
    if( OK == iAMI_PROXY_DRIVER_Initialise(  AMC_PROXY_DRIVER_ID_AMI, &xGCQ_IF_Ami )
    {
        iAMI_PROXY_DRIVER_BindCallback( &iMyAmiCallback );
    }
    else
    {
        printf( "Error initialising AMI Proxy Driver\r\n" );
    }

    if( OK == iASC_PROXY_DRIVER_Initialise( AMC_PROXY_DRIVER_ID_ASC, &xI2C_IF_Sensors )
    {
        iASC_PROXY_DRIVER_BindCallback( &iMyAscCallback );
    }
    else
    {
        printf( "Error initialising ASC Proxy Driver\r\n" );
    }

    /* etc... */
}

The application defines a local callback that handles the events for the proxy driver. E.g.:

Example event handling

int iMyAmiCallback( uint8_t ucProxyID,  uint8_t ucEventID, uint8_t ucInstance )
{
    int iStatus = ERROR;

    if( AMC_PROXY_DRIVER_ID_AMI == ucProxyID )
    {
        switch( ucEventID )
        {
        case AMI_PROXY_DRIVER_E_SENSOR_READ_REQUEST:
        {
            /* retrieve data first */
            if( OK == AMI_PROXY_DRIVER_GetSensorReadRequest( ucInstance, uint8_t &ucRequest ) )
            {
                /* handle data appropriately, e.g. send it to the relevant subsystem */
                if( OK == ASC_PROXY_DRIVER_GetSensorData( ucInstance, ucRequest, &xSensorData ) )
                {
                    iStatus = OK;
                }
            }

            break;
        }

        /* etc, cases for all the AMI Proxy Driver events... */

        default:
            break;
        }
    }

    return iStatus;
}

Event Raising

The proxy driver raises the events via the EVL. It can also store the unique instance of this event raised for further use (if necessary). E.g.:

Example event calling

/* prepare data for retrieval by the application */
if( GRAB_RX_MUTEX )
{
    memcpy( &pLocalData->pxRxData->ucSensorReadRequest, &ucNewSensorReadRequest, sizeof( uint8_t ) );
    RELEASE_RX_MUTEX;
}

/* note - the "GRAB/RELEASE RX_MUTEX" should also be used in the "AMI_PROXY_DRIVER_Get..." function that retrieves this same data */

/* raise event */
iEVL_RaiseEvent( &pLocalData->xEVLRecord( pLocalData->ucMyID, AMI_PROXY_DRIVER_E_SENSOR_READ_REQUEST, &ucLastEvRecord );

Note: Not every event has to be associated with data or with a “Get” function. An event may simply be an update that something has occurred, or it may be a single command/request that doesn’t require any further clarity.


Upon an event being raised, the EVL assigns that specific instance a unique value which can be stored by the caller. This instance event is passed through to the application callback, where it can be passed on to any Proxy Driver public API functions. This allows Proxy Drivers to check if an incoming API call is in response to a specific event raised.

It is the responsibility of the Proxy Driver to maintain its own record of event instances, to whatever depth it deems necessary.

Event List

ACC Proxy Driver

Event NameModule IDEvent IDDescriptionApplications handling
ACC_PROXY_DRIVER_E_CLOCK_SHUTDOWN_ENABLED



0x00

0x00

Clock Shutdown enabled for threshold crossing

AMC Main
ACC_PROXY_DRIVER_E_CLOCK_SHUTDOWN_DISABLED0x01Clock Shutdown disabled for threshold crossingAMC Main
ACC_PROXY_DRIVER_E_CLOCK_SHUTDOWN_ACTIVATED0x02Report clock shutdownAMC Main
ACC_PROXY_DRIVER_E_CLOCK_SHUTDOWN_CLOCK_REENABLED0x03

Report clock has been reenabled

AMC Main

AXC Proxy Driver

Event NameModule IDEvent IDDescriptionApplications handling
AQC_PROXY_DRIVER_E_QSFP_PRESENT


0x01

0x00QSFP module (added to AXC proxy) is present, temperature will be polled by the proxyAMC Main
AQC_PROXY_DRIVER_E_QSFP_NOT_PRESENT0x01QSFP module (added to AXC proxy) is not present, temperature cannot be polled by the proxyAMC Main

APC Proxy Driver

Event NameModule IDEvent IDDescriptionApplications handling
APC_PROXY_DRIVER_E_DOWNLOAD_STARTED






0x02




0x00Image download to flash, startedAMC Main
APC_PROXY_DRIVER_E_DOWNLOAD_COMPLETE0x01Image download to flash, completeAMC Main

APC_PROXY_DRIVER_E_DOWNLOAD_BUSY

0x02APC busy downloading image to flash (Mutex taken)AMC Main

APC_PROXY_DRIVER_E_DOWNLOAD_FAILED

0x03Image download to flash, failedAMC Main

APC_PROXY_DRIVER_E_FPT_UPDATE

0x04Update FPT ASDM

APC_PROXY_DRIVER_E_COPY_STARTED

0x05Image copy to flash, startedAMC Main

APC_PROXY_DRIVER_E_COPY_COMPLETE

0x06Image copy to flash, completeAMC Main

APC_PROXY_DRIVER_E_COPY_BUSY

0x07APC busy copying image to flash (Mutex taken)AMC Main

APC_PROXY_DRIVER_E_COPY_FAILED

0x08Image copy to flash, failedAMC Main

APC_PROXY_DRIVER_E_PARTITION_SELECTED

0x09 FPT partition selectedAMC Main

APC_PROXY_DRIVER_E_PARTITION_SELECTION_FAILED

0x0A FPT partition selection failedAMC Main

ASC Proxy Driver

Event NameModule IDEvent IDDescriptionApplications handling
ASC_PROXY_DRIVER_E_SENSOR_UPDATE_COMPLETE







0x03

0x00Sensor reading complete with no issuesIn-band Telemetry
ASC_PROXY_DRIVER_E_SENSOR_UNAVAILABLE0x01Sensor is reporting as unavailableIn-band Telemetry
ASC_PROXY_DRIVER_E_SENSOR_COMMS_FAILURE0x02Communication failure when reading sensorIn-band Telemetry
ASC_PROXY_DRIVER_E_SENSOR_WARNING0x03Sensor is reporting a warningIn-band Telemetry
ASC_PROXY_DRIVER_E_SENSOR_CRITICAL0x04Sensor is reporting a critical warningIn-band Telemetry
ASC_PROXY_DRIVER_E_SENSOR_FATAL0x05Sensor is reporting a fatal warningIn-band Telemetry
ASC_PROXY_DRIVER_E_SENSOR_LOWER_WARNING0x06Sensor reading is lowIn-band Telemetry
ASC_PROXY_DRIVER_E_SENSOR_LOWER_CRITICAL0x07Sensor reading is critically lowIn-band Telemetry
ASC_PROXY_DRIVER_E_SENSOR_LOWER_FATAL0x08Sensor reading is fatally lowIn-band Telemetry
ASC_PROXY_DRIVER_E_SENSOR_UPPER_WARNING0x09Sensor reading is highIn-band Telemetry
ASC_PROXY_DRIVER_E_SENSOR_UPPER_CRITICAL0x0ASensor reading is critically highIn-band Telemetry
ASC_PROXY_DRIVER_E_SENSOR_UPPER_FATAL0x0BSensor reading is fatally highIn-band Telemetry

AMI Proxy Driver

Event NameModule IDEvent IDDescriptionApplications handling
AMI_PROXY_DRIVER_E_PDI_DOWNLOAD_START




0x04



0x00Host wants to start a PDI DownloadAMC Main
AMI_PROXY_DRIVER_E_PDI_COPY_START0x01Host wants to start a PDI CopyAMC Main
AMI_PROXY_DRIVER_E_SENSOR_READ0x02Host wants to read sensor dataIn-band Telemetry
AMI_PROXY_DRIVER_E_GET_IDENTITY0x03Host wants the AMC version informationAMC Main
AMI_PROXY_DRIVER_E_BOOT_SELECT0x04Host sends boot select requestAMC Main
AMI_PROXY_DRIVER_E_HEARTBEAT0x05Host wants the current heartbeat counterNone
AMI_PROXY_DRIVER_E_EEPROM_READ_WRITE0x06Host sends eeprom read write requestIn-band Telemetry
AMI_PROXY_DRIVER_E_MODULE_READ_WRITE0x07Host sends module read write requestIn-band Telemetry

RMI HandlerIN_PROGRESS


Application Behaviour

In-Band Telemetry

The In-Band Telemetry application handles any requests from the In-Band interface (AMI Proxy) that require data or information from other proxy drivers (primarily the ASC).

This application does not have its own task and operates entirely on events raised by the AMI and ASC proxy drivers.

Out-of-Band Telemetry (IN_PROGRESS)

The Out-of-Band Telemetry application handles any requests from the Out-of-Band interface (RMI Handler) that require data or information from other proxy drivers (primarily the ASC).

This application does not have its own task, and operates entirely on events raised by the RMI Handler and ASC proxy drivers.


Page Revision: v. 127