Individual Participation

A geração do projeto hardware tem como finalidade a geração dos ficheiros relacio- nados com a parte hardware do projeto. Para isso recorreu-se à ferramenta Vivado IDE já referida no capítulo anterior. Com esta ferramenta é possível ter o controlo do projeto, abranger todas as fases que envolvem um projeto desta natureza. A geração do projecto hardware foi dividida em duas partes: 1. Geração dos ficheiros de simulação que permitem a comunicação dos periféricos com barramento virtual QEMU; 2. Criação de um projeto Hw no Vivado IDE, com o objetivo de criar um projeto e inserir todos os ficheiros e configurações necessárias ao desenvolvimento de um design definido pelo utilizador.

Neste caso foi escolhido o barramento virtual QEMU para fazer a comunicação com a ferramenta de simulação software, podendo assim ir de encontro a um dos objetivos da presente dissertação, dar suporte a ambiente de co-simulação de um sistema hardware/software. Mas, ao dividir esta tarefa em duas partes, permite que a framework possa dar suporte a outros barramentos, tais como o Advanced eXtensible Interface (AXI), Processor Local Bus (PLB), Device Control Register (DCR), entre outros.

Geração dos Ficheiros de Simulação

Para que a componente de hardware do projecto possa interagir com a plataforma de simulação de software recorreu-se ao wrapper que permite conectar os IP ao bar- ramento virtual QEMU, o que possibilita transações com a plataforma de software simulada no QEMU.

Na integra este wrapper é composto por um bloco de registos que representam as entradas e saídas do IP, sendo assim uma forma simples do barramento poder ace- der aos dados do IP. Para que este acesso seja possível é necessário ter um bloco de controlo que coordene o acesso aos registos e ao mesmo tempo controle o pro- cessamento do IP. Deste modo é possível ter um interface genérico de comunicação com todos os IP. O modelo do wrapper é representado na figura 3.24.

Todos os IP presentes no repositório que seguem o modelo de threads são compa- tíveis com barramento. Contudo é necessário diferenciar quais os IP que seguem o modelo de threads descrito anteriormente. Sendo necessário criar um modelo descritivo para este tipo de interface. Por isso recorreu-se a dois top-elements

Figura 3.24: Modelo geral do Wrapper

do standard IP-XACT o busDefinition e o abstractDefinition. Estes top-elements permitem descrever interfaces como por exemplo o AXI, PLB, DCR entre outros. Neste caso foi criado um modelo descritivo do barramento do QEMU. Como cada modelo descritivo de cada IP permite referenciar no seu modelo de meta-dados os interfaces com que é compatível é possível saber quais os IP compatíveis com o barramento QEMU.

Posto isto, para que os IP instanciados em hardware possam comunicar com a plataforma de software é necessário que a framework gere as ligações do IP ao

wrapper que permite a comunicação com o barramento QEMU. Assim sendo cada

IP irá ter o seu próprio wrapper e além disso, irá ser necessário um ficheiro top-

level que regista os wrappers criados no barramento QEMU. Estes dois ficheiros

irão estar presentes no repositório com seu comportamento pré-definido. Cabe à

framework copiar este ficheiros para a pasta do projecto e gerar todas as ligações

e instanciações nos ficheiros através dos meta-dados.

O fluxograma da figura 3.25 representa a abordagem seguida para geração das ligações dos IP ao wrapper assim como o registo dos wrappers no ficheiro top-level.

Essa geração começa pela cópia do ficheiro top-level que permite registar os wrap-

pers no barramento para a pasta do projeto. Posto isto, é procurado o primeiro

periférico definido em hardware no design. Encontrado esse periférico é copiado um wrapper para a pasta do projecto com o mesmo nome de instanciação do pe- riférico, sendo assim possível distinguir os vários wrappers no caso de múltiplas

Figura 3.25: Fluxograma de geração do wrapper Qemu

instanciações do mesmo IP em hardware. Copiado o ficheiro, são adicionados os campos necessários ao correcto funcionamento do IP, como o nome de instancia- ção, endereço em que o IP está mapeado, número de interrupções e mapeamento das interrupções além disso é registado o periférico no ficheiro top-level. Concluí- das a edição das configurações gerais do IP no wrapper, os portos do periférico são iterados sendo assim possível gerar a sua instanciação no wrapper assim como a declaração dos sinais de entrado e saída do periférico. A próxima etapa é ligar os sinais do periférico aos sinais do wrapper possibilitando assim a comunicação do IP com o barramento QEMU. Através da metainformação dos IP é possível gerar de uma forma automática estas ligações. O mapeamento dessas ligações está explicito no fluxograma presente no apêndice B.

Geração do projecto Hw no Vivado IDE

Criados todos os ficheiros necessários à integração dos IP no barramento QEMU é necessário a criação de um projecto no Vivado IDE, assim é possível compilar todos os ficheiros e lançar a simulação no ModelSim. Além disso o designer pode interagir com o projeto no modo project mode usufruindo de todas as funcionali- dades do Vivado IDE. Para a criação do projeto recorreu-se ao modo non-project

mode do Vivado IDE, conseguindo assim configurar e acrescentar todos os fichei-

O primeiro ficheiro será o ficheiro responsável pela criação e configuração do pro- jeto. O segundo ficheiro será responsável por lançar a simulação. O fluxograma da figura 3.26 traduz o comportamento da geração dos ficheiros Tcl.

Figura 3.26: Fluxograma de geração do projeto Vivado IDE

A geração do primeiro Tcl srcipt começa pela geração dos comandos responsáveis pela criação do projeto indicando a pasta do projeto, assim como, a referência do FPGA. De seguida, são iterados os elementos em hardware do design e adiciona- dos os seus ficheiros HDL ao projeto, assim como o wrapper de cada IP gerado na etapa anterior. Adicionados todos os ficheiros, ainda é adicionado o ficheiro

top-level de simulação que permite registar no barramento Qemu todos os IP in-

tegrantes do projeto. Posto isto, são importados todos os ficheiros para a pasta do projeto para ser possível editar os ficheiros sem alterar os originais. De seguida é configurado como plataforma de simulação do HDL o ModelSim e compiladas todas as suas bibliotecas. Para finalizar o Tcl srcipt de configuração do projeto é necessário verificar se existe algum IP pertencente ao repositório do Vivado IDE caso exista, é necessário configurar esse IP para as configurações do projeto atual. Por último, é criado um novo ficheiro Tcl srcipt que tem como única finalidade lançar a simulação.