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

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

58 Chapter 5<br />

the key features that <strong>de</strong>fine a dynamic scheduling behavior in<strong>de</strong>pen<strong>de</strong>nt of<br />

any specific RTOS implementation.<br />

The dynamic scheduling step in Figure 5-1 refines the unscheduled system<br />

mo<strong>de</strong>l into the final architecture mo<strong>de</strong>l. In general‚ <strong>for</strong> each PE in the system<br />

a RTOS mo<strong>de</strong>l corresponding to the selected scheduling strategy is imported<br />

from the library and instantiated in the PE. Processes insi<strong>de</strong> the PEs are<br />

converted into tasks with assigned priorities. Synchronization as part of communication<br />

between processes is refined into OS-based task synchronization.<br />

The resulting architecture mo<strong>de</strong>l consists of multiple PEs communicating via<br />

a set of busses. Each PE runs multiple tasks on top of its local RTOS mo<strong>de</strong>l<br />

instance. There<strong>for</strong>e‚ the architecture mo<strong>de</strong>l can be validated through simulation<br />

or verification to evaluate different dynamic scheduling approaches (e.g.<br />

in terms of timing) as part of system <strong>de</strong>sign space exploration.<br />

In the backend‚ each PE in the architecture mo<strong>de</strong>l is then implemented<br />

separately. Custom hardware PEs are synthesized into a RTL <strong>de</strong>scription. Bus<br />

interface implementations are synthesized in hardware and software. Finally‚<br />

software synthesis generates co<strong>de</strong> from the PE <strong>de</strong>scription of the processor<br />

in the architecture mo<strong>de</strong>l. In the process‚ services of the RTOS mo<strong>de</strong>l are<br />

mapped onto the API of a specific standard or custom RTOS. The co<strong>de</strong> is then<br />

compiled into the processor’s instruction set and linked against the RTOS<br />

libraries to produce the final executable.<br />

4. THE RTOS MODEL<br />

As mentioned previously‚ the RTOS mo<strong>de</strong>l is implemented on top of an<br />

existing SLDL kernel [8]. Figure 5-2 shows the mo<strong>de</strong>ling layers at different<br />

steps of the <strong>de</strong>sign flow. In the specification mo<strong>de</strong>l (Figure 5-2(a))‚ the<br />

application is a serial-parallel composition of SLDL processes. Processes<br />

communicate and synchronize through variables and channels. Channels are<br />

implemented using primitives provi<strong>de</strong>d by the SLDL core and are usually part<br />

of the communication library provi<strong>de</strong>d with the SLDL.

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

Saved successfully!

Ooh no, something went wrong!