测试不同级别的FPGA设计

时间:2015-09-03 17:05:12

标签: testing vhdl verilog fpga

这里讨论了FPGA的测试策略的各个方面,但是我发现以下问题已被提出/讨论/回答:

您应该在什么级别模拟FPGA设计,以及在每个级别验证什么?

如果您使用x级别测试等概念回答,其中x =块,子系统,函数或其他内容,请描述x适合您的内容。像典型的大小,复杂性或一个例子。

9月14日

对于实际问题,两个给出的答案都是一样的,但我接受@kraigher的答案,因为它是最短的答案。

9月10日

这是@Paebbles和@kraigher的两个答案的摘要和比较。其中一个答案很长,所以希望这将有助于任何想要为自己的答案做出贡献的人。请记住,这是一笔岌岌可危的赏金!

  • 他们都模拟所有级别的所有组件。至少@Paebbles会对功能含量很少的组件例外,例如MUX。
  • 他们都在努力实现测试自动化
  • 他们都开发了"工具"简化板级测试
  • 他们都避免在一个级别测试已经在下面的级别进行过测试的事情
  • 最大的区别似乎在于测试平台的模拟频率。 @Paebbles直接在HW中进行测试,除非有重大的设计更改,在这种情况下也会运行模拟。 @kraigher随着设计的发展不断运行模拟。我认为这也是一个非常重要的问题,我个人更喜欢@kraigher表达的方式。但是,这不是原始问题的一部分,所以我认为这两个答案之间存在共识。关于测试运行频率的问题之前也已在SO上讨论过,例如how often should the entire suite of a system's unit tests be run?

他们进行的实验室测试有多大差异,但似乎主要与项目的具体情况有关(有多少事情无法通过模拟进行有效测试)。我碰巧知道@kraigher的最后一个项目,所以我可以说这两个项目都属于1年以上的类别。从一个规模较小的人那里听到一个故事会很有趣。从我所看到的远离所有项目的模拟中的功能覆盖范围来看,所以必须有其他故事。

9月7日

这是@peabbles的一些后续问题太长,无法在评论中使用。

是的@peabbles,你已经提供了很多我正在寻找的内容,但我还有其他问题。我担心这可能是一个冗长的讨论,但考虑到我们花在验证上的时间以及人们应用的各种策略,我认为它值得关注。希望我们会有更多的答案,以便可以比较各种方法。你的赏金一定会有所帮助。

我认为你的故事包含许多有趣且有趣的解决方案,但我是工程师,所以我会专注于我认为可以挑战的部分; - )

您花了大量时间在硬件上进行测试,以解决您遇到的所有外部问题。从实际的角度来看(因为他们不会修复他们的SATA标准违规行为),这就像有一个有缺陷的需求规范,这样你就可以开发一个解决错误问题的设计。这通常是在您“交付”时发现的,这会激发您为什么要经常交付并尽早发现问题。我对一件事感到好奇。当您在实验室中发现需要进行设计更改的错误时,您是否会在可以测试的最低级别更新测试平台?不这样做会增加错误在实验室中重新出现的风险,并且随着时间的推移,它也会降低测试平台的功能覆盖率,使您更加依赖于实验室测试。

你说大多数测试是在实验室完成的,这是由你必须调试的外部问题造成的。如果你只看你自己的内部代码和错误,你的答案是否相同?

当您像往常一样长时间工作时,您会找到各种方法来利用这段时间。您描述了在第一次测试时开始合成下一个设计,并且如果您在一个驱动器中发现了一个错误,那么您开始为该驱动​​器合成一个修复程序,同时继续使用当前设计测试其他驱动器。您还在实验室中进行了测试时描述了可观察性问题。我会对此做一些持怀疑态度的解释,你必须提供积极的解释!

如果您在开始测试第一个设计时可以立即合成下一个设计,那么您似乎正在以非常小的增量进行工作,但仍然努力在每个级别运行每个测试一直到硬件。这似乎有点过分/昂贵,尤其是当您在硬件测试中没有完全自动化时。另一个持怀疑态度的解释是,您正在寻找一个错误,但由于可观察性差,您正在制作随机试验和错误类型的构建,希望它们能够提供您尝试隔离的问题的线索。这是否真正有效地利用了时间,因为每一个构建都增加了价值,还是更“做某事比做什么更好”?

在设计更高的协议层时,您是否考虑在较高级别上对通信堆栈进行短路以加快仿真速度?毕竟,下层已经过测试。

您重用了一些组件并假设它们没有错误。那是因为他们配有测试平台,证明了这一点吗?使用证明往往很弱,因为重用通常发生在另一个环境中。 Arianne 5火箭是一个很好的例子,你可以再次将XAPP 870用于Virtex 5。

由于您在不同级别进行了模拟,因此我认为您可以在较低级别重视较快的运行时间,并且在较大的结构完成之前可以验证设计的一部分时使用较短的反馈循环。仍然有一些代码片段足够重要,可以授予他们自己的组件,但仍然太简单,无法获得自己的测试平台。你能给出这样一个组件的例子吗?他们真的没有bug吗?就个人而言,在我犯错之前我不会编写很多行代码,所以如果我有一个包装好的代码就像一个组件,我会抓住机会在上一级进行测试。

1 个答案:

答案 0 :(得分:6)

我在各个层面进行行为模拟。这就是所有实体都应该有一个相应的测试平台,旨在实现全功能覆盖。如果实体A,B和C的具体细节已经在其相应的测试平台中单独测试,则它们不必包含在实例D的测试平台中,实体D实例化A,B和C,其应该集中于证明集成。

我还有设备或板级测试,其中实际设计在实际设备或板上得到验证。这是因为当模型开始变得不精确并且需要很长时间时,您无法信任设备级仿真。在真实设备中,可以实现测试时间而不是毫秒。

我试图避免执行任何合成后仿真,除非在设备级别测试中发生故障,在这种情况下我执行它以查找综合工具中的错误。在这种情况下,我可以制作一个后综合网表的小包装器,并从行为模拟中重新使用测试平台。

我非常努力地避免任何形式的手动测试,而是依靠测试自动化框架进行模拟和设备级测试,以便可以连续进行测试。

为了自动化模拟,我使用VUnit测试自动化框架,@lasplund和我自己就是这个框架的作者。