Power Exploration (Gerstlauer et al [5], IEEE 2012)
3.1.6 On the interfacing between QEMU and SystemC for virtual platform construction: Using DMA as a case (Yeh et al [6],
Elsevier 2012)
A co-simulação de componentes de hardware e de software em um ambi- ente de plataforma virtual demanda a utilização de interfaces para o acesso de memória, para realização de operações de E/S e para o gerenciamento de interrupções. Para suportar estes requisitos, o trabalho de Yeh et al. [6] uti- liza modelos de hardware modelados na linguagem SystemC e um simulador em nível de instruções baseado no QEMU [56].
ISS interconnect and peripheral models ISS virtual platform interconnect and peripheral models ISS virtual platform OS porting
Figura 28: Plataforma convencional baseada em ISS
Em uma abordagem baseada em ISS integrado no ambiente de plata- forma virtual, ilustrada na figura 28, todos as funcionalidades da plataforma precisam ser modelados em uma SLDL para permitir que o código binário do sistema possa ser executado sem modificações ou porte do SO.
virtual platform processor
model virtual machine
OS porting
peripheral modelsinterconnect and
virtual platform virtual machine OS porting extendedvirtual platform processor model peripheral modelsinterconnect and
ISS wrapper infrastructure
interface
interconnect andexternal peripheral models
Figura 29: Plataforma baseada em máquina virtual
Ao invés de modelar todos os aspectos do sistema em um ISS, a aborda- gem de máquina virtual utilizando o QEMU realiza a tradução dinâmica do código binário da arquitetura alvo em tempo de execução para o sistema nativo de desenvolvimento. Esta tradução ocorre em nível de blocos básicos que são mapeados em uma cache de 16 MB e utilizam uma alocação fixa de registradores, além de realizar o gerenciamento de memória e o tratamento de interrupções.
3.1.6.1 Fluxo de Desenvolvimento
A utilização da abordagem proposta por Yeh et al. [6] tem como objetivo a utilização da infraestrutura do QEMU para execução do código binário do sistema sem modificações e a geração de uma interface entre o ambiente nativo do QEMU e o ambiente virtual de simulação baseado em SystemC. Para implementar a comunicação entre estes dois ambientes, é utilizada a comunicação baseada em fila unidirecional, como pode ser visto na figura 30, além de portas para acesso de instruções e de dados e de módulos para interface com a memória e para interrupção.
bus portdata instruction bus port internal memory access interfcace FIFO unidirectional SystemC QEMU
ISS wrapper & interrupt interface
··· receiver transaction transactiondispatcher transactions extractedfromQEMU packet information extractor software MMU interrupt interface memory model signal transition interrupt cascading interfaceinitialization interfaceinitialization
Figura 30: QEMU integrado em um ambiente SystemC
As principais contribuições desta organização, com relação aos demais trabalhos baseados em QEMU, está na possibilidade de utilização de dispo- sitivos mestres na plataforma, como o Acesso Direto à Memória (DMA), que facilitam o co-projeto dos modelos de hardware e dos gerenciadores de dis- positivos em um estágio precoce de desenvolvimento. Outro aspecto que está sendo explorado no trabalho é a avaliação do desempenho da arquitetura do sistema, utilizando uma versão com e sem suporte de DMA para transferência de dados.
3.1.6.2 Resultados
Nos experimentos realizados foi modelado em SystemC um módulo de DMA PrimeCell PL080 que, por não possuir gerenciador de dispositivo para Linux, pre-
cisou ser desenvolvido para realização das simulações. O ambiente virtual de simulação utiliza a plataforma Versatile/PB926EJ-S do QEMU, que é baseada na família ARM9 de processadores para execução do sistema. O desempe- nho foi avaliado de duas formas distintas: medindo o tempo de inicialização do sistema operacional Linux e analisando as informações coletadas durante o processo de inicialização.
Para obtenção dos resultados foram realizadas 30 simulações de inicializa- ção do Linux com e sem utilização de transferência de dados por DMA. Foi observado que para cada palavra transferida pelo DMA foi evitada a execu- ção de 9,05 até 12,36 instruções pelo processador, o que impediu a perda de desempenho do sistema com o DMA habilitado.
3.1.6.3 Contextualização
A proposta de Yeh et al. [6] procurou suportar o desenvolvimento inte- grado de hardware e de software através de uma abordagem de simulação semi-nativa que consiste em utilizar as instruções nativas do sistema de desen- volvimento para implementar as instruções de uma determinada arquitetura alvo, utilizando a tradução dinâmica de código em nível de blocos básicos.
O alto nível de detalhe fornecido pela emulação do QEMU permite ava- liar com precisão de instrução o comportamento do sistema, gerando uma melhoria para o estado da arte ao evitar a complexa modelagem do ISS e ao verificar precocemente o comportamento do sistema, mesmo sem ter a plataforma de hardware disponível. Entretanto, o desempenho de simulação obtido é bastante inferior com relação a outras abordagens baseadas em interpretação de instruções e em simulação compilada, basicamente pela grande quantidade de informações geradas decorrentes dos acessos à me- mória e das operações de E/S realizadas.
3.2
Modelos Híbridos de Simulação
Quando se fala em uma abordagem híbrida, é natural pensar em uma es- tratégia que combina o melhor de duas ou mais soluções. Este caso não é diferente, pois os trabalhos pesquisados particionam o sistema em uma parte
independente e em outra dependente de plataforma, buscando combinar suas melhores características. Se valendo do uso de modelos rápidos para execução da porção independente de plataforma, são obtidos ganhos de desempenho da ordem de 100 vezes, quando comparadas a estratégica que utiliza unicamente modelos baseados em ISS. A parte do sistema dependente de plataforma continua sendo simulada em um ISS e se comunica com o mo- delo rápido, de forma a manter uma baixa taxa de erro das estimativas.
Read/Write Operations Software Platform-dependent (ISS) Interruption Handling Platform-independent (Model)
Figura 31: Fluxo de uso de modelos híbridos
O fluxo de desenvolvimento é ilustrado na figura 31, onde o software é pro- cessado por um conjunto de ferramentas e particionado em duas unidades: uma dependente de plataforma, contendo o software assembly e acesso ao hardware; e outra independente de plataforma que é responsável pelas fun- cionalidades do sistema, como aplicações e tarefas de controle e escalona- mento de tarefas do sistema operacional.