The intention here was to originally start working on the program generator, but it went off on a lot of tangents to add some basic things that were required before I could really get into the prog gen development.
This includes:
A system for apps to define commands
A file differ
A working examples command
A working version command and app versioning system
Some modifications to the tester top-level API to make it less patgen centric and able to support both pattern and program generation from the 'origen g' command
DUTs can now only be instantiated within a target load process, the same as O1. This just makes it easier to do any housecleaning and setup associated with a new DUT rather than letting it happen anywhere.
Logger - added some better colors and more macros. It now works from time 0 meaning that trace/debug logging can be used everywhere, even before the log file is established.
This exposes a subset of the clap options, though we could extend it to all of them if we want - for now though, I think the current subset should be adequate for 99% of use cases. It also supports sub-commands.
Basically just define Python modules named after the command and it must implement a run function where the command line options will be passed in as kwargs. All args will be passed in as a list of strings and it is up to the command to cast them as required.
It is well documented and tested if anyone wants to use it elsewhere, it supports everything the O1 differ did including optionally ignoring diffs in comments, blanks lines and the ability to suspend/resume diffing whenever a certain character sequence is encountered.
The origen -v command now reports the CLI version, Origen version used by Python and the app version when run within an app.
Outside of an app just a single Origen version is reported since the CLI and Origen core version will always be the same in that case.
The object returned by origen.app in Python now has its root base class defined in Rust (same technique used by @coreyeng for the tester.
Tester Changes
Changed with produce_pattern(... to with Pattern(.., which is more consistent with other APIs.
Changed the ST7 identifier to be SMT7, that's at least more intuitive to me and what I believe is the more common acronym for this.
Added a tester.stats object to keep track of the number of generated files, those with diffs, etc.
Tried to push more of the tester state setup down to Rust to simplify the Python side.
Changed tester.render() to tester.render_pattern()
Moved most of what was previously in the top-level of an ATE implementation into a module called pattern_renderer since it was patgen specific. This is to allow the top-level ATE implementations to be used for both prog and patgen.
DUT Loading
Targets can now also be set to a function, this is most useful to create ad-hoc targets for testing.
Use STATUS::output_dir() and STATUS::reference_dir() now to get the respective directories in Rust code. These are no longer tied to the app since they could have meaning in global commands too. These methods account for all ways to set - a default, by the app, and by the current command.
The file handler supports dir args now, e.g. origen g some/dir though still not list files yet.
The job instance now provides a good helper method for resolving file references
Added a useful to_relative_path function to utility/file_utils.
Prog Gen
There is some early functionality included in this, but will cover that in more detail in a future PR.
In this version the origen g can be executed on the flows in the app directory and the infrastructure is in place to instantiate an interface.
I've probably missed some things, please just ask below if you want an explanation on anything you see that is not covered.
ginty
commented
4 years ago
The intention here was to originally start working on the program generator, but it went off on a lot of tangents to add some basic things that were required before I could really get into the prog gen development. This includes:
App Commands
Apps can define commands via
config/commands.tomlas shown in the example app - https://github.com/Origen-SDK/o2/blob/d1d3567c66f30a18057727767c17a8f878586006/example/config/commands.tomlThis exposes a subset of the clap options, though we could extend it to all of them if we want - for now though, I think the current subset should be adequate for 99% of use cases. It also supports sub-commands.
Commands are defined in
<app>/commandsas shown in these examples - https://github.com/Origen-SDK/o2/tree/d1d3567c66f30a18057727767c17a8f878586006/example/example/commandsBasically just define Python modules named after the command and it must implement a
runfunction where the command line options will be passed in as kwargs. All args will be passed in as a list of strings and it is up to the command to cast them as required.File Differ
A file differ utility has been added here - https://github.com/Origen-SDK/o2/blob/d1d3567c66f30a18057727767c17a8f878586006/rust/origen/src/utility/differ.rs
It is well documented and tested if anyone wants to use it elsewhere, it supports everything the O1 differ did including optionally ignoring diffs in comments, blanks lines and the ability to suspend/resume diffing whenever a certain character sequence is encountered.
This is fully hooked up to the patgen and an
origen save_refcommand has been added to update reference files. See here for more details on how this system works - https://github.com/Origen-SDK/o2/blob/d1d3567c66f30a18057727767c17a8f878586006/rust/origen/src/core/reference_files.rsApp Versioning
An application version is now defined by
config/version.toml. Rust APIs exist to read and write this, e.g.origen::app().version()- See https://github.com/Origen-SDK/o2/blob/d1d3567c66f30a18057727767c17a8f878586006/rust/origen/src/core/application.rsThe
origen -vcommand now reports the CLI version, Origen version used by Python and the app version when run within an app.Outside of an app just a single Origen version is reported since the CLI and Origen core version will always be the same in that case.
The object returned by
origen.appin Python now has its root base class defined in Rust (same technique used by @coreyeng for the tester.Tester Changes
with produce_pattern(...towith Pattern(.., which is more consistent with other APIs.tester.statsobject to keep track of the number of generated files, those with diffs, etc.tester.render()totester.render_pattern()DUT Loading
instantiate_duthelper was added to the shared test lib which makes use of this to instantiate a variable DUT within the target process - https://github.com/Origen-SDK/o2/blob/d1d3567c66f30a18057727767c17a8f878586006/example/tests/shared/__init__.py#L31Misc
STATUS::output_dir()andSTATUS::reference_dir()now to get the respective directories in Rust code. These are no longer tied to the app since they could have meaning in global commands too. These methods account for all ways to set - a default, by the app, and by the current command.origen g some/dirthough still not list files yet.to_relative_pathfunction toutility/file_utils.Prog Gen
There is some early functionality included in this, but will cover that in more detail in a future PR.
In this version the
origen gcan be executed on the flows in the app directory and the infrastructure is in place to instantiate an interface.I've probably missed some things, please just ask below if you want an explanation on anything you see that is not covered.