测试程序流产生失败的选项

Question

我通过选项哈希传递一些参数在我的主流程文件：

Flow.create(environment: :ws, interface: 'MyTestLibrary::Interface', lib_version: Origen.top_level.lib_version) do 
    import "components/bist" 
    import "components/func" 
    pass 1, softbin: 55 
end 

的问题是，选择不留当其他子流被调用时是持久的。下面是拳头时间考验的接口被称为撬会议：

14: def initialize(options = {}) 
    15: options = { 
    16:  lib_version: nil 
    18: }.merge!(options) 
=> 19: binding.pry 
[1] pry(#<MyTestLibrary::Interface>)> options 
=> {:lib_version=>"3.14", :environment=>:ws, :interface=>"MyTestLibrary::Interface"} 

然而，这里是从第二次撬会议同样命中断点：

[1] pry(#<MyTestLibrary::Interface>)> options 
=> {:lib_version=>nil} 

我想我有几个问题：

1. Aren't the main flow options supposed to be persistent to sub-flows，用户没有添加任何工作？
2. 为什么界面被重新初始化？似乎应该只发生一次一代命令。

提前THX

• 编辑*

@Ginty，你在你的答案说以下内容：

至于传递到顶层的选项流程去吧，关于将它们传递给初始化并没有任何保证。相反接口应该创建启动和关闭的方法，如果要拦截它们：

但在docs，我看到下列规定：

对于运行它必须实现所有的方法的接口将被你的流程调用。也习惯于创建一个初始化方法，该方法将捕获传入Flow.create的任何选项（例如在我们的流程示例中将该环境声明为probe）。

此外，启动方法看起来像是一个回调，它在接口初始化后运行。在接口完成初始化之前，我使用选项散列传递的信息需要。下游用户不应该担心这是否会造成脆弱的运行顺序依赖性？ 问候

Answer 1

假设我们有两个顶级流，以及流组件：

# program/prb1.rb 
Flow.create interface: 'MyApp::Interface', temperature: 25 do 
    import 'components/ram' 
end 

# program/prb2.rb 
Flow.create interface: 'MyApp::Interface', temperature: 125 do 
    import 'components/ram' 
end 

# program/components/_ram.rb 
Flow.create do |options| 

end 

该接口：

module MyApp 
    class Interface 
    include OrigenTesters::ProgramGenerators 

    def initialize(options = {}) 
     puts "New interface!" 
     puts "The temperature is: #{options[:temperature]}" 
     super 
    end 
    end 
end 

然后如果我们产生通过运行PROG两个流在程序目录origen p program上，那么我们会看到该接口被实例化两次，每个顶级流程一次：

$ origen p program 
[INFO]  0.006[0.006] || ********************************************************************** 
[INFO]  0.010[0.004] || Generating... prb1.rb 
New interface! 
The temperature is: 25 
[INFO]  0.024[0.014] || Generating... prb2.rb 
New interface! 
The temperature is: 125 
[INFO]  0.052[0.028] || Writing... prb1.tf 
[INFO]  0.053[0.001] || *** NEW FILE *** To save it: cp output/testflow/mfh.testflow.group/prb1.tf .ref/prb1.tf 
[INFO]  0.054[0.000] || ********************************************************************** 
[INFO]  0.058[0.004] || Writing... prb2.tf 
[INFO]  0.059[0.001] || *** NEW FILE *** To save it: cp output/testflow/mfh.testflow.group/prb2.tf .ref/prb2.tf 
[INFO]  0.059[0.000] || ********************************************************************** 
Referenced pattern list written to: list/referenced.list 
[INFO]  0.061[0.002] || *** NEW FILE *** To save it: cp list/referenced.list .ref/referenced.list 
[INFO]  0.061[0.000] || ********************************************************************** 

因此，从输出中我们可以看到接口的两个实例被创建，每个顶级流生成一个实例，传递给Pattern.create的选项被传递到接口的初始化方法。

请注意，当顶层流导入子流/组件时，不会实例化新接口。

最初，每次遇到Flow.create时都会创建一个新的接口实例，这与目标被重新加载的时间相同。我们这样做是因为当目标持续整个流程时，我们已经看到了早期实施中的问题。这导致一些流程生成顺序依赖性开始蔓延到一些应用程序中，例如当你产生它独立位置与在相同的时间的其他流生成它从prb1.rb输出是不同的。 所以从一张白纸每次开机，它消除了非有意改变取决于你的目标此前做了流量的输出的可能性。我们发现，在生成完整的顶级流程的上下文中，我们确实需要一些持久化状态，以便像跟踪测试数量一样。因此妥协的同时，保持在目标上刷新每Flow.create但只有在遇到一个新的顶级Flow.create刷新界面。

到目前为止，已在实践中运作良好。但是，如果你觉得你需要一个持续了整整俄程序生成命令的接口，那么也许你跨一个用例来我们没有预见，或者也许还有另一种方式来做到你想实现什么。

如果需要，打开另一个问题以提供更多详细信息。