search

Origen-SDK / o2

MIT License
4 stars 0 forks source link

Dynamic configs #89

Open ginty opened 4 years ago

ginty commented 4 years ago

In O1, config/application.rb supported config attributes being made dynamic by assigning the given attribute to a block.

Currently in O2 the equivalent file is now a TOML file (i.e. static) and I do like the simplicity of that. On the other hand, it was definitely useful to have some dynamic capability in O1, however I think that was mainly used for setting attributes, like the output directory, based on the current target.

I would like to propose that we keep the current TOML file approach, but enhance with some simple string substitution system which would allow some dynamic capability to be introduced based on the current target.

e.g. something like this :

output_directory = "output/${origen.dut.name}/${origen.tester.name}"

Such substitutions would be eval'd as late as possible, e.g. per https://github.com/Origen-SDK/o2/issues/88 it is being proposed to support multiple testers at once, so the output directory would only be finally eval'd when a given tester was about to write.

Any Python should be valid within a substitution block.

Is anyone aware of any use cases from O1 which could not be covered by such a system?

coreyeng commented 4 years ago

I had some dynamic settings for Windows vs. Linux. Options for the maillist and such, but were mostly unrelated to the generation process.

FWIW, Python does also have config files built into the stdlib (available post 3.5 I think). I'm fine with TOML, but the configparser is I think closer to what we had in O1.

ginty commented 4 years ago

The current O2 implementation uses this Rust config parser, which seems to be very similar in capabilities and features - https://docs.rs/config/0.10.1/config/

I don't propose changing that here and the configs would be resolved with the embedded Python still in place.

Though as I write this now, I'm wondering if embedded Python is the right thing, maybe it should be more like a C macro system since both language domains will refer to these vars and I really don't like the idea of coupling the Rust side to Python.

coreyeng commented 4 years ago

Do you think the actual parsing could be frontend implemented and the dynamics only being computed when needed? The TOML can be given to the Rust side as just raw strings and when an attribute is needed the frontend can compile it in whatever it chooses? May be unnecessary backend-to-frontend handshaking though for most cases.