TRABALHO DE CONCLUSÃO DE CURSO
CONCEPÇÃO E SIMULAÇÃO EM ALTO NÍVEL
DE SISTEMAS ELETRÔNICOS PARA APLICAÇÕES DE RSSF, COM SÍNTESE DIRETA EM CIRCUITOS INTEGRADOS
Bruno Bezerra Marques
Brasília, julho de 2015
UNIVERSIDADE DE BRASÍLIA
FACULDADE DE TECNOLOGIA
UNIVERSIDADE DE BRASÍLIA Faculdade de Tecnologia
TRABALHO DE CONCLUSÃO DE CURSO
CONCEPÇÃO E SIMULAÇÃO EM ALTO NÍVEL
DE SISTEMAS ELETRÔNICOS PARA APLICAÇÕES DE RSSF, COM SÍNTESE DIRETA EM CIRCUITOS INTEGRADOS
Bruno Bezerra Marques
Relatório submetido ao Departamento de Engenharia Elétrica como requisito parcial para obtenção do grau de Bacharel em Engenharia de Computação
Banca Examinadora
Prof. José Camargo da Costa, ENE/UnB Orientador
Prof. Gilmar Silva Beserra, FGA/UnB Co-orientador
Prof. Renato Coral Sampaio, FGA/UnB Examinador interno
Prof. Ricardo Pezzoul Jacobi, CiC/UnB Examinador interno
Dedicatória Dedico este trabalho aos meus pais.
Bruno Bezerra Marques
Agradecimentos
Agradeço a todos, que de forma direta ou indireta, contribuiram para a realização deste trabalho e para minha formação acadêmica.
Bruno Bezerra Marques
RESUMO
Este trabalho propõe o desenvolvimento de rede de sensores sem fio (RSSF) a partir da integra- ção do framework ADRIX (Ambiente de Desenvolvimento de Rede de sensores sem fio Inteligente) com outras ferramentas para validação e implementação das indicações de hardware resultantes para aplicações de RSSF.
A validação da funcionalidade pode ser feita via simulações utilizando bibliotecas de modelos em SystemC-TLM e/ou simuladores de RSSF, como o IDEA1. Já para a implementação, a proposta inclui também a integração com o CTOS (C-to-Silicon), ferramenta de síntese em alto nível que permite a implementação automatizada de alguns blocos digitais dos nós sensores da rede, inicialmente descritos em SystemC.
No desenvolvimento deste projeto, foram realizados testes com a ferramenta IDEA1 para si- mulação das RSSF, e também foram utilizadas Ferramentas Cadence, para o processo de síntese em alto nível. Neste último caso, para demonstrar a validade da proposta, o processo completo de síntese foi realizado utilizando uma ULA (Unidade Lógica Aritmética) descrita em SystemC.
O código RTL e o layout foram gerados de forma automatizada e os mesmos foram validados com sucesso.
ABSTRACT
This work proposes the development of wireless sensor network (WSN) from the ADRIX (In- telligent wireless Sensors Network Development Environment) framework integration with other tools for validation and implementation of the resulting hardware indications for WSN applicati- ons.
The validation of the functionality can be made via simulations using models of libraries in SystemC-TLM and/or WSN simulators like IDEA1. As for implementation, the proposal also includes integration with CTOS (C-to-Silicon), synthesis tool at high level which enables automated deployment of some digital blocks of the sensor nodes of the network, initially described in SystemC.
In developing this project, tests were performed with IDEA1 tool for simulation of WSN, and were also used Cadence tools for the synthesis process at a high level. In the latter case, to demonstrate the validity of the proposal, the complete process of synthesis was performed using an ALU (Arithmetic Logic Unit) described in SystemC. The RTL code and the layout have been generated in an automated manner and they were successfully validated.
SUMÁRIO
1 Introdução . . . . 1
1.1 Contextualização... 1
1.2 Motivação ... 2
1.3 Objetivos do projeto ... 2
1.4 Apresentação do manuscrito ... 2
2 Revisão Bibliográfica . . . . 3
2.1 Rede de Sensores Sem Fio ... 3
2.1.1 Introdução ... 3
2.1.2 Arquitetura dos Nós Sensores ... 4
2.1.3 Funcionalidades e Classificação ... 5
2.1.4 Aplicações ... 6
2.2 ADRIX ... 6
2.3 Linguagem de Descrição de Hardware (HDL) ... 8
2.3.1 Verilog... 8
2.3.2 SystemC ... 8
2.4 LDCI Modeling Library ... 9
2.5 IDEA1... 10
2.6 Síntese em Alto Nível e Ferramentas Cadence ... 12
2.6.1 Síntese em Alto Nível ... 12
2.6.2 Cadence SimVision Debug... 12
2.6.3 C-to-Silicon Compiler (CTOS)... 12
2.6.4 Encounter RTL Compiler ... 13
2.6.5 SoC Encounter RTL-to-GDSII System ... 14
3 Metodologia . . . . 16
3.1 Introdução ... 16
3.2 Fluxo de Desenvolvimento ... 17
4 Desenvolvimento . . . 19
4.1 Introdução ... 19
4.2 Inclusão do MipsUnB ao Ambiente IDEA1 ... 19
4.3 Síntese do MipsUnB ... 22
4.4 Síntese da ULA ... 23
4.5 Resultados e discussões ... 26
5 Conclusões . . . 29
6 Agradecimentos . . . 31
REFERÊNCIAS BIBLIOGRÁFICAS . . . . 32
Anexos . . . 34
I Utilização do Simulador de RSSF IDEA1 . . . . 35
II Utilização da Ferramenta C-to-Silicon Compiler (CTOS) . . . . 37
III Utilização das Ferramentas NC Launch e SimVision Debug . . . 39
IV Utilização da Ferramenta Encounter RTL Compiler . . . . 42
V Utilização da Ferramenta SoC Encounter RTL-to-GDSII System . . . . 45
VI Códigos Fonte . . . . 49
VI.1 main.cpp ... 49
VI.2 ula.cpp ... 50
VI.3 ula.h ... 52
VI.4 ula_rtl.v ... 53
VI.5 Ula_TB.v ... 55
LISTA DE FIGURAS
2.1 Estabelecimento de uma RSSF [1] ... 4
2.2 Arquitetura de um nó sensor de uma RSSF [2] ... 5
2.3 Arquitetura ADRIX [3] ... 7
2.4 Questionário ADRIX [3] ... 7
2.5 Solução apresentada pelo ADRIX [3] ... 8
2.6 Interface Gráfica (GUI) do IDEA1 [4]... 10
2.7 Arquitetura do IDEA1 [4] ... 11
2.8 Fluxo ASIC do CTOS [5] ... 13
3.1 Fluxo do Projeto Digital ... 16
3.2 Fluxo de Desenvolvimento ... 18
4.1 GUI de Configuração da RSSF... 20
4.2 GUI após a simulação da RSSF... 20
4.3 GUI de configuração modificada ... 21
4.4 Esquemático da ULA ... 23
4.5 Fragmento do Testbench da ULA ... 25
4.6 Formas de Onda dos Resultados ... 27
4.7 Continuação da Figura 4.6 ... 27
4.8 Layout final da ULA ... 27
4.9 Resumo do layout da ULA ... 28
4.10 Resumo do layout da ULA ... 28
I.1 GUI de Configuração da RSSF... 35
I.2 GUI do IDEA1 após a simulação ... 36
II.1 Trecho do código fonte do arquivo ula_rtl.v ... 38
III.1 GUI pós simulação ... 40
III.2 Resultados da simulação do Verilog-RTL da ULA ... 41
III.3 Continuação da Figura III.2 ... 41
IV.1 GUI do NC Launch após a simulação da síntese lógica ... 43
IV.2 Resultados da Simulação após a síntese lógica ... 44
IV.3 Continuação da Figura IV.2 ... 44
V.1 Layout da ULA ... 46
V.2 GUI do NC Launch após a simulação da síntese física... 47
V.3 Resultados da Simulação após a síntese física ... 48
V.4 Continuação da Figura V.3 ... 48
LISTA DE TABELAS
2.1 Microcontroladores, Transceptores e Protocolos de Comunicação disponíveis no IDEA1 ... 10 4.1 Comparativo entre as versões 2011 e 2015 do IDEA1 ... 21 4.2 Funcionalidades da ULA... 24
LISTA DE SÍMBOLOS
Siglas ADL ADRIX ASIC CI CTOS ENE FPGA GUI HDL IDE INL LDCI MIPS RF RISC RSSF RTL SCNSL SoC TLM ULA UnB
Architecture Description Language
Ambiente de Desenvolvimento de Rede de sensores sem fio Inteligente Application Specific Integrated Circuit
Circuitos Integrados C-to-Silicon Compiler
Departamento de Engenharia Elétrica Field Programmable Gate Array Graphical User Interface
Hardware Description Language Integrated Development Environment Institut des Nanotechnologies de Lyon
Laboratório de Dispositivos e Circuitos Integrados Microprocessor without Interlocked Pipeline Stage Rádio Frequência
Reduced Instruction Set Computer Rede de Sensores Sem Fio
Register Transfer Level
SystemC Network Simulation Library System-on-Chip
Transaction Level Modeling Unidade Lógica Aritmética Universidade de Brasília
Capítulo 1
Introdução
Este capítulo apresenta inicialmente a contextualização do trabalho realizado. Em seguida são apresentadas a motivação, os objetivos e a organização do manuscrito.
1.1 Contextualização
A evolução da microeletrônica, tornou viável a integração de circuitos de radiofrequência (RF), analógicos e digitais em um único circuito integrado (CI), resultando nos Sistemas em Chip (SoCs).
Apesar de sua maior complexidade, um Sistema em Chip (SoC) possui diversas vantagens, como por exemplo: a redução de tamanho, o baixo custo (quando produzidos em escala), o baixo consumo de energia e o aumento de potência [1].
O Laboratório de Dispositivos e Circuitos Integrados (LDCI), do departamento de Engenharia Elétrica (ENE) da Universidade de Brasília (UnB), vem desenvolvendo SoCs para aplicação em Redes de Sensores sem Fio (RSSF). As RSSF são redes compostas por um conjunto de nós sensores com capacidade de aquisição e processamento de informações, e possuem também meios para a comunicação entre si, via radiofrequência. Os nós sensores são compostos basicamente por unidades de energia, processamento, sensoriamento e comunicação [6].
O LDCI também vem desenvolvendo uma ferramenta para auxiliar no desenvolvimento de projetos de RSSF, o ADRIX, Ambiente de Desenvolvimento de Rede de sensores sem fio Inteligente.
Essa ferramenta tem o objetivo de fornecer um suporte aos projetistas de RSSF, visando obter ganhos com a redução no tempo e nos custos do desenvolvimento de seus projetos, a partir do emprego de técnicas de Inteligência Artificial (IA).
O ADRIX permite obter especificações de inúmeras RSSF que sejam compatíveis com os re- quisitos do projetista, cabendo ao projetista realizar as simulações das diversas possibilidades fornecidas pela ferramenta, e escolher aquela que melhor satisfaz suas necessidades. Caso a es- pecificação escolhida seja uma plataforma de componentes comerciais, o projetista pode adquirir os componentes e montar a rede, caso seja uma plataforma de componentes dedicados o proje- tista pode realizar a implementação da rede via uma Aplicação Específica de Circuitos Integrados
(ASIC) [3].
1.2 Motivação
Para a continuidade do processo de desenvolvimento das RSSF é preciso realizar etapas de simulação e implementação das soluções das redes especificadas pelo ADRIX. Para isso é preciso utilizar outras ferramentas.
A validação das funcionalidades da RSSF é feita por simulação, utilizando simuladores de RSSF, como o IDEA1 [7]. O processo de implementação dos blocos digitais da RSSF pode ser feito com o auxílio de ferramentas de síntese, como por exemplo as da Cadence Desing System [8], empresa que desenvolve tecnologias para a concepção de Circuitos Integrados (CIs) e SoCs. Entre essas ferramentas destaca-se o CTOS (C-to-Slicon Compiler), ferramenta que tem como principal funcionalidade realizar a síntese em alto nível de blocos inicialmente descritos em SystemC.
1.3 Objetivos do projeto
O desenvolvimento deste trabalho tem como objetivos:
• Adicionar módulos dedicados, presentes na LDCI_Modeling_Library, ao simulador IDEA1, e realizar simulações de RSSF, utilizando os novos módulos.
• Utilizar ferramentas Cadence para gerar, de forma automatizada, um modelo em RTL a partir de um modelo descrito em SystemC. Após a geração do modelo RTL, realizar suas sínteses: física e lógica, afim de se gerar o layout do módulo.
1.4 Apresentação do manuscrito
O Capítulo 2 apresenta uma breve revisão bibliográfica sobre os assuntos mais relevantes para o desenvolvimento deste trabalho, como por exemplo, RSSF, ADRIX, IDEA1, Linguagens de Descrição de Hardware (HDLs) e Ferramentas Cadence. O Capítulo 3 faz uma abordagem da me- todologia utilizada para o desenvolvimento do projeto. O desenvolvimento, os resultados obtidos e suas análises são apresentados no Capítulo 4. O Capítulo 5 apresenta as conclusões e suges- tões para trabalhos futuros. O capítulo 6 faz alguns agradecimentos especiais. Este documento apresenta ainda alguns Anexos. O Anexo I mostra a utilização da ferramenta IDEA1 para as simulações de RSSF. A utilização das ferramentas Cadence é apresentada nos Anexo II, III, IV e V. E finalmente no Anexo VI são apresentados os códigos de maior relevância desenvolvidos pelo autor para a realização deste projeto.
Capítulo 2
Revisão Bibliográfica
Este capítulo apresenta uma breve revisão dos assuntos mais relevantes para o desenvolvimento deste trabalho. Primeiramente são apresentadas as RSSF, com suas principais características, ar- quitetura de seus nós sensores e suas aplicações. A seguir são apresentados conceitos e definições relativos à SystemC e HDLs e posteriormente são apresentadas as ferramentas utilizadas no de- senvolvimento deste projeto: ADRIX, IDEA1 e as Ferramentas Cadence.
2.1 Rede de Sensores Sem Fio
2.1.1 Introdução
Uma RSSF pode ser vista como um tipo de rede móvel ad hoc (MANET – Mobile Ad hoc Network) e como uma das vertentes da computação ubíqua. Pode ser usada para monitorar e controlar um determinado ambiente, em geral uma RSSF é formada por centenas ou milhares de dispositivos autônomos que são projetados em pequenas dimensões (cm3 ou mm3), chamados de nós sensores. Os nós individualmente possuem pouca capacidade computacional e de energia, mas em conjunto são capazes de realizar uma grande tarefa [9].
Quando comparadas a redes de computadores apresentam diversas diferenças: possuem um grande número de elementos distribuídos, operam sem a intervenção direta do homem, têm res- trições severas de energia e devem possuir mecanismos de autogerenciamento, devido a problemas de perda dos nós e de falha de comunicação dos nós [9].
Para o estabelecimento de uma RSSF os nós da rede podem ser lançados sobre áreas remotas (reservas ambientais, oceanos, vulcões, rios, florestas etc.), e sem a intervenção de técnicos ou operadores formam uma rede sem fio ad hoc, que coleta os dados sobre os fenômenos de interesse, realiza o processamento local, e dissemina as informações para um ponto de acesso através do qual a rede comunica-se com outras redes e usuários [2]. Os nós de RSSF podem ser distribuídos de forma ordenada ou aleatória, e podem ter uma localização fixa ou dinâmica. A Figura 2.1 apresenta as etapas iniciais para o estabelecimento de uma rede de sensores sem fio.
Figura 2.1: Estabelecimento de uma RSSF [1]
2.1.2 Arquitetura dos Nós Sensores
Um nó sensor é basicamente composto por uma fonte de alimentação, módulo computacional composto por memória e processador, tranceptor e uma unidade de sensores. A Figura 2.2 apre- senta um diagrama conceitual para a arquitetura de um nó sensor básico de uma RSSF, com seus principais componentes [2]:
• Processador - responsável por controlar e processar as atividades realizadas pelo nó da rede.
• Memória - responsável em armazenar o software da aplicação e as demais informações do nó da rede.
• Transceptor - responsável em permitir a comunicação e a troca de dados entre os nós da rede.
• Sensor - responsável em obter os dados e informações necessárias para o funcionamento da aplicação. Os sensores podem ser: acústicos, sísmicos, infravermelhos, térmicos etc.
• Bateria - responsável em fornecer energia para o funcionamento do nó.
Figura 2.2: Arquitetura de um nó sensor de uma RSSF [2]
2.1.3 Funcionalidades e Classificação
As RSSF apresentam diversas características e funcionalidades, as principais são:
• Grande diversidade de sensores disponíveis no mercado.
• Possibilidade de um nó possuir inúmeros sensores.
• Mobilidade dos sensores e nós.
• Capaz de determinar, controlar e monitorar valores de determinados parâmetros, a partir de seus sensores de temperatura, velocidade, luminosidade, pressão, umidade, frequência cardíaca etc.
• Possibilita o rastreamento e a localização de objetos.
A classificação de uma RSSF depende de seus objetivos e da área de sua aplicação. Sua aplica- ção interfere diretamente nas suas funcionalidades, na arquitetura, na quantidade e na distribuição de seus nós, no protocolo de comunicação dos nós etc. As RSSF podem ser classificadas de acordo com a configuração, o sensoriamento e o tipo de comunicação da rede [9].
• Configuração - homogênea x heterogênea (composição); hierárquica x plana (organização), estacionária x móvel (mobilidade), balanceada x densa x esparsa (distribuição)
• Sensoriamento - periódica x contínua x tempo real (coleta de dados)
• Comunicação - simplex xhalf-duplex xfull-duplex (transmissão)
2.1.4 Aplicações
Devido a essas características e funcionalidades as RSSF possuem um enorme potencial para serem aplicadas em diferentes áreas e setores do mercado, entre os principais exemplos de aplicações das RSSF destacam-se [1]:
• Ambiente – monitorar o valor de variáveis ambientais em locais como: prédios, residências, florestas e oceanos.
• Tráfego – monitorar o tráfego de veículos em uma determinada rodovia.
• Segurança – promover a segurança em centros comerciais e estacionamentos.
• Saúde – monitorar o funcionamento de órgãos como o coração e detectar presença de subs- tâncias nocivas presentes no corpo humano ou em animais.
• Militar – detectar movimentos dos inimigos, explosões e presença de materiais perigosos como gás venenoso e radiação.
Para auxiliar na definição e especificação de projeto de RSSF, algumas ferramentas podem ser utilizadas, entre elas destaca-se o ADRIX, ferramenta em desenvolvimento pelo LDCI da UnB.
2.2 ADRIX
O Ambiente de Desenvolvimento de Rede de sensores sem fio Inteligente, o ADRIX, é um framework, desenvolvido em Java, que possui uma GUI (do inglês, Interface Gráfica do usuário) amigável, que facilita a utilização da ferramenta por parte do usuário. O ADRIX tem como principal objetivo proporcionar ao projetista uma indicação de hardware mais adequada para a aplicação de RSSF desejada. As saídas obtidas pelo ADRIX podem ser utilizadas em simuladores de RSSF já existentes, como por exemplo o NS-2, ou em modelagens em alto nível, para realizar a verificação e a validação das funcionalidades do projeto especificado [3].
Para a utilização da ferramenta é preciso que o usuário crie uma conta de acesso. Ao iniciar a sessão no ADRIX o usuário responde um questionário através de sua GUI, atualmente composto por 20 questões e cada uma delas com suas respectivas opções de respostas pré definidas. As respostas são capturadas, processadas e armazenas em um banco de dados, posteriormente essas informações são utilizadas como entrada de dados para que a ferramenta gere como saída, especi- ficações de RSSF que atendam os requisitos do usuário. A Figura 2.3 apresenta um diagrama da arqutetura do ADRIX [3].
A Figura 2.4 apresenta parte do questionário a ser respondido pelo o usuário, enquanto que a Figura 2.5 apresenta um trecho do relatório final das soluções dadas pelo ADRIX para uma determinada RSSF. São elementos das especificações fornecidas pelo ADRIX [3]:
• Arquitetura: configuração e topologia da rede
• Cobertura e conectividade: quantidade de nós sensores, o alcance do transceptor RF e o protocolo de comunicação a serem utilizados pela rede
• Especificação formal da plataforma: taxa de transmissão, transceptor, frequência, memória e processador.
Figura 2.3: Arquitetura ADRIX [3]
Figura 2.4: Questionário ADRIX [3]
Figura 2.5: Solução apresentada pelo ADRIX [3]
Os módulos (microcontroladores, tranceptores e protocolos) presentes no banco de dados do ADRIX são desenvolvidos em Linguagens de Descrição de Hardware, para fins de simulação e validação da rede proposta.
2.3 Linguagem de Descrição de Hardware (HDL)
A Linguagem de Descrição de Hardware (HDL) é um tipo de linguagem de programação de alto nível que permite descrever todas as características importantes em um sistema lógico digital [10]. Dentre as HDLs mais utilizadas estão as linguagens Verilog e SystemC.
2.3.1 Verilog
O Verilog é uma linguagem de descrição de hardware que pode ser usado para modelar e simular um sistema lógico, sua descrição pode ser totalmente funcional e permite que o sistema projetado seja validado antes de sua concepção [11].
O fluxo de projeto em Verilog HDL se dá basicamente da seguinte maneira: primeiramente é realizada a descrição da arquitetura dos módulos e de suas funcionalidades, posteriormente ou paralelamente a esta etapa são descritos, também em Verilog HDL, os testbenches, programas utilizados para simular e validar as funcionalidades especificadas pelos módulos. Após sua valida- ção os módulos poderão ser sintetizados e fabricados. Atualmente existem 3 tipos de sínteses: a comportamental, a de alto nível e a em nível RTL, a última sendo a mais comum [11].
2.3.2 SystemC
C++ é uma linguagem orientada a objetos que permite a abstração de dados e a elaboração de projetos hierárquicos. SystemC é uma biblioteca C++ utilizada para a descrição de hardware que contempla níveis sistêmicos de abstração de projeto. Por ter mecanismos que permitem a modelagem em níveis mais altos de abstração, é mais do que uma simples linguagem de descrição
de hardware [12].
O uso de SystemC permite a descrição de hardware e software em um ambiente homogêneo, facilitando o processo de compreensão, descrição e validação de projeto. Esta linguagem facilita o processo de modelagem de hardware por possuir características como tipos de dados próprios para definição de hardware (sc_lv), estruturas (sc_module) e processos (sc_method) que flexibilizam a descrição de paralelismo natural em hardware. A base fornece um núcleo de simulação orientado a objeto e qualquer programa pode ser compilado usando um compilador C++ e produzir um arquivo executável [13].
O SystemC permite também a descrição do sistema em diferentes níveis de abstração e um deles é o TLM, Transaction Level Modeling. O TLM é uma abordagem em alto nível para a modelagem de sistemas digitais. Os meios de comunicação entre os módulos são modelados como canais, fazendo com que os módulos se comuniquem através de transações. Essas transações são geradas por funções chamadas pelas interfaces dos módulos. O uso do SystemC/TLM permite aumentar a velocidade de simulação do sistema [13].
Atualmente o LDCI tenta otimizar o processo de simulação de RSSF utilizando a LDCI Mo- deling Library, uma biblioteca de modelos descritos em SystemC/TLM para fins de validação das funcionalidades dos sistemas por meio de simulações em alto nível.
2.4 LDCI Modeling Library
O LDCI utiliza atualmente o processo básico de simulações para modelos em SystemC/TLM para realizar as simulações das RSSF desenvolvidas pelo laboratório, porém é utilizada uma bi- blioteca, visando otimizar o processo de simulação das RSSF, a LDCI Modeling Library.
A LDCI Modeling Library foi criada a partir de diversos trabalhos [14, 15, 16] desenvolvidos pelo laboratório, para ser utilizada no desenvolvimento de plataformas virtuais de SoCs que estão sendo implementados pelo LDCI. Com ela é possível simular sistemas mistos, realizar o desen- volvimento de softwares embarcados e também fazer uma estimativa preliminar do consumo de potência da plataforma utilizada.
Os módulos de processadores presentes na LDCI Modeling Library são: MipsUnB - proces- sador Mips1 gerado pelo ArchC e modificado [15] e o TLM2_RISC16 - processador RISC de 16 bits. A biblioteca também dispõe de modelos de periféricos, como timers, transceptor, bloco reconfigurável, etc.
Uma das limitações presentes com o uso da LDCI Modeling Library é de que as configurações para as simulações devem ser feitas manualmente, pela edição dos códigos dos módulos desenvol- vidos e dos arquivos makefiles gerados. Uma medida que poderia ser adotada, afim de otimizar ainda mais o processo de simulação de RSSF, seria de utilizar simuladores específicos de RSSF.
2.5 IDEA1
O IDEA1 é um framework para a simulação de RSSF modeladas em SystemC/TLM. Assim como o IDEA1, existem outros simuladores de RSSF, como por exemplo: NS-2, OMNeT++, SCNSL, TOSSIM, ATLeS-SN e SNOPS , mas o IDEA1 foi o primeiro simulador de RSSF a ser validado a partir de inúmeras medições experimentais. Os resultados obtidos pelo IDEA1 foram comparados aos resultados do simulador NS-2, o mais utilizado para a simulação de redes MANET, e mostraram que com o IDEA1 se tem uma simulação mais rápida e mais detalhada da rede.[4, 17].
Figura 2.6: Interface Gráfica (GUI) do IDEA1 [4]
O framework desenvolvido pelo INL, Instituto de Nanotecnologia de Lyon, é uma ferramenta de software livre e está disponível para download no site: www.idea1inl.free.fr . Sua primeira versão conta com uma interface gráfica do usuário (GUI), que foi desenvolvida para facilitar o estabelecimento do sistema, a visualização da topologia de rede, a configuração e o controle da simulação e a análise dos resultados [18]. A Figura 2.6 mostra a GUI do simulador IDEA1, já a Tabela 2.1 apresenta os microcontroladores e os tranceptores comerciais além dos protocolos de comunicação disponíveis na ferramenta para a simulação de RSSF.
Tabela 2.1: Microcontroladores, Transceptores e Protocolos de Comunicação disponíveis no IDEA1
Microcontroladores Tranceptores Protocolos de Comunicação
ATMEL ATMega128 Texas Instrument CC1000 TDMA
M icrochipP IC16LF88 Texas Instrument CC2420 IEEE 802.15.4
T.I MSP430 Microchip MRF24J40 CSMA-CA Slotted
CSMA-CA N-Slotted
Com o IDEA1 é possível obter informações precisas da rede, e a partir delas avaliar o desem- penho da RSSF em relação a taxa de entrega dos pacotes, o tempo de latência de transmissão e seu consumo de energia [18]. O IDEA1 utiliza um modelo de rede herdada do SCNSL (SystemC Network Simulation Library), composto por: nós, nós-proxy e a rede sem fio. Um nó-proxy atua como uma interface entre seu respectivo nó e a rede [4]. Mas diferentemente do SCNSL o IDEA1 suporta a simulação de RSSF heterogêneas, ou seja, redes que contém nós com diferentes carac- terísticas, como por exemplo nós com diferentes microcontroladores [17]. A Figura 2.7 apresenta a arquitetura geral do simulador IDEA1[4].
Figura 2.7: Arquitetura do IDEA1 [4]
As principais características e funcionalidades do IDEA1 são [18]:
• Escalabilidade – o tempo de simulação não aumenta na mesma proporção do aumento do número de nós da RSSF.
• Consumo de Energia – o IDEA1 é capaz de prever o consumo de energia dos nós da RSSF, pelo fato de seus módulos serem todos comerciais. O cálculo do consumo de energia é baseados nos datasheets dos componentes dos nós.
• Extensibilidade – capaz de modificar os módulos existentes e adicionar novos módulos ao simulador.
• Suporte a redes heterogêneas – suporta a simulações de redes heterogêneas.
• Usabilidade – o uso de uma GUI e da Linguagem C++ como padrão facilitam o uso do simulador.
Caso os nós sensores sugeridos pelo ADRIX sejam compostos por módulos não comerciais, o projetista terá a opção de implementá-los seguindo o fluxo de projeto ASIC com as ferramentas Cadence, após a validação por meio de simulações em alto nível.
2.6 Síntese em Alto Nível e Ferramentas Cadence
2.6.1 Síntese em Alto Nível
A Síntese em Alto Nivel é a transformação de uma especificação feita em um determinado nível de abstração para uma outra descrição, a um nível mais próximo da implementação física do modelo. Ela consiste em encontrar uma estrutura que implemente o comportamento do modelo, inicialmente descrito em uma HDL, rspeitando suas especificações, restrições e objetivos [19]. Para isso se utilizam ferramentas de síntese em alto nível como o CTOS (C-to-Silicon). O layout do modelo sintetizado é gerado a partir dos processos de síntese lógica e síntese física.
A síntese lógica é o processo utilizado para transformar o modelo em RTL em uma descrição estrutural deste mesmo modelo, mapeado utilizando apenas portas lógicas. Essa descrição é chamada de netlist. Sua implementação pode ser feita tanto para ASIC como para FPGA (Field Programmable Gate Array). Já a Sintese Fisica consiste na geração de um layout para o modelo sintetizado e dos arquivos com as especificações físicas necessárias para a sua fabricação [20].
A Cadence Design Systems é uma empresa americana da área de eletrônica, entre suas prin- cipais atividades está a produção de frameworks para auxílio a concepção de CIs e SoCs. Nos tópicos a seguir serão apresentadas as principais ferramentas da empresa que foram utilizadas nos processos de síntese desenvolvidos neste projeto [8].
2.6.2 Cadence SimVision Debug
O Cadence SimVision Degub é uma ferramenta utilizada para depurar modelos digitais, analó- gicos ou mistos, escritos nas linguagens Verilog, VHDL, SystemVerilog, Verilog-AMS, SystemC, C ou C++. A partir da formulação de testbenches (arquivos com diretivas de simulação, utilizados para a validação do sistema) é possível realizar e gerenciar simulações para o modelo desenvolvido.
Entre as principais funcionalidades do SimVision Debug, destacam-se [21]:
• Visualização do esquemático e das formas de onda, das entradas e saídas, do sistema.
• Definição de pontos de parada (breakpoints) e de valores arbitrários, para uma determinada posição de memória, durante a simulação.
2.6.3 C-to-Silicon Compiler (CTOS)
O CTOS é uma ferramenta capaz de gerar, de forma automática, um código Verilog RTL sintetizável a partir de uma descrição de hardware feita em SystemC/TLM. Entre as principais
características e funcionalidades do CTOS estão [5]:
• O SystemC descreve apenas a funcionalidade do sistema, enquanto o CTOS implementa sua micro-arquitetura, permitindo a exploração de seus registradores, memória, loops, clock. A ferramenta permite também a visualização: do esquemático do fluxo de dados, de possíveis caminhos críticos do sistema, dos códigos fontes de entrada e saída do sistema.
• Suporte para as linguagens IEEE SystemC e OSCI TLM 1.0.
• Fornece uma GUI para a síntese, análise e depuração do sistema, dando ao usuário um excelente gerenciamento e visibilidade do processo da síntese em alto nível.
• Pode ser utilizado para projetos em ASIC ou em FPGA. Para FPGAs a ferramenta suporta dispositivos da Xilinx e da Altera. A Figura 2.8 apresenta o diagrama do fluxo ASIC do CTOS.
Figura 2.8: Fluxo ASIC do CTOS [5]
2.6.4 Encounter RTL Compiler
O Encounter RTL Compiler é uma ferramenta utilizada para realizar a síntese lógica do sistema.
O objetivo desta etapa é transformar o código RTL, desenvolvido em HDL, para o nível de uma descrição estrutural em portas lógicas, os Netlists. O Encounter RTL compiler tem como principais características e funcionalidades[22]:
• Tem como entrada o código RTL e como saída um Netlist, que descreve a conectividade entre os componentes do sistema.
• Realizar a otimização simultânea de temporização e área, visando reduzir o consumo de energia do chip e aumentar sua qualidade e eficiência.
No processo da síntese lógica, o Encouter RTL utiliza uma biblioteca de células de uma de- terminada tecnologia, como por exemplo a AMS 0.35 µm e a TSMC 0.18µm, afim de mapear as funcionalidades do código RTL. Entre os arquivos de Uma biblioteca de células estão [20]:
• LIB (.lib) - contém informações sobre temperatura, timing, potência e área dos módulos da tecnologia.
• LEF (.lef) - contém as informações de resistência e capacitância (RC), e demais caracterís- ticas físicas dos elementos. Este arquivo é utilizado na síntese física.
• Tech files (.tch e .ict) - descrevem as características da tecnologia.
• CapTable (.captbl) - é gerado a partir dos arquivos LEF e .ict. Contém informações de RC dos elementos da tecnologia.
• Std-cells HDL - modelo dos elementos da tecnologia descritos em HDL.
• GDSII - contém as informações necessárias para a fabricação dos elementos da tecnologia.
2.6.5 SoC Encounter RTL-to-GDSII System
O SoC Encounter RTL-to-GDSII System é uma ferramenta utilizada para realizar a síntese física do sistema. O objetivo desta etapa é gerar o layout do sistema para a fabricação de seu chip.
As principais etapas realizadas pela ferramenta e suas respectivas funcionalidades estão descritas a seguir[23] [20]:
• Floorplanning - posicionamento das macros no layout, visando um melhor desempenho, seja de timing, potência ou área.
• Powerplanning - configurar a distribuição das redes de alimentação do layout (Vdd e Gnd), afim de se ter uma distribuição homogênea.
• Placement - distribuição das std-cells no layout. A distribuição é feita de modo que as std-cells fiquem próximas umas das outras, visando um melhor desempenho do sistema.
• Clock Tree Synthesis (CTS) - distribuição homogênea dos sinais de Clock nos diversos pontos de captura do Clock no layout. Essa distribuição visa minimizar os problemas de timing.
• Routing - conexão física, através de fios, dos pinos e macros do layout. Após o roteamento é preciso fazer uma análise de conectividade, para saber se as conexões foram realizadas com sucesso.
Após o estudo dos temas mais relevantes, das tecnologias e ferramentas a serem utilizadas é preciso definir um método de trabalho. O capítulo 3 apresenta a metodologia adotada para a realização deste projeto.
Capítulo 3
Metodologia
Este capítulo apresenta a metodologia proposta para o desenvolvimento de blocos digitais de RSSF a partir da ferramenta ADRIX. Inicialmente é apresentado um fluxo de projeto de sistemas digitais, e posteriormente são descritas as etapas a serem realiazdas em cada uma das fases do projeto.
3.1 Introdução
A metodologia usada para a realização deste trabalho baseou-se na metodologia de desenvol- vimento de projetos de sistemas digitais. A Figura 3.1 apresenta a metodologia proposta.
Figura 3.1: Fluxo do Projeto Digital
Ela se inicia com a definição das especificações funcionais e comportamentais do projeto, e termina com a simulação pós layout, afim de garantir que todas as etapas intermediárias foram realizadas com sucesso, confirmando assim o bom funcionamento do sistema desenvolvido.
3.2 Fluxo de Desenvolvimento
Esta seção apresenta o fluxo de desenvolvimento proposto para projetos de RSSF. A Figura 3.2 mostra o diagrama das atividades a serem realizadas durante o desenvolvimento do projeto. As etapas representadas por linhas tracejadas, correspondem as etapas não realizadas neste trabalho, enquanto que as representadas por linhas contínuas foram de fato executadas.
O fluxo é iniciado com a identificação de um problema ou necessidade para uma determinada aplicação, definindo-se por exemplo: os objetivos do projeto e as funcionalidades e requisitos do sistema. Em seguida o projetista deve responder ao questionário da ferramenta ADRIX, através de sua GUI. Ao final do processo são fornecidas ’N’ diferentes especificações de RSSF, como soluções para o projeto.
Dadas as soluções possíveis, o projetista realiza a simulação de todas as ’N’ especificações de RSSF fornecidas pelo ADRIX. Essas simulações podem ser feitas com o simulador de RSSF, IDEA1, ou pelo processo básico de simulações de SystemC/TLM, podendo ser possível a utilização da LDCI_Modeling_Library. A partir da análise dos resultados obtidos, o projetista escolhe a solução que apresenta o melhor custo - benefício. Caso a escolha for por uma RSSF que utiliza ape- nas componentes comerciais é possível comprar os componentes desejados, caso contrário é preciso fabricar os componentes dedicados. Para o caso de RSSF dedicados, focou-se no desenvolvimento de blocos digitais dos nós sensores.
O desenvolvimento dos blocos digitais dos nós sensores é realizado com o auxílio das ferra- mentas Cadence. Inicialmente é preciso converter os códigos dos módulos descritos em linguagem SystemC para uma linguagem Verilog-RTL sintetizável, para isso utiliza-se o ambiente CTOS.
Com os módulos descritos em Verilog-RTL, é preciso validar o processo de síntese feito pelo CTOS.
Elabora-se então um testbench a fim de se testar as funcionalidades dos módulos. Com as ferra- mentas NClaunch e SimVision Debug é possível compilar os arquivos: testbench e Verilog-RTL, além de simular e vizualizar os resultados.
Com a validação preliminar dos resultados, pode-se realizar as sínteses lógica e física dos módulos. A partir do arquivo Verilog-RTL sintetizável gerado pelo CTOS, é possível realizar a síntese lógica dos componentes, utilizando a ferramenta Encounter RTL Compiler. Com a síntese lógica se obtem como saída um arquivo Netlist, que será usado na síntese física. Antes de passar para a etapa da síntese física é importante realizar uma simulação pós síntese lógica, utilizando novamente as ferramentas NClaunch e SimVision Debug, para validar o processo realizado nesta etapa. Para essa simulação utiliza-se o netlist gerado, um arquivo SDF, que contém as informações de atraso, e um testbench, com as mesmas funcionalidades do testbench anterior, para que se obtenha os mesmos resultados da simulação anterior, mas agora considerando as informações de atraso das células.
Após a validação da síntese lógica é realizada a síntese ou implementação física, para se obter o layout do bloco digital a ser fabricado. Essa etapa é realizada no ambiente SoC Encounter RTL-to-GDSII System. Assim como foi feito para a validação da síntese lógica, é preciso realizar uma nova simulação para validar o correto funcionamento do circuito gerado pela síntese física,
levando-se em consideração o atraso das células e das interconexões. Para essa simulação pós layout utiliza-se o arquivo netlist gerado após a síntese física, o arquivo SDF e um testbench com as mesmas funcionalidades das simulações anteriores.
Com a metodologia definida pode-se iniciar sua execução, afim de se chegar aos objetivos propostos. O capítulo 4 mostra o processo de desenvolvimento deste trabalho, apresentando os principais problemas, soluções e resultados encontrados.
Figura 3.2: Fluxo de Desenvolvimento
Capítulo 4
Desenvolvimento
Este capítulo apresenta as atividades realizadas no desenvolvimento deste trabalho. Inicial- mente são apresentadas as atividades realizadas com o simulador de RSSF, IDEA1, e posterior- mente as atividades realizadas com as Ferramentas Cadence.
4.1 Introdução
O desenvolvimento deste trabalho se concentrou na realização dos processos de simulação e síntese em alto nível dos módulos digitais de uma RSSF. Para a fase de simulação, o objetivo inicial foi de adicionar módulos dedicados ao simulador IDEA1 e posteriormente realizar simulações de RSSF utilizando os novos módulos. Enquanto que na fase de síntese o objetivo desejado foi de utilizar as Ferramentas Cadence para gerar, de forma automática, um modelo em RTL a partir de um descrito em SystemC. E com o modelo RTL gerado, realizar também as sínteses lógica e física, para se obter o layout dos blocos digitais do chip, podendo assim ser possível a sua fabricação.
A seguir serão apresentadas as atividades realizadas para se chegar aos objetivos desejados.
Serão apresentadas as imagens, das atividades e dos resultados, de maior relevância para cada etapa realizada. Os Anexos I, II, III, IV e V apresentam com maiores detalhes o processo de de- senvolvimento deste trabalho. Já o Anexo VI apresenta os códigos fonte, gerados e desenvolvidos, de maior relevância.
4.2 Inclusão do MipsUnB ao Ambiente IDEA1
Foram utilizados nesta fase:
• Sistema Operacional Ubuntu, em sua versão 13.10.
• Simulador de RSSF IDEA1, em suas versões 2011 e 2015.
• O IDE (Ambientes Integrados de Desenvolvimento) Qt Creator, em sua versão 5.4.
Inicialmente foram realizadas algumas simulações de RSSF utilizando os módulos já existentes no IDEA1 em sua versão 2011, afim de se familiarizar com a ferramenta. A Figura 4.1 apresenta a GUI para a configuração da RSSF a ser simulada, enquanto que a Figura 4.2 apresenta a interface gráfica do simulador após a simulação da rede, nela é possível visualizar, entre outras informações, os componentes, a topologia e os resultados de simulação da rede.
Figura 4.1: GUI de Configuração da RSSF
Como pode ser visto na Figura 4.1, a ferramenta possibilita ao usuário configurar, entre outras coisas, a quantidade de nós e suas posições, o microcontrolador, o transceptor e o protocolo de comunicação a serem utilizados pela RSSF. Com isso o IDEA1 proporciona ao projetista configurar a RSSF de forma rápida e fácil.
Figura 4.2: GUI após a simulação da RSSF
Após as diversas simulações realizadas, com os módulos já existentes, se teve a percepção de que a ferramenta poderia facilitar bastante o processo de configuração das RSSF, e então decidiu-se adicionar módulos não comerciais ao simulador. O primeiro módulo escolhido foi o MipsUnB, pelo fato de ser um módulo digital, estar presente na LDCI Modeling Librarye já ter sido validado em outros trabalhos [15]. A proposta inicial era dividir este processo em 2 momentos, primeiramente adicionar novas opções de escolha à GUI de configuração da RSSF, utilizando o IDE Qt Creator, e posteriormente adicionar os códigos fontes do MipsUnB a base de dados do IDEA1.
Logo de início problemas foram encontrados, principalmente referentes à incompatibilidade da sintaxe da linguagem de programação utilizada nas diferentes versões do IDE. A GUI inicial do IDEA1 foi desenvolvida utilizando a versão 3.3 do Qt Creator, enquanto que a versão utilizada foi a 5.4. O desenvolvimento na versão 5.4 foi mantido, visto que não é vantajoso condicionar o desenvolvimento de um projeto à uma determinada versão de software. Após a solução dos pro- blemas apresentados, foi possível modificar a GUI de configuração inicial do IDEA1, adicionando novas opções aos campos Microcontroller, Transiver e Protocol, como mostra a Figura 4.3.
Figura 4.3: GUI de configuração modificada
A pastaIDEA1/IDEA1/doccontém um tutorial que mostra como adicionar novos módulos ao simulador, porém encontra-se desatualizado. Então foi feito um contato junto aos desenvolvedores da ferramenta, afim de se obter o suporte necessário para o acréscimo de novos módulos ao IDEA1.
Como resposta foi informado que a versão 2011 não é mais suportada, e que encontra-se disponível para download a versão 2015.
A versão 2015 foi testada, e verificou-se que ela não chega a ser uma atualização da versão 2011, pois se comparada a esta apresenta grandes diferenças,principalmente em relação a usabilidade, devido a falta de uma GUI, mas também em relação ao banco de dados, apresentando um menor número de combinações disponíveis para simulação, como mostra a Tabela 4.1.
Tabela 4.1: Comparativo entre as versões 2011 e 2015 do IDEA1
Versão Microcontroladores Tranceptores Protocolos GUI
2011 ATMEL ATMega128 Texas Instrument CC1000 TDMA SIM
Microchip PIC16LF88 Texas Instrument CC2420 IEEE 802.15.4 Microchip MRF24J40 CSMA-CA Slotted
CSMA-CA N-Slotted
2015 ATMEL AVR Texas Instrument CC2420 CSMA-CA Slotted NÂO Microchip PIC16LF88 Microchip MRF24J40 CSMA-CA N-Slotted
Após utilizar, comparar e analisar as 2 versões do IDEA1, se optou em continuar adotando o processo padrão de simulações de SystemC/TLM aliado a LDCI Modeling Library para as simulação de RSSF, e não continuar o desenvolvimento do simulador IDEA1, entre as principais justificativas para essas escolhas estão:
• Apesar de possuir uma GUI, a versão 2011 não é mais suportada e não apresenta um tutorial atualizado para adicionar novos módulos à ferramenta.
• Alto custo (complexidade e tempo de desenvolvimento) para adicionar novos módulos à ferramenta sem ajuda dos desenvolvedores.
• Não se tem a garantia da compatibilidade entre os módulos da LDCI Modeling Library e o IDEA1.
• A versão 2015, apesar de ser suportada, ainda não apresenta uma GUI, o principal motivo encontrado para o emprego do IDEA1. A configuração da RSSF deve ser feita manualmente, similar ao que já é feito atualmente nos projetos desenvolvidos pelo LDCI.
• A atual versão ainda encontra-se em desenvolvimento, estando sujeita a instabilidades e bugs.
Com isso, o foco do trabalho passou a ser a etapa de síntese completa de blocos digitais (desde a concepção em SystemC até a geração do layout), constituintes do processador embarcado em nós dedicados.
4.3 Síntese do MipsUnB
Foram utilizados nesta fase:
• Sistema Operacional CentOS, em sua versão 5.1
• Ferramentas Cadence: NC Launch, Cadence SimVision Debug, C-to-Silicon Compiler (CTOS), Encounter RTL Compiler e SoC Encounter RTL-to-GDSII System.
A fase de síntese inicia-se com a utilização do CTOS, ferramenta que tem como principal funcionalidade a geração automática de um modelo sintetizável, descrito em Verilog-RTL, a partir de um modelo em alto nível, descrito em SystemC/TLM.
Inicialmente alguns exemplos fornecidos pela Cadence, presentes nas pastas de instalação do CTOS, foram testados, afim de se familiarizar com o uso da ferramenta, e como esperado, os exemplos não apresentaram problemas. Decidiu-se então iniciar o processo de síntese do proces- sador MipsUnB, disponível na LDCI_Modeling_Library. Sua síntese não foi possível, pelo fato
de o MipsUnB utilizar bibliotecas do ArchC, uma ADL, Linguagem de Descrição de Arquitetura, não suportada pelo CTOS. Posteriormente foram testados exemplos encontrados nos arquivos de instalação do SystemC, em suas versões 2.2 e 2.3, mas também não se teve sucesso, pelo fato desses exemplos utilizarem estruturas não suportadas pelo CTOS, como por exemplo as classes:
class sc_event e class sc_clock.
Devido as limitações encontradas, foram então testados modelos mais simples, alguns apre- sentaram sucesso e outros continuaram apresentando erros devido as limitações da ferramenta.
Entre os que apresentaram sucesso encontra-se um contador de 8 bits, descrito em [24]. Para esse contador foi possível a gerar e simular o arquivo Verilog-RTL.
Pelo fato do contador ser um modelo muito simples, e os exemplos disponíveis mais complexos apresentarem incompatibilidade com a ferramenta, decidiu-se então desenvolver um modelo hie- rárquico, com uma abordagem bottom-up. Iniciou-se então com o desenvolvimento de um bloco básico do processador. Neste caso uma ULA, Unidade Lógica e Aritmética.
4.4 Síntese da ULA
A ULA desenvolvida, em SystemC, foi uma ULA genérica de 8 bits. Apesar do custo de desenvolvimento de uma ULA de 32 bits ser praticamente o mesmo de uma ULA de 8 bits, a segunda foi escolhida pelo fato de que poderia trazer menos problemas que a primeira, nos processos de síntese lógica e física, por possuir uma menor quantidade de células e interconexões ocupando assim um menor espaço físico. Futuramente a ULA de 8 bits poderá se tornar facilmente em uma ULA de 32 bits, trocando-se apenas o valor do tamanho das variáveis em seus códigos fonte.
A ULA possui 3 entradas (A, B, opcode) e 2 saídas (Z, zero). Por se tratar de um circuito combinacional a ULA não possui um sinal de Clock (Clk) como entrada. A Figura 4.4 apresenta o esquemático da ULA, e a Tabela 4.2 apresenta suas funcionalidades. Os códigos fonte da ULA podem ser vistos no Anexo VI.
Figura 4.4: Esquemático da ULA
As entradasA, Bsão os operandos da ULA, compostos cada um por 8 bits. A entradaopcode é composta por 3 bits, portanto possui 8 diferentes valores possíveis, e indica qual a operação a
Tabela 4.2: Funcionalidades da ULA Opcode Funcionalidade Operação
0x00 ADD Z = A + B
0x01 SUB Z = A - B
0x02 AND Z = A and B
0x03 OR Z = A or B
0x04 NOT Z = not(A)
0x05 NOT Z = not(B)
0x06 XOR Z = A xor B
0x07 MAIOR Se A > B, Z = A
Se A < B, Z = B
ser realizada pela ULA. A saída Z também é composta por 8 bits, e representa o resultado da operação realizada pela ULA. A saída zero possui 1 bit, e informa se o resultado da ULA é ou não igual a 0 (zero), se for assume o valor ’1’ se não o valor ’0’.
Com o modelo definido e descrito na linguagem SystemC, pode-se então voltar a utilizar a ferramenta CTOS para a geração de um modelo sintetizável da ULA, descrito agora em Verilog- RTL.
A seguir são descritas as principais etapas a serem realizadas com o CTOS para geração de um modelo RTL sintetizável. O Anexo II apresenta com mais detalhes o processo de geraração do modelo RTL sintetizável da ULA.
• Inicialmente carrega-se os arquivos .cpp e .h do modelo, neste caso os arquivos main.cpp, ula.cpp e ula.h.
• O CTOS realiza a compilação dos arquivos selecionados, verificando a sintaxe e a semântica dos códigos. Caso sejam compatíveis com a ferramenta e não apresentem erros, é definido o arquivo Top Level do modelo.
• Posteriormente é possível a inclusão e configurações de Clocks. Pelo fato da ULA ser um circuito combinacional, não foram incluidos sinais de Clock. Concluídas as configurações iniciais é realizada uma nova compilação, com a geração de 2 arquivos ula_ctos_wrapper.h e ula_post_build.v. O arquivo Verilog gerado ainda não pode ser sintetizado.
• Para finalizar o processo e obter o Verilog-RTL, é preciso que o projetista solucione, com au- xílio da ferramenta CTOS, eventuais situações críticas de implementação, como por exemplo:
loops, funções e alocação de memória. A ULA não apresentou problemas. Após a solução dos problemas é possível gerar o código Verilog-RTL sintetizável, no caso da ULA, o arquivo ula_rtl.v.
Após a geração do arquivo Verilog-RTL, é preciso desenvolver um testbench e realizar uma simulação do modelo, para validar o processo feito com o CTOS, utilizandos as ferramentas NC Launch e SimVison Debug.
O testbench, Ula_TB.v, desenvolvido para a realização da simulação do modelo sintetizável, é mostrado na Figura 4.5. O teste inicia com as entradas A = 0xA0, B = 0x0F e opcode
= 0x00. Oopcode é aumentado em uma unidade, a cada 10 unidades de tempo, até seu valor chegar a 0x07. Então as entradasAeB assumem, respectivamente, os valores0x0F, 0xA7, e a entrada opcodepassa a ser diminuida, em uma unidade, a cada 10 unidades de tempo, até que seu valor volte para 0x00.
Figura 4.5: Fragmento do Testbench da ULA
Posteriormente é realizada a compilação dos arquivosula_rtl.v e Ula_TB.v, são preparadas as estruturas RTL para a simulação, utilizando a ferramenta NC Launch. Com o SimVision Debug é possível a visualização do esquemático do circuito e das formas de ondas dos resultados gerados.
Os resultados serão apresentados na seção 4.4. O Anexo III apresenta com detalhes o que foi feito para se chegar aos resultados apresentados.
Com a validação do modelo RTL sintetizável, pode-se iniciar os processos de síntese lógica e física da ULA, utilizando, respectivamente, as ferramentas Encounter RTL Compiler e SoC Encounter RTL-to-GDSII System. A tecnologia da biblioteca de células utilizada nos processos das sínteses lógica e física foi a AMS 0.35µm, pelo fato da disponibilidade e por conter um tutorial de utilização [25]. As bibliotecas de células dizem respeito ao conjunto de arquivos que descrevem
as informações e especificações de timing, área e potência, por exemplo [20].
A síntese lógica é inicializada com a execução do script synth_rtl_ula.tcl na ferramenta En- counter RTL Compiler. Após a execução do script alguns arquivos são gerados na pasta lo- gic_synthesis_output_files. São utilizados na simulação pós síntese lógica, os arquivos gera- dos: ula_rtl_out_net.v (Netlist) e ula_rtl_out_sdf.sdf, os arquivos da biblioteca de células:
c35_CORELIB.v e udp.v, além de um testbench com as mesmas funcionalidades do apresen- tado na Figura 4.5. O processo de simulação é similar com o que foi feito após a geração do arquivo Verilog-RTL, o Anexo IV apresenta as etapas da síntese lógica e da simulação pós síntese com mais detalhes.
Com a validação dos resultados obtidos na síntese lógica, pode-se iniciar a síntese ou imple- mentação física. O objetivo desta última etapa é a geração do layout do chip para o modelo síntetizado. Esta etapa se incia com a execução do arquivo setup.sh, para criar todas as pastas a serem utilizadas neste processo.
No SoC Encounter é criado um novo design, e sua configuração é feita a partir do arquivo Netlist (ula_rtl_out_net.v), dos arquivosc35b4.lef e CORELIB.lef da biblioteca de células e dos arquivos corners.io e Default.view gerados com a execução dosetup.sh. Após a configuração são executadosscripts, localizados na pastascripts, para a geração do layout. Abaixo são apresentados os principais scripts e suas respectivas funcionalidades:
• floorplan.tcl - posicionar as macros no layout.
• powerplan.tcl - distribuir as redes de alimentação do layout (Vdd e Gnd).
• placement.tcl - distribuir os demais blocos no layout.
• nanoroute.tcl - realizar a conexão física dos pinos e macros do layout
• generate.tcl - gerar o layout final.
Ao final deste processo se obtém o layout do chip da ULA, mas é preciso ainda realizar uma simulação pós layout, para validar o correto funcionamento do circuito gerado, levando-se em consideração o atraso e as interconexões das células. São utilizados na síntese pós layout os arquivos gerados: ula_1.v (Netlist) e ula_1.sdf, os arquivos da biblioteca de células: c35_CORELIB.v e udp.v, além de um testbench com as mesmas funcionalidades dos utilizados nas simulações anteriores. O processo de simulação pós layout é similar aos já realizados. O Anexo V apresenta com detalhes o processo da implementação física da simulação pós layout. Os resultados do layout obtido serão mostrados na seção 4.5.
4.5 Resultados e discussões
As Figuras 4.6 e 4.7 apresentam os resultados obtidos na simulação do modelo RTL sinte- tizável da ULA, gerado pela ferramenta CTOS. Como pode ser visto nos Anexos III, IV e V,
as 3 simulações realizadas durante o desenvolvimento deste trabalho apresentaram os mesmos resultados.
Figura 4.6: Formas de Onda dos Resultados
Figura 4.7: Continuação da Figura 4.6
Analisando as funcionalidades da ULA, na Tabela 4.2, e os estímulos gerados pelo testbench, na Figura 4.5 é possível verificar que os resultados mostrados nas Figura 4.6 e 4.7, estão de acordo com esperado. Portanto os resultados obtidos com os processos de síntese realizados pelas ferramentas CTOS, Encounter RTL e SoC Encounter podem ser considerados satisfatórios, assim como o layout da ULA, mostrado na Figura 4.8.
Figura 4.8: Layout final da ULA
As Figuras 4.9 e 4.10 apresentam algumas informações do layout gerado. É possível verificar que a ULA desenvolvida possui 172 células que ocupam o espaço de 11.921,00µm2, o que pode ser considerado plausível, visto que componentes de RSSF tem dimensões na ordem decm3, e a ULA é um módulo de um dos blocos dos nós sensores. É possível ver também que durante a geração do
layout nenhuma violação foi encontrada, mostrando mais uma vez que o resultados encontrados podem ser considerados satisfatórios.
Figura 4.9: Resumo do layout da ULA
Figura 4.10: Resumo do layout da ULA
Como foi visto anteriormente, não foi possível dar continuidade ao desenvolvimento do simula- dor IDEA1, porém com o desenvolvimento da metodologia proposta foi possível obter resultados satisfatórios na fase de síntese de blocos digitais, chegando-se a um dos objetivos propostos inici- almente. O Capítulo 5 apresenta as principais conclusões a respeito da realização deste trabalho, mostrando também seus pontos fortes e sugestões para eventuais trabalhos futuros.
Capítulo 5
Conclusões
Este capítulo apresenta as conclusões deste trabalho e em seguida são propostas sugestões para trabalhos futuros.
Neste trabalho foi proposto integrar ferramentas às etapas de simulação de RSSF e síntese de circuitos integrados digitais ao ADRIX, afim de automatizar o fluxo de projeto impementado no mesmo. Onde os objetivos iniciais eram:
• Adicionar módulos dedicados ao simulador IDEA1, e realizar simulações de RSSF, utilizando os novos módulos.
• Utilizar ferramentas Cadence para gerar, de forma automática, um modelo em RTL a partir de um modelo descritos em SystemC. Além de realizar as sínteses física e lógica do modelo RTL gerado, afim de obter layout dos blocos digitais para a sua fabricação.
Infelizmente não foi possível chegar aos objetivos desejados em relação a ferramenta de simu- lação IDEA1, devido, principalmente, a falta de suporte para a versão 2011, e a inviabilidade de desenvolvimento para a versão 2015, por ainda não apresentar uma interface gráfica. Apesar disso, esta fase possibilitou o aprendizado sobre a arquitetura, as aplicações e funcionalidades, os processos de simulação e as tecnologias utilizadas para o desenvolvimento das RSSF.
Os objetivos em relação a síntese de alto nível foram alcançados, com a obtenção de resultados satisfatórios. Foi possível a geração do layout de uma ULA, de 8 bits, a partir da sua descrição em SystemC. Esta fase possibilitou realizar diversos procedimentos práticos para a fabricação de um SoC.
A metodologia proposta neste trabalho, descrita no Capítulo 3, possibilita o desenvolvimento de RSSF, tendo como base os módulos disponíveis na ferramenta ADRIX, podendo estes módulos serem comerciais ou não.
A síntese em alto nível dos blocos digitais realizada neste trabalho difere das já realizadas pelo LDCI. Pelo que se pôde ver até a finalização deste trabalho, este foi o primeiro a utilizar a
ferramenta CTOS no processo de síntese em alto nível. Apesar das limitações encontradas com o uso da ferramenta, já foi possível se obter resultados satisfatórios.
Com isso, este trabalho certamente servirá de base para o desenvolvimento de outros trabalhos relacionados ao processo de síntese em alto nível, pelo fato de ter sido possível realizar, com sucesso, o processo completo de síntese em alto nível, ou seja, foi possível a geração do layout de um módulo a partir de seu modelo descrito em SystemC, com o auxílio das Ferramentas Cadence, tendo o CTOS um maior destaque.
Para a continuação deste trabalho, sugere-se o desenvolvimento de um novo simulador de RSSF. Se possível, ter como um dos requisitos a integração com a ferramenta ADRIX. Este novo simulador poderia conter uma interface gráfica, onde em um primeiro momento o usuário realize o upload dos arquivos de saída do ADRIX, para que então sejam executadas as simulações das RSSF. Os resultados de simulações seriam mostrados na interface gráfica da ferramenta, assim como ocorre no simulador IDEA1, em sua versão 2011.
Considerando as limitações da ferramenta CTOS, outra sugestão para trabalhos futuros, seria a inserção gradativa de novos módulos ao projeto da ULA desenvolvida neste trabalho, até que se chegue a síntese completa de um processador. Esta síntese completa do precessador poderia ser implementada tanto em ASIC, como também em FPGA. O próximo módulo a ser inserido à ULA poderia ser o seu controlador, podendo ser implementado por uma máquina de estados.
Capítulo 6
Agradecimentos
Agradeço ao CNPq, Conselho Nacional de Desenvolvimento Científico e Tecnológico, por con- ceder uma bolsa de estudos para a realização de um PIBIC, Programa Institucional de Bolsas de Iniciação Científica, o qual foi desenvolvido paralelamente a este trabalho. O PIBIC estimulou a aprendizagem de técnicas e métodos de pesquisa, e a busca de conhecimento sobre os temas relacionados com este projeto.
Agradeço também ao Instituto Nacional de Ciencia e Tecnologia NAMITEC (INCT NAMI- TEC), por fornecer o suporte e a manutenção necessária para o bom funcionamento do LDCI, local onde se desenvolveu a maior parte deste projeto.
REFERÊNCIAS BIBLIOGRÁFICAS
[1] LOUREIRO, A. A. et al. Rede de Sensores Sem Fio. In: Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos (SBRC). [S.l.: s.n.], 2003.
[2] RUIZ, L. B.MANÁ: Uma Arquitetura para Gerenciamento de Rede de Sensores Sem Fio. Tese (Doutorado) — Universidade Federal de Minas Gerais - UFMG, Departamento de Ciência da Computação., 2010.
[3] ZOBY, L. T. M.Metodologia para implementação de Arcabouços Inteligentes para o Auxílio ao Projeto de Redes de Sensores Sem Fio. Tese (Doutorado) — Universidade de Brasília - UnB, Departamento de Engenharia Elétrica., 2013.
[4] DU, W. et al. IDEA1 A Validated SystemC-Based Simulator for Wireless Sensor Networks.
Eigth IEEE International Conference on Mobile Ad-Hoc and Sensor Systems, 2011.
[5] CADENCE. C-to-Silicon Compiler Datasheet. [S.l.], [Online: acessado em 11 de Junho de 2015]. Disponivel em<http://www.cadence.com>.
[6] COSTA, J. C. da et al. CMOS SoC for Irrigation Control. In: IEEE International SOC COn- ference (SOCC), Washington,DC. [S.l.: s.n.], 2005. p. 51–54.
[7] INL.IDEA1 - hIerarchical DEsign plAtform for sensOr Networks Exploration. [S.l.]. Disponivel em<http://idea1inl.free.fr/IDEA1/>.
[8] CADENCE. Cadence Design System, Inc. [S.l.], [Online: acessado em 26 de Junho de 2015].
Disponivel em<http://www.cadence.com/rl/Resources/financial_reports/cadenceataglance.pdf>.
[9] RUIZ, L. B. et al. Architecture for Wireless Sensor Network. In: Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos (SBRC). [S.l.: s.n.], 2004.
[10] UYEMURA, J. P. Sistemas Digitais: Uma Abordagem Integrada. [S.l.]: Thomson, 2002.
[11] DOULOS.The Designerś Guide to Verilog. [S.l.], [Online: acessado em 11 de Junho de 2015].
Disponivel em<http://www.doulos.com/knowhow/verilog_designers_guide>.
[12] INITIATIVE, O. IEEE Standard Systemc Language Reference Manual. IEEE Computer So- ciety, p. 1666–2005, 2001.
[13] GRöTKER, T. et al. System Design with SystemC. [S.l.]: Springer Netherlands, 2002.
[14] BESERRA, G. S.Modelagem em Nível Transacional de Sistemas em Chip Mistos para Aplica- ções de Rede de Sensores sem Fio. Tese (Doutorado) — Universidade de Brasília, Departamento de Engenharia Elétrica., 2010.
[15] MEDEIROS, J. E. G. de. Modelagem em SystemC de um SoC em Ambientes de Redes de Sen- sores sem Fio. Dissertação (Mestrado). Universidade de Brasília, Departmento de Engenharia Elétrica, 2010.
[16] MADUREIRA, H. M. G. Modelagem em Alto Nivel do Consumo de Energia para Sistemas em Chip em Redes de Sensores sem Fio. Dissertação (Mestrado). Universidade de Brasília, Departmento de Engenharia Elétrica, 2011.
[17] NAVARRO, D. et al. Simulation of Hardware and Software in Heterogeneous Wireless Sensor Network.International Journal on Advances in Networks and Services, v. 7, 2014.
[18] DU, W.; MIEYEVILLE, F.; NAVARRO, D. IDEA1 A SystemC-based System-level Simulator for Wireless Sensor Networks. 2010.
[19] NASCIMENTO, F. A. M. do. Síntese de Alto Nível a partir de VHDL Comportamental.
Dissertação (Mestrado).Universidade Federal do Rio Grande do Sul, Instituto de Informática, 1992.
[20] SILVA, L. M. de L. Tutorial: Fluxo de Projeto ASIC para Circuitos Integrados Digitais.
Universidade Federal do Rio Grande do Sul, Instituto de Informática, 2011.
[21] CADENCE. Overview Cadence SimVision Debug. [S.l.], [Online: acessado em 11 de Junho de 2015]. Disponivel em <http://www.cadence.com>.
[22] CADENCE.Encounter RTL Compiler Datasheet. [S.l.], [Online: acessado em 11 de Junho de 2015]. Disponivel em<http://www.cadence.com>.
[23] CADENCE.SoC Encounter RTL-to-GDSII System Datasheet. [S.l.], [Online: acessado em 11 de Junho de 2015]. Disponivel em <http://www.cadence.com>.
[24] ALDEC. System C Lab 1 – Up_Down Counter. [S.l.], [Online: acessado em 18 de Junho de 2015]. Disponivel em <http://users.ece.utexas.edu/ gerstl/ee382v- ics_f11/soc/tutorials/System_C_Code_Examples_3/SystemC>.
[25] FGA. Projeto de Circuitos Integrados Digitais - 2/2014. Tutorial - Síntese Lógica e Física.
[S.l.], 2014.
[26] CADENCE. Cadence C-to-Silicon Compiler User Guide. [S.l.], 2012. Disponivel em .../C- TOS/tools/ctos/doc/Cadence_CtoS_User_Guide.pdf.
ANEXOS
Os anexos a seguir apresentam tutoriais de utilização do simulador de RSSF IDEA1 e das Fer- ramentas Cadence utilizadas. Além dos códigos mais relevantes desenvolvidos durante a realização deste trabalho.
I. UTILIZAÇÃO DO SIMULADOR DE RSSF IDEA1
Este Anexo apresenta um tutorial de utilização do simulador de RSSF IDEA1.
• Inicialização do IDEA1
Abrir um terminal, e no diretório /usr/local/IDEA1/GUI executar o comando:
$ ./GUI_1_1
Após a execução do comando o IDEA1 é inicializado.
• Configuração da RSSF
Para configurar a RSSF a ser simulada, clicar no íconeconfigure, localizado no lado superior esquerdo da tela.
Para este exemplo foram feitas as seguintes configurações;
– Número de nós: 30
– Microcontrolador: ATMega 128 – Transceptor: CC2420
– Protocolo: IEEE 802.15.4.GTS
Figura I.1: GUI de Configuração da RSSF
Após a configuração da RSSF, clicar em OK. As configurações definidas e a topologia da RSSF serão mostradas na tela, nas abas Configuration e Topology, respectivamente.
• Simulação da RSSF
Para dar início a simulação da RSSF, deve-se clicar no íconerun, localizado ao lado do ícone configure.
As informações da simulação serão mostradas na tela, na aba Console
Figura I.2: GUI do IDEA1 após a simulação
II. UTILIZAÇÃO DA FERRAMENTA C-TO-SILICON COMPILER (CTOS)
Este Anexo apresenta os passos realizados na utilização da ferramenta CTOS, para a geração do arquivo Verilog-RTL sintetizável da ULA. Os passos descritos a seguir foram feitos no computador do LDCI, e foram baseados no tutorial (Apêndice A) do Guia do Usuário da ferramenta [26].
• Inicialização do CTOS
Abrir um terminal, e no diretório .../ULA/Base executar os seguintes comandos:
$ csh
$ ctosgui
Após a execução dos comandos o CTOS é inicializado.
• Novo Projeto
Criar um novo projeto em: File -> New Desing.
Definir Name: como ulae Clicar em Next Em seguida definir os campos:
Source Files: Adicionar os arquivos main.cpp, ula.cpp Header Files: Adicionar o arquivo ula.h
Clicar em (...) para definir o Top Module.
Escolher o Top Module e clicar em Next
Na próxima janela são feitas as definições dos nomes e das frequências dos clocks utilizados no projeto. Como a ULA é um circuito combinacional, não foi preciso utilizar nenhum sinal de clock. Então basta clicar em Next.
Agora são definidas, entre outras coisas, as tecnologias a serem utilizadas. Definir respecti- vamente os campos Implemementation Target e Technology Library como ASIC e tutorial.lbr, e clicar em Next.
• Compilação do projeto
Após concluir todas as configurações do projeto é possível compilá-lo, mas para uma melhor organização dos diretórios, selecionar a opção Edit desing properties before build e clicar em Finish
Na aba Incremental, selecionar a opção Auto Save Baseline e adicionar ../ antes de ula_incremental, e então clicar em Build, para a compilação do projeto.
