Modelling hardware platform configuration and platform model reuse

[Gaudeval]

Issue #31 raises a higher level discussion as to how we capture platform configuration in a PML model especially to promote model reuse. As an example let us consider the case of a platform which main memory can be optionally partitioned, we could:

• define distinct models per configuration: one where the memory is partitioned with separate targets, one where the memory is a single target;
• define a parametrised model: expose the partitions as a configuration point, and generate the configured model. This would promote reuse as other components would not be impacted. If the configuration changes, so does the platform model and additional layers, such as the software allocation, may be invalidated.
• define platform configuration as an additional layer: we could express the configurations as transformations of a base model, e.g. non-partitioned memory merges existing targets on a model (the partitioned memory). Said transformations may preserve the semantic of upper layers, e.g. the software allocation;
• define the platform as a configurable object: similar to the parametrised solution, but interactions with the platform would go through an object/interface that abstracts and is independent from the configuration. The object would need to redefine some of the syntactic sugar offered by PML, e.g. how to map a piece data to the memory target(s).

Those are just proposals off the top of my head. Comments and suggestions are more than welcome.

[kevin-delmas]

Thank you for the propositions, here some comments

• Concerning the first proposition, a more refined solution is to utilize an abstract class to encapsulate the shared architectural elements and then specialize it with the two alternatives. I acknowledge that such a solution may be valid for simple configurations (few possible concrete platforms) but not for complex ones. Another approach is to define component names without instantiating them, though this can be somewhat tricky.
• If you change your platform's interface by adding new parameters, this will likely lead to a possible invalidation of the software allocation layer if it specifies something on the parameterized part.
• I'm unsure about the transformation layer's design. Currently, it's not possible to remove or modify a HW component within an architecture; it can only be deactivated (which also triggers deactivation of the provided services).
• For the last one, providing a minimal example would be helpful.