The Elements of Traceability

搜索最新SoC解决方案
关于汽车电子...物联网...安全...音频...视频

by Vincent Thibaut - ArterisIP, Oct. 19, 2021 – 

要观察复杂系统的开发活动，欧洲是一个有趣地方。它或许没有超大型企业或智能手机领军公司，但它拥有在世界舞台上占主导地位的两家商业飞机制造商之一，拥有活跃的欧洲航天局，还有几个高端汽车品牌和支持汽车半导体的领先一级汽车系统供应商。此外，在无线基础设施领域，它还拥有两家最大的公司。由于以色列在商业方面通常被算作欧洲的一部分，它在汽车自动驾驶和活跃的军事工程方面增加了许多领先技术。这种经验水平使欧洲对于半导体的最终目标，以及组件和所服务的系统之间日益密切的相互依赖关系，拥有独特的丰富视角。

此外，欧洲还以其对标准和法规的喜爱而闻名。这需要大量的文书工作和交叉检查，以便工程师能够从不同的供应商那里成功建立复杂的系统和子系统。类似的要求现在是世界各地的标准 - DO-254，ISO 26262，等等。作为组件制造商，团队往往认为这些标准是在他们的专业领域需要做的额外事情的清单。但是，有一个非常重要的方面，从顶层系统到最底层的组件，都有跨领域的联系：需求的可追溯性。系统工程师想知道所定义的需求是否得到了满足，即使硬件和软件在系统的许多部分的发展中不断演变。在任何不符合要求的地方，他们希望立即得到问题的通知。

可追溯性的默认方法

在项目开始时，客户提供了一堆详细说明其要求的文件。无论如何，工程师们都会有一个汇集条件的电子表格，它可能是通过从那堆PDF文件中提取关键段落建立的。添加说明栏来记录谁负责检查，并辅以关于如何检查的细节（设计评审、验证断言），当前状态和可能阻止批准该项目的任何因素。

这不是设计师只检查一次就可以的事情。随着设计的发展，团队将做出权衡，修复错误，并解决后期的变化。其中一些变化可能会破坏现有的需求，而这些需求只有通过繁琐的检查才能发现。团队会继续审查可追溯性矩阵，并多次重新检查设计，以确保所有组件都是正确的。可能会有一些自动化来支持这项活动，但它在很大程度上仍然是手工操作。如果团队发现了问题，必须确定问题的原因。是设计上的错误，还是需求变化打破了原有联系？

从默认到自动化

如果系统级芯片（SoC）足够复杂，以至于顶级需求必须被分解成子表，那么这种追溯可能很快就会变得乏味，而且非常复杂。一个专业集成商分享说，他们的工程团队一直在期盼一个更好的解决方案。这些团队花在检查和更新电子表格的时间比实际建立和检查设计的时间还要多！工程师们希望有一种工具能够自动处理大部分记账工作，从而让他们回到他们真正的工作中去。

一个好的起点是在为此目的而设计的平台（例如 DOORS或Jama）中获取需求。然后自动建立从这些平台到SoC设计流程的链接，但这显然是一个挑战。需求通常是用自然语言写的，即使是在这些现代化工具中。架构师如何将其与高度结构化的SoC设计语言中的实现或验证定义联系起来？

答案有两部分。首先，需求关心的是相对高层次的特性：内存图、总线宽度和知识产权（IP）配置。从实现的角度来看，没有必要深入研究寄存器传输级（RTL）行为。或者更确切地说，不应该有这种需要。IP-XACT标准捕获了大多数/所有这些特性，所以它是连接规范和实现的完美表示。需求工具有一个程序性的接口；IP-XACT工具也有一个程序性的接口。团队只需要把它们连接起来，并找出规格和实现之间的联系 - 这是解决方案的第二部分。

追溯步骤的自动化

工程师如何在自然语言需求和IP-XACT表示的对象之间建立联系？在软件领域，关于这个主题有大量论文。在SoC领域，需要考虑的对象范围则非常有限：像总线宽度、配置参数和寄存器特性。从需求到实现，这些对象的标签通常是一致的，尽管不是完全一致，所以团队必须允许一些不一致的情况。类似的名字在不同的情况下使用，一些自然语言处理可以帮助区分。可能仍然有少数情况需要设计者介入，但这很有可能大大减少记账的负担。

Arteris IP已经推出切实有效的生产用IP-XACT工具，并且多年来积累了大量的经验，了解可行的可追溯性解决方案的特点。给我们打个电话吧。我们将很乐意讨论您的目标。

 Back