在功能验证抽象抽象抽象

我听到一个明确由三部分组成的消息在2月底DVCon:

1. 验证工程师必须抽象地拥抱的抽象概念通过更高的抽象级别抽象抽象抽象;
2. 我们过度使用抽象来强调这个词的价值无论我们恰巧验证技术讨论;和
3. 新的抽象的关键是使用便携式刺激尽可能抽象。

希望我们能同意这前两个点并不都是新的。第三是绝对新的'ish…至少是我。

似乎便携式刺激是最新的下一件大事,它伴随着abstraction-induced生产力的承诺。我不太了解便携式刺激,但是我很满意抽象的想法,所以我认为这将是有趣的回顾如何成功的我们一直在创造新的设计抽象和给人们机会思考如何可能便携式刺激。

首先,让我们同意意味着什么搬到一个更高层次的抽象。对我来说,抽象意味着我们发现一个新的方式来表示喷火充分抓住它的本质,同时让我们避免处理细节。

Foo可以是任何东西。Foo将蒙娜丽莎。有很多详细的蒙娜丽莎。人写了很多;所有聚集在一起,形成一个华丽和迷人的艺术作品,列奥纳多·达·芬奇谁画的,它对其他艺术家的影响等等。太好了;对一些人来说这些细节问题。对我们其余的人来说,整本书关于蒙娜丽莎是超出我们所需要的。我们《蒙娜丽莎》可以被描述为“一个古老的绘画从著名的家伙一个女人长长的黑发和一个奇怪的笑容。“这是一个抽象的描述蒙娜丽莎;一个适当的泛化,抓住它的本质。

在硬件开发的背景下,更贴切的设计抽象RTL的例子。通过RTL与它相关联的语言和工具,我们已经给了人们一种充分概括电路行为而让他们很大程度上忽视个体的存在盖茨和完全忽视晶体管的存在。设计和验证IP其他抽象的好例子。IP是一个泛化的规范,让我们坠入一个SoC子系统或实例化的一部分testbench而无视相关协议和实现细节。

创造新的设计抽象表现良好有生产力效益(见:RTL与原理图捕获)。根据定义,它也为代价。最明显的取舍是我们失去控制的细节。成功的抽象与生产力的好处大于失去控制。

我们不是总是成功的抽象时因为有时失去控制是无法忍受的。例如,尝试提高RTL设计抽象——通过语言和工具HLS——继续下跌。(不要倾倒在HLS太多,因为显然利基市场存在团队展示了更抽象的语言因为它是优于RTL。但是我认为我很安全的说RTL仍然是热门主流设计抽象尽管多年的研究,投资和广告潜在HLS。)各种设计捕捉语言来自C,例如,可以是抽象的,我们失去了连接硬件和其优化的机会。换句话说,一个设计抽象是不够的,当它太抽象。

另一个尝试抽象,将达到接近回家验证工程师事务级建模。从销TLM旨在提高抽象级别硬件交互松散定时或者不计时的基于消息的通信。在验证团队TLM可能是司空见惯的事情,但是我认为它的价值小于势不可挡。我们的建模习惯往往是由低级的总线协议;总线周期直接映射到与针和巴士直接映射到领域的事务。我们使用的数据结构可能会给我们的印象,我们选择了一个更抽象的表示pin-level事务,尽管在很多情况下我们所做的就是选择一个不同的表示相当的粒度。所有相同的细节穿过testbenches——从测序和终止在记分牌和跳棋——的方式很难达到奖金生产力我们希望。鉴于pin-level接口和模型之间的一致性详细交易,我认为它更适合叫TLM增量改进比真正的硬件抽象。

评论:我们钉与RTL和IP抽象;设计捕获在更高级别的软件语言为主流太抽象;TLM不够文摘。

这就引出了下一个大事件。便携式刺激的卖点之一,是它提供了建模和测试在一个抽象层次比我们现在更有效率。鉴于我们的历史混合的结果,我认为这是很自然的问题是否会是如此。

如果你读过这么多希望我有一些聪明的洞察事情将如何运作,你会失望地听到我不知道足以提供任何。我所能说的就是,在DVCon听后有些人确实有洞察力,我做了一些观察,我相信是轻微的引起人们的关注。

针对便携式刺激,我看到一些详细的如何在DVCon模型行为的例子,但我没有看到任何人退后一步,目前便携式刺激与权衡的价值。抽象为代价。没有承认的权衡,我自动抽象的价值问题。也不清楚在哪里以及如何适用于便携式刺激。除了有广阔的空间,我没听见任何人在DVCon目前便携式如何刺激(a)补充或(b)取代我们目前的发展模式。最后,便携式刺激我们有一个新的语言——一个声明性语言不——会给团队采用一个障碍。我很想知道开发人员需要它。

更普遍的担忧与发布PSS这么快。肯定我不能是唯一的人谁认为标准化一个想法之前用户已经欣然采纳了外观的书写工具提供商的利益而不是用户。进一步,我听到“标准合作,竞争工具”参数调用几次讨论,但说事实比作为一个合理的论点。跳过过去“竞争思想”步骤的真正价值在哪里出生,但不可否认,也许这里的竞争已经发生了,我来不及看。

这些观测信号保证者,但在我看来他们点之前,将需要解决便携式刺激设计抽象的成功提供了新的手段。

人们都同意的一件事是,我们仍然在早期的便携式刺激。如果你有意见会发生什么与便携式刺激或不同的观点如何成功与抽象,我们现在将是一个伟大的时间跳。

尼尔。

PS:回滚子弹两个从一开始,这个想法我们过度使用“抽象”强调价值…我想鼓励我的设计和验证工程师叫BS当人们调用抽象作为解决方案没有进一步的解释。它经常发生。不是抽象并不是一个值得追求的目标,因为它是,毫无疑问。但是我们条件自己接受自己“抽象”作为一个有效的参数通过创建一个高效的设计忽视了事实抽象并不总是容易的,显而易见的,保证甚至是有用的。如果人们给你“抽象”没有一个明确的价值定位和解释,认为这提醒要求更多。