Spec brokers AdvancedTCA and IRTM interoperability
David explains the circumstances that led to the creation of a framework for design disclosure to address Zone 3 interconnect standardization.
Modern computing systems, with their varied array of I/O choices, have sought access to these I/Os in many different ways. With the limitations of front-panel space and backplane standards that support only particular bus or fabric types, many standards provide for passage of different I/O types to the rear through the use of Rear Transition Modules (RTMs). In many cases, the particular RTM standard specifies what I/O you need to route on specific pins of specific connectors in specific locations. The PICMG 3.0 AdvancedTCA specification solves this problem by leaving the primary rear transition I/O area known as “Zone 3” user-defined. This approach creates flexibility and allows board developers to create RTMs that are precisely matched to their specific board’s I/O and power requirements. With the recently ratified PICMG Intelligent RTM specification (IRTM.0), a framework has been defined to foster disclosure of design information, promoting interoperability of various implementations of Intelligent RTMs (IRTMs) and to standardize a management infrastructure for IRTMs to enable operation between compatible AdvancedTCA Front Boards and IRTMs from different vendors (Figure 1).
An electrical extension of the front board
The “wide open” concept behind the Zone 3 area is a good thing. Board designers using other board standards have been frustrated with the fixed choice of connector types and pinouts for the rear interconnects that don’t always match well with the particular I/Os trying to egress. With Zone 3, board designers are free to select from a seemingly unlimited set of connectors with which to pass the I/O to a rear transition module. Combinations of single-ended interconnects and differential interconnects can be easily accommodated by using separate connectors in the Zone 3 area. Need better power connections? Find yourself a stouter power connector, and throw that in as well. The possibilities for functionality on the RTM are greatly increased with the use of application- specific interconnects. In fact, the RTM for AdvancedTCA, as opposed to traditional RTMs, has essentially become an electrical extension of the Front Board, many times containing electrical components of complexity equal to what you’d find on the Front Board.
There is a downside to all of this flexibility, however. The variety of Zone 3 implementations led to situations where specific RTMs must be used with specific Front Boards, forming proprietary solutions. These situations are ironic when one considers that AdvancedTCA was created to foster a transition from legacy telecommunication systems with proprietary network elements to modular network elements, allowing for the use and reuse of standardized off-the-shelf components.
The need for standardization
The industry recognizes the need for standardization of the Zone 3 interconnects. Communication equipment providers have pushed standardization by utilizing a common interconnect for Zone 3 on their Front Board products and disclosing their design information to various suppliers to provide a variety of compatible RTMs. Until now, however, this design information has remained largely in the possession of the equipment providers and some of their suppliers. Without a forum for publically disclosing the design information, diverse interoperable product development is stifled.
As the equipment providers and their suppliers are all members of PICMG, and the issue surrounds the Zone 3 section of AdvancedTCA, the members decided to create a framework for design disclosure. This framework is known as the “IRTM Mechanical Keying Repository.” A representation of the data stored in the repository is shown in Figure 2. As of this writing the exact format of the data as it appears on the PICMG website has not been determined.
Simple in concept, the repository is maintained on the PICMG website and allows sponsors of a particular Zone 3 implementation to publicize links to their implementation-specific design information. It also allows supporters of a particular Zone 3 implementation to publicize their support. It is believed that an even bigger benefit will be realized as designers reference the repository when considering new Front Board or RTM designs. Why reinvent the wheel? If designers find a Zone 3 implementation in the repository that fits their applications well, it is expected that they will adopt the implementation to foster interoperability among products, increasing sales opportunities for their new designs. Although there will always be cases where a Zone 3 interface is so application-specific that it isn’t widely supported, with Zone 3 implementations being fully disclosed products should tend to gravitate to a relative few implementations.
The repository contains the necessary information for describing the various IRTM implementations. For example, a typical IRTM like that shown in Figure 1 might support a Zone 3 interconnect that is standard with a variety of Front Boards, using PCIe and other I/O standards like Gigabit Ethernet SERDES signals at the interface. The general-purpose nature of PCIe, for example, would allow other vendors to offer products with features other than those shown in Figure 1 while still remaining compatible with the same Front Boards.
With the management system mandated by IRTM.0 (more on that below), the Front Boards can discover the particular IRTM installed and enable I/Os as appropriate. PICMG assigns an entry in the repository for each unique implementation of the Zone 3 I/O interface (for example, entry #104, Figure 3) and products, assuming they were all IRTM.0 compliant, would be referenced as “IRTM.0 REP 104 Compliant.” This term means that the product is compliant to the PICMG IRTM.0 specification, and also to the sponsor’s implementation specific design document accessed using the information in the repository for entry #104. There would likely be several entries in the repository for entry #104 as there would likely be multiple vendors offering multiple products (both Front Board and IRTM) that support the implementation. But, there would only be one common source (the sponsor) for design information for entry #104, and all entries would reference this source. It is the responsibility of the sponsor of the implementation to maintain the quality of the design document and to make revisions to the document.
Management for the RTM
A primary objective of IRTM.0 is to require a level of manageability similar to what is required for an AMC. The IRTM is another managed FRU in the AdvancedTCA system as shown in Figure 4.
Just like an AMC, the IRTM is required to have a Module Management Controller (MMC) that handles the negotiation with the Front Board’s IPMC in order to enable the Zone 3 interface(s). In fact, the management system definition within IRTM.0 consists of references to applicable sections of the AMC.0 specification, with some slight modifications. For example, the specifics of the Zone 3 interfaces are left up to the discretion of the implementation specific documentation, so the IRTM.0 specification does not impose a requirement that signals like PS#0 and PS#1 are present. All that is required by IRTM.0 is that a method be defined to detect when the IRTM is fully seated and ready for management by the IPMC. Similarly, the Front Board must send an “enable” signal, although it is not required to be implemented as on an AMC, just functionally equivalent. Additionally, concepts like “geographical addressing,” which are necessary to differentiate multiple AMCs on a Front Board, are not applicable to the IRTM. However, other management aspects of an AMC are out of necessity carried forward. The generation of a hot-swap event based on the action of a switch and the requirement for a blue LED enable the management of an IRTM as it is inserted or removed from a Front Board.
AMC and IRTM differences
Because of the uniqueness of the IRTM as compared to an AMC, there are some other differences in the way an IRTM is managed by the IPMC. In an AMC, the payload power supplied by the Front Board is specified to be 12 V. However, power supplied to the IRTM is implementation specific. As a result, the IRTM.0 needs to report power requirements to the IPMC generically, regardless of the actual power used on the Zone 3 interface. For simplicity’s sake, the IRTM.0 specification requires that total power usage, regardless of the power source, be expressed to the IPMC in equivalent units of 12 V. For example, if an IRTM uses 1.0 A of 5 V and 2.1 A of 3.3 V (for a total of 12 W) as the payload power, it would report to the IPMC that it requires 1 A @ 12 V. This allows the IPMC to properly collect total power requirements into its overall budget for reporting to the system manager. If a need exists for determination to a finer detail of power usage between the Front Board and the IRTM, the implementation-specific design document is free to define a suitable mechanism.
Another unique aspect of the Zone 3 interface over the AMC is its ability to support significantly more than 31 ports of signaling. The IRTM.0 specification accommodates this by requiring that the Zone 3 interface be divided into groups of 31 ports (when necessary) per AMC conventions and by assigning a unique “On-Carrier Device ID” to each group. To help prevent the overlapping of “On-Carrier Device IDs” on the IRTM and on the Front Board, the IRTM.0 specification requires that the Front Board assign IDs in forward sequential order starting with ID “0x00” whereas the IRTM assigns IDs in reverse sequential order starting with ID “0x0F”. To complete the management process, the IPMC utilizes the “Zone 3 Interface Compatibility record” to check for Front Board and IRTM compatibility and point-to-point E-Keying, as is done on AMC to enable the various ports. Using these mechanisms, complicated systems with large numbers of ports can be configured to only enable ports determined to be interoperable.
Deriving the bulk of the management requirements from the AMC.0 specification minimizes the requirement for new MMC firmware. An enable signal, the blue LED, and the same hot-swap behavior when the handle position changes are required. This allows IRTM insertion and removal to be managed in a similar way as with an AMC. By sticking to the same power and port usage reporting as defined in the AMC.0 specification, the PICMG community anticipates that a slight modification to MMC firmware can enable IRTM.0 support. As a result, designing RTM interfaces to be compliant to IRTM.0 allows suppliers to reconnect with the original intent of AdvancedTCA, with a choice of interoperable modular equipment.
GE Intelligent Platforms firstname.lastname@example.org www.ge-ip.com