If this is not possible, the system could either calculate during runtime all
possibilities or find new configurations on demand. The overhead of finding a new
configuration is low, as typically only a small number of reconfiguration entities are
affected.
Every software reconfiguration entity is in one of the state in Fig. 7.20. Upon
boot up, every reconfiguration entity is in the state Init, which means that the
module itself is already linked and ready for execution (The modules of all
applications might be linked already at link time and not at runtime). However,
what is missing in this state is a concrete working configuration of all reconfiguration entities.
The reconfiguration monitor then finds the first working configuration for the
system and starts the initialization sequence. The reconfiguration entities must not
have circular dependencies, as this would complicate recovery considerably.
After the first reconfiguration, all reconfiguration entities that are currently in use
have the state Active, the ones that are not used are still in the state Init.
Now, if an alternative entity is needed, it is initialized, and set to Active, the one
that is being replaced is set to Standby. If the entity is no longer used, it is set to
Deletion and removed by the runtime system.
Upon boot up, the main processor and the main memory are initialized and
transferred to state Active.
This state is the standard state of a component that is actively participating in the
system. If no reconfigurability is available in the system, this would be the one and
only state of the hardware. Any active hardware component can and should have
checking schemes built-in which allows the hardware component to check itself.
The checking procedure could be either software or hardware initiated and
consists of hardware and/or software checking schemes.
In Chap. 8, we introduce some language constructs that support this hardware
reconfiguration, which is then in explained in detail in Chap. 9.
Ac#ve&
Stand,by&
Init&
Dele#on&
Fig. 7.20 Software states as seen by runtime system
7.4 Software Support for Hardware Reconfiguration
107
possibilities or find new configurations on demand. The overhead of finding a new
configuration is low, as typically only a small number of reconfiguration entities are
affected.
Every software reconfiguration entity is in one of the state in Fig. 7.20. Upon
boot up, every reconfiguration entity is in the state Init, which means that the
module itself is already linked and ready for execution (The modules of all
applications might be linked already at link time and not at runtime). However,
what is missing in this state is a concrete working configuration of all reconfiguration entities.
The reconfiguration monitor then finds the first working configuration for the
system and starts the initialization sequence. The reconfiguration entities must not
have circular dependencies, as this would complicate recovery considerably.
After the first reconfiguration, all reconfiguration entities that are currently in use
have the state Active, the ones that are not used are still in the state Init.
Now, if an alternative entity is needed, it is initialized, and set to Active, the one
that is being replaced is set to Standby. If the entity is no longer used, it is set to
Deletion and removed by the runtime system.
Upon boot up, the main processor and the main memory are initialized and
transferred to state Active.
This state is the standard state of a component that is actively participating in the
system. If no reconfigurability is available in the system, this would be the one and
only state of the hardware. Any active hardware component can and should have
checking schemes built-in which allows the hardware component to check itself.
The checking procedure could be either software or hardware initiated and
consists of hardware and/or software checking schemes.
In Chap. 8, we introduce some language constructs that support this hardware
reconfiguration, which is then in explained in detail in Chap. 9.
Ac#ve&
Stand,by&
Init&
Dele#on&
Fig. 7.20 Software states as seen by runtime system
7.4 Software Support for Hardware Reconfiguration
107