技术 | 从个人提效到团队协同，AMD Ross如何改变嵌入式开发

在嵌入式开发项目中，工程师往往需要处理非常多不同领域，不同方面的零散工具的需求，包括原理图设计、审查、PCB设计、板级布局、以及FPGA的RTL设计，功耗分析，以及软件开发等工具。而且如果开发团队比较大的话，不同团队成员通常分布在不同的客户现场，彼此之间可能会缺乏沟通，不知道彼此做了什么更改，这样就会影响RTL，或者FPGA的设计等等。这样就会导致嵌入式开发工程师在使用不同工具上花费大量的时间和精力。

为了帮助嵌入式工程师解决这个问题，提高开发效率，AMD近期推出了一个面向嵌入式开发的智能体AI助手——AMD Ross。据AMD自适应与嵌入式计算产品组合产品、软件与解决方案企业副总裁Kirk Saban介绍，这是一款以赛灵思（Xilinx）联合创始人Ross Freeman命名的AI工具，目标是将AMD工具、官方知识库和专家经验接入智能体工作流，让开发者可以用自然语言进行设计、优化和调试。

AMD Ross的重点不只是生成代码，还能查询文档、执行工具命令、分析报告，并按照预设工程方法推进任务。其的价值主要体现在三个方面，即成为生产力倍增器；将专家能力推广到整个团队；以及通过上下文感知改善开发流程。这三点实际上对应着嵌入式开发中的三个问题，单个任务怎么样做得更快、团队怎样复用成熟经验，以及多个设计领域又怎样保持一致。

生产力倍增器：把时间从工具操作转向设计优化

AMD Ross本质上是一款智能体AI（ agentic AI ）工具，它覆盖从架构设计到优化、调试、PCB 设计、原理图审查、软件、AI 以及实际系统部署的全流程，且支持自然语言工具交互，并可部署由专家开发的智能体（ agent ）技能（skill）、可复用工作流和以 AMD 专业知识为基础的知识库，为整个设计流程提供指导。它能够连接各类工具、规模化应用专业知识、自动执行经验证且可重复的工作流程，并对结果进行分析，从而帮助工程师快速将设计构想转化为实际实现，同时大幅缩短典型的嵌入式开发周期。

AMD Ross采用的思路，是让用户选择大语言模型（可以选择ChatGPT、DeepSeek、或者千问等均可）和开发入口，再接入AMD的工具、知识库、专家技能及设计示例。模型负责理解需求和组织任务，AMD工具负责实际执行，工具返回的结果则成为下一步分析的依据。

其中，模型上下文协议（MCP）服务器承担连接作用，让智能体访问运行中的工具会话、查询项目状态和执行命令。知识库通过检索增强生成（RAG）提供AMD公开文档，包括用户指南、应用笔记和技术解答，帮助回答落到具体器件和方法上。

更值得关注的是Skills。它们以Markdown文件记录专家方法，包括先做哪些检查、如何分析结果、遇到问题时采取什么措施。通用模型由此可以获得AMD工具的操作流程，企业也可以把内部验证规则和项目经验整理进去，供团队复用。

工具连接也有不同路径。例如，Vivado可以通过MCP与运行中的会话交互；HLS技能则可通过标准命令行工具完成编译。

AMD展示的第一个案例，是为Spartan UltraScale+评估套件创建MicroBlaze V微控制器系统。AMD Ross确认目标板卡后形成11步计划，处理配置不匹配，并完成本地存储器、时钟等子系统配置。这个案例展示了智能体如何将一句需求拆成工具能够执行的操作，并根据执行反馈调整步骤。

另一个案例针对布局布线后的时序问题。按AMD展示的结果，AMD Ross调用相关技能，将735项失败路径按类别分析，经过修复与验证，最终降至零。对FPGA开发者而言，价值在于把报告阅读、问题归类和修改后复查组织成连续流程。

还有一个AMD Ross帮助优化算法的案例。据Kirk Saban介绍，该算法优化项目如果让一位优秀的开发工程师来做也需要花2天的时间才能完成，现在AMD Ross则可以在2小时内完成这项工作。具体的项目是，一个最初由MATLAB描述的图像传感器去马赛克流水线，目标吞吐量为每秒3亿像素。AMD比较了专家手写的Vitis HLS C++实现与Ross辅助实现，两者均达到目标；前者使用1801个查找表（LUT），后者使用1177个，减少约35%。开发时间则由2天缩短到2小时。

这里值得分析的，是资源和开发时间同时改善。高层次综合（HLS）虽然能够把C++转换为硬件，但代码的数据流组织、流水线和编译指令仍会影响实现质量。智能体如果能调用专家方法并读取综合报告，就有机会帮助开发者更快找到合适的结构。

也就是说，AMD Ross能够帮助嵌入式开发流程中各个不同的角色满足他们的需求，从系统架构师到PCB设计师、FPGA设计师、嵌入式软件开发人员、算法和AI开发人员等。而且，它能够让不同的项目角色获得相同的技能，了解项目的状态。

从设计团队出发，让专家经验成为可复用的能力

个人效率提高之后，企业还会面对另一个问题：怎样让更多工程师使用同样成熟的方法？嵌入式开发涉及系统架构、板级设计、FPGA、软件、算法和验证等角色，经验往往集中在少数资深人员手中。新成员拿到工具和文档，并不意味着能够迅速掌握故障排查与优化的顺序。

AMD Ross对此给出的主要载体是Skills。专家把方法写成结构化文件，智能体在相应任务中读取，再结合项目状态执行。例如，面对HLS性能问题，工作流可以引导智能体检查数据流、存储访问和编译结果。经验由此能够进入日常操作，供不同项目和人员复用。

这也是Ross与通用编程智能体形成差异的地方。通用模型提供理解和推理能力，AMD则补充具体工具的用法、器件文档以及工程方法。在Kirk Saban看来，这种针对性能够帮助开发者更快获得与AMD设计相关的结果，并减少反复补充背景资料的工作。

AMD 自适应和嵌入式计算事业部技术市场经理周丽娜在媒体问答中进一步介绍，企业可以统一维护和分发Skills，也可以扩展现有技能，将内部经验加入工作流。对于设计团队，这意味着常用检查、特定设计模式和交付要求，都有机会被整理为共享方法，降低新人对个人带教的依赖。

既有工具也可以继续发挥作用。按AMD介绍，团队可以通过MCP连接工具，或通过技能调用已有命令和脚本。例如，先由AMD工具产生设计，再调用第三方仿真器，最后使用内部检查工具评估结果。具体第三方产品的支持版本仍需确认，但这种架构为复用企业已有资产提供了基础。

部署方式也影响团队能否采用。AMD Ross支持将知识库和工具接口部署在本地，再配合本地模型运行，以适应设计信息不能离开企业网络的项目。若仍使用云端模型，相关提示和上下文就可能进入模型服务，因此本地文档检索与完全离线部署需要分开理解。

AMD披露，已有超过800位客户参与早期访问。其展示的34份已完成问卷中，用户重视的功能包括综合与时序报告分析、文档检索和重复操作自动化。这些反馈说明了早期需求所在，但还不能代表全部参与客户的评价。团队层面的收益，仍要观察培训、复核和维护工作是否同步减少。

此外，共享流程需要持续维护。工具升级、项目要求变化后，Skills也应更新并重新验证。只有把适用条件和检查结果管理起来，专家经验才更容易形成稳定的团队能力。

上下文感知，让设计变化沿着整个流程传递

当一个团队能够更快完成各项任务后，系统开发还有更难的问题：一次变更发生后，相关人员能否及时知道哪些地方必须跟着调整？Kirk Saban指出，板级布局发生变化，可能影响FPGA设计，但不同团队之间的信息传递未必同步，由此带来的返工会消耗大量时间。

AMD以摄像头系统说明这种关联。摄像头接口需求变化后，FPGA接口逻辑可能需要更新，PCB引脚、摄像头驱动和图像处理流水线也可能随之调整，最后还要重新检查系统时序并运行验证。任何一个环节遗漏，都可能让局部正确的修改在集成时出现问题。

Ross所追求的上下文感知，就是让智能体在执行任务时保留需求、接口和项目状态之间的联系，识别变化对后续工作的影响，并在获得授权后推动更新。这样，开发者就有机会沿着同一份设计依据，追踪变更、处理任务并检查结果，减少在多个工具之间重新解释背景的工作。

在AMD展示的未来流程中，规格生成器先将需求整理为设计、验证和接口规范，再由工作流规划各项任务的依赖关系。经过人工审查，不同领域的智能体分别处理板级、FPGA、算法和软件工作，最后由集成智能体确认交接是否完整。

这会改变工程师与工具打交道的方式。工程师可以更集中地描述目标、查看影响范围和审查结果，让智能体承担部分工具协调工作。不过，支撑这种体验的前提，是接口定义清楚、项目资料一致，以及验证结果能够追溯。上下文是否准确，将直接影响后续动作是否可靠。

按照AMD给出的路线图，目前已提供知识库、Vivado和Vitis HLS相关能力，功耗估算、ChipScope调试及Vitis AI相关能力被列入第四季度扩展计划。

在整个嵌入式产品开发流程中，人仍承担关键判断。周丽娜明确指出，AI工作流具有非确定性，结果可能随模型、提示词和运行过程变化。官方文档、专家方法和实际工具结果可以提高可信度，具体设计仍需通过工程验证与正式评审，最终签核由人负责。

结语

AMD Ross 支持从硬件设计与调试到软件和算法开发、边缘AI实现及部署的整个嵌入式开发过程。开发人员可以使用自然语言，让AI智能体搜索文档、检查工具状态、运行命令、指导调试并执行业经验证的工作流。AMD Ross 覆盖全部 AMD 嵌入式工具产品组合（包括 FPGA、自适应 SoC、x86 嵌入式处理器和专用边缘 AI 平台），使用户能够：