Memory Access Service

Error: unable to migrate element with tag=""

The following diagram shows how the JAS Memory Access Service fits into the overall communication stack. The Memory Access Service provides a standard interface to applications that allows them to remotely access memory on a JAS node across a communication link. This is accomplished through a specific set of software or firmware that interprets incoming protocol packets and performs the memory functions. One example is the Remote Memory Access Protocol (RMAP) for SpaceWire. Another example is communication with a bus controller or remote terminal over a 1553 interface. The memory access service provides the interface to the applications while the method(s) for changing the memory is specific to the protocols and data links that are used.

Applications communicate to the Memory Access Service through an interface described in the CCSDS SOIS subnetwork memory access service standard. The Memory Access Service is responsible for translating and routing data between applications and a variety of memory access protocols. JAS-based systems shall use the interface described in the CCSDS SOIS subnetwork memory access service standard as much as possible. If there are fields that don’t map to a particular protocol or data link, they should still be included, but can be unused. For example, if a node has a single memory map, the use of the Memory ID field may be unnecessary.

The Memory Access Service routes the data to the appropriate protocol based on the destination address that is specified. The destination address shall be unique for a specific node, data link, and protocol. Lookup tables are used to manage this information. The protocols are responsible for packaging the data and handling the communication with the remote node.

The protocols send the data to their respective data link interfaces for communication across the network. Priority and resource reservation are handled at a system level, which means these functions are provided at the data link layer as the data comes together from potentially different protocols. Implementation of priority and resource reservation within JAS is optional and system specific. Some data links may support priority and resource reservation inherently, such as SRIO, and others may not, such as SpaceWire. If needed, a simple method for implementing priority is to use a priority queue at the data link interface and assign each data link packet a priority level. Resource reservation can be implemented using a time multiplexed or bandwidth based approach. JAS systems should be able to support either if necessary, but there is no specific standard defined for JAS at this time. A simple method for implementing guaranteed bandwidth is to create a set of channels for a particular data link. Data link packets get assigned to a specific channel and then data is pulled from the channels and written to the data links based on the percent of bandwidth that is allocated to the channel.

The following diagram describes the implementation approach for the JAS memory access service and shows how it maps to the CCSDS SOIS memory access service standard. It shows the communication service layers from applications to data links and describes the information provided at each layer and how it is used. At each service layer, information is provided through lookup tables or argument parameters that are passed to route the data through the communications stack. The left hand side of the diagram, the transmit side, describes the information used going down the stack, and the right hand side, the receive side, describes the information used going up the stack. These paths correlate to the request and indication primitives described in the CCSDS SOIS memory access service standard.

Lookup tables are stored in configuration data files and provide much of the information that is needed. This is referred to as Management Information Base (MIB) within the CCSDS SOIS standards. Using a MIB reduces the need to hard code the data into applications making them more reusable. MIB data is typically stored in nonvolatile memory separate from applications and read in upon startup. The details are implementation specific.

Implementation Approach

It should be noted that there is one memory access service for each processing node in a JAS system. This eliminates the need for any routing information between the data link protocols and the memory access service when passing data up the communications stack.

There are three memory identifiers used to resolve the source and destination locations of a memory transaction within a system: source address identifier, destination address identifier, and a memory identifier. These identifiers should be abstract references when used within applications. An example is that a destination address identifier references a particular hardware device that uses a memory mapped interface for control. The application should use the specific memory address to access that device, but instead should use an abstract reference for the device. The translation from abstract to physical addresses then takes place in the layers of the communication stack through lookup tables. This allows the details of the device to be managed in lookup tables separately from the applications, making the system more flexible.

Source and destination address identifiers are used to route data within the network. The source address is the MASAP address in the CCSDS SOIS memory access service standard and maps to applications that send and receive memory requests. The destination address maps to an endpoint application in the network that processes the requests such as an RMAP endpoint within a SpaceWire network. Unique addresses shall be assigned to every application within the system that will send or receive data. Multiple destination addresses may be assigned to the same node in order to support endpoints on different data links. This allows for different routing options in the communication stack. Finally, a memory identifier is also specified in the standard to be used at network endpoints to differentiate between memory devices when they have different memory maps. If all memory devices at an endpoint share the same memory map, this option may not be needed.

Transaction identifiers are assigned to requests in order for applications and protocols to correlate indications, or responses they receive. The protocols are responsible for maintaining the transaction identifiers and notifying applications, via the memory access service, if expected responses are not received.

Address, data and size parameters are used to physically access the memory and perform specific function. These map to the start memory address, size and data parameters within the standard. An additional parameter, called address increment, may optionally be used also. This parameter allows for successive read or write operations that skip over memory locations. In other words, if the address increment is two, the first write operation might take place at address n, the second at address n+2, the third at address n+4, and so on. This option is protocol dependent which is why it is optional for JAS systems.

QoS attributes relate directly to the channel, priority, acknowledgement, verification, and authorization parameters within the CCSDS SOIS memory access standard. The use of these QoS values is optional in JAS and based on the needs of the program. These parameters drive the network and data link protocol’s features that will be used. They shall be provided for consistency but can be ignored if not used.

Results are passed to applications through the results metadata parameter. The standards specify that this parameter is used to specify a successful or failed result of the memory access operation.

Lookup tables are used by the services to pass data between the layers of the communication stack. The use of these lookup tables is specific for each data link. For example, SRIO may encapsulate the protocol and data link functions within a single interface, while they may be separate and distinct functions for SpaceWire. The mechanism for passing data between the layers is implementation specific, but it is expected that the source and destination memory identifiers will be used as indexes into the lookup tables to determine how data ultimately gets transmitted on the data link. On the transmit side, the protocol lookup table and data link lookup table will be indexed by the destination address identifier. On the receive side, the protocol lookup table is indexed by a protocol identifier. This is part of the data link packet, assuming the data link supports more than one protocol. The application lookup table is indexed by the source address identifier.

Error Handling

A variety of errors may exist throughout the communication process. Errors should be handled at the lowest level of the communication stack as possible. For example, hardware errors, such as resetting a data link, should be handled at the data link level. Errors should only be propagated up to applications when they need to know it. The CCSDS SOIS memory access service standard identifies the results metadata parameter in the indication primitives to provide feedback to applications in the event of errors associated with failures to complete task. The acknowledgement and verification QoS flags can optionally be used to control some of the error reporting. Protocols use parameters such as the source and destination address identifiers and transaction identifiers to keep track of requests and responses. Timeouts can then be enforced to ensure results are delivered as expected and errors can be sent if they are not.

Programs shall define the set of error conditions that are appropriate to propagate up to applications and share this information to application developers. For flexibility, error identifiers should use a lookup table approach where an error number is sent to the application and additional information on actions can be provided in the table. An example would be to use an approach similar to the standard set of errors returned by the “errno” flag, which is available in many programming languages such as C & C++. Additional metadata should be made available to applications if they need more details. The specifics of what metadata will be used shall be defined by the program and it shall be documented and provided to each application as part of the packet service interface definition.