1

我一直在查看流代码，以寻找一种更直接地控制 93k 测试节点上的通过/失败分支的方法。我们可以在 origen-testers 的 93k 输出端添加额外的钩子，但是我们冒着打破平台不可知论的风险。

相反，我相信如果我们能够更直接地影响 ATP 数据结构的构建方式，那么已经存在的测试器输出驱动程序将正确处理它。ATP 已经支持 :on_pass 和 :on_fail 键，但目前似乎只支持将 bin 放入这些块中。

我想做的是能够编写这样的流程：

func :test1, param1_key: param1_value, on_pass: do
    func :test2, param2_key: param2_value
end, on_fail: do
    func :test3, param3_key: param3_value
    bin 10
end

我意识到我可以使用流控制变量来做到这一点，但是如果有很多测试需要这种类型的结构，就会导致大量的测试 ID 和流控制变量。能够直接说出通过与失败路径中的测试将大大简化流程。它也自然导致嵌套的能力，例如，如果上面的 test2 需要通过和失败路径。

我还在学习 ruby​​，但我意识到上面的代码会引发编译错误。我相信我们可以通过在流程构建器中进行一些递归并使用 lambda 来完成这样的事情：

func :test1, param1_key: param1_value, on_pass: ->{
    func :test2, param2_key: param2_value
}, on_fail: ->{
    func :test3, param3_key: param3_value
    bin 10
}

是否已经有一种方法可以更直接地控制或影响内部 ATP 流数据结构？如果没有，我们可以在增强请求列表中添加类似于我上面的内容吗？

4

1 回答 1

1

我并不反对这个语法建议，但这是应该使用当前可用的 API 进行编码的方式：

func :test1, param1_key: param1_value, id: :t1

if_passed :t1 do
  func :test2, param2_key: param2_value
end

if_failed :t1 do
  func :test3, param3_key: param3_value
  bin 10
end

这也完全支持嵌套：

func :test1, param1_key: param1_value, id: :t1

if_passed :t1 do
  func :test2, param2_key: param2_value, id: :t2

  if_failed :t2 do
    func :test4
  end
end

if_failed :t1 do
  func :test3, param3_key: param3_value
  bin 10
end

添加对传递给的块/lambdas 的支持on_pass可能on_fail并不像您想象的那么容易实现。例如，它应该直接映射到 V93K，但在 Teradyne 上，我们需要将其全部展平并生成标志，因为它不提供相应的可嵌套 IF 结构。

我认为这个 Origen 源代码非常易读且明确，这就是我们在那个级别上努力的目标。理想情况下，我们希望流代码甚至可以被非技术利益相关者阅读，以便它可以作为流的文档。

我认为您真正要解决的是这样一个事实，即这当前会生成实际上并不需要存在的流控制变量，但它们很快就会消失。我们采用的方法是使用元数据助手（如流变量）生成内部低级实现，这使得泰瑞达很容易定位，它提供比 V93K 少得多的流控制能力。

然后对于 93K 或其他提供类似 C 流控制 API 的平台，编译器将在内部表示上运行一些优化，以在最终渲染之前摆脱冗余标志结构。

下一轮优化的工作已经在进行中，请密切关注此拉取请求 - https://github.com/Origen-SDK/origen_testers/pull/52。我将添加一些额外的测试用例，就像这里提到的那样，以确保优化掉不必要的标志。

如果您遵循上面的编码指南，它将生成逻辑上正确的测试程序，然后在几周内您可以更新到新版本的 OrigenTesters，并且输出会变得更漂亮。

于 2017-09-15T22:41:02.150 回答