Contrary to my closing remarks on #83, I have another large PR, though, I think in terms of pure additions/subtractions, less than half the size of the last. This one contains some of the groundwork for pattern generation, including what I think is valid V93K output (I didn't run it through anything though).
For the high level view, you can now write patterns and have it generate some meaningful output. I've got a few example patterns here and here, which will actually generate output:
FORMAT clk portc
R100 simple 0 ZZ # <EoL Comment>;
# Producing pattern at index 2
R20 simple 0 ZZ # <EoL Comment>;
SQPG STOP;
The later will also generate three patterns, each named with the postfix.
In addition to combining cycles, I also have a pin state combiner` which should clean up superfluous pin state changes and leave the way clear for the cycle combiner.
One unfortunate thing that I wasn't able to find a workaround for was that the dut and tester from the standard context must be functions, so the () are required. The standard context now returns these as lambda functions which are run to give the most up-to-date DUT. Without that, Python sends a reference to the object, but there's no easy way I could tell to fully unload it when we want to re-initialize the target within a similar context, such as in a produce_pattern loop.
Some other notes:
I re-branded O1's generator as the producer, which is another static object which holds jobs. I renamed it because we have already have another generator module and Python has its own meaning of generator, though it is drastically different from ours.
This also includes #86, as I needed a place to put the output. The output directory can be set in the applications's .toml, or the default of <app root>/output.
I stole my output stuff from my web docs branch though, so I also copied over the same output directories I use over there, in case your curious as to why those are along for the ride.
I added few helpers similar to Ruby's respond_to to see if a method is available.
I'm not a big fan of Rust's file IO interface, so I wrapped my own. We can grow this as we need. I intend to add some Windows vs. Linux stuff as I've already had some issues with that. Even though pathbuf can handle it fine on the Rust side, things get terribly jumbled when moving from Python to Rust and back again.
I've also got startup and shutdown callbacks available from the DUT controller.
This is still a work in progress, but I think there's enough groundwork to warrant a review, and probably enough to where someone could pick up program generation, if there's any volunteers.
Hello,
Contrary to my closing remarks on #83, I have another large PR, though, I think in terms of pure additions/subtractions, less than half the size of the last. This one contains some of the groundwork for pattern generation, including what I think is valid V93K output (I didn't run it through anything though).
For the high level view, you can now write patterns and have it generate some meaningful output. I've got a few example patterns here and here, which will actually generate output:
The later will also generate three patterns, each named with the postfix.
In addition to combining cycles, I also have a pin state combiner` which should clean up superfluous pin state changes and leave the way clear for the cycle combiner.
One unfortunate thing that I wasn't able to find a workaround for was that the
dutandtesterfrom the standard context must be functions, so the()are required. The standard context now returns these aslambda functionswhich are run to give the most up-to-date DUT. Without that, Python sends a reference to the object, but there's no easy way I could tell to fully unload it when we want to re-initialize the target within a similar context, such as in aproduce_patternloop.Some other notes:
generatoras theproducer, which is another static object which holdsjobs. I renamed it because we have already have anothergeneratormodule and Python has its own meaning of generator, though it is drastically different from ours.applications's .toml, or the default of<app root>/output.respond_toto see if a method is available.pathbufcan handle it fine on the Rust side, things get terribly jumbled when moving from Python to Rust and back again.startupandshutdowncallbacks available from the DUT controller.This is still a work in progress, but I think there's enough groundwork to warrant a review, and probably enough to where someone could pick up program generation, if there's any volunteers.