We want a more systematic way to keep track of configurations especially of the ROCs as they grow in number. This issue is focused on outlining my thoughts.
- The
Compiler::extract method can take a YAML::Node of chip parameters, so we can nest chip parameters deeper in a YAML tree and then provide those to the compiler.
- The
Parameters class shows how we can process YAML tags to "mark up" the configuration with types. This is currently used for the pftool configuration file, but we can use the same logic for a subsystem configuration. https://github.com/LDMX-Software/pflib/blob/main/src/pflib/Parameters.cxx
- Currently, the only "type" that is supported via a tag is
!file which basically inserts another YAML file "in place".
- I think we'd want at least one more type as well, something like
!registers which would allow us to insert an "image" of register values that are pre-compiled and just need to be copied over. An "image" would be some mildly-compressed copy of the simple address/value listing. Jeremy suggested the Intel Hex Format since it has a checksum at the end making it difficult to change manually (hopefully preventing errors or corruption).
- I'd want some "overlay"/"overwrite" functionality so we could load some base configuration and then apply additional special values for specific chips. This would make testing more ergonomic and iterative. Final subsystem configurations (that are stored in a DB or Git repo) would probably be a "fully solidified" config where all parameters are only mentioned once to avoid confusion and allow for easier debugging.
- Since these files could get large, I'm also interested in loading their
gzipped form, but that kinda defeats the purpose of storing them in a Git repo. I'll need to look into that more.
- The subsystem file would start with two sections
rocs and econs for the ROCs and ECONs and each would use the chip index as a key in a map. I'm using a mapping here instead of a sequence because some indices may be skipped in the configuration or marked inactive if they break.
rocs:
all: !file shared-roc.yaml
0: !file special-roc0-pedestal-config.yaml
1: !file roc1-pedestals.yaml
0:
ch_0:
channel_off: 1 # special value for ROC0 only, overrides previous values
econs:
0:
# certain pages/parameters should be excluded since they would upset setup tasks
zs: !registers pre-compiled-zs-parameters.hex
We want a more systematic way to keep track of configurations especially of the ROCs as they grow in number. This issue is focused on outlining my thoughts.
Compiler::extractmethod can take aYAML::Nodeof chip parameters, so we can nest chip parameters deeper in a YAML tree and then provide those to the compiler.pflib/src/pflib/Compile.cxx
Line 436 in e574872
Parametersclass shows how we can process YAML tags to "mark up" the configuration with types. This is currently used for thepftoolconfiguration file, but we can use the same logic for a subsystem configuration. https://github.com/LDMX-Software/pflib/blob/main/src/pflib/Parameters.cxx!filewhich basically inserts another YAML file "in place".!registerswhich would allow us to insert an "image" of register values that are pre-compiled and just need to be copied over. An "image" would be some mildly-compressed copy of the simple address/value listing. Jeremy suggested the Intel Hex Format since it has a checksum at the end making it difficult to change manually (hopefully preventing errors or corruption).gzipped form, but that kinda defeats the purpose of storing them in a Git repo. I'll need to look into that more.rocsandeconsfor the ROCs and ECONs and each would use the chip index as a key in a map. I'm using a mapping here instead of a sequence because some indices may be skipped in the configuration or marked inactive if they break.