“DC-SCM is a sub-project of the OCP Hardware Management Project. DC-SCM implements modular server management, including all firmware state already stored on a typical processor motherboard. DC-SCMs typically move three key functions into a single standard form factor module (CFM).

“

Summary

DC-SCM is a sub-project of the OCP Hardware Management Project. DC-SCM implements modular server management, including all firmware state already stored on a typical processor motherboard. DC-SCMs typically move three key functions into a single standard form factor module (CFM).

• Management – BMC functionality and a new LTPI interface (Low Voltage Differential Signaling Channel Protocol and Interface)
• Safety
• control

This article describes the three aspects of DC-SCM’s LTPI (Server Management), Security and Control. All three key functions of DC-SCM 2.0 have been implemented in a single FPGA from Lattice semiconductor.

An important change in the DC-SCM 2.0 specification is the introduction of the Low Voltage Differential Signaling Path Protocol and Interface (LTPI). This article describes the DC-SCM and its LTPI implementation in a Lattice FPGA solution.

The DC-SCM’s security module, called ROT (Root of Trust), can be used to solve the security problem of hackers installing malicious code in the flash memory of confidential firmware. The Lattice PFR (Platform Firmware Protection Recovery) solution can act as a ROT for DC-SCM, avoiding such vulnerabilities in data center servers.

Lattice FPGAs also include DC-SCM-defined control functions that provide the re-sequencing and power management functions required by data center servers.

What is DC-SCM?

The Open Compute Project (OCP) is an organization that shares server and data center product designs and best practices among companies. DC-SCM (Datacenter-ready Secure Control Module) is a sub-project of the OCP hardware management project. It provides guidelines for moving common server management, security, and control functions from the motherboard to a standard form factor module (CFM).

The DC-SCM architecture defines the input/output ports that interoperate with the CPU board. The DC-SCM server has only the basic central computing element (CPU), high-speed memory and IO connectors on the HPM (host processor module) board, all other components are on the modular DC-SCM (security, control, management) board .

Why use DC-SCM?

DC-SCM has many benefits:

• DC-SCM enables easy CPU/memory design and deployment because management, security and control functions are independent of CPU/memory board development.

– Separating BMC and RoT implementation from server, enabling independent development and innovation
– Cost savings by moving management circuitry to smaller, lower-cost PCBs
– Save verification time by using a common DC-SCM design across multiple projects and architectures
– Simplifies HPM board layout and reduces development time
– After using DC-SCM, expansion of the chassis can be done with simple general development according to the CPU and SoC vendor’s guidelines

• System management and security features are constantly evolving and independent of CPU generation.

– DC-SCM can deploy management and security upgrades on the platform within one generation without redesigning more complex components

• DC-SCM uses an open source modular approach for easy interoperability.

– Standardized common Modules
– Adopt common interfaces such as high-speed interconnect (PCIe)

One of the advantages of DC-SCM is when servers are retired. The benefit of the modular design is that the security modules can be destroyed individually, and the sale or recycling of end-of-life servers will not reveal security data/keys.

DC-SCM Architecture

The DC-SCM architecture mainly includes the following parts:

• BMC: Baseboard Management Controller
• BMC Flash: use one or more flash devices (usually two) to store the BMC firmware image
• BIOS Flash: Use one or more flash devices (usually two) to store the BIOS firmware image
• DC-SCM CPLD: Programmable logic device containing application specific logic and LTPI interface (new LVDS channel protocol and interface introduced in DC-SCM 2.0)
• RoT Security Processor: The security processor responsible for validating the BMC, BIOS and/or other firmware images on the system
• Trusted Platform Module (TPM): Optional dedicated microcontroller with integrated encryption key to protect hardware

The following figure is a block diagram of the DC-SCM architecture module defined in the DC-SCM specification

DC-SCM LTPI

An important change in the DC-SCM 2.0 specification is the introduction of the Low Voltage Differential Signaling Path Protocol and Interface (LTPI). LTPI addresses the shortcomings of the serial GPIO interface in DC-SCM 1.0.

LTPI has lower latency than GPIO

It allows multiple management interfaces between the host platform module and the DC-SCM module for channel communication (provides channels for I2C, SMBus, UART, data custom protocols)

DC-SCM LTPI Architecture

As shown in the figure below, the LTPI interface is implemented using two FPGA/CPLD devices.

HPM FPGA – Provides bridging of native HPM interface to LTPI
SCM CPLD – Provides bridging of LTPI to native SCM interface

The LTPI interface is used to transmit various low-speed signals between HPM and SCM. The LVDS interface provides higher bandwidth and better scalability than the SGPIO interface in DC-SCM 1.0. It not only supports GPIO, but also supports channel transmission of low-speed serial interfaces such as SMBus, I2C and UART. It is also expandable with additional proprietary OEM interfaces and provides support for raw data channel transfer between HPM CPLDs and SCM CPLDs.

Lattice LTPI

Lattice DC-SCM LVDS channel protocol and interface IP core is a solution compatible with OCP and DC-SCM standards. Lattice LTPI IP fully supports interfaces and protocols conforming to the DC-SCM 2.0 protocol specification. The LTPI IP has the following features:

• Compliant with DC-SCM 2.0 protocol specification
– Link initialization, discovery and negotiation
• Supports multi-channel serial interface
– Supports GPIO, I2C, UART, OEM and data channel aggregation
– Supports aggregation/de-aggregation of up to 7 channels in total
• Supports up to 64-bit GPIO channels with sample rates up to 90kHz (low latency GPIOs up to 5 MHz)
• For I2C/SMBus interfaces, each interface can be configured as master, slave, or both master/slave (for multi-master)
• Supports LVDS and sub-LVDS
• LVDS data rates up to 1000Mbps for LFMXO5 devices

Lattice LTPI Channel Architecture

Building on the DC-SCM LTPI specification, Lattice transmits and receives LTPI channel data between the SCM and HPM using a time division multiplexed (TDM) high-speed LVDS full-duplex link.

As shown in the figure below, for each equal time slot TN (example frame T+1 in the figure below), there is one LTPI frame being transmitted. In each LVDS channel, some LVDS frames are transmitted in both directions. The number of bits allocated to a particular channel in each frame sent over the LTPI interface is proportional to the LTPI bandwidth dedicated to each channel.

Lattice LTPI Channel Block Diagram

The upper channel block diagram of the Lattice LTPI reference design is shown below. Data received from external channels is aggregated and transmitted between the Safety Control Module (SCM) and the Host Processor Module (HPM) via a Low Voltage Differential Signaling (LVDS) interface. Incoming data from the LVDS interface is remapped to the corresponding target external channel.

The DC-SCM/HPM LTPI IP consists of a multiplexer, frame/packet generator/parser, 8b/10b encoder/decoder, word aligner/link synchronizer, and GDDR transmit and receive blocks.

multiplexer

Multiplexer to connect external channels. After link training and feature negotiation, the multiplexer module switches samples between each channel, forming the payload.

Packet Generator/Parser

The frame generator and parser generate the packets required for link training and negotiation. The TX uses a frame generator to generate frames to be sent to the communication receiver. RX uses a frame parser to parse received frames.

8b/10b encoder/decoder

LTPI IP performs 8b/10b encoding/decoding of data sent to/received from the receiving host. For TX, 8-bit data is converted to 10-bit data according to the encoding rules specified in the IEEE 802.3 standard.

GDDR Serializer/Deserializer

Data is sent serially to the receiving host. The IP serializes the data through the generic DDR interface x5 (10 bit: 1 bit) of the LFXMO5 device and the DDR interface x4 (8 bit: 1 bit) of the MachXO3L/LF/D device. Likewise, in RX mode, data is deserialized through the DDR interface.

Lattice LTPI Interface Channel

The Lattice LTPI interface defines the following channels:

• GPIO channel: This channel realizes the mutual transmission of GPIO signals between HPM and SCM. GPIO channels can differentiate between low-latency and normal-latency GPIOs (serial GPIOs), thereby allocating more bandwidth to timing-critical GPIO signals and expanding the number of GPIOs transmitted.

• I2C/SMBus channel: transfers I2C/SMBus link data from SCM to HPM, and from HPM to SCM.

• UART channel: transmits a full-duplex UART interface that supports flow control between SCM and HPM.

GPIO interface

As defined in the DC-SCM specification, GPIO channels define low-latency and normal-latency GPIOs (see figure below). As part of the Lattice IP configuration, each instance of these interface modules uses a 64-bit channel. For successful transmit and receive, the PID (packet identifier) ​​of the transmit channel of the SCM or HPM should match the PID of the receive channel, which is instantiated on the transmit module.

UART interface

The UART interface is sent over the GPIO interface and requires at least one instance of GPIO TX and one GPIO RX channel.

I2C interface

The Lattice LTPI IP uses the I2C/SMBus channel to transfer I2C/SMBus bus data over the LTPI interface for those links that have only one controller on the SCM or HPM. The main use example of the DC-SCM LTPI I2C/SMBus is shown in the figure below, the BMC on the SCM acts as the controller for the I2C/SMBus link where the target device is located on the HPM. Each instance of these interface modules uses a channel. For successful transmission and reception, the PID of the I2C master channel of the SCM or HPM should match the PID of the I2C slave channel instantiated on the other module.

Lattice LTPI Channel Assignment

Lattice LTPI channels can functionally categorize specific types of interfaces used for communication between SCM and HPM. Lattice LTPI also enables flexibility in interface mapping. An example of the design flexibility of LTPI is shown in the figure below (refer to the DC-SCM LTPI specification). In this example, the GPIO channels are converted to SGPIO interfaces and additional logic is added in the SCM CPLD.

Lattice DC-SCM Security Implementation

Enterprise servers typically contain multiple processing components, each with its own non-volatile SPI flash cache that stores its firmware. With unauthorized access to the firmware, hackers can surreptitiously install malicious code in the component’s flash memory. The DC-SCM specification requires the use of a secure processor to authenticate the system’s BMC, BIOS, and/or other secure firmware images.

Lattice Security/RoT (Root of Trust) Implementation Overview

To address the security concerns of hackers installing malicious code in the flash memory of confidential firmware, the National Institute of Standards and Technology (NIST) released the NIST SP 800 193 specification in 2018, defining a method called Platform Firmware Protection Recovery (PFR) unified protection mechanism. Lattice’s PFR solution can be implemented as a RoT for DC-SCM, addressing such vulnerabilities in enterprise servers. The implementation of Lattice RoT is based on the following three guiding principles:

Protection – Lattice has demonstrated state machine-based algorithms that can detect security vulnerabilities in SPI memory with nanosecond response times. This prevents unauthorized access from modifying the firmware in the SPI memory. The solution can be customized through an easy-to-use database. Through secure communication using the PFR algorithm, the BMC can authorize modifications to the SPI memory to support in-system updates.

Detection – Elliptic Curve Cryptography (ECC) calculations are performed on the firmware stored in each SPI memory to detect all unauthorized modifications. The detection method is independent of the firmware security method currently used in this design. Using the integrated board power management feature, all unauthorized changes to the firmware can be detected before the board boots.

Recovery – If a security breach is detected, Lattice’s implementation provides a customizable recovery mechanism. This mechanism can perform a simple rollback operation, reverting to a previous firmware version, or fully reverting to the latest licensed version of the firmware. Power management and control PLD algorithms can also be customized to deal with intrusions of different natures, implementing a fully trusted recovery process for any board.

Program Features

Lattice’s PFR solutions have many of the features that customers and developers have come to expect. E.g:

Scalable – responds in nanoseconds to all firmware on the board.The solution can also protect other additional subsystems through secure communication with the corresponding root of trust
Not Bypassable – This solution implements the full power sequencing of the server board as well as the PFR, so it cannot be bypassed
Self-protection – The PFR implementation revolutionizes the use of FPGAs as the root of trust.This FPGA can dynamically control its attack surface and protect itself from external attacks
Self-checking – Root-of-Trust FPGAs detect any security holes in their configuration by using non-bypassable cryptographic hardware modules
Self-healing – The Root of Trust FPGA automatically switches to a known good image when it discovers that its active configuration has been compromised

Control Implementation of Lattice DC-SCM

Almost all servers today use Lattice FPGA devices for functions that control PLDs, such as power/reset timing, various types of serial buses (I2C, SPI, eSPI, SGPIO, etc.), debug ports, LED drivers, FAN PWM Drivers, front panel switch sensing and other general purpose GPIO functions. Lattice FPGA devices support 1 V signaling, enabling out-of-band signaling integration without the need for external GTL transceivers.

Non-disruptive I/O

To achieve zero downtime, Lattice has developed non-disruptive I/O capabilities. Often, controlling PLDs allows designers to significantly reduce time-to-market, helping them deal with market pressures to launch new custom hardware within a specified time frame. Occasionally, there may be errors in the implementation of control functions or in the overall system architecture, and new functions may need to be introduced. A common way to accomplish design modifications is to bring the newly programmed image into service through system updates and power cycles. To ensure continuous operation of a High Availability system, Lattice FPGA devices can maintain the I/O state during a configuration refresh and then initialize the new configuration.

Lattice Product Innovation: Three Key Features in One Solution

Lattice FPGAs offer the unique advantage of integrating three key functions of DC-SCM into Lattice solutions:

LTPI (Management Function)
Security (dynamic, real-time, end-to-end protection)
Control (Programmable System Control)

Lattice FPGAs are highly reliable and industry leaders in FPGA-based low-power applications with 100 times the Soft Error Rate (SER) performance of CMOS technology. Lattice FPGAs have proven standards and follow the DC-SCM protocol specification. The Propel tool also provides developers with a convenient drag-and-drop interface that greatly simplifies configuration.

Lattice products that support DC-SCM

Lattice takes DC-SCM very seriously. Lattice has a range of FPGA products supporting DC-SCM, Root of Trust and user power control logic. Below is a list of existing products that support DC-SCM.

End-to-end protection with Lattice SupplyGuard™

Lattice SupplyGuard™ assigns each customer a unique ordering part number. These numbers correspond to cryptographic credentials that lock Lattice FPGAs and extend platform root-of-trust protection to the entire supply chain, from IC manufacturing to final product end-of-life. Features of Lattice SupplyGuardTM include:

• Prevent over-manufacturing, cloning, counterfeiting and unauthorized hardware modification
• Ability to trace parts throughout the supply chain
• OEM or ODM does not require special highly secure programming equipment, processes or facilities

Authentication credentials for the external IC are programmed into the Lattice device as part of the customer’s encrypted configuration bitstream.This securely transfers encrypted ownership of the Lattice FPGA in the system to the customer during factory programming

in conclusion

Lattice Semiconductor is committed to the promotion of DC-SCM 2.0. Lattice implements and optimizes three key functions of the DC-SCM with a viable single-chip solution.

Lattice has fully validated DC-SCM reference designs available to a wider range of DC-SCM customers and board designers to help them easily implement DC-SCM. Lattice’s tightly integrated solutions provide board designers with a unified single FPGA solution without the need to come up with different combinations of solutions for LTPI, security and control. Lattice’s complete DC-SCM solutions increase performance, reduce power consumption, and take up very little space on the circuit board.

Lattice provides a framework that includes GUI and non-GUI tools for three key DC-SCM functions. System architects and board designers can easily implement features from a drop-down list. Our integrated design tool can provide architects/designers with the entire solution in one panel view, realizing the three major features of DC-SCM.