Target system changes

[ginty]

This is a proposal to modify the target system to improve it in the following areas:

• Allow it to have multiple testers to be selected at once to support outputting multiple different formats at once.
• Make it possible to have more than 2 layers of target vs. O1 which only supports 2 layers - the 'target; and the 'environment'
• Drop the name 'environment' since some users have reported confusion between the Origen environment and the system/Linux environment.

Note that only one DUT will be allowed to be instantiated at once and an error will be raised if a selected target combination attempts to instantiate multiple DUTs.

The proposal is for O2 to drop the 'environment' directory and instead make the 'target' directory support sub-dirs which each represents a different target layer.
This is mainly for logical organization however and the system will support selecting multiple targets from the same sub-dir where appropriate - e.g. to select multiple backend tester targets.

By convention, all apps should have the sub-dirs target/dut/ and target/tester/ which logically map to the O1 target/ and environment/ dirs respectively.

Target files will be the same as they are today - just a regular Python file where runtime objects can be instantiated and configured.

The origen t command should work something like this...

An application default target configuration can be set in config/application.toml:

target = ["dut/falcon", "tester/v93k"]

This will be reflected in the workspace by default:

$ origen t
dut/falcon
tester/v93k

Targets can then be added and removed via the command line:

$ origen t add targets/tester/uflex.py

$ origen t
dut/falcon
tester/v93k
tester/uflex

$ origen t remove targets/tester/v93k.py

$ origen t
dut/falcon
tester/uflex

Or it can be set explicitly like this:

$ origen t targets/dut/eagle.py targets/tester/j750.py

$ origen t
dut/eagle
tester/j750

The current target can be examined programatically like this:

origen.target         # => Returns a list-like object, ["dut/eagle", "tester/j750", "tester/v93k"]
origen.target.tester  # => Filters by sub-dir, ["tester/j750", "tester/v93k"]
# Drilling down further returns a boolean
origen.target.tester.j750   # => True
origen.target.tester.ultraflex   # => False

# Which allows things like:

if origen.target.tester.j750:
  # Some J750 specific operation

The names of the sub-dirs and target files are arbitrary and the application can add whatever additional target options they want. /dut and /tester will not really have any special significance for Origen beyond being the encouraged convention.

The origen.tester interface may well offer a similar API to inspect which tester targets are currently selected.

[coreyeng]

This all looks good to me. I don't mind taking this item since it goes along with #83.

The origen.tester interface may well offer a similar API to inspect which tester targets are currently selected.

I do already have something like this, if you wanted to see this idea in action.

[ginty]

@coreyeng, please feel free to pick this up, thanks!

That's good you already have similar under origen.tester.target so would be good to give these the same look and feel.