Enable test node object such that test node cloning is simple

[info-rchitect]

Hi,

In origen v1 the test node/suite model is lacking all of the information necessary to clone itself. Many attributes are only passed through to the selected generator versus being stored in an object instance. The advantage of native cloning is auto-generation of similar child tests such as characterization test nodes (e.g. vmin search of the parent test node).

regards

[info-rchitect]

Here is what I see in the V93K test suite in O1:

OrigenTesters::SmartestBasedTester::Base::TestSuite#methods: extract_atp_attributes  inspect  interface  meta  meta=  method_missing  name=  pattern=  respond_to?  smt8?  to_meta
OrigenTesters::SmartestBasedTester::V93K::TestSuite#methods:
  analog_set   fail_per_label   force_serial           hw_dsp_disable   level_spec                 log_mixed_signal_waveform=  pattern           set_fail=       test_level=   tim_equ_set=      timing_set=
  analog_set=  fail_per_label=  force_serial=          hw_dsp_disable=  level_spec=                mx_waves_enable             per_pin_on_fail   set_pass        test_method   tim_spec_set      timing_spec
  anaset       fail_value       frg_enable             lev_equ_set      levels                     mx_waves_enable=            per_pin_on_fail=  set_pass=       test_method=  tim_spec_set=     timing_spec=
  anaset=      fail_value=      frg_enable=            lev_equ_set=     levels=                    name                        per_pin_on_pass   site_control    test_num      time_set          timset
  bypass       ffc_enable       hardware_dsp_disable   lev_spec_set     levset                     output_on_fail              per_pin_on_pass=  site_control=   test_num=     time_set=         timset=
  bypass=      ffc_enable=      hardware_dsp_disable=  lev_spec_set=    levset=                    output_on_fail=             pin_levels        site_match      test_number   timeset           value_on_fail
  comment      ffc_on_fail      hold                   level_equation   lines                      output_on_pass              pin_levels=       site_match=     test_number=  timeset=          value_on_fail=
  comment=     ffc_on_fail=     hold=                  level_equation=  log_first                  output_on_pass=             seqlbl            test_function   test_type     timing_equation   value_on_pass
  context      ffv_enable       hold_on_fail           level_set        log_first=                 pass_value                  seqlbl=           test_function=  test_type=    timing_equation=  value_on_pass=
  context=     ffv_enable=      hold_on_fail=          level_set=       log_mixed_signal_waveform  pass_value=                 set_fail          test_level      tim_equ_set   timing_set
self.methods: __pry__
instance variables:
  @comment     @force_serial    @level_set   @name            @output_on_pass  @pattern          @per_pin_on_pass  @site_match   @timing_set
  @fail_value  @level_equation  @level_spec  @output_on_fail  @pass_value      @per_pin_on_fail  @site_control     @test_method  @timing_spec

Here are some attributes I think we need that I could not figure out how to store in a single test node object in O1:

• Binning (hardbin, softbin, test number, is_binnable?)
• Can it be characterized?
• Does it need alarm checks?
• Pattern burst (is that covered by pattern?)
• Company metadata (is that covered by meta or is meta only for tester platform meta?)
• Was it cloned?

[coreyeng]

I think all that seems pretty straightforward. Might want to also build something into the generators for what attributes they can support. For example, I don't think the J750 has built-in alarms, so maybe some way of knowing that and throwing up a warning would be nice.

Regarding the company metadata, I think it'd have to go in meta. I'll look into how we can build that into the Rust side. Right now I've only used it in the frontend.

[ginty]

I think this approach/mindset is fighting against the way O1 is designed. Maybe this is indicating that O2 should be more designed around the concept of a test object though, not sure.

O1 is expecting that if you had two tests, one with cz and one without, then you would define it twice in the flow. That is some duplication, but it is expecting that the amount of variables you pass from the flow is limited and most things should be undeclared and use default values:

func :my_test, pattern: "blah", bin: 15

if_enable :cz_flow do
  func :my_test, pattern: "blah", bin: 15, cz: true
end

Then something like cz: true is implemented via a decorator method in your interface:

def func(name, options = {})
  t = test_suites.add(name, options)
  t.test_method = test_methods.my_tml.func_test(pin_list: '@')
  # Decorate with a CZ setup if required
  if options[:cz]
    add_cz(t)
  end
  # Add the test to the flow
  flow.test(t, option)
end

def add_cz(test_obj)
  test_obj.some_attribute = "something"
  test_obj.some_other_attribute = "something_else"
end

[info-rchitect]

I think this approach/mindset is fighting against the way O1 is designed. Maybe this is indicating that O2 should be more designed around the concept of a test object though, not sure. O1 is expecting that if you had two tests, one with cz and one without, then you would define it twice in the flow. That is some duplication, but it is expecting that the amount of variables you pass from the flow is limited and most things should be undeclared and use default values: func :my_test, pattern: "blah", bin: 15

if_enable :cz_flow do func :my_test, pattern: "blah", bin: 15, cz: true end Then something like cz: true is implemented via a decorator method in your interface: def func(name, options = {}) t = test_suites.add(name, options) t.test_method = test_methods.my_tml.func_test(pin_list: '@')

Decorate with a CZ setup if required

if options[:cz] add_cz(t) end

Add the test to the flow

flow.test(t, option) end

def add_cz(test_obj) test_obj.some_attribute = "something" test_obj.some_other_attribute = "something_else" end

@ginty thx for the thorough thoughtful feedback. Perhaps I can show our implementation in O1 in detail at the next meeting and we can see the best way forward?

[ginty]

@info-rchitect, yes let's do that at this weeks' meeting.