anchor.diff:  Many users of the V93K program generator however, are likely to want to use it in combination
   with their own custom test method library...
   
  -### Custom Test Methods
  +#### Custom Test Methods
   
   An API exists to define the naming and parameter signature of test methods provided by
   a 3rd party library, enabling them to be used within an interface exactly like in the examples above.
  
positive.code: t.test_method = test_methods.origen.functional_test(check_shutdown: 1)
  ~~~
  
  ### Limits
  
  The limits can be set for all test objects using the following API, see here for some examples
  [of the available unit helpers](<%= path 'guides/misc/coreext/#Unit_Helpers' %>):
  
negative.code: % render "layouts/guides.html" do
  
  ### Flow Considerations
  
  By default, a top-level `Flow.create` call in Origen will generate a standalone V93K testflow file which is
  internally wrapped by a flow group, like this:
  
  ~~~text
  group <FLOW_NAME> {
    // Flow content here
  }
  ~~~
  
  When such flows are imported into a master flow file, SmarTest does not provide a standard enable mechanism
  to control which sub-flows are executed.
  
  However, Origen provides the ability to generate V93K flow modules with an enable-word wrapper, thereby allowing
  the top-level flow to easily enable/disable the execution of flow modules via flow variables.
  
  By enabling this feature in the target like this:
  
  ~~~ruby
  OrigenTesters::V93K.new(add_flow_enable: :enabled)
  ~~~
  
  the flow will now generate like this:
  
  ~~~text
  group <FLOW_NAME> {
    if @<FLOW_NAME>_ENABLE == 1 {
      // Flow content here
    }
  }
  ~~~
  
  The `@<FLOW_NAME>_ENABLE` variable will be initialized to 1 in the generated variables file for the given flow,
  meaning that the module will run by default if the top-level flow does nothing with this variable.
  
  Alternatively, the variable can be initialized to off like this:
  
  ~~~ruby
  OrigenTesters::V93K.new(add_flow_enable: :disabled)
  ~~~
  
  Meaning that by default, the module will not run and the top-level flow must always enable it by including
  `@<FLOW_NAME>_ENABLE = 1` before hitting the module.
  
  Setting this attribute in the target means that it will apply to all flows. Alternatively, it can be set within
  the flow itself (or the interface) if it is necessary to use this feature for only a subset of flows, or to override
  the default setting for a particular flow.
  
  Here is an example:
  
  ~~~ruby
  Flow.create interface: 'MyApp::Interface' do
  
    # Ensure that this flow is always generated with an enable word wrapper that is enabled by default
    self.add_flow_enable = :enabled
  
    # Some functional test
    func :blah
  end
  ~~~
  
  This same API may be used to implement similar features on other platforms in future, but for now only the V93K is implemented.
  
  
  ### Interface Considerations
  
  Be sure to read and understand the guide to
  [Creating an Interface](<%= path "guides/program/interface" %>) before
  