4.5. Architecture Exploration

In order to add a PE into the design, users click the button Add... to pop up the PE Selection dialog which opens and loads the PE database and allows users to select an additional PE out of the PE database. The PE Selection dialog is shown in Figure 4-17.

At the left of the PE Selection dialog is a PE category table. Each row represents one category of PEs in the database. For example, row Processors contains all the general-purpose processors in the database.

By clicking and selecting one row in the table at left, users will be shown all the PEs in the selected category in the table at the right. Each row of the table at the right represents one type of PE in the database under the selected category. The name of the PE type is shown in the Component column. The Proc and Mem columns show the features of the PE, i.e. whether the PE is a general processor (is capable of executing arbitrary code/behavior) and whether the PE can act as a shared memory (is capable of exporting local storage to other PEs), respectively. Finally, other attributes of the PE type are displayed in separate columns. Users can select the desired PE type by clicking the corresponding row.

There are two buttons at the bottom of the PE Selection dialog: Ok and Cancel. By clicking the Ok button, an additional PE of the selected PE type and with an automatically determined name is added into the design's allocated architecture. In addition, PEs can be allocated by double-clicking into the desired PE type row in the PE Selection dialog (equivalent to selecting the row and pressing Ok). Clicking the Cancel button aborts and cancels PE selection without changes to the PE allocation. Either clicking Ok or Cancel button will close the PE Selection dialog and return to the PE Allocation dialog.

Components in the database can be parametrizable during instantiation. For such components, their type is shown in italic letters in the Component column. Furthermore, when allocating such a parametrizable component (by pressing the Ok button or by double-clicking on the component), a Component Parameter dialog will be popped up (see Figure 4-18). In this dialog, the user has to enter and confirm all parameters for the given component instance to be allocated. Users can enter any value for any parameter (within the value range allowed by the component) by clicking into each parameter's value field in the dialog. Clicking the Ok button of the dialog will generate a new customized component type with the selected parameters and will then allocate a new instance of this parametrized type. Clicking the Cancel button aborts component parametrization and returns to the PE Selection dialog.

In order to duplicate an existing PE in the design's PE allocation, users can select a PE by clicking the corresponding row in the allocation table and click the button Copy. Clicking Copy will add a new PE instance with an automatically determined name and with the same type, attributes and description as the currently selected PE to the design's allocation.

In order to remove a PE from the design's allocation, users can select the target PE to be removed in the allocation table and click the Remove button. Clicking Remove will remove the selected PE from the list of allocated PEs.

Users can edit the PE name and PE description in the PE Allocation dialog by clicking into the respective Name or Description column of the corresponding PE. Clicking into any of these cells will allow editing of the respective text in the cell by opening a text edit box in place. Pressing the Esc key during editing aborts the edit operation. Pressing Enter accepts the entered text and changes the PE name or description in the allocation accordingly.

Users can view the parameters assigned for parameterized components by clicking on the Parameters... button in the PE Allocation dialog after a component has been allocated. In this view, parameters are read-only and are uneditable. Clicking the Ok button closes the dialog.

There are two buttons at the bottom of the PE Allocation dialog: Ok and Cancel. By clicking the Ok button, the allocation displayed in the PE Allocation dialog's allocation table is saved into the design. Clicking Cancel will abort and cancel PE Allocation. When cancelling, all modifications made to the allocation table will be lost and no data will be saved in the design. Either clicking Ok or Cancel button will close PE Allocation dialog.

Behavior mapping allows for mapping of behavior types/classes in the design onto allocated PEs, i.e. behavior mapping information is stored as annotations at the behavior classes in the design. In order to be able to map a behavior onto a PE, the PE out of the database must allow execution of arbitrary code on it (Proc feature in PE Allocation and PE Selection dialogs, see Section 4.5.1).

Users can explicitly map every behavior type on a PE. Explicit mapping will map all instances of that behavior onto the selected PE. If instances should be mapped to different PEs, selected instances have to be isolated first (see Section 4.4.3).

If a behavior is not mapped to any PE, all of its instances will be implicitly (and recursively) mapped onto the same PE as the parent behavior class in which they are instantiated in. If different instances are implicitly mapped to different PEs, appropriate copies of the behavior in each PE will be automatically generated during refinement.

Note that user must map all the behaviors under the top-level behavior to PEs either implicitly (by mapping the top-level behavior itself) or explicitly.

Variable mapping allows for mapping of variable instances in the design into local memories of allocated regular PEs or into allocated global, shared memory PEs. Variable mapping information is stored as annotations attached to variable definitions inside a behavior class. As a result, multiple incarnations of the same variable in different instances of the parent behavior will all share the same mapping information.

If a variable is not explicitly mapped by the user, during refinement a local copy of the variable will be created in each PE accessing the variable. Refinement will also automatically insert necessary code (additional behaviors inside PEs and channels between PEs) for synchronization and message passing to keep copies updated and synchronized such that shared semantics are preserved. Implicit mapping is not supported for variables that are shared among concurrent behaviors mapped to different PEs.

If a variable is explicitly mapped into local memory of a regular PE or into a shared, global memory PE, all of its incarnations will be moved there and other PEs will access the variable through a memory interface. Explicit mapping of variables is only supported for target PEs out of the database that support external accesses via a memory interface (Mem feature in PE Allocation and PE Selection dialogs, see Section 4.5.1).

Channel mapping allows for mapping of complex channel instances (of c_queue or c_semaphore type) in the specification onto PEs in the allocated target architecture. Channel mapping information is stored as annotations attached to channel instantiations inside a behavior class. As a result, multiple incarnations of the same channel (instance) in different instances of the parent behavior will all share the same mapping information.

If a complex channel (instance) is explicitly mapped to a PE, implementations for all of its incarnations will be generated in that PE during refinement. If a complex channel (instance) is not explicitly mapped, implementations for each of its incarnations will be generated in the PE the parent behavior of that incarnation is mapped to. In both cases, other PEs accessing the channel incarnation will communicate with the target PE the channel incarnation is implemented in through additional automatically inserted simple channels.

In order to be able to map a channel onto a PE, the PE out of the database must allow execution of arbitrary code on it. (Proc feature in PE Allocation and PE Selection dialogs, see Section 4.5.1).

Behavior refinement introduces PE behaviors from the database, groups the original behaviors under the new PEs, and inserts synchronization and message passing to preserve execution semantics.

Variable refinement (re-)distributes variables into PEs, generates necessary PE memory interfaces, and updates accesses to shared variables inside leaf behaviors.

By checking or unchecking the Separate variable interfaces checkbox, users can select whether during variable refinement of memory-mapped I/O a separate memory interface is generated for each variable mapped to a synthesizable hardware PE (such that distinct base addresses can later be assigned to each variable/interface, see Section 4.7.1). If unchecked, a single, combined interface is generated for all variables mapped to a PE.

Channel refinement generates implementations of complex channels inside PEs, creates adapters for accesses to complex channel implementations, and inserts necessary simple channels in between.