Framework compatível com repositório IP-XACT para domínio específico de aplicações

Mar celo A . C. P . e Sous a Mar celo A . C. P . e Sous a

Universidade do Minho

Escola de Engenharia

César Ulisses Cruz Monteiro

Framework compatível com Repositório

IP-XACT para o Domínio Específico de

Aplicações

Trabalho efetuado sob a orientação do

Professor Doutor Adriano José da Conceição

Tavares

Dissertação de Mestrado

Ciclo de Estudos Integrados Conducentes ao Grau de Mestre

em Engenharia de Eletrónica Industrial e Computadores

Declaração

Nome:

César Ulisses Cruz Monteiro

Endereço Eletrónico: [email protected]

Telefone/Telemóvel: 91 752 94 96

Número do Bilhete de Identidade: 14169405

Título da Dissertação: Framework compatível com Repositório IP-XACT para o Domínio Específico de Aplicações

Orientador: Professor Doutor Adriano José da Conceição Tavares

Designação do Mestrado:

Mestrado Integrado em Engenharia Eletrónica Industrial e Computadores

É AUTORIZADA A REPRODUÇÃO INTEGRAL DESTA TESE APENAS PARA EFEITOS DE INVESTIGAÇÃO, MEDIANTE DECLARAÇÃO ESCRITA DO INTE-RESSADO, QUE A TAL SE COMPROMETE

Universidade do Minho, ____/_____/________

Agradecimentos

Primeiro que todo queria agradecer à minha mãe e ao meu irmão por todo o apoio e esforço que depositaram em mim ao longo do meu percurso académico.

Ao meu orientador Professor Doutor Adriano Tavares pelo a oportunidade e apoio dada durante o desenvolvimento do presente trabalho. Um muito obrigado ao Mestre Vitor Silva por toda a ajuda e disponibilidade principalmente nos momentos de aflição.

Aos meus colegas que me ajudaram ao longo deste percurso, principalmente ao Nelson Naia, Marcelo Sousa e João Gonçalves que sempre estiveram ao meu lado nos bons e maus momentos.

Resumo

Muitos dos sistemas actuais combinam de uma forma sinergética a componente hardware e software, para cumprir os requisitos do sistema e alcançar as perfor-mances desejadas. Ao desenvolver este tipo de sistemas é necessário adotar design

flows hardware/software coerentes. Ao adoptar um design flow típico

hardware/-software uma das fases mais críticas do co-design é o desenvolvimento e integração de aceleradores dedicados. Uma possibilidade para agilizar este processo passa pelo reaproveitamento de Intellectual Property (IP), sendo desta forma possível diminuir o tempo de desenvolvimento do protótipo e consequentemente diminuir o time-to-market. Outra possibilidade passa pelo desenvolvimento de ferramen-tas alinhadas com o design flow, permitindo agilizar o processo de configuração e desenvolvimento de um projeto desta natureza.

A presente dissertação surge na necessidade desenvolvimento de uma framework compatível com o standard IP-XACT que seja responsável por gerir um repositório de IP de software e hardware que tem como finalidade o desenvolvimento de apli-cações para um sistema operativo Linux de uma forma transparante, abstraindo o utilizador dos detalhes tecnológicos. Com este modelo descritivo é possível a reu-tilização dos IP em projetos futuros e desenvolver processos que permitam agilizar as várias etapas do design flow através da integração na framework de ferramentas importantes no co-desenvolvimento de hardware/software do sistema conseguindo assim dar suporte a um ambiente de co-simulação. Além de integrar diversas ferra-mentas, a framework oferece um conjunto de serviços que seguem uma abordagem generativa de código, responsáveis pela geração de drivers, wrappers e classes agi-lizando e automatizando o processo de desenvolvimento.

Abstract

Currently, a lot of systems merge hardware and software in a symbiotic way, to meet system requirements and achieve targeted performances. While developing these kind of systems, it is necessary to adopt coherent hardware-software design flows. In this process, one of the most critical phases is the development and integration of dedicated accelerators. A possibility to hasten this process is IP re-utilization to shorten prototype development time and consequently shorten time-to-market. Another possibility is developing tools which match and promote adopted design flows, allowing to improve the configuration and development pro-cess of a project of this nature.

The proposed dissertation arises from the necessity of developing a framework that’s compatible with the IP-XACT standard that is responsible to manage an IP repository of software and hardware oriented to hybrid Linux application deve-lopment in a transparent way, abstracting the user from technological intricacies. With this descriptive model, it is possobile to re-utilize IP in future projects, and develop processes that allow to improve several design flow stops through impor-tant hardware-software co-design tool integration in the framework, being able to support a co-simulation environment. Besides integrating several tools, this fra-mework provides a set of services responsible for the generation of the drivers, wrappers and classes contributing to the streamlining and automation of the de-velopment cycle.

Conteúdo

2.4.1 Simple Object Access Protocol . . . 14

2.4.2 Kactus2 . . . 14

2.4.3 Vivado IP Catalog e Vivado IP Integrator . . . 16

2.5 Frameworks e Bibliotecas . . . 16

2.6 Field Programmable Gate Array . . . 18

2.6.1 Estrutura interna da Field Programmable Gate Array . . . . 18

2.6.2 Design Flow . . . 21

2.6.3 Vivado Integrated Design Environment . . . 23

2.6.4 Tool Command Language . . . 24

2.6.5 Modelsim . . . 25 3 Framework Design 29 3.1 Design Flow . . . 29 3.1.1 IP Packaging . . . 30 3.1.2 Design . . . 31 3.1.3 Verificação . . . 31

3.2 Modelo de Threads . . . 32

3.3 Funcionalidades e Restrições . . . 34

3.4 Base Dados IP-XACT . . . 35

3.4.1 Estrutura das Classes da Base Dados IP-XACT . . . 36

3.4.2 Arquitetura da Base Dados IP-XACT . . . 39

3.4.3 Restrições na Implementação . . . 43

3.5 Gestor de Repositório . . . 43

3.5.1 Mecanismos e Arquitetura do Repositório . . . 45

3.5.2 Organização do Repostório de IP . . . 48

3.6 Gerador de ToolChain . . . 49

3.6.1 Criação das Diretorias de Output . . . 50

3.6.2 Geração Cross-Compiling Toolchain, Root File System e Ker-nel Image . . . 51

3.6.3 Geração do Projeto Hardware . . . 53

3.6.4 Geração dos Drivers . . . 57

3.6.5 Geração das software Sources . . . . 60

3.7 Ambiente de Co-Simulação . . . 63

3.8 Interoperabilidade entre Módulos . . . 64

4 Cenário de Aplicação 69 4.1 Modelação do Sistema . . . 69 4.2 IP-PACKGING . . . 70 4.3 Design . . . 74 4.4 Verificação . . . 79 5 Conclusão 83 5.1 Trabalho Desenvolvido . . . 83 5.2 Trabalho Futuro . . . 84 Bibliografia 88 A IP-XACT 89 A.1 Conceitos Base . . . 90

A.2 Análise de um Elemento IP-XACT . . . 93

B Fluxogramas 95 B.1 Fluxogramas da Base Dados IP-XACT . . . 95

B.3 Fluxogramas Gerador Tool Chain . . . 100

C Criação e Customização de um Projeto no Vivado no modo

Non-Project Mode 101

D Teoria p-q 103

E Resultados 105

E.1 Ficheiro XML de Descrição da Transformada de Clarke . . . 105 E.2 Ficheiro XML de Descrição do Design . . . 106

Lista de Figuras

2.1 Modelo de inetração do QEMU com ferramentas externas de simulação 11 2.2 Schema do elemento top-level Component do standard IP-XACT[14] 12

2.3 Ambiente de design IP-XACT [14] . . . 13

2.4 Mensagem XML entre duas aplicações . . . 14

2.5 Esquema de uma mensagem do protocolo SOAP . . . 15

2.6 Esquema de uma mensagem do protocolo SOAP . . . 15

2.7 Design flow da framework Kactus2 [13] . . . 16

2.8 IP-Core . . . 18

2.9 Estrutura básica da FPGA [4] . . . 19

2.10 LUT de 2 entradas configurada para implementar uma porta AND[3] 20 2.11 Arquitetura típica de uma FPGA [3] . . . 20

2.12 FPGA design flow . . . 21

2.13 Vivado Design Flow [15] . . . 24

2.14 ModelSim Design Flow [7] . . . 25

2.15 Modelo de interface do ModelSim com a extensão do QEMU . . . . 27

3.1 Design Flow seguido pela Framework . . . 30

3.2 Caso geral de uma thread . . . 32

3.3 Caso geral de um thread software e hardware . . . 33

3.4 Padrão de um IP presente no Repositório . . . 33

3.5 Visão Geral da Framework . . . 35

3.6 Estrutura geral de uma classe que define um elemento IP-XACT . . 36

3.7 Processo de leitura de um elemento IP-XACT a partir de um nó XML 37 3.8 Processo de leitura de um elemento composto com múltiplas definições 37 3.9 Fluxograma template do métodos de validação de uma classe IP-XACT . . . 38

3.10 Processo de escrita de um nó de um elemento IP-XACT . . . 39

3.11 Processo de escrita de elemento composto com múltiplas definições . 39 3.12 Top-level UML da base dados IP-XACT . . . 40

3.13 Fluxograma do método readTopXML . . . 41

3.14 Representação UML do elemento portMap . . . 42

3.15 Representação de parcial do schema do elemento IP-XACT Port . 42 3.16 Representação UML da classe CPortType . . . 44

3.17 Fluxograma do mecanismo de leitura dos ficheiros XML presentes no Repositório . . . 45

3.18 Fluxograma de acesso a um IP no repositório . . . 46

3.19 Diagrama de Classes do repositório IP-XACT . . . 47

3.20 Ordem de geração das partes integrantes do Gerador de ToolChain 49 3.21 Organização de Pastas de um projecto gerado pela framework . . . 50

3.22 Fluxograma de criação das pastas dos projecto . . . 51

3.23 Fluxograma de geração da Cross-Compiling Toolchain, Root File System, Kernel Image e bootloader. . . 52

3.24 Modelo geral do Wrapper . . . 54

3.25 Fluxograma de geração do wrapper Qemu . . . 55

3.26 Fluxograma de geração do projeto Vivado IDE . . . 56

3.27 Esquema de comunicação entre a hardware delegate thread e o pe-riférico . . . 57

3.28 Fluxograma do processo write do device driver . . . 58

3.29 Fluxograma do processo read do device driver . . . 58

3.30 Fluxograma da geração do device driver . . . 59

3.31 Caso geral de uma classe referente a um thread . . . 60

3.32 Fluxograma da geração dos ficheiros de software . . . 62

3.33 Modelo de interface do ModelSim com o QEMU . . . 63

3.34 Diagrama UML da Framework . . . 65

3.35 Diagrama de sequência da inicialização da Framework . . . 66

4.1 Diagrama de blocos da aplicação . . . 69

4.2 UML da aplicação de teste . . . 70

4.3 Top level IP core Clarke Transform . . . 71

4.4 Menu de inserção de um novo IP . . . 71

4.5 Menu de inserção da informação de um porto . . . 72

4.6 Menu de inserção do interface QEMU_BUS . . . 73

4.7 Ficheiros de HDL e software gerados pela framework . . . 73

4.8 Menu de inserção de filesets da framework . . . 74

4.9 Menu de criação de um projeto . . . 75

4.11 Código verilog gerado pela framework no wrapper que permite a

ligação do IP ao barramento virtual QEMU . . . 76

4.12 Threads geradas pela framework . . . 79

4.13 Menu de co-simulação proporcionado pela framework . . . 80

4.14 Aplicação de cálculo das potências instantâneas a correr sobre uma plataforma emulada pelo QEMU . . . 80

4.15 Circuito de teste do sistema desenvolvido . . . 81

4.16 Tensões e correntes de entrada do ADC . . . 81

4.17 Potências instantâneas calculadas pela aplicação . . . 82

A.1 VLNV schema [14] . . . 90

A.2 Compositor sequência [14] . . . 90

A.3 Compositor sequencia com variações [14] . . . 91

A.4 Compositor escolha com variações [14] . . . 92

A.5 Abstract Definition schema [14] . . . 93

A.6 Classe Abstract Definition . . . 94

B.1 Fluxograma do método de reset da classe CIP-XACT . . . 95

B.2 Fluxograma do método de acesso ao elemento da classe CIP-XACT 96 B.3 Fluxograma para encontrar um IP no repositório . . . 97

B.4 Fluxograma de escrita de um IP presente no repositório . . . 97

B.5 Geração do ficheiro top-level verilog do IP . . . 98

B.6 Geração dos ficheiros de software do IP relativos a cada processo . . 99

B.7 Fluxograma de geração das ligações dos portos de um periférico no wrapper Qemu . . . 100

Lista de Acrónimos

API Application Programming Interface ASIC Application Specific Integrated Circuits AXI Advanced eXtensible Interface

CLB Configuration Logic Block CPU Central Processing Unitl DCR Device Control Register DE Design Environment

EDA Electronic Design Automation FPGA Field Programmable Gate Array GUI Graphical User Interface

HDL Hardware Description Language HLS High Level Synthesis

IDE Integrated Design Environment IP Intellectual Property

LUT Lookup Table PLB Processor Local Bus

PLI Programming-Language Interface RFS Root File System

SHC Schematic

SOAP Simple Object Access Protocol Tcl Tool Command Language

TGI Tight Generator Interface XML eXtensible Markup Language

Capítulo 1

Introdução

Neste capítulo é contextualizado o âmbito da presente dissertação assim como os seus objetivos e motivações. No final, é apresentada a organização da dissertação.

1.1

Contextualização

A maior parte dos sistemas do quotidiano são controlados por um sistema embe-bido, com diferentes domínios de aplicação desde uma simples máquina de lavar a um automóvel. O desenvolvimento deste tipo de sistemas é particularmente mais exigente do que outros domínios da engenharia de software, devido a apresentar requisitos funcionais e não funcionais no que toca à qualidade, confiabilidade e performance. O desenvolvimento de aplicações para este tipo de sistemas pode ser feito em bare-metal onde a aplicação corre diretamente sobre o processador, o que é suficiente para desenvolver sistemas low end, mas quando os sistemas neces-sitam de: 1. de mais segurança; 2. correr sobre múltiplos processadores ou correr rotinas ao mesmo tempo; 3. lidar com eventos externos de uma maneira eficiente e standard; 4. integrar serviços ou protocolos de comunicação standard, como por exemplo o TCP/IP; 5. integrar mecanismos de gestão de memória; 6. fazer o es-calonamento entre as várias tarefas; a inclusão de um sistema operativo é uma mais valia. Ao utilizar um sistema operativo é possível fazer uma abstração da componente física do sistema e gerir os recursos de hardware e multiplexá-los para as tarefas. Um dos sistemas operativos mais populares é o Linux, devido a ser

open source, suportar as arquiteturas mais conhecidas de microprocessadores e ser

tem requisitos extremamente exigentes a nível de performance, pode tornar-se um desafio o preenchimento destes requisitos, pois ao utilizar o Linux é introduzido muito overhead no desempenho do sistema. Para contornar este problema uma abordagem passa por recorrer a blocos de hardware para acelerar as componentes críticas do sistema.

Com a rápida evolução da tecnologia Field Programmable Gate Array (FPGA) é cada vez mais comum o recurso a co-designs hardware/software para o desenvol-vimento de sistemas com requisitos exigentes, acelerando o sistema recorrendo ao processamento em paralelo que o hardware proporciona. O co-designs

hardware/-software tem como objetivo aumentar as várias métricas do sistemas como

per-formance, time to market, custo entre outras, migrando as secções críticas para

hardware para que estas possam ser aceleradas. No entanto o desenvolvimento

deste tipo de sistemas pode ser muito moroso devido à sua complexidade e múlti-pla integração tecnológica, pois a sua implementação implica o desenvolvimento de módulos de software, hardware e as respectivas interfaces capazes de estabelecer conectividade entre ambos.

Muitas das vezes o processo de desenvolvimento e integração de aceleradores em

hardware nos sistemas pode ser bastante complexo e longo, o que faz com que a

reutilização de IP num projeto seja uma escolha mais viável. Deste modo, não é necessário direcionar recursos para o desenvolvimento de periféricos já desenvolvi-dos e testadesenvolvi-dos. Com isto, é necessário ter ao alcance mecanismos que permitam a fácil integração dos periféricos nos sistemas a desenvolver. Neste contexto surge o standard IP-XACT[14] que permite descrever um periférico através de um mo-delo de meta-dados. Assim, é possível que qualquer designer possa desenvolver os seus IP e facilmente os integre em qualquer ferramenta que siga este standard. Isto permite que seja possível construir ferramentas neutras que permitem a fácil integração de periféricos, sendo assim possível construir sistemas mais complexos de forma mais ágil e intuitiva.

Já existem algumas ferramentas que adotam o standard IP-XACT para descrever IP como é o caso do Kactus2[13] desenvolvido pela Tampere University. Esta ferramenta dá suporte a inúmeras funcionalidades, desde da descrição de IP à modulação de designs. Esta ferramenta também apresenta algumas limitações, tal como não permite a verificação comportamental dos sistemas.

1.2

Motivação e Objetivos

Hoje em dia o desenvolvimento de um sistema embebido com componente de

hard-ware e softhard-ware é prática usual em grandes setores industrias que tem requisitos

extremamente exigentes, como por exemplo os setores aeroespacial, automóvel, telecomunicações e energético. O que faz com que seja necessário adotar designs

flows típicos para um co-design hardware/software para o desenvolvimento deste

tipo de sistemas de maneira a agilizar e automatizar o processo de desenvolvi-mento e verificação de sistemas desta natureza. Além disto é necessário adotar e desenvolver ferramentas alinhadas com o design flow de maneira a automatizar o processo de configuração no seu desenvolvimento.

Estas necessidades fazem com que seja necessário desenvolver ferramentas que permitam aumentar a produtividade no desenvolvimento deste tipo de sistemas e proporcionar ao programador um ambiente de desenvolvimento compatível com o Linux que abstrai o programador dos detalhes tecnológicos do sistema. Com isto, pretende-se criar uma framework que permita gerir um repositório de IP de

hardware e software que vise a sua reutilização e assente sobre o modelo descritivo

IP-XACT. Deste modo, é possível criar processos que permitem automatizar e agilizar as diferentes etapas do design flow e criar um sistema automatizado e transparente ao utilizador.

1.3

Organização da Dissertação

Este documento descreve o desenvolvimento de uma framework compatível com o standard IP-XACT para gestão de um repositório de IP para um domínio espe-cifico de aplicações. Para além da introdução esta dissertação contem mais cinco capítulos.

O segundo capítulo consiste num levantamento de conceitos teóricos que esta dis-sertação abordada. Começa pela descrição de algumas ferramentas importantes suportadas pela framework. É feita uma descrição do standard IP-XACT e abor-dadas algumas ferramentas que usam este standard para descrever IP. De seguida são abordados os conceitos de framework e bibliotecas. É também feita uma des-crição da tecnologia FPGA, assim como design flow de um projeto de hardware. Para finalizar é abordado o co-design hardware/software, onde é descrito um

ferramenta que permite o desenvolvimento destes sistemas.

O terceiro capítulo descreve o modelo de desenho de um sistema hardware/software que a framework segue. É também neste capítulo que é apresentado com detalhe o desenvolvimento da framework e toda a tomada de decisões em relação à sua modulação. São também explicadas as funções dos diversos módulos integrantes da framework.

O quarto capítulo apresenta um cenário de aplicação onde a framework foi apli-cada. Neste capítulo é modelado um sistema simples para teste da framework. É desenvolvido o sistema proposto com o auxilio da framework, onde são descritos os diversos passos integrantes desse desenvolvimento.

O documento termina com a conclusão e discussão dos resultados obtidos no tra-balho desenvolvido e é feita uma reflexão sobre tratra-balhos futuros no seguimento deste tema.

Capítulo 2

Estado da Arte

Este capitulo inicia-se com a descrição de um design flow típico hardware/software. De seguida é abordado o Linux e descritas as ferramentas Buildroot e QEMU. É apresentada uma visão geral do standard IP-XACT e descritas algumas ferramen-tas que usam como base este standard. São analisados os conceitos de framework e bibliotecas. Para terminar é apresentada a tecnologia FPGA, onde é feita uma descrição da sua estrutura interna e do seu design flow.

2.1

Co-Design HW/SW

Com a crescente evolução da tecnologia FPGA e ao mesmo tempo a baixa de preço desta tecnologia, faz que seja possível o desenvolvimento de projetos que englobem uma componente hardware/software esteja ao alcance de qualquer programador. Mas este tipo de projetos são complexos, por isso é necessário adotar designs flows coerentes para que seja facilitado o desenvolvimento e a tomada de decisão durante o projeto.

De seguida será descrito um design flow típico seguido para o desenvolvimento de projetos com componente hardware/software.

2.1.1

Design Flow

Formalmente o design flow destes sistemas segue um padrão. A primeira fase consiste no desenvolvimento de uma aplicação numa linguagem de software que

modela o comportamento do sistema. Nesta fase apenas é modelado o compor-tamento do sistema, sem ter em conta as métricas do mesmo. Desta forma são depurados os algoritmos a utilizar, tal como o seu comportamento geral. Esta aplicação é compilada para um host onde irá decorrer o desenvolvimento do pro-jeto, pelo que nesta fase não é relevante que a aplicação seja cross-compiled para o target que irá ser utilizado no projeto, uma vez que o interesse reside na sua modelação. A próxima fase é a identificação de possíveis tarefas dentro da aplica-ção e a sua posterior paralelizaaplica-ção virtual com recurso a API de multithreading, sendo seguida da fase de profiling. Nesta fase, através de ferramentas de profiling a aplicação é caracterizada de forma a serem detetadas as tarefas mais críticas para identificar tarefas candidatas a possível migração parcial, ou até mesmo total, para

hardware. Após decididos quais os hardware-IP a desenvolver a próxima fase é o

uso de Hardware Description Language (HDL) para o desenvolvimento de modelos Register-transfer level (RTL) para os hardware-IP a desenvolver. Uma vez desen-volvidos os hardware-IP deve-se passar por uma fase de validação do sistema de forma a confirmar o seu funcionamento integral, terminando com uma fase de im-plementação e confirmação das métricas desejadas. Este processo é iterativo pelo que na fase de confirmação se as estratégias utilizadas não cumprem as métricas pretendidas, retorna-se à fase de desenvolvimento do hardware-IP ou até mesmo à fase de profiling.

Modelação do Sistema

Para modelar o sistema, tipicamente é desenvolvida uma aplicação em linguagens de programação flexíveis, como o C/C++ que são linguagens de eleição para

em-bedded software. Desta forma o código é o mais genérico e portável possível para

poder ser compilado tanto para a plataforma target como também para a plata-forma host. Assim sendo, a aplicação poderá ser testada e validada facilmente na plataforma host sem recurso à plataforma target.

Paralelização em Software

Usualmente esta paralelização é efetuada através de API como a API de

mul-tithreading POSIX muito utilizada em sistemas Unix-based. Após identificadas

as tarefas, os algoritmos das várias tarefas são implementados em threads sepa-radas. Uma vez que há uma grande possibilidade de existirem dados partilhados

entre as várias threads, pode ser necessário o uso de mecanismos de sincronismo entre as várias threads, usualmente providenciados na API, de forma a evitar race

conditions.

Profiling

O profiling consiste em utilizar ferramentas para analisar a aplicação. Para aplica-ções com requisitos temporais é necessário ter escalonamento de tarefas em tempo real, de forma a a ter uma resposta determinística do sistema. As ferramentas de profiling devem ser utilizadas várias vezes para recolher dados, que permitem identificar as tarefas críticas e bottlenecks do sistema.

Paralelização em Hardware

A implementação de hardware-IP é feita recorrendo a linguagens HDL, nomeada-mente Verilog ou VHDL. O desenvolvimento é feito a nível RTL e é validado e depurado através de ferramentas de simulação como o ModelSim que simulam os sinais do IP.

Ferramentas de síntese posteriormente sintetizam o IP e ferramentas de routing efetuam o floorplan de forma a que este possa ser transferido para um Application Specific Integrated Circuits (ASIC) ou um FPGA. Estas ferramentas são normal-mente integradas numa toolchain e fornecidas num ambiente desenvolvimento, tal como o Vivado Integrated Design Environment (IDE).

Atualmente os microcontroladores ou outro tipo de ASIC são desenvolvidos desta forma, sendo utilizadas plataformas FPGA para a sua validação e depuração, e aquando a conclusão do projeto fabricados em ASIC. O processo de desenvol-vimento, validação e depuração de IP pode constituir um processo moroso, e complexo. A compilação de HDL e a sua posterior síntese, mesmo com as fer-ramentas atuais no mercado, pode ser morosa, especialmente quando é utilizada uma plataforma física ao invés de uma ferramenta de simulação. Além disso, o paradigma de codificação em HDL é diferente dos paradigmas de programação das linguagens software. Devido a estas razões, existem ferramentas de tradução de algoritmos em linguagens software para linguagens HDL como o Vivado High Level Synthesis (HLS). Obviamente que esta tradução é muito menos eficaz que o desenvolvimento de IP em HDL.

Validação

Nesta fase deve ser efetuada uma validação do sistema desenvolvido na sua tota-lidade de forma qualitativa. Através de um ambiente de co-simulação integrado, o processo de desenvolvimento é acelerado de forma substancial, sendo possível testar e depurar o sistema integralmente, simultaneamente com o seu desenvolvi-mento. Desta forma a implementação na plataforma target só é necessária quando a validação de todo o sistema integrado for concluída. Uma possibilidade passa por recorrer ao QEMU como ferramenta de emulação da componente de software, interligando-o a outras ferramentas de simulação de outros de domínios, permi-tindo gerar um ambiente de co-simulação.

Confirmação/Implementação

Idealmente esta fase deve consistir na implementação do sistema na plataforma

target, sendo posteriormente confirmados os requisitos temporais e a funcionalidade

do sistema implementado. Através de ferramentas como o ChIPcope que criam um wrapper em silício para o sistema desenvolvido é possível analisar os sinais temporais do sistema físico de forma a confirmar que os requisitos temporais são realmente cumpridos.

O conceito de ambiente de co-simulação integrado pode ser expandido de forma a visar a validação de uma multitude de métricas após a validação qualitativa de forma a ser obtida uma validação quantitativa, expandido a utilidade do mesmo.

2.2

Linux

O Linux é um sistema operativo baseado no sistema UNIX criado por Linus Tor-valds em 1991. Este sistema operativo teve logo um grande sucesso o que levou a uma rápida evolução do sistema, que fez com que surgissem distribuições Li-nux contendo todos os elementos de software necessários à instalação e uso de um sistema operativo Linux, sem ser necessário ter grandes conhecimentos técnicos. Desde do lançamento da sua primeira versão o Linux tornou-se um sistema robusto e fiável, devido à contribuição de vários programadores através da proposta de no-vas ideias e identificação de problemas existentes, devido a este ser um sistema livre e open source.

Cada vez mais o Linux é adotado como sistema operativo de suporte, devido a este ser suportado por inúmeras arquiteturas de processadores que permite o de-senvolvimento de uma vasta gama de sistemas, desde os mais complexos aos mais simples com um baixo custo. Nos dias de hoje o sistema operativo Linux por ser encontrado em grande parte dos dispositivos digitais do quotidiano, como máqui-nas de lavar, GPS e carros. De seguida será feita uma descrição das características principais do Linux:

1. Suporta um grande número de dispositivos de hardware;

2. Grande número de produtores de plataformas de desenvolvimento dão su-porte ao sistema operativo Linux;

3. Possibilita uma grande variedade de protocolos de comunicação (CAN, SPI, UART, I2C, etc) que faz que seja mais fácil a comunicação com outros sis-temas;

4. Por ser distribuído pela Internet permite que seja acessível a todos os pro-gramadores e faz com que seja mais rápido o lançamento de novas versões e deteção de erros.

Estas características fazem com que o sistema operativo Linux seja o mais utilizado pelos sistemas embebidos na atualidade.

2.2.1

Buildroot

O Buildroot é uma ferramenta que permite simplificar e automatizar o processo de construção da imagem e geração de ferramentas de compilação para um sistema embebido Linux. É composto por uma série de makefiles e patches instalados num sistemas host, permitindo a cross-compilation. O Buildroot é capaz de gerar: 1. cross-compilation toolchain, responsável por criar todas as ferramentas necessá-rias à compilação dos ficheiros para a plataforma alvo; 2. Root File System (RFS), gera todos os ficheiros constituintes do sistema para a plataforma alvo; 3. Linux

kernel image, gera a imagem do kernel de acordo com as configurações escolhidas

para um sistema Linux; 4. bootloader, permite colocar em execução o sistema ope-rativo na plataforma alvo. Com isto o Buildroot é uma ferramenta extremamente poderosa pois permite agilizar de forma considerável o desenvolvimento de um sistema embebido para diferentes plataformas, suportando diversas arquiteturas

O uso do Buildroot traz algumas vantagens para quem o utiliza:

1. Permite criar cross-compilation toolchain, root filesystem, Linux kernel image e bootloader para um sistema embebido Linux, compatível com inúmeras arquiteturas;

2. Permite a fácil configuração de um sistema embebido através do menuconfig, xconfig, etc;

3. Processo de construção e geração dos ficheiros é através das ferramentas make e kconfig, o que permite ao programador compreender e editar os sripts de geração do Buildroot.

Muitas das ferramentas usam como ferramentas externas o Buildroot por este dar suporte a inúmeros arquiteturas de processadores e por conter as configurações das plataformas mais usuais, reduzindo o processo de desenvolvimento das ferramentas [1].

2.3

QEMU

O QEMU é uma ferramenta open source que permite emular e virtualizar o com-portamento de um grande número de arquiteturas de processadores. O QEMU dinamicamente traduz o código binário da máquina emulada para a máquina onde está ser corrido o QEMU. Quando utilizado como virtualizador o QEMU consegue atingir performances muito semelhantes às nativas, uma vez que executa o código virtualizado diretamente no Central Processing Unitl (CPU) do host.

O QEMU é uma poderosa ferramenta no teste de sistemas embebidos, pois permite o desenvolvimento e debug numa plataforma alvo, sem ser necessário recorrer à plataforma física. Toda a software stack pode ser desenvolvida no QEMU, só depois de validada é migrada para a plataforma alvo.

O QEMU oferece uma extensão para ligação a ferramentas externas de simulação, permitindo assim por exemplo a co-simulação com hardware externo (ao emulado pelo QEMU). Assim é possível emular as transações de dados entre a componente de software que corre sobre o QEMU com ferramentas de diferentes domínios de simulação. A figura 2.1 apresenta um exemplo em que um sistema alvo baseado em Linux, a correr sobre o QEMU, co-simulado com uma extensão de hardware suportada por um modelo de simulação.

Figura 2.1: Modelo de inetração do QEMU com ferramentas externas de simulação

A aplicação embebida corre sobre o ambiente Linux emulado no QEMU. As

hard-ware delgate thread em vez de conter os algoritmos de processamento delegam o

processamento a co-processadores utilizados para esse efeito, através de chamadas ao sistema com interação com os device drivers. Quando os device drivers inte-ragem com o hardware, as rotinas de emulação do QEMU irão ser invocadas por os modelos respectivos do hardware acedido. No caso especifico de os modelos de co-processadores de hardware serem simulados externamente a informação da transação irá ser reencaminhada para a respectiva ferramenta de simulação.

2.4

IP-XACT

O standard IP-XACT foi concebido pela SPIRIT Consortium com o objetivo de permitir a reutilização de IP de uma maneira mais fácil e eficiente [14]. Em 2009 o IEEE lançou o standard 1685 que descreve o IP-XACT. Uma descrição IP-XACT é descrita na linguagem eXtensible Markup Language (XML), o que permite uma fácil interpretação/leitura tanto do designer como das ferramentas.

O formato IP-XACT descreve o componente, ou seja, não tem nenhuma infor-mação relativa à sua implementação, assim sendo, não é considerado como um substituto de HDL como o VHDL ou Verilog. Contém informações chave sobre os IP (barramentos, portos, registos, mapeamento da memoria), esta informação é representada através de XML schema. No modelo descritivo de cada IP é possível

referenciar os ficheiros, tais como ficheiros que traduzem o comportamento dos IP, simulações, drivers entre outros. Este standard assegura a fácil integração de IP de diferentes vendedores no design, suprimindo os problemas de compatibilidade e agilizando o processo de verificação do sistema. O designer pode utilizar IP já de-senvolvidos e verificados, não necessitando de os desenvolver novamente, podendo assim aceder a repositórios de IP de diferentes vendedores conseguindo assim uma melhor performance. A figura 2.2 representa schema de um elemento top-level do formato IP-XACT que descreve um IP. Neste modelo representativo é possível inserir todas as informações relativas ao IP, como nome, vendedor, portos,

inter-faces com que o IP é compatível, referencias aos ficheiros importantes ao IP entre

outras informações importantes à descrição do IP.

spirit:componentType

To define all elements and attributes supported w hen defining a component.

spirit:com ponent

typespirit:componentType

This group of elements identifies a top lev el item (e.g. a component or a bus definition) w ith v endor, library , name and a v ersion number.

spirit:versionedIdentifier

A list of bus interfaces supported by this component.

spirit:busInterfaces

Lists all channel connections betw een mirror interfaces of this component.

spirit:channels

C ontains a list of remap state names and associated port v alues

spirit:rem apStates

If this component is a bus master, this lists all the address spaces

defined by the component.

spirit:addressSpaces

Lists all the slav e memory maps defined by the component.

spirit:memoryMaps

M odel information.

spirit:model

typespirit:modelType

Generator list is tools-specific.

spirit:componentGenerators

C hoices used by elements w ith an attribute spirit:choiceRef.

spirit:choices

List of file sets associated w ith component.

spirit:fileSets

A list of w hiteboxElements

spirit:w hiteboxElem ents

cpu's in the component

spirit:cpus

Defines a set of clock driv ers that are not directly associated w ith an input port of the component.

spirit:otherClockDrivers

typespirit:otherClocks

F ull description string, ty pically for documentation

spirit:description

typexs:string

A collection of parameters.

spirit:param eters

C ontainer for v endor specific extensions.

spirit:vendorExtensions

Figura 2.2: Schema do elemento top-level Component do standard IP-XACT[14]

O standard IP-XACT para além de permitir descrever IP permite também a des-crição de electronic system designs, geradores e interfaces que permitem fazer ligações de vários IP facilitando integração dos IP cores de diferentes vendedores e das Electronic Design Automation (EDA), o que leva ter um Design Environ-ment (DE) que pode ser compatível com todas as ferraEnviron-mentas que suportem este formato. Através da informação do design contida DE é crucial que exista um

para assim ser possível integrar geradores independentes. Assim sendo, o standard IP-XACT define um interface denominado Tight Generator Interface (TGI) que permite a interação de geradores externos com DE, sendo este mecanismo de co-municação baseado no protocolo Simple Object Access Protocol (SOAP). Além disso o formato IP-XACT também permite a descrição destes geradores.

A figura 2.3 dá uma visão geral do ambiente de design IP-XACT.

Figura 2.3: Ambiente de design IP-XACT [14]

Este ambiente é dividido em três partes:

1. IP-XACT Compilant Object Descriptions: são os objetos que definem as informações dos IP, interfaces e designs presentes num repositório compatível como standard IP-XACT;

2. IP-XACT DE: é o local onde é possível construir um design, através da informação dos IP e interfaces presentes no IP-XACT Compilant Object Descriptions, permitindo instanciar e interligar os IP de acordo com as

es-pecificações dos seus interfaces;

3. IP-XACT Compilant Generators: descreve os geradores compatíveis com o DE, o que permite ao DE invocá-los sempre que necessários. Estes geradores

irão aceder à informação do design presente no DE através do TGI.

No apêndice A o standard IP-XACT é analisado em maior detalhe.

2.4.1

Simple Object Access Protocol

O SOAP é um protocolo standard de partilha de mensagens entre aplicações. As mensagens enviadas entre aplicações não são nada mais do que um XML-based

envelope que contém a informação a ser transferida e as regras de tradução dessa

mensagem para os tipos de dados suportados pelo XML. O protocolo SOAP segue rigidamente os standards XML o que permite que a troca de mensagens seja feita através de um documento XML. Com isto, é possível a troca de mensagens entre qualquer aplicação independentemente do sistema operativo em que executa ou da linguagem de programação em que esta foi codificada.

Figura 2.4: Mensagem XML entre duas aplicações

Para que a informação trocada entre aplicações possa ser bem interpretada é ne-cessário adotar uma estrutura comum para cada mensagem. Neste contexto cada mensagem enviada pelo protocolo SOAP é dividida num header e num body. O

header contem a informação de como deve ser a mensagem processada. O body

representa a mensagem a ser entregue. O esquema da figura 2.5 representa a estrutura de uma mensagem.

Para que a troca de dados seja efetuada entre duas aplicações é enviada uma mensagem do cliente ao servidor. O servidor processa esse pedido e envia uma resposta, essa transação está representada na figura 2.6.

Com este protocolo é possível implementar o TGI, fazendo com que seja possível a invocação de geradores externos ao IP-XACT DE.

2.4.2

Kactus2

O Kactus2 é uma framework desenvolvida pela Tampere University com o principal objetivo de permitir uma abstração de software/hardware para o desenvolvimento

Figura 2.5: Esquema de uma mensagem do protocolo SOAP

SOAP Client SOAP Server

Request Message

Response Mensage

Figura 2.6: Esquema de uma mensagem do protocolo SOAP

de aplicações software, assim como a reutilização de IP. A sua base é o stan-dard IP-XACT 1685 IEEE e a metodologia é fundamentada em platform based

design paradigm com auxilio dos meta-dados, conseguindo assim representar os

componentes e sistemas desenvolvidos, assim como a interoperabilidade de várias ferramentas [13].

O design flow seguido por esta framework é bastante simples representado pela figura 2.7. Através da representação de cada IP no formato IP-XACT é possível selecionar os IP necessários ao design. Através do modelo de meta-dados de cada IP é possível interliga-los de uma forma eficiente e validar essas ligações. Con-cluído este processo é possível chamar geradores e processos de forma automatizar o processo de desenvolvimento do design, como por exemplo chamar o gerador responsável pela geração do ficheiro top-level do design.

Para facilitar o design e colmatar algumas lacunas no standard IEEE 1685 IP-XACT foram criadas extensões, sendo assim possível criar IP de software.

Com isto verifica-se que a perspetiva do Kactus2 incide no design de SoC, inte-grando um repositório de IP e uma série de mecanismos que visam automatizar e agilizar o processo de design.

Figura 2.7: Design flow da framework Kactus2 [13]

2.4.3

Vivado IP Catalog e Vivado IP Integrator

O Vivado IP Catalog e o Vivado IP Integrator são ferramentas comerciais que que integram o Vivado Suite da Xilinx. Ambas as ferramenta seguem o standard IP-XACT para poder lidar com a informação dos diferentes IP de uma forma neutra.

O Vivado IP Catalog integra um repositório de IP já desenvolvidos e testados por parte da Xilinx ou por outros entidades, onde todos os componentes presen-tes no repositório estão definidos pelo standard IP-XACT. Através do modelo de meta-dados de cada IP a ferramenta providencia mecanismos que permitem a auto-matização de algumas tarefas de desenho do projeto: geração de código; packaging de novos componentes; criação de designs através do Vivado IP Integrator.

O Vivado Integrator é uma ferramenta que permite construir sistemas comple-xos através da interligação dos IP presentes no Vivado IP Catalog. Através do ambiente gráfico que esta ferramenta oferece é possível ligar os vários IP de uma forma interativa e simples, assim como, validar essas ligações. Através do design especificado a ferramenta é capaz de gerar de forma autónoma drivers, wrappers e o mapeamento de registos de maneira a diminuir o esforço do utilizador no desen-volvimento deste tipo de projetos.

2.5

Frameworks e Bibliotecas

As frameworks fornecem um ambiente de desenvolvimento que oferece um conjunto de funcionalidades especificas que permitem o desenvolvimento de aplicações para

um domínio especifico [2]. Segundo Fayad e Schmidt, frameworks representam uma estrutura formada por blocos pré-fabricados que os programadores podem usar, es-tender ou adaptar para uma solução específica através do uso de padrões de

soft-ware para resolver um problema complexo num determinado domínio. Deste modo,

pode-se dizer que uma framework é reutilizável e uma "semi-completa"aplicação que pode ser especializada para desenvolver uma aplicação personalizada [10].

Ao contrário das biblioteca, a framework dita o fluxo de controlo da aplicação, o utilizador é capaz de fazer o overriding de funcionalidades ou mesmo acrescentar novas funcionalidades à framework. Software frameworks podem dar suporte a compiladores, ferramentas externas e API, criando assim assim um ambiente que permite automatizar e configurar o projeto.

Desenvolvendo aplicações com recurso a frameworks torna-se num processo mais produtivo, devido à possibilidade de reutilização de código e designs, conseguindo assim um mais pequeno time-to-market no desenvolvimento de novas aplicações. Com isto é possível ter aplicações com menos bugs (reutilização implementações já testadas) e mais homogéneas (aplicações desenvolvidas a partir da mesma

fra-mework têm mesma arquitetura e similar implementação) [9].

As bibliotecas são um conjunto de rotinas ou classes que têm um interface bem definido para um domínio de aplicações bem definido. Ao contrário das frameworks é o programador quem dita o fluxo da aplicação e gere as chamadas de rotinas das bibliotecas. O programador não necessita de saber como as bibliotecas estão implementadas, mas sim perceber bem o seu interface e as suas especificações. As bibliotecas são facilmente substituídas por outras bibliotecas ao contrário do que acontece com as frameworks.

Ao utilizar um design flow no desenvolvimento de um design software/hardware é possível identificar métricas e processos padrões que podem ser agilizados e au-tomatizados. Uma vez identificados esses padrões, é possível adotar abordagens generativas de código e de automatização processo de configuração do design o que favorece o uso de frameworks. Com isto, é possível criar uma framework vertical ao

design flow, permitindo ao programador uma maior abstração dos detalhes

técni-cos. Isto permite que parte chave do design e a implementação seja padronizada o que torna mais fácil ao programador a deteção de erros e fácil alteração do design.

2.6

Field Programmable Gate Array

Ao contrário dos ASIC os dispositivos FPGA podem voltar a ser configurados. Um dispositivo FPGA consiste num conjunto de arrays lógicos que podem ser configurados após o seu fabrico. A maioria dos dispositivos FPGA é composta por diferentes tipos de blocos lógicos: blocos gerais lógicos, memórias e blocos aritméticos (multiplicadores, somadores, divisores etc).

Figura 2.8: IP-Core

Uma FPGA pode ser vista como um circuito lógico que pode ser configurado, sendo essa configuração geralmente especificada em HDL, em que a ligação dos vários blocos lógicos é possível a construção de circuitos mais complexos. A tecno-logia FPGA possibilita a implementação dos mais diversos circuitos lógicos, sem um custo acrescido, ao contrário dos ASIC que demoram semanas a ser fabrica-dos, podendo ser configurados em minutos, sendo esta tecnologia essencialmente aplicada na prototipagem e no desenvolvimento de ASIC. Os dispositivos FPGA sofreram uma grande evolução tecnológica nos últimos anos, sendo atualmente dispositivos muito sofisticados e com poderosos recursos que levam ao seu uso em muitas mais áreas (médica, militar, espacial, etc).

2.6.1

Estrutura interna da Field Programmable Gate

Ar-ray

Fisicamente as FPGA são uma coleção de gates programáveis, podendo ser interli-gadas. Estas gates são implementadas através de Lookup Table (LUT), flip-flops,

switchable interconnects e blocos I/O. As LUT e os flip-flops e as switchboxs

Figura 2.9: Estrutura básica da FPGA [4]

especifica a configuração da FPGA designa-se por bitstream, por outras palavras, especifica quais as LUT e as switchboxs que estão interligadas. A configuração de uma FPGA pode ser guardada de diferentes maneiras. Algumas FPGA usam EPROM, mas este tipo de memórias só permite a escrita de informação uma só vez, impedindo assim a reconfiguração da FPGA. Outras arquiteturas usam SRAM, o que faz com que FPGA necessite de ser programada quando é ligada, pois trata-se de uma memória volátil. Ao usar este tipo de memórias permitem a reconfigura-ção do design da FPGA. Os bits da SRAM estão distribuídos por toda a FPGA, especificando quais as tabelas de verdade das LUT e as ligações das switchboxs.

O tamanho da SRAM limita o número de entradas de uma LUT. Mas as novas arquiteturas de FPGA estão organizadas em maiores regiões, conhecidas por Con-figuration Logic Block (CLB). A CLB é um bloco complexo constituído por LUT,

multiplexers e flip-flops, contendo também circuitos lógicos auxiliares que fazem

com que a performance do circuito implementado pela CLB seja superior.

Na figura 2.11 é possível observar que os CLB são ilhas rodeadas por um mar de interconexões [3]. Através da configuração das interconexão entre os vários CLB é possível criar circuitos mais complexos.

Figura 2.10: LUT de 2 entradas configurada para implementar uma porta AND[3]

2.6.2

Design Flow

O desenvolvimento de sistemas baseados na tecnologia FPGA seguem um design

flow semelhante ao dos ASIC. Na figura 2.12 estão representadas as suas etapas.

Figura 2.12: FPGA design flow

Design Entry

O Design Entry é a primeira fase de desenvolvimento do design, é aqui que são criados os ficheiros onde será descrito o comportamento do sistema a desenvolver. Existem diferentes formatos de descrição do sistema como por exemplo o HDL ou o Schematic (SHC), normalmente para o desenvolvimento deste tipo de sistemas recorre-se ao HDL, dando assim ao utilizador um nível de abstração, separando-o dos detalhes do hardware.

Synthesis

Nesta fase o HDL é traduzido para operações boleanas, sendo estas representadas por elementos lógicos (flip-flops, gates, multiplexers, etc). Também nesta fase é

gerada a netlist que representa as ligações dos elementos lógicos gerados. Através das ferramentas de síntese é possível ao designer verificar o esquema de elementos lógicos e ligações geradas pela ferramenta, de forma a este garantir que lógica gerada é a desejada.

Implementation

Feita a síntese, o design lógico é convertido para um formato físico para que possa ser interpretado pela plataforma alvo. Esta fase pode ser dividida em 2 processos:

1. Mapping: esta fase consiste em dividir todo o circuito lógico em pequenos blocos lógicos, para que estes possam ser definidos pelas CLB;

2. Place and Route: nesta fase será determinado em que LUT as funções lógicas irão ser mapeadas assim como as ligações entre si;

Device Programming

Quando todas as etapas precedentes são realizadas com sucesso é gerado um fi-cheiro bistream que contém a informação que especifica o conteúdo das CLB e as ligações entre si da FPGA. Este ficheiro é enviado para FPGA especificando o seu design.

Behavioral Simulation

Este tipo de simulação é realizada antes da fase de síntese do projecto com o intuito de verificar se o design cumpre o comportamento desejado. Este tipo de simulação é muito rápida, permite mudar o código HDL facilmente e verificar o seu comportamento sem ter que sintetizar o projecto ao nível da gate.

Functional Simulation

Este tipo de simulação já é mais realista, pois permite a simulação do circuito digital gerado. Assim o designer consegue simular estruturalmente o seu design e verificar se existem erros.

Static Timing Analysis

Este tipo de verificação pode ser feita depois do Mapping ou Place and Route, sendo assim possível gerar relatórios temporais com os atrasos dos sinais, conseguindo assim verificar se as restrições temporais do design estão a ser cumpridas. Deve-se ter em conta o comprimento das ligações, pois ligações muito extensas podem causar atrasos, pelo que deve-se ter a consideração de colocar os circuitos mais críticos juntos.

2.6.3

Vivado Integrated Design Environment

O Vivado IDE permite o desenvolvimento e verificação de designs FPGA [16]. O Vivado IDE é composto por um leque de ferramentas para que todo o processo do design flow seja optimizado, uma dessas ferramentas é o Vivado IP catalog que permite o acesso a IP já desenvolvidos e testados. Também é possível o packaging de novos IP de maneira a estes serem reutilizados em futuros designs, alcançando um menor time to market.

O Vivado IDE providencia um intuitivo Graphical User Interface (GUI) com po-derosas funcionalidades em que todas as suas ferramentas obedecem a comandos Tool Command Language (Tcl), conseguindo assim o seu uso através do Vivado IDE ou pela Tcl shell. Através do Vivado IDE é possível analisar as métricas do design durante as várias etapas do seu processo, como por exemplo, a análise do cumprimento dos requisitos temporais após synthesis, placement ou routing. Como toda a informação é acedida através do Tcl é possível editar as configurações do design ou das ferramentas em tempo real sem ter que forçar a re-implementação. O design flow do Vivado está representado na figura 2.13 [15].

O Vivado IDE usa o conceito de carregar toda a informação sobre design para a memória [15]. Com isto, são carregadas para a memória todas as informações sobre cada etapa do design flow, permitindo visualizar e interagir com o design em qualquer etapa. Desta forma é possível experimentar diferentes tipos de implemen-tação, redefinir constraints, explorar o catalogo de IP que o Vivado providencia.

O Vivado IDE permite dois tipos de design flow:Project Mode e Non-Project Mode. No modo Project Mode é possível criar um projecto no Vivado IDE e o Vivado IDE controla todos os estados do design, sendo responsável por gerar os relatórios e mensagens fazendo a gestão dos ficheiros fonte. O modo Non-Project Mode usa

Figura 2.13: Vivado Design Flow [15]

comandos Tcl ou scripts. Neste modo o utilizador tem o controlo do design flow mas os relatórios e mensagens não são geradas automaticamente, não sendo feita a gestão dos ficheiros fonte. Apesar do modo de operação Non-Project Mode é possível abrir o projecto com Vivado IDE em qualquer etapa do design flow e fazer qualquer análise ao design assim como adicionar constraints [15].

Esta ferramenta possui um simulador denominado Vivado Simulater para a verifi-cação do HDL. Para além deste simulador o Vivado IDE permite a integração de outros simuladores como o VCS, ModelSim e Questa, gerando os srcipts necessários à execução dessa simulação na ferramenta de simulação especificada.

2.6.4

Tool Command Language

O Tcl é uma linguagem de programação para scripts, que tem uma vasta gama de aplicações, sendo mais usual no desenvolvimento de programas com GUI. A biblioteca Tcl consiste num parser para linguagem Tcl, rotinas para implementar os comandos Tcl built-in e mecanismos que permitem estender o Tcl em mais

comandos para uma aplicação especifica. Os comandos podem ser gerados a partir da leitura de ficheiros de texto, ou pela associação de comandos a elementos de um GUI como botões, widgets, menus, etc. A Tcl shell é muito parecida com a linha de comandos do Windows ou terminal Linux. Como já foi referido, é fácil estender o Tcl mas também já existem algumas extensões conhecidas e muito usadas, tais como: ObjectTcl, TclX, Tix entre outras. Através desta linguagem é possível gerar

srcipts para interagir com ferramenta Vivado IDE através do modo Non-Project Mode o que permite a ferramentas externas interagirem com as funcionalidades do

Vivado IDE.

2.6.5

Modelsim

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 dede-sign,

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.

3.2

Modelo de Threads

Como referido anteriormente, os sistemas desenvolvidos pela framework assentam sobre um modelo de threads. Este modelo tem o objetivo de permitir interagir com IP instanciados em software ou hardware da mesma maneira, tornando o sistema mais transparante ao programador fazendo com que este fique abstraído dos detalhes de implementação dos diferentes IP. Neste modelo cada thread irá simbolizar um IP instanciado no sistema em hardware ou software.

Para que o modelo de threads possa ser o mais transparante possível foi criado um padrão para cada thread, independentemente de se tratar de uma thread de

hardware ou software. Assim é possível para o utilizador lidar com qualquer tipo

de thread da mesma maneira. O esquema geral de uma thread está representado na figura 3.2.

Esperar pelo sinal Start

Enviar sinal End

Thread

... Fazer o processamento

...

Figura 3.2: Caso geral de uma thread

Cada thread necessita de uma sinalização para começar o processamento e, quando este é finalizado, envia um sinal indicando que o processo está concluído. No caso de uma thread de hardware existirá uma delegate thread em software que irá ser responsável pelas transacções com o acelarador de hardware respetivo e pelo sincronismo com as restantes threads (software) do sistema. Caso seja uma thread de software o processamento é diretamente implementado em software. O esquema que representa as diferenças entre as thread de hardware e software encontra-se na figura 3.3.

Para que os IP possam ser compatíveis com hardware delegate thread necessitam de seguir um padrão de desenho, esse padrão encontra-se visível na figura 3.4. Cada IP deverá ter como sinais de entrada um sinal de START que indica o

Esperar pelo sinal Start

Algoritmos de processamento em software

...

... Enviar Sinal End

Esperar pelo sinal Start Escrever nos registos de entrada

do periférico

Ler nos registos de saída do periférico Enviar sinal End

Software Thread Hardware Delegate

Thread

...

Figura 3.3: Caso geral de um thread software e hardware

inicio do processamento e os restantes sinais representam os dados de entrada como saída terá que ter um sinal de END que indica o final do processamento, um sinal WENABLE que indica a escrita dos dados de saída na memória para que o barramento virtual QEMU tenha acesso a esses dados, os restantes sinais representam sinais de dados de saída. Estes sinais descritos dizem respeito a um processo de hardware de cada IP. Um processo de hardware consiste num bloco independente de processamento de dados em hardware, isto é, cada IP poderá ser descrito por vários processos de hardware em que cada processo de hardware consiste numa operação especifica sobre os dados dados. Por exemplo, no caso de uma FIFO que é composta por dois processos um push e um pop, cada um destes processos irá conter os seus sinais de entrada e de saída pois tratam-se processos que podem operar em paralelo. Os sinais RST e CLK dizem respeito aos sinais de

reset e clock respectivamente.

3.3

Funcionalidades e Restrições

Como o objectivo desta dissertação passa pelo desenvolvimento de um repositório compatível com o standard IP-XACT para um domínio especifico é importante fazer um levantamento das funcionalidades e restrições do sistema em causa.

Uma das principais funcionalidades do sistema, consiste em a framework ser capaz de interagir com um repositório compatível com o standard IP-XACT mantendo sempre a integridade dos ficheiros IP-XACT. Para isso será necessário implementar mecanismos de validação, leitura e escrita, impossibilitando desta forma a escrita de ficheiros IP-XACT que não sigam as restrições impostas pelo standard.

A framework necessita de ser direcionada ao design flow definido por forma a au-mentar o grau de abstração do utilizador. Todos os IP que constituem o repositório devem seguir esta metodologia, dando assim liberdade ao utilizador de mapear os IP (hardware ou software) no design.

A framework também deverá fornecer ao designer um pacote de ferramentas im-portantes ao desenvolvimento de um co-design hardware/software, designado neste projeto de gerador de toolchain. Desta forma o processo de configuração é agili-zado e junta numa só ferramenta todos os mecanismos necessários à elaboração de um projeto desta natureza.

No que toca à fase de verificação a framework dará suporte a um ambiente de co-simulação, que permitirá a validação integral do sistema a um nível funcional. Para isso será necessário dar suporte ao QEMU e ao ModelSim gerando os fichei-ros necessários para que seja possível as trocas dedados entre as ferramentas de simulação de hardware e software.

Na figura 3.5 está representado a visão geral do sistema onde estão representados os vários módulos da framework, assim como as suas interações no sistema.

A framework pode ser dividida em 4 módulos independentes: 1. Base Dados IP--XACT 2. Gestor de Repositório 3. Gerador de Toolchain 4. Ambiente de Co-Si-mulação

No primeiro módulo serão modeladas e implementadas as classes de acordo com o

standard IP-XACT. No segundo módulo será implementado um gestor de

reposi-tório capaz de gerir os IP presentes no reposireposi-tório. No terceiro modulo será criado um gerador de toolchain que permitirá ao utilizador ter acesso a todas as