ModelSim é uma ferramenta de simulação de VHDL, Verilog, SystemVerilog e
mixed-languade designs, oferecendo assim uma sólida plataforma de verificação
[8]. O ambiente do ModelSim permite a visualização do valor dos sinais simulados, independentemente da linguagem em que estes se encontram modelados. Permite também aplicar métodos de análise e debug na pós-simulação e durante a simulação [5].
Na figura 2.14 estão representados as etapas necessárias à simulação de um design no ModelSim.
Create a working library
Compile design files
Load and Run simulation
Debug results
Figura 2.14: ModelSim Design Flow [7]
A primeira etapa é a criação de uma biblioteca de trabalho, ou seja, é necessário a criação de um local de trabalho para que todos os ficheiros integrantes do de- sign sejam lá compilados. A segunda fase é a compilação dos ficheiros de design,
com recurso às biblioteca do Modelsim, sendo estas compatíveis com enumeras plataformas. Com isto é possível re-compilar o design para qualquer plataforma suportada pelo ModelSim. A terceira fase consiste em carregar para o simulador o design já compilado e correr a simulação. A última etapa designa-se de debug-
ging dos resultados, isto é, quando os resultados não são os esperados através das
funcionalidades do ModelSim é possível encontrar o problema de uma forma mais intuitiva [7].
O ModelSim permite o interface com ferramentas externas através do protocolo de comunicação Programming-Language Interface (PLI). Através das rotinas PLI que são funções descritas na linguagem de programação C, é possível ter acesso à informação da simulação. Estas funções podem ser usadas para aceder a qualquer parte do design independentemente da hierarquia em que estas se encontram. O controlo da simulação é assim possível em termos de execução, permitindo o acesso a toda informação durante a simulação assim como alterar valores durante a mesma [6].
Com intuito de poder dar suporte a um ambiente de co-simulação é desenvolvido uma biblioteca de rotinas PLI que permite a comunicação com a extensão do QEMU descrita anteriormente, de maneira a serem possíveis as transações de dados entre a componente de hardware e software. Para essa biblioteca ser utilizada é necessário usar um modelo de barramento virtual imposto pela extensão, sendo ainda necessário um wrapper para permitir a comunicação entre o barramento virtual QEMU e o IP. O modelo que permite a ligação do ModelSim à extensão do QEMU está representada na figura 2.15.
No apêndice C é explicado como foram compiladas as bibliotecas do Modelsim através do Vivado IDE para que este pudesse ser utilizado como plataforma de simulação de HDL.
Capítulo 3
Framework Design
Nesta capítulo é descrita toda a implementação de uma framework compatível com um repositório IP-XACT para um domínio especifico de aplicações. Onde é apresentada toda a sua estrutura interna, assim como, as suas suas funcionalidades.
3.1
Design Flow
Para poder tirar partido de todas as potencialidades da framework foi adotado um design flow para o desenvolvimento de projetos através da framework. Este centra-se em duas etapas do design flow hardware/software descrito no capítulo anterior: Paralelização em hardware e Validação. Através do estudo destas duas etapas foi possível identificar métricas e processos que podiam ser padronizados e automatizados diminuindo o tempo de desenvolvimento deste tipo projetos. Assim foi possível integrar diversas ferramentas na framework com intuito de automati- zar o processo de configuração de um projeto hardware/software. As ferramentas integradas na framework foram as seguintes.
1. Vivado IDE: permite criar e gerir o projeto de hardware;
2. Buildroot: permite criar toda a toolchain de software necessária à realização de um projeto desta natureza;
3. QEMU: permite fazer a verificação da componente de software do sistema;
4. ModelSim: permite fazer a verificação da componente de hardware do sis- tema;
De maneira a poder acelerar o desenvolvimento de sistemas hardware/software, foi adotado um modelo de desenho para os sistemas desenvolvidos com recurso à framework que assenta sobre um modelo de threads, conseguindo assim ter um padrão de desenho semelhante em todos os sistemas desenvolvidos pela framework o que faz com que seja possível seguir uma abordagem generativa de código. Este modelo será explicado posteriormente.
O design flow adotado pela framework encontra-se explicitado na figura 3.1. Este encontra-se dividido em três fases fases: IP Packaging, design e verificação.
Figura 3.1: Design Flow seguido pela Framework
3.1.1
IP Packaging
A primeira etapa do design flow denomina-se de IP Packaging, tendo como fina- lidade a introdução dos IP no repositório. O designer nesta fase pode introduzir todas as informações relativas ao IP no repositório, tais como, documentação, modelos de simulação, drivers e a descrição do seu comportamento. O seu com- portamento pode estar descrito em HDL ou C++.
Para que o designer possa usufruir de todas as funcionalidades da framework foi adotado um padrão de desenho para cada IP que tem como base um para-
digma de programação orientado a multithreading. Este padrão visa facilitar o co-desenvolvimento de hardware/software de um sistema que pode ser visto como um conjunto de threads com várias tipos de mapeamento tanto em hardware como em software e hardware alcançando um curto time-to-market. O modelo de dese- nho que cada IP deve seguir encontra-se explicitado posteriormente.
Este padrão adotado não invalida que o utilizador não possa inserir outro tipo de IP no repositório, mas com isso, não terá acesso a todas as funcionalidades da
framework.
3.1.2
Design
Com todos os IP necessários ao desenvolvimento de um co-design hardware/-
software específico presentes no repositório é possível ao utilizador criar um design
com os seus requisitos. Com isto, é possível escolher quais os IP que necessita para o seu design, assim como especificar a sua instanciação em hardware ou software. A framework segue uma abordagem generativa. Através desta aboradgem é possí- vel gerar todo o ambiente e ficheiros necessários ao desenvolvimento de um projeto desta natureza, assim como, drivers, wrappers, threads, toolchains, etc. Tudo isto é gerado tendo como base o modelo de metainformação IP-XACT que descreve os IP presentes no repositório. No final da geração do projeto o designer terá ao seu alcance todos os mecanismos necessários ao desenvolvimento do seu projecto.
3.1.3
Verificação
A fase de verificação pode ser uma das mais importantes e morosas do desenvolvi- mento de um projecto deste tipo. Para isso a framework dá suporte a um ambiente de simulação integrado que permite simular a parte de hardware e software em con- junto, dando suporte a um ambiente de co-simulação. Esta simulação é efetuada através do ModelSim e a integração da biblioteca de rotinas PLI que permite as transações de dados com a componente de software emulada no QEMU, fazendo uso da extensão do QEMU que permite a integração de ferramentas de simulação, já descrita no capítulo anterior.