4. 交换芯片软件开发套件（SDK）与SAI

在Broadcom数据中心交换平台的设计与集成中，交换芯片本身只是硬件基础，真正让芯片“活起来”的是其软件开发套件（SDK）。Broadcom的交换芯片SDK（历史上称为OpenNSL，后演进为OpenNSA/BCM SDK）是芯片驱动、转发逻辑、表项管理和硬件抽象的核心。而SAI（Switch Abstraction Interface）则是在SDK之上的一层标准化接口，用于屏蔽不同芯片厂商的差异，使上层网络操作系统（NOS）能够以统一方式操作交换芯片。理解这两者的关系、API层次、初始化流程以及设备抽象机制，是进行平台集成和二次开发的前提。

OpenNSL与SDK的定位

OpenNSL是Broadcom早期推出的开源网络交换库，它封装了底层SDK的复杂调用，提供了一套相对简洁的C语言API，用于配置端口、VLAN、ACL、路由表、隧道等。OpenNSL并非独立于SDK，而是SDK的一个“薄封装层”，其内部仍然调用BCM SDK的底层函数。随着社区发展，OpenNSL逐渐被OpenNSA（Open Network Switch API）取代，后者更贴近现代SAI的语义。在实际项目中，如果NOS直接基于Broadcom SDK开发，通常会使用OpenNSA或直接调用BCM API；如果NOS需要跨厂商兼容，则通过SAI接入。

SDK的核心价值在于：它管理着交换芯片内部的所有硬件资源——包括L2/L3转发表、ACL表、计数器、调度器、缓冲区、端口MAC/PCS等。SDK向上提供API，向下通过PCIe、SPI或MDIO等总线访问芯片寄存器。一个典型的Broadcom交换芯片SDK包含以下模块：

• 系统模块（System）：负责芯片初始化、内存分配、中断处理、DMA通道管理。
• 端口模块（Port）：配置端口速率、FEC、链路训练、自协商、统计计数器。
• L2模块：MAC地址表、VLAN、STP、组播复制。
• L3模块：路由表、下一跳、ECMP、隧道解封装。
• ACL/QoS模块：TCAM表项、流分类、优先级映射、队列调度。
• 仪表与诊断模块：sFlow、镜像、计数器读取、寄存器dump。

SAI架构与SDK API层次

SAI（Switch Abstraction Interface）是由OCP（Open Compute Project）定义的标准化API，它位于NOS和芯片SDK之间。SAI定义了一组与厂商无关的对象模型，如sai_port_api、sai_vlan_api、sai_route_api、sai_acl_api等。每个对象由一组属性（attribute）描述，NOS通过sai_create_*、sai_set_*、sai_get_*、sai_remove_*等函数进行操作。SAI的实现者（如Broadcom）需要提供一套“SAI适配层”，将SAI调用翻译成SDK API调用。

因此，从NOS到硬件的完整调用链为：NOS应用 → SAI API → SAI适配层（厂商实现） → Broadcom SDK API（OpenNSA/BCM） → 芯片驱动 → 硬件寄存器。这个层次结构使得同一套NOS代码可以运行在Broadcom、Marvell、Mellanox等不同芯片上，只要各厂商提供符合SAI规范的适配层。

下图展示了SAI与SDK的层次关系以及典型的数据流方向：

SDK初始化流程

交换芯片上电后，SDK的初始化是一个多阶段过程，顺序错误会导致芯片无法正常工作。以Broadcom SDK为例，典型初始化流程如下：

1. 系统初始化（bcm_init）：加载SDK库，初始化内部数据结构，建立与芯片的通信通道（PCIe/SPI）。此阶段会探测芯片型号、版本和端口数量。
2. 芯片复位与配置加载：通过bcm_device_init将芯片从复位状态唤醒，加载固件（如微码），配置PLL和时钟。
3. 端口初始化（bcm_port_init）：遍历所有物理端口，设置默认速率、FEC模式、接口类型（KR/CR/SR），并启动链路训练。
4. 表项管理器初始化：初始化L2/L3表、ACL TCAM、计数器池等硬件资源，建立软件影子表与硬件表的同步机制。
5. 中断与DMA配置：注册中断处理函数，配置DMA通道用于报文上送CPU和CPU下发报文。
6. SAI适配层初始化：在SDK初始化完成后，SAI适配层调用sai_api_initialize，创建switch对象，并依次初始化各模块（port、vlan、route、acl等）。

在实际集成中，初始化顺序通常由NOS的启动脚本控制。例如，SONiC会先加载SAI库，然后调用sai_api_initialize，再通过sai_create_switch触发底层SDK的完整初始化。如果初始化失败，可以通过SDK的日志（bcm_loglevel_set）和寄存器dump工具（bcm_reg）定位问题。

设备抽象与对象模型

SAI的核心是对象模型。每个SAI对象都有一个唯一的对象ID（sai_object_id_t），并关联一组属性。例如，一个端口对象包含SAI_PORT_ATTR_SPEED、SAI_PORT_ATTR_FEC_MODE、SAI_PORT_ATTR_ADMIN_STATE等属性。NOS通过sai_set_port_attribute修改属性，SAI适配层将其转换为SDK的bcm_port_speed_set等调用。

设备抽象还体现在“交换机”对象上。一个SAI switch对象代表一个逻辑交换芯片，可以包含多个端口、VLAN、虚拟路由器（VRF）。在Broadcom SDK中，这对应bcm_switch_create和bcm_vlan_create等操作。通过这种抽象，NOS无需关心芯片内部是单芯片还是多芯片级联，只需操作SAI对象即可。

典型配置示例：创建VLAN并添加端口

以下示例展示通过SAI API创建一个VLAN 100，并将端口1加入该VLAN的过程。代码为伪代码，用于说明调用关系：

// 1. 创建VLAN对象
sai_object_id_t vlan_id;
sai_attribute_t attr;
attr.id = SAI_VLAN_ATTR_VLAN_ID;
attr.value.u16 = 100;
sai_vlan_api->create_vlan(&vlan_id, g_switch_id, 1, &attr);

// 2. 创建VLAN成员对象，将端口1加入VLAN 100
sai_object_id_t vlan_member_id;
sai_attribute_t member_attrs[2];
member_attrs[0].id = SAI_VLAN_MEMBER_ATTR_VLAN_ID;
member_attrs[0].value.oid = vlan_id;
member_attrs[1].id = SAI_VLAN_MEMBER_ATTR_PORT_ID;
member_attrs[1].value.oid = port1_id;
sai_vlan_api->create_vlan_member(&vlan_member_id, g_switch_id, 2, member_attrs);

// 3. 设置端口PVID为100
attr.id = SAI_PORT_ATTR_PORT_VLAN_ID;
attr.value.u16 = 100;
sai_port_api->set_port_attribute(port1_id, &attr);

上述SAI调用在Broadcom适配层中会依次转换为：bcm_vlan_create(unit, 100)、bcm_port_vlan_member_set(unit, port1, 100, BCM_VLAN_MEMBER_UNTAGGED)、bcm_port_untagged_vlan_set(unit, port1, 100)。通过对比SAI和SDK的调用，可以验证适配层是否正确工作。

初始化与设备抽象的常见问题

在平台集成中，初始化失败和设备抽象不匹配是最常见的问题。例如，SAI适配层可能未正确实现某个属性的get/set，导致NOS读取端口状态时返回错误；或者SDK初始化时端口映射与硬件实际连接不符，导致链路无法up。排查时，应首先确认SDK初始化日志中芯片型号、端口数量、固件版本是否与硬件一致；其次检查SAI适配层是否完整实现了NOS所需的API子集；最后通过bcm_port_link_status_get等底层调用验证硬件状态。

总之，OpenNSL/OpenNSA与SAI共同构成了Broadcom交换平台的软件基石。理解SDK API层次、初始化流程和设备抽象机制，不仅有助于快速定位集成问题，也为后续开发自定义转发逻辑和性能调优打下基础。