Tester specific API - Githubissues

ginty commented 3 years ago

The intention of this PR is to merge in the following API which should be applicable to both patgen and proggen code to implement tester-specific sections (sections of code that utilize ATE-specific APIs to target non-std ATE features).

# Example of a section of code specific to one tester
with tester().specific("v93k_smt7") as v93k:
    v93k.some_ate_specific_api_method()

# Example of a section of code specific to multiple testers
with tester().specific("v93ksmt7", "v93ksmt8") as (v93k7, v93k8):
    v93k7.some_ate_specific_api_method()
    v93k8.some_ate_specific_api_method()

The arguments given to the specific method to select a specific tester API should be one of the supported testers defined here: https://github.com/Origen-SDK/o2/blob/6145b770c935ad93ac7113a69c6e37955d725611/rust/origen/src/testers/supported_testers.rs#L6-L11

It is case insenstive and underscores will be ignored. Some aliases are also supported, e.g. "ultraflex" or "uflex" will be accepted.

The object yielded to the tester-specific block exposes the API for the given tester. Note that it is not a substitute for tester() and it does not implement any of the methods/functionality provided by the tester() object. The tester() object can and should be used as normal within the block to access and common API features.

However, all content generated within the specific block will apply to the given tester only - e.g. any vectors generated or tests added to a flow will only appear in the output for that specific tester.

These internal functions will be called at the start and end of the block to open and close the tester-specific sections in the current pattern or test program: https://github.com/Origen-SDK/o2/blob/3164c8c489e5e541e406b2dc1ede82f893454934/rust/origen/src/core/tester.rs#L122-L139

It doesn't bother checking whether we are currently generating a pattern or a program and just opens/closes a tester-specific section on them both.

It is allowed to further select a subset of the existing testers within an existing specific block, however attempts to select another tester that is not already selected will raise an error:

# Example of a section of code specific to multiple testers
with tester().specific("v93ksmt7", "v93ksmt8") as (v93k7, v93k8):
    v93k7.some_ate_specific_api_method()
    v93k8.some_ate_specific_api_method()

    # This is allowed to further refine the selection:
    with tester().specific("v93ksmt7") as v93k7:
         v93k7.some_ate_specific_api_method()

    # But this will raise an error because we are already in a block that does not include the uflex
    with tester().specific("uflex") as uflex:
         uflex.some_ate_specific_api_method()

Finally the tester specific APIs should be added to this module: https://github.com/Origen-SDK/o2/tree/3164c8c489e5e541e406b2dc1ede82f893454934/rust/pyapi/src/tester_apis

Currently it only contains APIs applicable to proggen, but its envisaged that patgen APIs will be added alongside.

This PR brings lots of program generator WIP with it, however we can go through that later in a more final intent PR for that feature. Aside from this specific block feature being discussed, everything else related to the proggen should exist in parallel to the patgen and should be discrete from it.

However, if you want any more details on the proggen now, or have questions on anything you see in here please feel free to indicate below.

ginty commented 3 years ago

Likely "V93K" will also be supported in the near future and that would implement sections/APIs that are applicable to both SMT7 and SMT8 targets.

priyavadan commented 3 years ago

@ginty still looking through the PR.

Would it be correct to assume custom tml's would be added through a python module.

Should the test_templates_dir in build.rs be a variable that can be overwritten by the user to point to the custom tmls?

ginty commented 3 years ago

Hi @priyavadan, yes custom test libraries will be added either by an application itself or by a (Python) plugin.

The mechanism for that has still to be added, but there will be a load path where Origen will look for a matching library/test name in each directory in the load path and the first match will be the one that is used. At the end of the path will be the built in templates that are shipped with Origen (that's all that's currently implemented), thereby allowing an app/plugin to add to or override the library definitions that ship with Origen.

Whether the definition exists in Origen code or a Python package, it would be the same json definitions that are used, like this: https://github.com/Origen-SDK/o2/blob/3164c8c489e5e541e406b2dc1ede82f893454934/rust/origen/src/prog_gen/test_templates/advantest/smt7/ac_tml/frequency_by_digital_capture.json

Other formats will probably also be supported in future, e.g. that custom format from ADV that you showed recently.

The directory in build.rs should not be a variable as that is compile-time code, it is used to include the json files for the default libraries into the compiled Origen build.

Instead this method will be enhanced to introduce the load path lookup: https://github.com/Origen-SDK/o2/blob/3164c8c489e5e541e406b2dc1ede82f893454934/rust/origen/src/prog_gen/advantest/common/mod.rs#L66

Likely this is how the test template load path will be implemented:

The app has highest priority, templates would be added simply by dropping them in a specific directory, e.g. <app root>/test_templates/
There will be a simple API to add plugins into the mix, e.g. origen.add_test_templates_from("my_plugin"), that would then cause Origen to look in the plugin's test_templates/ dir too
Then finally look in Origen core itself

ginty commented 3 years ago

I went ahead and merged this, but please feel free to continue the discussion here on the prog gen as required.

Origen-SDK / o2

Tester specific API #126