4.7. Communication Synthesis

Communication Synthesis is the main task of the Communication Synthesizer tool. Communication synthesis deals with the process of implementing point-to-point communication channels between PEs and CEs in a network model over actual busses and bus protocols in order to generate a respective communication model for the design. Communication synthesis therefore helps designers to determine the communication details on each bus and to generate a Transaction-Level or Communication Model. Specifically, Communication Synthesis consists of four tasks:

  1. Bus Parameter Assignment to assign the parameters to the communication performed over each bus in the system (see Section 4.7.1).

  2. Communication Refinement to automatically generate a Transaction-Level or Communication Model from the given Network Model based on the decisions made during Bus Parameter Assignment (see Section 4.7.2).

In order to perform Communication Synthesis, not all the tasks described above need to be done. However, some tasks must be executed and must be executed in a certain order. These mandatory tasks and their execution sequence are:

  1. Project Creation or Project Opening.

  2. Preferences Editing and Project Settings Editing.

  3. File Opening.

  4. Design Adding.

  5. Bus Parameter Assignment.

  6. Communication Refinement.

  7. Project Saving and/or CS Exiting.

Note that steps 5 and 6 can be performed repeatedly in a loop in order to generate multiple candidate communication design models in one CS session.

4.7.1. Bus Parameter Assignment

The network model defines the sets of logical point-to-point communication channels between PEs and CEs to be implemented over each bus segment in the system. In order to implement data transfers and synchronization associated with these logical point-to-point communication channels over the actual busses, users need to assign distinct physical bus addresses, data transfer modes and distinct synchronization methods to each channel as needed.

In general, multiple slaves and multiple masters can be connected to and communicating over each bus protocol. Any kind of data transfer between communication partners requires assignment of a corresponding bus address and a data transfer mode. In order to distinguish channels going over the same bus, each channel has to be assigned a separate addresses. One-way synchronization from master to slave is inherent in any data transfer. Master-to-slave synchronization without data is implemented as a special transfer also requiring a distinct address (but always using the default transfer mode) for setting a slave flag. On the other hand, interrupt lines or polling are supported for synchronization from slave to master. Interrupts can be shared among channels. In this case, an additional distinct address is required for each shared channel to support querying of the slave status on interrupt. Similarly, if synchronization without interrupts through polling is selected for a channel, an additional distinct polling address needs to be assigned. For busses that do not distinguish between masters and slaves, nodes can also be synchronized via special message data transfers. In this case, an additional distinct synchronization address needs to be supplied. In all cases, synchronization or polling transfers are always implemented using the default bus transfer mode, i.e. they do not require a mode assignment.

The network model can contain double-handshake channels, queue channels, single-handshake channels and PE memory interfaces mapped to each bus [4]. Since double-handshake and queue channels require link data transfers and synchronization, they need to be assigned one address, one link transfer mode and one synchronization method each. Singe-handshake channels only require one-way synchronization with no data transfer. Depending on their direction, they need to be assigned either one address (from master to slave) or one synchronization method (from slave to master). Memory interfaces require a contiguous block of memory data transfers each with a size determined by the network model. During communication synthesis, a base address and a memory transfer mode needs to be assigned to each memory interface which in turn will determine the range of addresses occupied and the data transfer mode used by the memory interface on the respective bus. In all cases, corresponding address, mode, interrupt and polling assignments are stored as annotations attached to memory interfaces and channel instances inside the top-level behavior of the design.

Busses are taken out of the bus database during Communication Synthesis. Each bus in the database defines the range of addresses, the link and memory transfer modes, and the set of interrupt lines it can support [7]. During Bus Parameter Assignment, users can choose parameters for each channel freely out of the set of supported addresses, modes and interrupt lines. However, database models for each PE and CE connected to the bus can define ranges of addresses on the bus reserved for PE- or CE-internal use. During Bus Parameter Assignment, the user is restricted from selecting any of those reserved addresses. For example, CPUs can define restricted addresses on their busses reserved for CPU-internal accesses to its local memory or interrupt controller. Also, bus slave interfaces of bridges will always reserve the complete range of master side addresses mapped into the slave side.

Figure 4-27. Bus Parameter dialog.

Operation: In order to assign addresses and synchronization, users can pop up the Bus Parameter dialog by selecting Main::Synthesis->Assign Link Parameters. As a result, the current address, mode, interrupt and polling assignments are read from the design and shown in the dialog. In case of errors reading the parameters from the design (e.g. wrong annotation table format), assignments in error are discarded silently.

The Bus Parameter dialog is shown in Figure 4-27. The dialog contains a number of tabs, one for each bus protocol in the system where the name of a tab is determined by the name of its bus and bus protocol. If a bus contains only a single protocol, only the bus name will be displayed. Clicking on a tab at the top of the dialog will raise and show the corresponding tab in the front.

Each tab contains a table with five columns: Channel, Start Address, End Address, Mode, Interrupt, and Period. The Channel column shows the name of each channel, interface or PE/CE. The columns Start Address and End Address show the range of addresses assigned to each channel, interface or PE/CE in hexadecimal format. For busses that do not support addressing (e.g. point-to-point busses), both address columns will be disabled. The Mode column shows the data transfer mode selected for each item. If the bus does not support any modes other than the default, regular transfer mode, the Mode column will be disabled. The Interrupt column shows the name of the bus interrupt line assigned to a channel. If polling is selected for a channel, the Interrupt column will show ``(poll)'' and the Period column will show the associated polling period (in ms). If a bus has built-in synchronization and does not require interrupts, the Interrupt and Period columns will not be shown. If the bus does not support polling (i.e. does not support memory-type accesses), the Polling column will not be shown and the polling option will not be available as a synchronization method. Finally, if a bus does neither support interrupts nor polling (but would require synchronization, i.e. has no built-in synchronization), the Interrupt column will be shown but will be disabled.

The table lists all channels, memory interfaces and PEs/CEs on the corresponding bus. Note that end address are always determined automatically. For items that do not require them, address, mode or interrupt fields are marked as ``(n/a)'' (not applicable) and can not be changed (i.e. are disabled). Channel and PE/CE address fields can be empty if no address is available or reserved. For PEs or CEs that reserve addresses, their address space will be listed and the address fields will be disabled (i.e. can not be changed). If the mode field is empty, the default transfer mode is selected. The interrupt field can be empty if no interrupt line or polling is necessary. The period field is empty if polling is not selected, i.e. if an interrupt is assigned. Both are always not required and disabled for memory interfaces and PEs. The list of channels, memory interfaces and PEs/CEs can be sorted by any column and in ascending or descending order each by clicking into the corresponding column header. By default, the list is sorted by ascending start addresses.

For Bus Parameter Assignment, users can perform the following actions in the dialog:

Address Assignment

Users can assign start (base) addresses to channels and memory interfaces in the list. In order to assign addresses, users click into the Start Address column for the respective channel or interface. The dialog will prevent editing and ignore column clicks for PEs/CEs and for channels that do not require an address or if the address columns are disabled. Otherwise, clicking will open a text edit box in place to allow entering of the desired address in hexadecimal format directly in the cell. The user can abort editing by pressing the Esc key. Pressing Enter accepts the entered text and assigns the new address to the channel/interface.

Entering a new address will automatically update the End Address column for the corresponding channel/interface (for channels, the end address is determined by the amount of addresses the channel requires, i.e. the end address is equal to the start address plus number of additional synchronization or polling addresses; for memories, the end address is equal to start address plus memory size).

If the user assigns an address that is outside of the address range allowed for the channel (based on the address range of the PE/CE on the channel's slave side), the channel's addresses will be drawn in bold text in the dialog. If the user assigns an address that is already used by another channel, interface or PE/CE to any of the channels or interfaces, the conflicting entries will be highlighted (using red text color) in the corresponding cells of the Bus Parameter dialog.

In addition to manual address assignment on an item per item basis, addresses can be automatically assigned to all channels and interfaces. Automatic address assignment is based on base address ranges specified for the PE/CE on the channel's slave side (see Section 4.6.1). Using slave address ranges, all channels and interfaces that connect to the same slave PE/CE can be automatically assigned consecutive addresses within the allowed range starting from the slave's base address. Right-clicking onto an item in the bus parameter dialog will pop up a context menu with the following entries:

Clear address

Selecting Clear address will remove the address currently assigned to the item. The menu entry is disabled (greyed out) for items that do not have any address assigned or that do not allow or require address assignment.

Clear all addresses

Selecting Clear all address will remove all addresses currently assigned to any item in the dialog.

Autofill address

Selecting Autofill address will automatically assign a distinct, unique, non-overlapping address to the item within its allowed range. The menu entry is disabled (greyed out) for items that do not allow or require address assignment. If the item already has an address assigned, a dialog will be popped up first querying the user whether to overwrite the existing address. If no valid address could be found, a corresponding Error dialog is popped up and the automatic address assignment is aborted.

Autofill all addresses

Selecting Autofill all addresses will automatically assign distinct, unique, non-overlapping addresses within allowed ranges to all items in the dialog that require an address but do not have any address assigned already. If there are items with invalid (out of range or overlapping) addresses, a dialog is popped up to query the user whether to also overwrite and automatically assign valid addresses to those items. If for any item no valid address could be found, a corresponding Error dialog is popped up and the automatic address assignment for that item is aborted.

Mode Assignment

Users can assign the mode used for data transfers of channels or memory interfaces by clicking into the Mode column for the respective item. The dialog will ignore clicks if the column is disabled, if the PE/CE or channel does not require data transfers, or if the bus does not support the type of (memory or link) data transfer needed by the item (PE/CE or channel, respectively). Otherwise, clicking will open a drop-down combo box in place of the cell with entries for all possible transfer modes supported by the bus. Depending on whether the item is a PE/CE or channel, the combo box will only list the modes that are supported by the bus for memory or for link transfers, respectively. For synchronization-only, single-handshake channels, only the default transfer mode will be listed and available for selection in any case.

Interrupt and Polling Assignment

Users can assign interrupts to certain channels in the list by clicking into the Interrupt column of the respective channel. Clicking into the Interrupt column if it is disabled or for memory interfaces, PEs/CEs or channels that do not require synchronization will be ignored. Otherwise, clicking will open a drop-down combo box in place of the cell with entries for all possible interrupt lines supported by the bus. If the bus does not support interrupt sharing (i.e. does not support memory-type transfers for slave polling) the combo box will only list unused interrupts. In addition, the combo box optionally contains an empty and a ``(poll)'' entry to select synchronization via data messages or polling, respectively, if supported by the bus. Hence, in the combo box users can choose and select the synchronization method to assign to the channel. Note that changing the interrupt selection may influence the number of addresses required for a channel. Therefore, any changes in interrupts might trigger updates of the End Address column or might enable that a previously unneeded Start Address becomes required.

If ``(poll)'' is selected for a channel, the user can click into the Period column to open a text edit box in place that allows entering of the desired polling period (in ms) directly in the cell. The user can abort editing by pressing the Esc key. Pressing Enter accepts the entered text and assigns the new polling period to the channel.

There are two buttons at the bottom of the Bus Parameter dialog: Ok and Cancel. By clicking the Ok button, the assigned bus parameters are saved into the design. If users click the Cancel button, the Bus Parameter Assignment task will be cancelled. Either clicking Ok or Cancel buttons will close the Bus Parameter dialog.

Error/Information Messages: When entering a new address, the Bus Parameter dialog performs validation of the entered text to ensure that it is in correct hexadecimal format and within range of supported bus addresses. In case of errors, a corresponding Error dialog is popped up and address editing eventually resumed.

When clicking the Ok button in the dialog, address and interrupt assignments are validated for conflicts. If there are conflicting/overlapping assignments, an Information dialog is popped up querying the user whether he is sure to commit the changes. If the user declines, he will be returned to the Bus Parameter dialog. If the user accepts (or if there are no conflicts in the first place), address and interrupt assignments annotations are written back into the design. If an error writing the annotations occurs, a corresponding Error dialog is popped up and the Bus Parameter Assignment aborted.

4.7.2. Communication Refinement

Communication Refinement executes the implementation decisions made in the other Communication Synthesis tasks by refining the current Network Model into an automatically generated Transaction-Level or Communication Model based on and reflecting the decision made during Bus Parameter Assignment.

Figure 4-28. Communication Refinement dialog.

Operation: In order to do refinement, users can select the Main::Synthesis->Communication Refinement menu entry to pop up the Communication Refinement dialog. The the Communication Refinement dialog is shown in Figure 4-28.

In the Communication Refinement dialog, users can select what type of output model should be produced by the architecture refinement process. By selecting the corresponding radio button, the type of refined output model can be decided. By default, a final pin-accurate communication model will be generated. The two possible outputs of communication refinement are:

  1. Transaction-Level Model which generates a TLM in which bus pins and wires are abstracted away to the level of complete bus transactions.

  2. Pin-Accurate Model which generates a complete, pin-accurate, bus-functional communication model at the output.

Optionally, communication refinement supports optimization of the generated output code. Specifically, optimizations apply to the protocol stacks generated inside the PEs for external bus communication. The purpose of optional protocol stack manipulation is to produce code that is optimized for further hardware or software synthesis in the backend tools. By default, optimizations are enabled. The optimizations that can be enabled or disabled during communication refinement are:

Flattening and interrupt hoisting

which automatically inlines communication code into the existing network protocol code and therefore produces a completely flattened final protocol stack; furthermore, in order to reduce synchronization resource requirements, hoists, moves and consolidates all synchronization code to only synchronize communication partners once at the very beginning of a complete message transfer.

Optionally, communication refinement can produce an additional, auxiliary file on disk which summarizes the mapping of specification-level objects down to implementation-level addresses and interrupts used on the system busses. By selecting the corresponding check box, a text file with such a table in comma-separated value (CSV) format will be generated. The user can choose the name and location of the output file in the associated line edit field.

User can then start the communication refinement process by clicking the Start button. If users click the Cancel button, the Communication Refinement operation will be aborted and cancelled. Either clicking Start or Cancel buttons will close the Communication Refinement dialog.

After clicking the Start button, the communication refinement command line components of the Communication Synthesizer will be executed in the background. Any diagnostic, status and informative output of the communication refinement tools will be shown in the Refinement tab of the Output Window (Output::Refine).

When the communication refinement process is finished, the newly generated transaction-level or communication models are automatically opened and loaded, and corresponding new Design Windows are created in the Workspace. The new Design Windows are automatically activated and raised to the front. In addition, the new models are automatically added to the current project (see Design Adding, Section 4.2.5) as a child of the specification model they were generated from.

While the architecture refinement background tools are running, the majority of the main CS GUI is disabled. However, users can abort/kill execution of the background tools by selecting Main::Synthesis-> Stop. After clicking, the current communication refinement background task is aborted.

Error/Information Messages. While the communication refinement tool is running, informational (e.g. progress and status reports) and error messages generated by the background tool are displayed in the Output::Refine tab of the Output Window.

If the communication refinement background tools abort with an error or are killed via the Main::Synthesis-> Stop menu entry, a corresponding error message will be shown in Output::Refine and an Error dialog will pop up. Upon confirming the error, the remainder of the Communication Refinement Operation will be cancelled.

Specifically, the communication refinement background tools check for and can produce the following classes of errors:

If an error can be attributed to a specific location in the input design model, the file name and line number of the corresponding SpecC source code input will be shown as part of the error message.

Finally, if the design the new models were generated from is not in the project, the new models are not added to the project and an Error dialog to that effect will be popped up.