Para contornar o gargalo de simulação de sistemas complexos, o trabalho de Krause et al. [8] propõe a utilização de um modelo de RTOS em SystemC integrado ao ISS, de tal forma que o software executa no ISS integrado com o modelo de RTOS, descrito em nível de sistema. Desta forma, ocorre uma drás- tica redução no tempo de simulação, uma vez que todas as funções do RTOS são executadas pelo sistema nativo, deixando para o ISS apenas as funções da aplicação propriamente ditas.
3.2.2.1 Fluxo de Desenvolvimento
O fluxo de desenvolvimento consiste em combinar o modelo de RTOS com ISS em modelo em nível de transação ou Transaction Level Model (TLM), como pode ser visto na figura 33, terceirizando todas as funções de escalonamento para o modelo de RTOS em SystemC, de mais alto nível e execução mais rá- pida.
SystemC RTOS model SystemC scheduler model
t 3 t 2 t 1
ISS thread 2
SystemC - ISS wrapper RAM thread 1 thread 3 stack heap I/O CPU reg. CPU reg. thread switch
Figura 33: Arquitetura proposta de Krause et al. [8]
Ambos os ambientes de simulação, o ISS e o modelo RTOS, efetuam a troca de dados, como informações sobre escalonamento de tarefas (thread switch) e sua sincronização. Cada aplicação possui sua memória e registradores se- parados, permitindo que durante a troca de tarefa seja necessário somente trocar os ponteiros (stack, heap, CPU reg).
SystemC wrapper start simulation start simulation RTOS model calculate new schedule send new schedule start simulation receive schedule ISS 3 ISS 2 ISS 1 sim_main schedule core 0 thread name run n cycles schedule core 1 thread name run n cycles Namespace: ISS_Simulation Schedule_info +_core_name : string +_thread_name : string + _run_for : unsigned int Schedule_info( core_name : string,
thread_name : string, run_for : unsigned int)
Figura 34: Modelo de simulação de Krause et al. [8]
No modelo de simulação completo, detalhado na figura 34, toda a pla- taforma em SystemC pode ser observada, com seu modelo de RTOS (RTOS model) e o envoltório para o ISS (wrapper), além das estruturas de dados de comunicação entre eles, contendo as informações de escalonamento para cada núcleo de processamento utilizado.
3.2.2.2 Resultados
Para avaliar a proposta híbrida, foram utilizados o ISS Simplescalar, com conjunto de instruções ARM e o sistema operacional de tempo real RTEMS. Nas análises teóricas, a melhoria que desempenho (MD) é calculada pela pro- porção de tempo de simulação do RTOS no ISS (TSRTOS) dividido pelo tempo
de simulação do modelo RTOS proposto (TSMODELO), como pode ser visto na
equação 3.1. O TSRTOS é definido pela soma do tempo de execução do pro-
grama (P), do tempo ocioso (O) e do tempo de execução do RTOS (ERTOS), já
o TSMODELO é a soma do tempo do programa (P) e do tempo de execução do
modelo do RTOS (EMODELO).
MD= TSRTOS
TSMODELO =
P+ O + ERTOS
P+ EMODELO
(3.1)
Nos resultados experimentais, a precisão foi medida utilizando ciclos de relógio, utilizando a execução totalmente baseada em ISS como referência, e as políticas de escalonamento usadas foram: round robin (RR) e priority-based rate monotonic (RMS). Foram utilizadas duas aplicações com as duas políticas
de escalonamento, sendo verificado o comportamento dos simuladores de acordo com o número de troca de tarefas realizadas.
Tabela 9: Desempenho e precisão de Krause et al. [8]
Simplescalar ISS Modelo RTOS Desempenho Erro
9129936 9130679 1,8836x 0,0081%
9152704 9153444 1,8876x 0,0081%
9390271 9389517 1,9364x 0,0080%
11778182 11764153 2,4010x 0,1191%
22395341 22337821 4,3403x 0,2568%
Os resultados obtidos na tabela 9, tem os tempos de simulação calculados em número de ciclos de relógio, dos quais serão feitos o cálculo da melho- ria de desempenho e da taxa de erro obtidas. Quanto mais troca de tarefas ocorrem, mais o sistema operacional é requisitado e consequentemente con- some mais tempo de simulação, sendo por isto que quando mais ciclos de simulação são realizados, maior é a melhoria de desempenho oferecida.
3.2.2.3 Contextualização
Com a forte motivação de melhorar o desempenho de simulação de sis- temas, o trabalho de Krause et al. [8] segue uma linha híbrida de simulação combinando o tradicional modelo ISS com um modelo abstrato de RTOS, in- tegrados em um ambiente virtual de simulação. Em sua abordagem o mo- delo ISS possui uma interface para o modelo de RTOS, assim delegando todo o comportamento referente ao SO para o modelo e desta forma reduzindo a quantidade de código executado no ISS.
Dentre os objetivos listados, o suporte para HdS é efetivo pelo uso de mode- los baseados em ISS, mas o desempenho alcançado por Krause et al. [8] está abaixo do que se espera atingir em uma simulação nativa. Apesar de abs- trair parte significativa do software do ISS, o trabalho de Krause et al. [8] ainda concentra no ISS todo o HdS e suas funcionalidades, conseguindo excelentes taxas de erro, mas com melhorias de desempenho modestas.
3.3
Geração de Software da Síntese de Modelos
Neste paradigma, a estratégia adotada busca a criação de modelos exe- cutáveis com alto nível de abstração, utilizando linguagens de projeto em ní- vel de sistema ou System Level Design Language (SLDL) para implementar o comportamento esperado. Existem algumas opções de linguagens disponí- veis, normalmente focadas em resolver problemas específicos, mas para fins de exemplificação, pode-se citar a linguagem SystemC [31], que permite di- versas modelagens para simulação de sistemas e plataformas.
Hardware Software
System Model High-level Synthesis
Figura 35: Fluxo de geração de software
Para permitir o uso destes modelos, são criadas ferramentas que permi- tem o seu refinamento em implementações de hardware e software. Cada trabalho possui suas peculiaridades, mas de maneira genérica, um compila- dor de sistema é construído para processar estas descrições criadas em SLDL, realizando passos intermediários, que são realizados por ferramentas (fluxo sim- plificado na figura 35), e, por fim, o software ou parte dele é gerado automa- ticamente, refletindo o comportamento de sua especificação de alto nível.