本页面使用了机器翻译。
请花 1 分钟时间完成一个翻译质量的调查。
在汽车 ASIC 开发中应用基于模型的验证
作者 Aswini Tata、Sanjay Chatterjee 和 Kamel Belhous，Allegro MicroSystems 以及 Surekha Kollepara，Cyient
随着客户的要求越来越高，交付时间越来越短，我们采用的基于模型的验证方法正在帮助我们的团队以更短的上市时间提供更复杂的算法和系统。
在为汽车行业服务的半导体公司中，工程团队被要求在紧迫的时间内交付日益复杂的系统。要满足这些紧迫的期限会面临后期测试相关的困难。例如，等到 RTL 可用后才开始功能验证可能会带来成本超支和交货延迟的风险。在此阶段发现的设计缺陷和需求问题更加昂贵且难以补救，团队会浪费宝贵的时间来调试不切实际的场景。在这种环境下，前置测试流程，也就是将验证活动在开发周期尽早进行，解决了此类后期测试挑战。
Allegro MicroSystems 的部分团队成员采用了一种新的流程前置方法，使用基于模型的 DSP 模块设计，其中包含混合信号 ASIC 的 HDL 代码生成以及用于 RTL 级验证的通用验证方法 (UVM) 测试台的生成。通过这种基于模型的验证方法，我们可以从 Simulink® 中的早期功能验证以及系统级设计视图中获益，以促进系统工程师和验证团队之间的协作（图 1）。早期模型验证可带来更高质量的 HDL，因为在代码生成之前发现并消除了高级设计和需求问题。我们预计这次早期的错误检测可以节省两个月的验证工作量。我们进一步受益于在 UVM 环境中对 HDL 实现的严格测试以及跨项目模型和测试资产的重用。
图 1. Allegro MicroSystems 的测试前置基于模型的验证。
从需求到可执行规范再到实施
在传统的开发工作流程中，系统工程师编写基于文本的需求，数字设计团队（系统架构师和 RTL 工程师）使用这些需求来制定规范，并据此制定 RTL 设计。我们的团队，即数字验证团队，将负责根据规范和功能验证创建测试计划，以确保 RTL 设计符合规范。在这个工作流程中，当检测到缺陷时（通常是在开发生命周期的后期），可能需要很长时间才能确定缺陷的根本原因在于实施、规范还是原始要求。
通过我们当前的方法，工作流程旨在能够更早地验证架构和需求。系统工程师在 Jama Connect® 中定义需求后，数字设计团队在 Simulink 中创建架构规范模型。该模型作为系统的可执行规范。通过使用该模型运行仿真，团队执行模型在环单元和集成测试以验证需求并验证架构（图 2）。在我们使用此方法的第一个项目中，这些仿真帮助我们识别了几个问题，包括条件语句相互矛盾的情况，导致某些输入刺激组合的输出无效。
图 2. 显示 Simulink 设计和 HDL 代码中验证的开发工件和活动的工作流程。
在下一个开发阶段，团队将架构模型转化为更加“硬件友好”的实现模型，为利用 HDL Coder™ 进行代码生成做准备。例如，这可以包括将算法从浮点转换为定点，或者从基于帧的处理切换到流式传输。
Simulink 中的测试台模型和验证
当数字设计团队在实施模型中构建组件时，这些组件的 Simulink 测试台模型也会并行开发。每个 Simulink 测试台模型包含与 UVM 组件对应的以下子系统：序列、驱动器、DUT、预测器、监视器和记分板（图 3）。使用HDL Verifier™ 生成测试台只需要序列、DUT 和记分板子系统。
图 3. UVM 测试台的通用模型结构（上图）和用于测试坐标旋转数字计算机 (CORDIC) 算法的测试台的 Simulink 实现（下图）。
此 sequence 子系统为被测设备生成激励，或 DUT 子系统，在本工作流程中是在 Simulink 中创建的实现模型。该子系统使用 MATLAB® 代码和 Simulink 模块创建并随机化激励，包括 Test Sequence 模块。其种子输入用于初始化 MATLAB 随机数生成器。此 scoreboard 子系统收集 DUT 的输出，并通过以下方式将其与预期输出进行比较 Assertion for DPI-C 模块，用于生成包含 SystemVerilog 断言的 DPI-C 组件（图 4）。（SystemVerilog 直接编程接口 [DPI] 是 SystemVerilog 与外部编程语言（如 C）之间的接口。HDL Verifier可以生成由带有 SystemVerilog 包装器代码的 C 代码组成的 DPI-C 组件；然后，生成的 DPI-C 组件可以由支持 SystemVerilog 的 HDL 仿真器执行。）
图 4. 断言检查用于验证输入信号在每个时间步骤中是否小于指定的上限。
使用测试台模型在 Simulink 中运行仿真，并结合各种模型验证和确认工具（如 Simulink Test™），进一步根据需求验证实施模型。我们将这些仿真的结果从 Simulink 拉回到 Jama，以促进基于需求的测试。此外，Simulink Design Verifier™ 可用于识别模式中的死代码逻辑。
代码生成、测试平台生成以及 HDL 仿真和测试
图 5. 生成 UVM 测试台记分板代码。
然后，我们使用生成的测试平台，在 UVM 环境中使用数字仿真器（例如 Cadence® Xcelium™ 仿真器）针对从实现模型生成的代码运行测试（图 6）。我们根据需要扩展生成的 UVM 测试台，以添加更复杂的约束随机化、断言检查器和 SystemVerilog 覆盖组，以进行功能覆盖率分析。当测试在 UVM 环境中失败时，我们使用失败测试中的种子和内存配置在 Simulink 仿真中重现故障情况，与直接在 HDL 级别进行调试相比，这使得设计工程师更容易调试和修复故障。
图 6. UVM 测试台的生成、集成和使用。
后续步骤
随着客户的要求越来越高，交付时间越来越短，我们采用的基于模型的验证方法正在帮助我们的团队以更短的上市时间提供更复杂的算法和系统。我们计划将这种流程前置概念扩展到其他项目，我们希望验证团队能够重用模型和相关的 Simulink 测试环境，从而为 Allegro 的中等复杂度项目节省另外两个月的开发工作量。展望未来，我们还在探索系统工程团队和客户重复使用模型的机会。
2024 年发布
