29.01.2015 Views

Embedded Software for SoC - Grupo de Mecatrônica EESC/USP

Embedded Software for SoC - Grupo de Mecatrônica EESC/USP

Embedded Software for SoC - Grupo de Mecatrônica EESC/USP

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

Exploring SW Per<strong>for</strong>mance 101<br />

operation through a channel. Each encapsulated operation is called in two<br />

steps, the first step is the <strong>de</strong>co<strong>de</strong> phase to i<strong>de</strong>ntify the serving slave<br />

operation, and then the invocation of the operation through the channel.<br />

This invocation adds new parameters to the slave operation which configures<br />

the channel transactions to be generated. Note that a master access<br />

only addresses a single channel, and that it can invocate a subset of the<br />

operations of several slaves, so that it has its own interface which may<br />

differ from the union of the slaves interfaces and doesn’t require to be an<br />

explicit sc_interface.<br />

2.1.2. Communication refinement<br />

Defining the accesses module is very straight <strong>for</strong>ward. They follow a simple<br />

pattern. This is why our tool is able of generating the accesses co<strong>de</strong> with<br />

very little configuration in<strong>for</strong>mation once the communication channel is<br />

chosen. Figure 8-3 shows the example of accesses to a bus communication<br />

channel. It combines UML class diagrams to <strong>de</strong>scribe modules and<br />

SystemC2.0 [6] graphical notation <strong>for</strong> ports and interfaces. Furthermore a<br />

graphical notation has been introduced to stereotype the accesses modules. It<br />

can be used as a full replacement to the class diagram. Both the master and<br />

the slave accesses can be customized by a policy. In the case of the master<br />

access, this policy indicates whether the two concurrent operation calls by<br />

the master IP are serialized or have interlaced transactions within the access.<br />

The channel is in<strong>de</strong>ed only capable of managing the concurrency between<br />

master accesses, but remains a concurrency between the threads of the modules<br />

sharing a master access. The slave access policy <strong>de</strong>termines the concurrency<br />

on the operations provi<strong>de</strong>d by the slave IP. Several masters can generate<br />

several interleaved transactions to the same slave, especially when the slave<br />

splits the transactions, requiring the slave to have a customizable concurrency<br />

policy.<br />

At last, one may think of composing channels. For example, a slave IP<br />

can be first attached to a FIFO channel which master access could then become

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!