Add `condition` attribute to `board`, `device` and `part` elements

[silviooliva]

The condition element can be used to create dependency rules using several attributes defined in the standard for other elements. E.g.:

• Dvendor, Dname, … attributes can be used for creating a dependency rule on a <device> element
• Cvendor, Cbundle, .. attributes can be used for creating a dependency rule on a <component> element
• Bvendor, Bname, .. attributes can be used for creating a dependency rule on a <board> element
• Hvendor, Hname attributes can be used for creating a dependency rule on a <part> element

At present, in the standard, among the <device>, the <component>, the <board> and the <part> elements, only the <component> has the attribute condition. Hence, a condition can be used only to create a dependency rule between a <component> element and the other elements (another <component>, a <device>, a <board> and a <part>). No other kind of dependencies can be created. E.g.: there is no way to describe in the PDSC file the dependency between boards (e.g. a daughter board working only when mounted on a specific mother board) or between a board and a part or a device (and vice-versa).

Adding the condition attribute also to board, device and part elements, could allow a pack developer to have all the tools in the standard for describing all the possible dependencies among the defined elements.

[silviooliva]

Hello @jkrech, what do you think about this proposal? Thanks.

(In case it is accepted, I can take charge of the PR.)

[mdortel-stm]

Should we clarify what would mean adding conditions to board, devices, parts? For a component, the specification allows to understand that it allows at least to validate the project and at most to trigger automatic resolution algorithm. My feeling would be that we expect only validation for these new condition owners. Do you see other use-cases, @silviooliva?

[silviooliva]

Hi @mdortel-stm, I'm perfectly aligned to your comment.

These conditions should only help an user to identify potential issues. They, if not satisfied, should not be considered blocking issues. So, also for preserving the backward compatibility, the Open-CMSIS toolbox should not be requested to provide the dependency resolution.

[jkrech]

I think this may need some further discussion. I am currently undecided whether we should have a separate <conditions> section for specifying hardware dependencies. What type of dependencies do you foresee? Would we describe something like an "api" for shields using a common form-factory like Arduino? In this case it would otherwise become a tedious task to maintain a list of compatible shields.

Would you be able to provide some examples that could be used for testing? How do we tell the tools which hardware parts got selected?

[silviooliva]

Hi, sorry for the late answer. We are having some further internal discussion on how to improve this proposal linking it to the possibility of creating HW projects. For the time being, we could put on hold this discussion for resuming it when the new complete proposal will be ready.

[jkrech]

In light of the proposal to optionally describe a hardware project (here: 1178, I am wondering whether the above extension describing inter-dependencies of hardware needs to be reviewed or is no longer relevant? Once a "complete" hardware project is present, I don't see a need, however in order to "complete" a hardware project, such dependencies might be useful?

[EmmanuelGrandin]

Hi,

As you mention @jkrech, when an HW project is created, it can serve as a reference to find SW Components with matching H-conditions as a complement to D-conditions and B-conditions (= in short, conditions between SW and HW), but there is no need for "intra-HW" dependencies (= conditions between HW elements such as boards, devices and parts). However, when creating or updating such an HW project, then those "intra-HW" H-conditions can be as useful as the C-conditions when completing a SW project : they can help selecting devices/parts matching together, or devices/parts matching board needs (e.g. when replacing a part by another part in a new board revision).

On the other side, allowing for conditions at the HW-elements level could also be used to introduce a HW-to-SW dependency : an HW part could optionally have a condition to select a (set of) SW Component able to drive it. However this bottom-up approach is not the way conditions are used today, so I'm not sure we want to enable this : those new conditions at HW-elements level could for example be limited to HW scope only.

BR

[ReinhardKeil]

Could this be solved using requirements/targets instead?

[EmmanuelGrandin]

Using requirements/targets will only set the HW dependency at the full package level.

This proposal aims at being more accurate than the package level when defining the dependencies between HW elements. For example a Board package might contain several boards, each of which might have their own dependencies on HW elements (boards or parts), so that's where the "condition" on any HW element is useful.

Another example : a board element describing an X-Nucleo daughterboard could have a condition on a Nucleo motherboard, or to any board holding a male ST Morpho connector.