Parameters API changes proposed

[info-rchitect]

Hi,

We use the Origen::Parameters API a lot and it really works great most of the time but some problems have arisen:

1. Not possible to query the parameter set contexts if a :default parameter set is not defined
2. Cannot use parameter context inheritance if the inheriting class does not have a parameter context defined.

1 Workaround

unless dut.scan.params(:ft).is_a?(Origen::Parameters::Missing)

2 Ruby code

  module TestModules
    class ScanTestModule < TestModule
      parameters_context :top # Sets the parameter context to track with the state of the DUT

2 error

peologin07:ppekit $ origen p jtag_flow.rb --job ft
Unknown parameter set :ft requested for TestModules::ScanTestModule, these are the valid sets:
  :tests
  :default

My proposal is that checking parameter contexts works regardless if no sets are defined. Secondly, that context inheritance does not force a parameter set to be defined, rather it is just a broadcast message that just sets the context and let's the object decide if it wants to listen. I think the fix for #1 will fix #2 as well. Thoughts?

thx

[info-rchitect]

Also the need for this is so we can create flow conditionals that are test module specific.

func :jtag_ore_enable if dut.jtag.ft?

[ginty]

The #1 workaround is ugly and yes we should fix it to remove the need to do that.

For #2, I think you are saying that if you setup an object to track the parameter context of another object and then the master object sets a context that the follower doesn't have, then it raises an error.

It's not clear what the follower object should do in that case, is that not a condition that it is worth alerting the user to via an error message?

[info-rchitect]

@ginty wrt #2, let me explain our use case. We have multiple test modules that are direct'children' of the DUT. Each test module has to decide if their test content is common to all test insertions, specific to a an actual insertion (e.g. WS1) or specific to an insertion platform (e.g. WS or FT) but not an actual insertion in the manufacturing flow. When the user uses the --job option they are directing the DUT to tell their test module to generate job specific content versus the default common content. Other test modules may not respond to that job but we think that is OK. I guess it is comparable to the on_mode_changed callback. When the DUT changes modes, if the test module calls the callback then it cares about the mode change, if not then no error.