新增组合提供提前开发的软件环境
2026年3月3日，英飞凌扩展DRIVECORE组合，新增RISC-V虚拟原型、PSOC智能端点及AURIX AUTOSAR三类软件包，帮助客户准备当前与未来平台。PG关注的是，硬件尚未到位时能够先完成哪些工作。
从项目安排看，软件与芯片开发不一定需要完全串行进行。若有足够明确的接口与模型，团队可以先组织程序、检查工具和探索部分系统关系。提前开展工作的意义，是把可独立回答的问题尽早处理，为后续集成留下时间。
但虚拟环境有自己的范围。它能够说明哪些行为，哪些细节尚未覆盖，都应让使用者清楚。不能把程序在模型中运行，直接等同于目标车辆上的全部功能已经确认，提前开发与最终验证仍需彼此衔接。
工具链首先需要形成一致的工作路径
从开发流程看，源代码经过编译、连接、加载与调试，才能变成可观察的运行结果。多个工具即使分别可用，也需要确认它们采用一致的配置与版本。预先组织这些关系，有助于减少团队刚开始项目时反复搭建环境。
虚拟环境还适合帮助团队提前理解接口调用顺序和错误返回方式，但这与真实硬件上的完整时间表现并不是同一项检查。把功能关系和物理条件分开记录，可以让各阶段任务更有针对性，也避免重复确认已经清楚的内容。工具结果也需要能够交接。某个程序在哪组设置下构建，调试时采用什么模型，出现问题如何重现，都应该留下记录。这样，不同人员不必依靠相同电脑和个人习惯，仍能围绕同一个现象共同排查。
例如，编译选项改变后，程序的行为或资源使用可能需要重新观察。若配置被保存在项目资料中，团队就能够知道差异从哪里开始，而不是把每次结果变化都归到架构本身。
架构迁移不只是重新编译一次
从软件维护看，不同架构之间可能有可复用的应用逻辑，也可能存在与底层接口紧密相连的部分。迁移前先识别这些边界，可以帮助团队估计工作范围，避免把已有代码整体视为可以直接沿用或必须全部重写。
接口、驱动与运行时之间的关系尤其值得整理。上层调用需要依赖什么行为，底层怎样表达状态，异常如何返回，都应当清楚。边界明确以后，团队才能分别处理通用逻辑与平台差异，减少修改扩散到无关部分。
开放架构也不意味着所有实现和工具都完全相同。具体产品仍有自身接口、资源与开发条件，采用时需要回到对应资料。把架构方向与产品实现分开理解，可以让迁移讨论更加具体。
实物到位后，要把此前结果接回来
从后续集成看，真实硬件能够补充模型未覆盖的时序、外设和系统条件。团队需要知道此前哪些结论可以保留，哪些需要重新确认，才能把提前开发的成果有效接到实物，而不是再从头做一遍。
一种清楚的交接方式，是让测试任务与需求对应。某项行为在虚拟环境中如何观察，在实物上又如何检查，结果差异采用什么规则分析。这样，模型与实物不会成为彼此独立的两套记录，也能让下一轮修改继续沿用已有的问题与结果对应关系。
在PG看来，DRIVECORE扩展的价值，在于让工具、模型和软件工作提前形成可协作的基础。把提前完成的内容与后续硬件确认明确接起来，才能将虚拟开发变成真实项目中可以持续复用的进展。