Nas abordagens de simulação nativa (host-compiled) mais recentes os mo- delos têm sido desenvolvidos com mecanismos precisos de tempo de execu- ção. A estratégia utilizada consiste em instrumentar o código que será execu- tado nativamente com informações de tempo que irão determinar os atrasos de cada trecho do código. No trabalho de Razaghi et al. [4] é proposto a eli- minação do compromisso entre desempenho e precisão de tempo estimado, utilizando execução de software nativa. Para tanto, é proposto um meca- nismo de ajuste automático e dinâmico de granularidade de tempo que per- mite a eliminação dos erros de temporização e mantém o alto desempenho da simulação, de aproximadamente 900 MIPS.
3.1.4.1 Fluxo de Desenvolvimento
A estratégia proposta consiste na utilização de simulador nativo de soft- ware em alto nível de abstração, organizado em camadas bem definidas, como está ilustrado na figura 24. Nesta arquitetura, estão dispostas 5 cama- das para execução nativa do sistema:
• Aplicação (Application): consiste de processos concorrentes e sequen- ciais descritos em uma SLDL, se comunicando uns com os outros através de canais abstratos da SLDL. Para integração desta aplicação com o sis- tema é utilizada uma interface genérica de SO provida pelo modelo de
OS Scheduler Dispatch ReadyQueue SLDL Intr. Handler T3 T2 T1 CH Application HAL TLM I/O Drv Intr. Task I/OIF Intr. IF
Figura 24: Arquitetura do simulador nativo de Razaghi et al. [4]
sistema operacional;
• Sistema Operacional (OS): faz a replicação de uma típica estrutura de SO, como forma de permitir e gerenciar a execução de uma aplicação de múltiplas tarefas. Este modelo escalona, enfileira, despacha e exe- cuta a aplicação e suas tarefas de interrupção, seguindo as políticas de escalonamento definidas;
• Camada de Abstração de Hardware (HAL): esta camada inclui todos os gerenciadores de entrada e saída de dispositivos, além de implemen- tar um mecanismo abstrato de gerenciamento de interrupção. Quando uma interrupção é capturada pela camada TLM, a camada HAL sus- pende a execução da aplicação e permite que a tarefa de tratamento seja iniciada pelo SO;
• Comunicação em Nível de Transação (TLM): permite que seja realizada a comunicação, através de transações, entre o sistema e a plataforma virtual, definindo as interfaces pelas quais podem ser realizadas entradas e saída, além das requisições de interrupção da plataforma;
• Linguagem de Descrição em Nível de Sistema (SLDL): funciona como in- fraestrutura básica, tanto para o sistema como para a plataforma, permi- tindo que as simulações sejam executadas com noção de tempo simu- lado e diversos construtores possam ser aplicados em todas as camadas superiores.
Com as técnicas propostas para controle de tempo é possibilitado que o núcleo do SO permita que uma tarefa execute e faça o acumulo de atrasos,
sem chamar o escalonador ou avançar o tempo de simulação. Este recurso permite que mesmo em alta granularidade de tempo, o desempenho não seja prejudicado. Isto ocorre basicamente pelo fato de cada tarefa ter seu próprio controle do tempo que precisa ser simulado e este tempo só é de fato contabilizado quando a preempção da tarefa é atingida.
3.1.4.2 Resultados
Para obtenção dos resultados experimentais, foi aplicada a SLDL SpecC e o modelo de RTOS em uma aplicação telefonia móvel de porte industrial. Esta plataforma é baseada na arquitetura ARM7 e o sistema em questão desem- penha funções concorrentes de decodificação de MP3, de codificação de JPEG e de tarefas de controle.
Tabela 4: Comparativo de simulação de RTOS de Razaghi et al. [4]
Métrica RTOS 1 us RTOS 10 us RTOS 100 us RTOS 1000 us Erro (MP3) 0,73% 0,79% 1,40% 9,65% Erro (JPEG) 7,33% 7,33% 7,33% 7,35% Erro (MP3 + JPEG) 4,18% 4,20% 4,49% 8,45%
Desempenho 340 MIPS 790 MIPS 930 MIPS 1080 MIPS
Tempo de Execução 0,61s 0,26s 0,22s 0,19s
Na tabela 4 são exibidos os resultados de erro médio, desempenho e tempo de execução considerando um modelo de sistema de RTOS, sem as técnicas propostas. São definidos 4 níveis de granularidade, variando de 1 até 1000 us, e conforme esperado, quanto maior a granularidade de tempo utilizada, maior o desempenho obtido. Entretanto, conforme também previsões, a me- dida que são utilizados passos maiores de tempo, o erro tende a ser majorado.
Tabela 5: Comparativo de simulação de ATGA de Razaghi et al. [4]
Métrica ATGA 1 us ATGA/Acc 1 us ATGA Evento ATGA/Acc Evento Erro (MP3) 0,73% 0,74% 0,73% 0,74% Erro (JPEG) 7,33% 7,32% 7,33% 7,32% Erro (MP3 + JPEG) 4,18% 4,18% 4,18% 4,18%
Desempenho 554 MIPS 684 MIPS 621 MIPS 892 MIPS
Tempo de Execução 0,37s 0,30s 0,33s 0,23s
automaticamente (ATGA), também são feitos 4 tipos de experimentos com granularidade de 1 us e baseado em evento, além de considerar a técnica de acumulação de tempo (Acc), conforme por ser visto na tabela 5. É impor- tante perceber que com a mesma granularidade mínima de 1 us e baseando em técnicas de acumulação de tempo ou por eventos, houve uma estabiliza- ção do erro médio em todos os casos.
3.1.4.3 Contextualização
O trabalho de Razaghi el al está dedicado a apresentar um conjunto de técnicas para controle automático de granularidade de tempo (ATGA), com o objetivo principal de melhorar o desempenho obtido e manter uma alta resolução de granularidade. Tudo isto aplicado em um contexto de simulação nativa (host-compiled), proporcionado pelo uso de SLDL para construção dos modelos e inclusive do próprio software.
Contextualizando o trabalho de Razaghi et al. [4] com os objetivos propos- tos, é notório como é relevante a necessidade de utilizar modelos de alto nível para atender as demandas de sistemas cada vez mais complexos. Porém, nos objetivos traçados se procura definir um modelo que abstraia a execução da implementação de software, sem utilização de modelos nem de ferramentas de síntese. Este aspecto é essencial para simulação de software em nível de sistema, com suporte para desenvolvimento de HdS, sem ter que obrigatoria- mente recorrer para complexos e lentos modelos ISS.