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

问题是当调用其他子流时，选项不会保持持久性。这是从第一次调用测试界面开始的pry会话：

    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"}

但是，这是从第二次击中相同断点的pry会话：

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

我想我有几个问题：

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

编辑*

就传递到顶级流程的选项而言，实际上没有任何关于将它们传递给初始化的保证。相反，接口应该创建启动和关闭方法，如果它想拦截它们：

但在docs中，我看到以下内容：

对于要运行的接口，它必须实现您的流将调用的所有方法。通常也会创建一个初始化方法，该方法将捕获传递给Flow.create的任何选项（例如在我们的流程示例中将环境声明为探测）。

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

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

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

$ 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的选项被传递到接口＆＃39; s初始化方法。

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

最初，每次遇到Flow.create时都会创建一个新的接口实例，这与重新加载目标的时间相同。我们这样做是因为我们已经看到了早期实现中的问题，当目标被持续整个流程时。这导致一些流程生成顺序依赖性开始蔓延到某些应用程序，例如prb1.rb的输出在独立生成时与其他流同时生成时不同。因此，每次从一个干净的平板开始，它消除了根据你的目标早先做了什么而无意地改变流量输出的可能性。

最终，我们发现在生成完整的顶级流程的上下文中，我们确实需要一些持久状态来跟踪测试数量。因此，为了妥协，我们会在每个Flow.create上保持目标刷新，但只有在遇到新的顶级Flow.create时才刷新界面。

到目前为止，在实践中一直运作良好。但是，如果您觉得需要一个持续存在于整个Origen程序生成命令的界面，那么您可能会遇到我们尚未设想的用例，或者可能还有其他方法可以执行您尝试的操作实现。

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

测试程序流生成在测试接口的后续内容中从主流文件中丢失选项

1 个答案: