Impossible to trigger mode transitions for some nested hardware components

[lwrage]

Bus and virtual bus subcomponents can have ports to trigger mode transitions. However, if they occur as subcomponents of a memory component, no connection can be made to such a port because memory components are not allowed to contain port connections. A similar situation occurs when a virtual bus is contained as a subcomponent in a (virtual) bus because bus and virtual bus cannot contain any connections.

[yoogx]

As discussed in Toulouse, investigate having in/out event port to carry out mode switch requests down the hierarchy. We would then have a legality rule stating that the end point should be a mode automata and/or BA

or extend memory implementation concept

[jjhugues]

Proposed resolution

• [ ] Add in event port to memory and buses components
• [ ] Add a legality rule to indicate that the destination is actually a mode automata trigger

coordinate with Lutz for proper wording

[jjhugues]

AS5506C already supports ports for memory -> no action required By transitivity, no need to add a legality rule, the constraints enforce that the semantic connection can only go to a mode trigger, and nothing else.

The only actions here seems to be that a port in a memory can only be an in event port @lwrage can you please confirm?

[lwrage]

The issue with memory is that legality rule L4 for memory only mentions that memory components can contain bus access connections but a port connection is required. Bus and virtual bus currently don't allow any connections even though they can contain virtual buses that can have modes. There is no way to trigger a mode change in a virtual bus contained in a bus. Also, nothing can connect to a virtual bus access feature of a virtual bus if it is contained in a bus or virtual bus.

[jjhugues]

Thanks, this clarifies, we did not capture the correct required updates. These have now been reflected in the doc