Embed Size (px)
Citation preview
UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR
CURSO DE CIÊNCIA DA COMPUTAÇÃO
VERIFICAÇÃO FUNCIONAL APLICADA A REDES-EM-CHIP
Área de Projeto de Sistemas Digitais
por
Pablo Pereira Pires
Cesar Albenes Zeferino, Dr. Orientador
Itajaí (SC), novembro de 2009
UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR
CURSO DE CIÊNCIA DA COMPUTAÇÃO
VERIFICAÇÃO FUNCIONAL APLICADA A REDES-EM-CHIP
Área de Projeto de Sistemas Digitais
por
Pablo Pereira Pires Relatório apresentado à Banca Examinadora do Trabalho de Conclusão do Curso de Ciência da Computação para análise e aprovação. Orientador: Cesar Albenes Zeferino, Dr.
Itajaí (SC), novembro de 2009
ii
AGRADECIMENTOS
A minha mãe, Vera, pelo amor e confiança inesgotáveis.
Ao meu pai, pelo apoio dado à minha formação.
Aos meus familiares, pelo suporte dado a cada fase desse meu início de vida e carreira.
A minha companheira, Dezyrre, pela motivação, apoio e por me fazer sorrir mesmo nos
momentos adversos.
Aos meus padrinhos, em especial à minha Dinda Vera (in memorium), por instigar minha
curiosidade e transformar meus “Porquês?” em outras mil perguntas, ideias e pensamentos. Além é
claro, por me ensinar que massa colorida faz bem.
Aos colegas de faculdade que compartilharam todo esse tempo entre estudos, códigos,
trabalhos e provas.
Aos meus colegas do LSED, pela ótima acolhida, pelo tempo compartilhado e por se
tratarem de amigos deveras preciosos.
Ao meu orientador e professor Cesar, pelas oportunidades concedidas, pelo conhecimento
transmitido e por ser exemplo.
Aos amigos feitos durante o curso, especialmente os aqui citados: Leko, Leandro, Léo e
Ton.
iii
SUMÁRIO
LISTA DE ABREVIATURAS ................................................................. v
LISTA DE FIGURAS ............................................................................. vi
LISTA DE TABELAS ............................................................................ vii
RESUMO ............................................................................................... viii
ABSTRACT ............................................................................................. ix
1 INTRODUÇÃO ................................................................................... 1 1.1 PROBLEMATIZAÇÃO ..................................................................................... 3 1.1.1 Formulação do Problema ................................................................................. 3 1.1.2 Solução Proposta ............................................................................................... 4 1.2 OBJETIVOS ........................................................................................................ 4 1.2.1 Objetivo Geral ................................................................................................... 4 1.2.2 Objetivos Específicos ........................................................................................ 4 1.3 METODOLOGIA ................................................................................................ 4 1.4 ESTRUTURA DO TRABALHO ....................................................................... 5
2 FUNDAMENTAÇÃO TEÓRICA ...................................................... 6 2.1 PROJETO DE SISTEMAS INTEGRADOS .................................................... 6 2.1.1 Sistemas Integrados .......................................................................................... 6 2.1.2 Gape de Produtividade ..................................................................................... 7 2.1.3 Time-to-market ................................................................................................. 8 2.1.4 Metodologias de Projeto Baseadas em Reuso ................................................ 8 2.1.5 Metodologia de Projeto de Núcleos: ipPROCESS ....................................... 10 2.2 VERIFICAÇÃO ................................................................................................. 13 2.2.1 Verificação Funcional ..................................................................................... 14 2.2.2 Linguagens de Descrição de Hardware ........................................................ 15 2.2.3 Linguagens de Verificação de Hardware...................................................... 15 2.2.4 Metodologia de Verificação Funcional ......................................................... 16 2.2.5 Abordagens de verificação funcional ............................................................ 19 2.2.6 Testbench .......................................................................................................... 21 2.3 REDES-EM-CHIP ............................................................................................. 22 2.3.1 Conceitos sobre comunicação em SoCs ........................................................ 22 2.3.2 Redes-em-chip ................................................................................................. 24 2.3.3 Topologia .......................................................................................................... 25 2.3.4 Controle de fluxo ............................................................................................. 27 2.3.5 Roteamento ...................................................................................................... 28 2.3.6 Arbitragem ...................................................................................................... 29 2.3.7 Chaveamento ................................................................................................... 29 2.3.8 Memorização ................................................................................................... 31
iv
2.4 A REDE SOCIN ................................................................................................. 31 2.4.1 Arquitetura da rede SoCINfp ........................................................................ 31 2.4.2 Arquitetura do roteador da rede SoCINfp ................................................... 35 2.5 TRABALHOS RELACIONADOS .................................................................. 39
3 DESENVOLVIMENTO .................................................................... 42 3.1 VISÃO GERAL ................................................................................................. 42 3.2 ANÁLISE DE REQUISITOS ........................................................................... 43 3.2.1 Requisitos Funcionais (RF) ............................................................................ 43 3.2.2 Requisitos não-funcionais (RNF) ................................................................... 44 3.3 IMPLEMENTAÇÃO ........................................................................................ 44 3.4 VALIDAÇÃO ..................................................................................................... 49 3.5 AVALIAÇÃO ..................................................................................................... 51 3.6 DISCUSSÃO ...................................................................................................... 52
4 CONCLUSÕES .................................................................................. 53
REFERÊNCIAS BIBLIOGRÁFICAS .................................................. 54
v
LISTA DE ABREVIATURAS
CNPq Conselho Nacional de Desenvolvimento Científico e Tecnológico CPM Crosspoint Matrix CPU Central Processing Unit DUV Design Under Verification DSP Digital Signal Processor EDA Electronic Design Automation FIFO First-In First-Out FLIT Flow Control Unit GAP Global Assertion Processor HDL Hardware Description Language HLP Higher Level Protocol HVL Hardware Verification Language IC Input Controller IFC Input Flow Controller IP Intellectual Property IRS Input Read Switch LAP Local Assertion Processor LSED Laboratório de Sistemas Embarcados e Distribuídos NoC Network-on-Chip OC Output Controller ODS Output Data Switch OFC Output Flow Controller OWS Output Write Switch ParIS Parameterizable Interconnection Switch PHIT Physical Unit RF Requisitos Funcionais RIB Routing Information Bits RNF Requisitos Não-Funcionais RTL Register Transfer Level RUP Rational Unified Process SCV SystemC Verification Library SoC System-on-Chip SoCIN System-on-Chip Interconnection Network SoCINfp System-on-Chip Interconnection Network Fully Parameterizable SPEM Software Process Engineering Metamodel TCC Trabalho de Conclusão de Curso TTM Time-to-market UNIVALI Universidade do Vale do Itajaí VHDL VHSIC Hardware Description Language VHSIC Very High Speed Integrated Circuit XP eXtreme Programming
vi
LISTA DE FIGURAS
Figura 1. Gape de produtividade .......................................................................................................... 7 Figura 2. Visão geral da estrutura do ipPROCESS ............................................................................ 12 Figura 3. Ciclo de produtividade da verificação ................................................................................ 16 Figura 4. Aspectos do Projeto ............................................................................................................ 17 Figura 5. Estrutura genérica de um testbench e de um DUV ............................................................. 21 Figura 6. Arquitetura de NoC: (a) formato da mensagem; e (b) interconexão de núcleos ................ 25 Figura 7. Redes diretas: (a) grelha (ou malha); (b) toróide; (c) hipercubo ........................................ 26 Figura 8. Redes indiretas: (a) crossbar; (b) multiestágio ................................................................... 27 Figura 9. Sistema de coordenadas ...................................................................................................... 32 Figura 10. Formato do pacote da SoCINfp ........................................................................................ 33 Figura 11. Enlace da SoCINfp ............................................................................................................ 34 Figura 12. Organização do ParIS ....................................................................................................... 36 Figura 13. Matriz de cruzamento para abordagens diferentes de roteamento: (a) XY; (b) West-First
.................................................................................................................................................... 38 Figura 14. Mecanismo de asserção em cadeia e processador local de asserções ............................... 40 Figura 15. Estrutura da NoC com verificação baseada em asserções ................................................ 40 Figura 16. Bloco construtivo OWS .................................................................................................... 45 Figura 17. Bloco OWS descrito em Verilog ...................................................................................... 45 Figura 18. Instanciação do DUV ........................................................................................................ 46 Figura 19. Simulação: (a) inicialização; (b) caso de teste .................................................................. 47 Figura 20. Geração aleatória de estímulos ......................................................................................... 48 Figura 21. Lógica de referência .......................................................................................................... 48 Figura 22. Verificação de resultados .................................................................................................. 49 Figura 23. Encerramento da simulação .............................................................................................. 49 Figura 24. Diagrama RTL do bloco OWS ......................................................................................... 50 Figura 25. Log de simulação de um testbench automatizado ............................................................. 50 Figura 26. Processo de verificação ..................................................................................................... 50
vii
LISTA DE TABELAS
Tabela 1. Notação e Definições do SPEM 1.0 ................................................................................... 11 Tabela 2. Disciplinas do ipPROCESS ................................................................................................ 13 Tabela 3. Formas comuns de controle de fluxo de arquiteturas de comunicação intra-chip ............. 27 Tabela 4. Classificação dos algoritmos de roteamento ...................................................................... 28 Tabela 5. Tipos de arbitragem ............................................................................................................ 29 Tabela 6. Mecanismos de memorização ............................................................................................ 31 Tabela 7. Comparação das características da SoCIN e da SoCINfp .................................................. 35
viii
RESUMO
PIRES, Pablo Pereira. Verificação Funcional Aplicada a Redes-Em-Chip. Itajaí, 2009. 65 f. Trabalho de Conclusão de Curso (Graduação em Ciência da Computação)–Centro de Ciências Tecnológicas da Terra e do Mar, Universidade do Vale do Itajaí, Itajaí, 2009. O aumento contínuo da capacidade de integração de transistores em um único chip tem possibilitado a criação de sistemas complexos em uma única pastilha de silício, denominados sistemas integrados (SoCs – Systems-on-Chip). Para os futuros SoCs, com várias dúzias de elementos de processamento (núcleos), estima-se que as arquiteturas de comunicação utilizadas atualmente não atendam aos requisitos de desempenho desses sistemas. Nesse cenário, as arquiteturas de Redes-em-Chip (NoCs – Networks-on-Chip) surgem como alternativa de interconexão pois oferecem desempenho em comunicação escalável. Visto que as redes-em-chip já se constituem em uma alternativa para a interconexão de núcleos, surge a necessidade de um processo que garanta a corretude dos componentes da rede, em especial o seu roteador. Nesse contexto, este Trabalho de Conclusão de Curso (TCC) analisou como as técnicas de verificação funcional podem ser aplicadas no projeto de roteadores para NoCs e avaliou o impacto do uso dessas técnicas na qualidade e no tempo de execução do projeto. Neste texto, é apresentada uma revisão sobre conceitos de projeto de sistemas integrados com ênfase em técnicas de verificação funcional e definições sobre arquiteturas de interconexão de núcleos, assim como o projeto, implementação e avaliação dos testbenches desenvolvidos. Palavras-chave: Projeto de Sistemas Digitais. Verificação Funcional. Redes-em-Chip.
ix
ABSTRACT
The continuous increase in the integration capacity of transistors on a single chip has allowed the building of complex systems on a single silicon chip, known as integrated systems (SoCs – Systems-on-Chip). For future SoCs, with dozens of processing elements (cores), it is estimated that the currently communication architectures will not meet the performance requirements of these systems. In this scenario, Network-on-Chip (NoC) architecture emerges as an interconnection alternative because it offers scalable performance in communication. Since the NoC approach is already an alternative to the core interconnection, a process that ensures correctness of network components, in particular the router, is necessary. In this context, this paper aims at analyzing how the functional verification techniques can be applied in the design of routers for NoCs, and intends to evaluate the impact of the use of such techniques in the quality and in the time to carry out the of a NoC. In this work, is presented a review of concepts on integrated systems design with emphasis on functional verification techniques. Also, they are discussed concepts on communication architectures for SoCs and architectural concepts on NoCs. Finally, they are presented the design, the implementation and the evaluation of the developed testbenches. Keywords: Digital System Design. Functional Verification. Network-on-Chip.
1 INTRODUÇÃO
O aumento contínuo da capacidade de integração de transistores em um único chip tem
possibilitado a criação de sistemas complexos em uma única pastilha de silício, incluindo
processadores, memória, interfaces de entrada-e-saída e/ou outras aplicações de lógica específica
(WILE; GOSS; ROESNER, 2005, p.653). Tais sistemas são denominados Systems-on-Chip (SoCs)
ou, em português, sistemas integrados. Os componentes de um SoC são, em geral, baseados em
modelos reutilizáveis de hardware, pré-projetados e pré-verificados, os quais são denominados
núcleos ou cores (GUPTA; ZORIAN, 1997). Por serem frutos de propriedade intelectual, os
núcleos são também chamados de IP cores ou, simplesmente, IPs (de Intellectual Property).
Interconexão de núcleos em SoCs
A interconexão entre os núcleos de um sistema integrado é geralmente feita por meio de
barramentos. Porém, o desempenho de um barramento é limitado e não escala com o tamanho do
sistema, pelo contrário, a inserção de um núcleo no barramento aumenta a competição pelo uso
deste e degrada a largura de banda disponibilizada aos demais núcleos. Nesse cenário, as Redes-em-
chip ou Networks-on-Chip – NoCs (JANTSCH; TENHUNEM, 2003) surgem como solução de
interconexão por oferecerem desempenho escalável e paralelismo de comunicação através de
conexões ponto-a-ponto, atendendo às necessidades dos futuros SoCs com várias dezenas de
núcleos.
As NoCs são baseadas nas arquiteturas de redes de interconexão utilizadas em computadores
paralelos. Segundo Zeferino (2003), uma rede de interconexão é constituída basicamente de
roteadores conectados através de enlaces (links). Os enlaces ligam os roteadores entre si e aos nodos
do sistema, enquanto que os roteadores estabelecem o caminho necessário à transferência de dados
pela rede. Zeferino (2003), ainda afirma que:
Um roteador é constituído por um núcleo de chaveamento (crossbar), uma lógica de controle para roteamento e arbitragem, e portas de entrada-e-saída para comunicação com outros roteadores e/ou com os nodos do computador paralelo. Essas portas de comunicação incluem canais de entrada e de saída, os quais podem possuir uma pequena memória para armazenamento temporário de informações (a qual é denominada buffer de memorização ou, simplesmente, buffer). As portas possuem ainda controladores de enlace para a implementação do protocolo físico de comunicação. Eles regulam o tráfego das informações que entram e saem do roteador.
2
Uso de verificação no projeto de núcleos
O desenvolvimento de um núcleo envolve muitas etapas e cada uma delas requer recursos
humanos e físicos para ser realizada. Todo o fluxo de projeto requer atenção em cada estágio, pois
um erro detectado no início é mais barato de ser corrigido do que um detectado apenas no final do
projeto. A identificação tardia de um erro leva a atrasos no projeto comprometendo o cumprimento
do prazo previsto para entrega. Como o chamado time-to-market constitui-se em uma das métricas
mais importantes no projeto de sistemas eletrônicos, atrasos significativos podem levar ao insucesso
de um projeto.
A tentativa de detectar erros funcionais no desenvolvimento de um núcleo durante o início
do fluxo é o maior desafio no projeto. Algumas técnicas de verificação são usadas para esse
propósito, identificando se o núcleo atende à sua especificação.
Bergeron et al. (2005) estabelecem três tipos de verificação:
• Formal ou estática;
• Funcional ou dinâmica; e
• Híbrida.
Os três tipos propõem verificar se o sistema obedece a uma determinada especificação. A
verificação formal, no contexto de hardware, está relacionada à prova ou refutação de um certo
sistema com base em uma especificação formal ou em propriedades que podem ser definidas por
métodos formais ou matemáticos (BERGERON et al., 2005).
Segundo Wile, Goss e Roesner (2005, p.7), a verificação funcional ou dinâmica garante que
o projeto realiza as tarefas designadas pela arquitetura global do sistema. Ela é responsável por
detectar erros no projeto lógico do sistema. Esse processo pode estar presente desde o início do
projeto até a sua conclusão e, portanto, é o processo mais demorado. Os modelos que serão
verificados são encapsulados em testbenches, estruturas que geram estímulos nos componentes e
realizam análise através de comparações da saída do modelo sob verificação com a saída esperada
de acordo com a funcionalidade do modelo. Caso o resultado da comparação seja positivo, o
modelo sob verificação certamente apresenta o comportamento esperado. Estima-se que a maior
parte do tempo de projeto de um hardware, cerca de 70%, seja gasto na verificação funcional
3
(BERGERON, 2003). Por último, a verificação híbrida, como se supõe, mescla métodos de
verificação formal e funcional.
O uso de verificação funcional no projeto de NoCs
O projeto de um chip pode facilmente consistir de centenas de milhares de linhas de código
de descrição em uma HDL (Hardware Description Language). O trabalho de um engenheiro de
verificação é procurar problemas na implementação HDL, reportando falhas ou bugs quando o
código não age de acordo com a especificação. Um engenheiro de verificação expõe estas falhas
executando simulações complexas sobre o núcleo, o qual, do ponto de vista da verificação é
chamado de DUV (Design Under Verification). Um DUV pode ser visto como todo o núcleo ou
como uma parte do núcleo (PESSOA, 2007) da qual se deseja verificar o atendimento de uma
especificação. O engenheiro de verificação encara dois desafios: lidar com um enorme espaço
amostral e detectar comportamentos incorretos (WILE; GOSS; ROESNER, 2005, p.8).
A verificação funcional se baseia na simulação da aplicação de estímulos ao DUV e na
avaliação das saídas por ele produzidas. Segundo Pessoa (2007), uma simulação no contexto de
projetos de hardware é representada por um conjunto de cenários nos quais o núcleo deve ser
submetido. A simulação então é satisfeita se o dado núcleo consegue se comportar da forma como
foi especificado no projeto.
Dentro desse contexto, imagina-se que aplicar verificação funcional a núcleos de redes-em-
chip, como os roteadores, pode impactar positivamente na qualidade do projeto e no melhor
aproveitamento de recursos, visto que quanto mais avançado em relação ao tempo o projeto está,
mais caro se torna a correção de um erro.
1.1 PROBLEMATIZAÇÃO
1.1.1 Formulação do Problema
Através de estudos realizados, foi possível perceber que a pesquisa sobre verificação
funcional aplicada a uma área em ascensão como redes-em-chip ainda é incipiente. Visto que as
redes-em-chip já se constituem como uma alternativa para a interconexão de núcleos, surge a
necessidade de um processo que garanta a corretude de um roteador sem prejudicar o tempo de
projeto.
4
O problema de pesquisa deste trabalho consiste em analisar como as técnicas de verificação
funcional podem ser aplicadas no projeto de roteadores para rede-em-chip e avaliar o impacto do
uso dessas técnicas na qualidade e no tempo de execução do projeto.
1.1.2 Solução Proposta
Analisar arquiteturas de roteadores de redes-em-chip de modo a identificar como as técnicas
de verificação funcional podem ser aplicadas no projeto de roteadores para rede-em-chip e avaliar o
impacto do uso dessas técnicas na qualidade e no tempo de execução do projeto.
1.2 OBJETIVOS
1.2.1 Objetivo Geral
O objetivo geral deste projeto é avaliar o impacto do uso de técnicas de verificação
funcional no projeto de um roteador para uma Rede-em-Chip.
1.2.2 Objetivos Específicos
Os objetivos específicos deste projeto são:
1. Identificar e caracterizar técnicas e ferramentas para verificação funcional;
2. Analisar e caracterizar modelos de roteadores para Redes-em-Chip;
3. Aplicar técnicas de Verificação Funcional no projeto de um roteador para Rede-em-
Chip;
4. Avaliar o impacto da verificação funcional na qualidade e no tempo de projeto;
5. Validar o modelo de roteador em dispositivo físico; e
1.3 METODOLOGIA
A metodologia adotada para produção deste documento se dividiu nas etapas de Estudo,
Análise e Desenvolvimento. Na Etapa de Estudos, foram feitos estudos referentes a temas
relacionados ao projeto de sistemas integrados em chip, incluindo conceitos como: tecnologias para
o projeto de sistemas integrados, verificação funcional e linguagem de descrição de hardware, entre
outros. Após foi realizado um estudo sobre as arquiteturas de Redes-em-Chip descritas na literatura.
Como material de pesquisa, foram utilizados livros, dissertações de mestrado, teses de doutorado e
artigos científicos. A etapa de análise consistiu na análise de uma arquitetura de Rede-em-Chip em
5
específico, incluindo o roteador que compõe essa rede e o levantamento de requisitos dos scripts de
verificação funcional. A partir da análise realizada na etapa anterior, foi efetuado o projeto e a
implementação dos testbenches da rede-em-chip além de uma avaliação qualitativa do uso de
técnicas de verificação funcional.
1.4 ESTRUTURA DO TRABALHO
Este documento está estruturado em quatro capítulos. O Capítulo 1, Introdução, apresentou
uma visão geral do trabalho e de seus objetivos. O Capítulo 2, Fundamentação Teórica, apresenta a
etapa de estudo, onde foi documentada a revisão bibliográfica dos temas abordados neste projeto e
trabalhos relacionados. O Capítulo 3 apresenta o desenvolvimento do TCC e também discute como
a solução proposta foi implementada, apresentando a metodologia que foi utilizada no
desenvolvimento. Concluindo, no Capítulo 4, apresentam-se as conclusões, onde são abordados os
resultados finais.
2 FUNDAMENTAÇÃO TEÓRICA
Este capítulo apresenta a revisão bibliográfica sobre os assuntos abordados neste projeto. A
Seção 2.1 aborda conceitos acerca do projeto de sistemas integrados. A Seção 2.2 apresenta
definições de verificação funcional. A Seção 2.3 aborda conceitos de redes-em-chip. A Seção 2.4
realiza um estudo de caso da rede SoCINfp e do roteador ParIS, utilizado nessa rede. A Seção 2.5
aborda as características de trabalhos relacionados desenvolvidos recentemente.
2.1 PROJETO DE SISTEMAS INTEGRADOS
2.1.1 Sistemas Integrados
Segundo Jerraya e Wolf (2005, p.1), um sistema integrado ou SoC é um circuito integrado
que implementa a maioria ou todas as funções de um sistema eletrônico completo. A característica
fundamental de um SoC é a complexidade. Um chip de memória pode ter muitos transistores, mas
sua estrutura regular faz dele um componente e não um sistema (JERRAYA; WOLF, 2005, p.1).
A escolha de quais componentes serão montados no sistema integrado varia de acordo com a
necessidade da aplicação. O sistema pode conter memória, processador(es), lógica especializada,
barramentos e outras funções digitais (JERRAYA; WOLF, 2005, p.2). A arquitetura do sistema é
geralmente adaptada para a aplicação ao invés de ser um chip de propósito geral.
Jerraya e Wolf (2005) ainda afirmam que os SoCs podem ser encontrados em muitas
categorias de produtos, desde bens de consumo a sistemas industriais, conforme ilustrado a seguir:
• Telefones celulares usam diversos processadores programáveis para manipular o
processamento de sinal e tarefas requeridas por protocolos de telefonia. Essas
arquiteturas precisam ser modeladas para operar a níveis muito baixos de energia
fornecida pelas baterias;
• Sistemas de telecomunicação e redes usam sistemas integrados especializados, como os
processadores de rede, para lidar com as enormes taxas de dados utilizadas pelos
equipamentos de transmissão modernos;
7
• Televisores digitais e set-top boxes (consoles de TV digital) usam multiprocessadores
sofisticados para executar vídeo em tempo real, decodificar áudio e realizar a interface
das funções do usuário;
• Equipamentos de produção de televisão usam SoCs para codificar o vídeo. A
codificação de vídeo em alta definição em tempo real requer taxas de computação
extremamente altas; e
• Consoles de vídeo games utilizam complexos processamentos paralelos para renderizar a
ação dos jogos em tempo real.
2.1.2 Gape de Produtividade
A evolução tecnológica proporcionou um aumento na densidade dos sistemas integrados
maior do que a capacidade de utilizá-los eficientemente (RASHINKAR; PATERSON; SINGH,
2002, p.4). A Figura 1 mostra este fenômeno conhecido como gape de produtividade. O
crescimento do número de transistores por chip, exibida em Gates/Chip e o crescimento da
produtividade dos engenheiros medida em Gates/Hour.
Figura 1. Gape de produtividade
Fonte: Rashinkar, Paterson e Singh (2002).
A crescente complexidade dos circuitos integrados se tornou um desafio tanto para
engenheiros de desenvolvimento quanto para engenheiros de verificação. Este gape de
produtividade, que mostra que o número de transistores por circuito integrado cresce mais
rapidamente do que a capacidade de utilizá-los eficientemente, não pode ser resolvido simplesmente
alocando mais engenheiros para o problema. Mesmo assim, não há engenheiros qualificados o
suficiente para solucionar o problema e, mesmo se houvesse, há limitações práticas do quão grande
8
uma equipe de desenvolvimento possa se tornar (RASHINKAR; PATERSON; SINGH, 2002, p.4).
Assim como equipes de desenvolvimento aumentam, também aumenta o nível de coordenação
requerida para manter todos os membros da equipe de desenvolvimento em sincronia. Como
alternativa, são requeridas novas metodologias que tornem o processo de desenvolvimento mais
produtivo.
2.1.3 Time-to-market
Segundo Vahid e Givargis (2002), time-to-market (TTM) é uma métrica de projeto utilizada
para medir o tempo requerido para desenvolver um sistema até o ponto em que ele possa ser
liberado e vendido para clientes. Os maiores contribuintes dessa métrica são tempo de projeto, o
tempo de manufatura e o tempo de teste.
Além do aumento da complexidade dos circuitos integrados, estão ocorrendo reduções
dramáticas do time-to-market de dispositivos eletrônicos. Essas tecnologias e os desafios do
mercado estão impactando fortemente nas metodologias e ferramentas de verificação
(RASHINKAR; PATERSON; SINGH, 2002, p.6). Ainda segundo Rashinkar, Paterson e Singh
(2002, p.6), estima-se que entre 40% e 70% do esforço total de desenvolvimento seja consumido em
tarefas de verificação. Claramente, estas atividades de verificação têm que ser executadas de forma
mais eficiente caso queiram alcançar a demanda do mercado global.
2.1.4 Metodologias de Projeto Baseadas em Reuso
As metodologias de desenvolvimento necessariamente se diferenciam entre projetistas de
sistemas e projetistas de processadores, como também se diferem entre projetistas de DSP e
projetistas de chipsets. Segundo Keating e Bricaud (2002, p.2), há um conjunto de problemas que
todos que desenvolvem chips complexos estão sujeitos a encarar, são eles:
• O time-to-market pressiona uma demanda de rápido desenvolvimento;
• A qualidade de resultados, em desempenho, área de silício, e consumo de energia, são
chaves para o sucesso no mercado;
• O aumento da complexidade dos chips torna a verificação mais dificultosa;
• A equipe de desenvolvimento tem níveis e áreas diferentes de especialização, e
freqüentemente se encontram geograficamente dispersos;
9
• Os membros da equipe de projeto podem ter trabalhado em projetos similares no
passado, mas não podem fazer reuso dos modelos porque o fluxo de projeto, ferramentas
e diretrizes mudaram; e
• O projeto de SoCs inclui núcleos de processadores embarcados, e, portanto, um
componente de software importante, que leva a mais metodologia, processos e desafios
organizacionais.
Em resposta a esses problemas, equipes de desenvolvimento têm adotado uma abordagem de
projeto baseada no reuso de blocos hardware previamente projetados e verificados (GUPTA;
ZORIAN, 1997), os quais são denominados núcleos. Segundo Zeferino (2003, p.53), um núcleo
representa uma propriedade intelectual que o construtor licencia ao usuário. Por isso, os núcleos são
também denominados blocos de propriedade intelectual ou IP cores. Gupta e Zorian (1997)
classificam os núcleos de acordo com sua implementação e disponibilização da seguinte forma:
• Soft-core: descrição em linguagem de hardware HDL (Hardware Description Language)
que pode ser mapeada para diferentes processos de fabricação;
• Firm-core: com mais informação que o soft-core, normalmente um netlist em nível de
portas lógicas ou ainda informações sobre o posicionamento e o roteamento; e
• Hard-core: composto por layout e informações referentes à temporização do circuito
para uma determinada tecnologia e está pronto para ser utilizado no sistema.
Reusar núcleos que já foram projetados e verificados ajuda a resolver todos os problemas
citados previamente. Contudo, ao adotar um projeto baseado em reuso, equipes de projeto têm
lidado com um problema significante. Keating e Bricaud (2002, p.2) afirmam que reusar núcleos
que não foram explicitamente projetados para reuso, freqüentemente traz pouco ou nenhum
benefício para a equipe. O empenho para integrar um núcleo pré-existente em novos sistemas pode
se tornar proibitivamente alto, se o núcleo não provê a documentação e funcionalidade correta.
Segundo Zeferino (2003, p. 54), SoCs utilizam núcleos que podem ser novos, herdados de
projetos existentes ou provenientes de uma ou mais bibliotecas. Alguns núcleos necessitam de
reprojeto para adequar-se a um protocolo de interface comum devido a problemas com integração e
teste, principalmente núcleos oriundos de fontes independentes. Vahid e Givargis (2001) afirmam
que encontrar um core com a funcionalidade desejada pode ser considerada uma tarefa difícil.
10
Uma segunda metodologia de projeto baseado no reuso é o projeto baseado em plataforma
ou PbD (Plataform-based Design), na qual um conjunto de elementos que são comuns a toda uma
família de produtos é identificado, integrado, e verificado como uma única entidade. Rashinkar,
Paterson e Singh (2002, p.5) ainda afirmam que, os produtos reais são, então, distinguidos
adicionando elementos individuais à plataforma. Os elementos individuais podem ser tanto blocos
IP adicionais ou elementos recém-criados. Esta metodologia de reuso não só reduz o esforço do
projeto, mas também reduz significativamente os esforços da verificação na concepção de um novo
modelo.
Zeferino (2003, p. 54) complementa esse conceito afirmando que “plataforma é uma
arquitetura de hardware e software para um domínio de aplicação, mas altamente parametrizável.
Ela inclui ferramentas de hardware (eg. processadores, memórias e dispositivos de E/S) e software
(eg. drivers de dispositivos, sistemas operacionais de tempo real e códigos de aplicação), os quais
podem ser parametrizados para atender os requisitos do sistema alvo”.
Vahid e Givargis (2001) ainda afirmam que o PbD é uma metodologia em que os fabricantes
oferecem ferramentas e bibliotecas completas para os projetos de SoCs que utilizarem suas
plataformas.
O uso de plataformas tem um custo inicial alto, mas projetos futuros se beneficiarão pela
reutilização de componentes de hardware e software reduzindo tempo e custo de projeto, visto que
componentes de projetos similares não precisam ser reimplementados (KEUTZER et al., 2000).
2.1.5 Metodologia de Projeto de Núcleos: ipPROCESS
Devido à necessidade da criação de núcleos reutilizáveis e distribuídos de forma soft, novos
processos de desenvolvimento se tornaram foco de pesquisas acadêmicas, como o já utilizado no
programa Brazil-IP do CNPq, ipPROCESS, apresentado por Lima e Santos (2005).
O ipPROCESS foi definido baseado em dois processos de desenvolvimento de software:
RUP (Rational Unified Process) e XP (eXtreme Programming). A principal idéia é utilizar a
especialização da engenharia de software em desenvolver software iniciando de um alto nível de
abstração (LIMA; SANTOS,2005). Em outras palavras, o projetista deve conceber um sistema sem
o implementar em alguma HDL. Os autores ressaltam que o alto nível de abstração permite a
11
detecção de erros nas primeiras fases do fluxo de projeto garantindo a qualidade da implementação
final.
Segundo Lima e Santos (2005), os conceitos, atividades e resultados do ipPROCESS foram
modelados com o SPEM (Software Process Engineering Metamodel), um perfil da UML para
definir processos e seus componentes (SPEM, 2009). Os principais construtores do SPEM 1.0
foram utilizados para modelar o ipPROCESS e estão descritos na Tabela 1, a seguir.
Tabela 1. Notação e Definições do SPEM 1.0
Estereótipo/Conceito
Descrição Notação
Fase É o tempo transcorrido entre dois grandes marcos do projeto, em que um conjunto de objetivos é alcançado, artefatos são concluídos, e decisões são tomadas para avançar ou não para a próxima fase.
Disciplina É uma coletânea de atividades, que estão relacionadas a uma ‘área de interesse’ maior.
Fluxo de Projeto
É um grupo de atividades que são realizadas de forma colaborativa para obter algum resultado. As atividades são tipicamente realizadas de forma paralela ou iterativamente, com os dados de saída de uma atividade sendo os dados de entrada de outra atividade.
Atividade É a unidade do projeto que um papel pode ser solicitado a realizar.
Papel É a atribuição de habilidades e responsabilidades de uma pessoa
para a equipe de desenvolvimento.
Produto ou Artefato
É qualquer coisa produzida, consumida ou modificada por um processo. Exemplos incluem planos, códigos, scripts, documentos etc.
Guia Utilizado para prover informações mais detalhadas aos profissionais sobre uma determinada atividade. Exemplos: orientações, técnicas, mentores de ferramentas, checklists, modelos etc.
Documento É um tipo de produto e representa um documento de texto
Modelo UML
É um tipo de produto e representa os diagramas da UML
Fonte: Adaptado de Lima e Santos (2005).
A Figura 2 mostra uma visão geral da arquitetura do ipPROCESS, que tem duas dimensões:
o eixo horizontal (Milestones) representa o tempo e exibe os aspectos de ciclo de vida do processo,
e o eixo vertical (Disciplines) representa as disciplinas, que se agrupam logicamente, de acordo com
a sua natureza.
12
Figura 2. Visão geral da estrutura do ipPROCESS
Fonte: Lima e Santos (2005).
A primeira dimensão representa o aspecto dinâmico do processo, i.e. como as atividades são
distribuídas ao longo do tempo. A dimensão é expressa em termos de fases e marcos. A segunda
dimensão representa os aspectos estruturais do processo: como ele é descrito em termos de
disciplinas, fluxos de projeto, atividades, artefatos e papéis. Os autores ainda ressaltam que o
gráfico mostra como a ênfase em uma atividade pode variar ao longo do tempo. Por exemplo, mais
tempo é gasto na primeira fase na disciplina de requisitos e na segunda fase, mais tempo é gasto na
disciplina de prototipação em FPGA.
Como mencionado previamente, o ipPROCESS é composto por disciplinas. Uma disciplina
inclui todas as atividades que se deve atravessar para produzir um determinado conjunto de
artefatos que são descritos em nível detalhado, chamado ‘workflow details’ (LIMA; SANTOS,
2005).
Um workflow detail, traduzido livremente por detalhe do fluxo de projeto, mostra como
personagens colaboram, e como eles usam e produzem artefatos (SPEM, 2009). A fim de ajudar a
descrição de cada disciplina, as disciplinas foram organizadas em uma ordem lógica e seqüencial de
detalhes do fluxo de projeto (LIMA; SANTOS, 2005).
13
A Tabela 2 mostra a relação entre as disciplinas do ipPROCESS e as principais áreas de
interesse no desenvolvimento de um core.
Tabela 2. Disciplinas do ipPROCESS
Disciplina “Áreas de interesse” no projeto de um core Requisitos Especificação Análise e Projeto Arquitetura do Hardware Implementação em nível RTL Implementação e Simulação Verificação Funcional Testes (desenvolvimento e automação) Prototipação em FPGA Síntese e Prototipação Física
Fonte: Adaptado de Lima e Santos (2005).
Pode-se perceber que a etapa de verificação se faz bastante presente em processos de
desenvolvimento de cores, como o ipPROCESS, para garantir a corretude do sistema. Dessa forma,
a seção a seguir, apresenta um aprofundamento a respeito desse tema.
2.2 VERIFICAÇÃO
Segundo Bergeron (2006), verificação não é um testbench, nem uma série de testbenches.
Verificação é um processo utilizado para demonstrar que a intenção do projeto está preservada na
sua implementação. O autor ainda faz uma analogia com a vida cotidiana afirmando que todas as
pessoas realizam processos de verificação diariamente: efetuando o balanço do talão de cheques,
degustando um prato cozido em fogo lento ou associando pontos de referência a símbolos de um
mapa.
Bergeron (2003), afirma que há três tipos de verificação:
• Formal ou estática;
• Funcional ou dinâmica; e
• Híbrida.
Verificação formal é a prova matemática da conformidade de um algoritmo a certa
especificação formal ou propriedade, usando métodos formais. Conforme Bergeron (2003), a
verificação funcional pode ser definida como um processo usado para demonstrar que o objetivo do
projeto é preservado em sua implementação, ou seja, que o HDL descrito é equivalente à
14
especificação do projeto. Por último, a verificação híbrida, como se supõe, mescla métodos de
verificação formal e funcional.
Esse trabalho aborda apenas a verificação funcional, no qual o circuito é simulado utilizando
um subconjunto de suas entradas e possíveis estados.
2.2.1 Verificação Funcional
Segundo Wile, Goss e Roesner (2005, p. 7), a verificação funcional garante que o modelo
realiza as tarefas conforme pretendido pela arquitetura global do sistema. Isso difere da validação
em nível de circuito de várias maneiras. Primeiramente, engenheiros de verificação
predominantemente trabalham no RTL (Register Transfer Level – nível de transferência entre
registradores) ao invés de trabalharem no nível de portas lógicas. RTL é uma forma mais abstrata de
especificar a lógica do modelo do que as portas lógicas de baixo nível AND e OR, componentes
principais do nível de portas lógicas (WILE; GOSS; ROESNER, 2005, p. 7). Linguagens que
trabalham em nível RT (HDLs – Hardware Description Languages) permitem ao desenvolvedor
especificar o comportamento utilizando construtores de alto nível como equações booleanas e
estruturas IF-THEN-ELSE. Os autores ainda ressaltam que embora o principal desafio para os
desenvolvedores de circuitos seja posicionar as portas na área de silício disponível e garantir que
metas de temporização sejam alcançadas, é do engenheiro de verificação a função de garantir que,
em primeiro lugar, o sistema apresente a funcionalidade correta.
Bergeron (2006) justifica que a importância de utilizar técnicas de verificação no projeto de
sistemas integrados reside nos seguintes fatos:
• 70% do esforço do projeto é gasto em verificação;
• A verificação está no caminho crítico;
• O tempo de verificação pode ser reduzido através de paralelismo;
• O tempo de verificação pode ser reduzido através de níveis mais altos de abstração;
• Utilizar níveis mais altos de abstração reduz o controle sobre detalhes de níveis mais
baixos de abstração;
• Os níveis mais baixos de abstração devem permanecer visíveis;
• O tempo de verificação pode ser reduzido através de automação; e
15
• O uso de estímulos aleatórios pode ser usado como uma ferramenta de automação.
2.2.2 Linguagens de Descrição de Hardware
A sigla que representa as linguagens de descrição de hardware é HDL, do inglês Hardware
Description Language. As HDLs são utilizadas para descrever modelos de dispositivos de
hardware.
A diferença fundamental entre uma linguagem de descrição de hardware e uma linguagem
convencional é que os comandos, com exceção de regiões de código específicas, são executados
concorrentemente (D’AMORE, 2005). Isso significa que a ordem na apresentação dos comandos é
irrelevante, para modelar o comportamento de um dispositivo eletrônico, a linguagem de hardware
precisa ter um mecanismo que consiga simular paralelismo e tempo. Segundo Vahid (2007, p.446),
HDLs permitem não só a descrição das interconexões dos componentes, mas também inclui
métodos para a descrição comportamental dos componentes. Segundo D’amore (2005), estes estilos
podem ser mesclados em uma mesma descrição, o que facilita a condução de projetos complexos
que partem de um nível mais elevado para um nível mais baixo de especificação, conhecidos como
top down design.Segundo Vahid (2007, p.447), as principais linguagens de descrição de hardware
são: VHDL, Verilog e SystemC. Além dessas linguagens, existem muitas outras com diferentes
sintaxes, porém com a mesma idéia fundamental de tentar modelar um sistema de hardware.
2.2.3 Linguagens de Verificação de Hardware
Bergeron (2006) define que linguagens de verificação de hardware, do inglês Hardware
Verification Languages (HVLs), são as linguagens que foram especialmente desenvolvidas para
implementar testbenches de forma eficiente e produtiva. Algumas soluções encontradas incluem
OpenVera da Synopsys, “e” da Cadence e soluções de código aberto como SystemC Verification
Library (SCV) e SystemVerilog.
SystemVerilog é uma linguagem que é baseada em Verilog e que se propõe a ser uma HDL
e HVL ou seja, adequada para codificação bem como para verificação. Isso demanda outras
funcionalidades que ainda não eram disponíveis em Verilog ou VHDL, mas que estavam
disponíveis em “e” ou Open Vera. Segundo Bergeron (2006), SystemVerilog inclui todas as
características de uma linguagem de verificação de hardware. Quando se utiliza SystemVerilog, não
se faz mais necessário usar uma linguagem separada para verificação.
16
Bergeron (2006) afirma que uma forma de incrementar a produtividade do projeto é
aumentar o nível de abstração utilizado para realizar uma determinada tarefa. Linguagens de alto
nível, como C e Pascal, elevaram o nível de abstração se comparado ao nível de linguagem de
montagem, possibilitando que engenheiros de software se tornem mais produtivos. De forma
análoga, os construtores de verificação do SystemVerilog possibilitam elevar o nível de abstração se
comparado ao Verilog, mantendo conceitos importantes e necessários para a interação com o
hardware como: temporização, concorrência e instanciação. As características do SystemVerilog
que auxiliam a aumentar o nível de abstração incluem: classes, extensões de classes orientadas a
objeto e propriedades de temporização.
Se níveis mais altos de abstração e orientação a objeto fossem suficientes, então C++ teria
sido há tempos identificada como a melhor solução, pois é livre e largamente conhecida.
SystemVerilog provê benefícios adicionais, como mostra a Figura 3. A linguagem pode automatizar
uma parte do processo de verificação gerando estímulos aleatórios, recolhendo a cobertura
funcional para identificar falhas ou buracos e então adicionar ou modificar restrições para criar mais
estímulos orientados a preencher esses buracos. Para suportar este ciclo de produtividade,
SystemVerilog oferece geração aleatória restritiva, medição da cobertura funcional e um
mecanismo de extensão de código orientado a objeto.
Figura 3. Ciclo de produtividade da verificação
Fonte: Adaptado de Bergeron (2006).
2.2.4 Metodologia de Verificação Funcional
Segundo Pessoa (2007, p. 7), “a metodologia de verificação funcional é o processo que rege
as regras de todas as etapas do processo de verificação funcional”. Existem três aspectos
17
importantes a serem observados para a realização da metodologia de verificação funcional, que são:
intenção do projeto, especificação e implementação (PIZIALI, 2004).
Segundo Pessoa (2007, p. 7), a visão que corresponde à intenção do projeto é tudo aquilo
que o cliente imagina antes mesmo de sua especificação. A visão que corresponde à especificação é
aquela em que o projetista estando consciente da intenção do projeto, consegue elaborar toda a
análise e documentação de maneira a dispor a uma especificação funcional do sistema a ser
implementado. A última visão é a da implementação, que corresponde ao que foi implementado
daquilo que foi especificado. Esses aspectos são apresentados na Figura 4 e discutidos a seguir.
Figura 4. Aspectos do Projeto
Fonte: Pessoa (2007, p.8).
Os subconjuntos ilustrados na Figura 4 possuem os seguintes significados:
• Subconjunto A: representa a parte da intenção do projeto que não foi especificada e nem
implementada;
• Subconjunto B: representa a parte da especificação que não faz parte da intenção do
projeto e que não foi implementada;
• Subconjunto C: representa a parte implementada que não faz parte nem da intenção do
projeto e nem da especificação;
• Subconjunto D: representa o que não faz parte da intenção do projeto e que também não
foi nem especificado e nem implementado;
18
• Subconjunto E: representa a parte da intenção e da especificação do projeto que não foi
implementada;
• Subconjunto F: é a parte da especificação que foi implementada, mas que não era
intenção do projeto;
• Subconjunto G: representa o que era intenção do projeto e foi implementado, mas que
não fazia parte da especificação; e
• Subconjunto H: é tudo aquilo que foi implementado e que faz parte da especificação e da
intenção do projeto.
Existe um esforço para maximizar os subconjuntos H e F e minimizar os subconjuntos B e
C. A idéia da verificação funcional é fazer com que casos nas áreas A e B sejam apontados
provocando a redução das mesmas e como conseqüência realizando o benefício para as áreas H e F.
A verificação funcional é a fase mais importante de projetos de hardware, pois, se algum
erro não for detectado nesta fase, então o mesmo será repassado mais adiante no processo de
criação do circuito integrado e posteriormente na fabricação, de forma a tornar a sua
comercialização inviável.
Conforme já comentado, estima-se que cerca de 70% do projeto de um hardware seja gasto
na verificação funcional, sendo essa, portanto, a fase mais importante em termos de dinheiro,
recursos humanos e tempo (PIZIALI, 2004; BERGERON, 2003).
Dessa forma, o time-to-market de um projeto de hardware também está muito relacionado ao
processo de verificação funcional, pois este é o responsável pela maior parte de tempo no processo
de desenvolvimento de um projeto de hardware (WILE; GOSS; ROESNER, 2005, p.15).
Outro ponto importante a se observar são os possíveis cenários para um dado projeto, ou
seja, quais são todas as possíveis combinações de entradas para um dado core.
Porém, gerar todos os possíveis cenários tem custo inviável para módulos maiores da mesma
forma que para testar muitas unidades menores também é inviável visto que pode levar um tempo
muito grande. Segundo Pessoa (2007, p.9), é necessário fazer escolhas, tais como:
• Verificar situações mencionadas na especificação;
• Verificar situações extremas;
19
• Utilizar estímulos reais; e
• Criar situações aleatórias.
Nesse contexto, situações aleatórias são especialmente importantes porque são capazes de
gerar cenários que seriam esquecidos (PESSOA, 2007, p.9).
2.2.5 Abordagens de verificação funcional
A verificação funcional pode ser realizada utilizando três abordagens complementares: caixa
preta, caixa branca e caixa cinza. Conforme discutido por Bergeron (2006).
Verificação de caixa preta
Na verificação de caixa preta, a verificação funcional é realizada sem conhecimento da
implementação real do componente. Toda a verificação é efetuada através das interfaces
disponíveis, sem acesso direto ao estado interno do sistema, sem conhecimento de sua estrutura e
implementação. Este método sofre de uma óbvia falta de visibilidade e controlabilidade. Em uma
abordagem de caixa preta, ocasionalmente é difícil alcançar uma determinada combinação de
estados ou isolar alguma funcionalidade. É igualmente difícil observar a resposta vinda da entrada e
localizar a fonte do problema. Porém, o autor afirma que a vantagem em utilizar uma abordagem
como essa é a independência de implementação. Não importa se o modelo foi implementado em
FPGA, código RTL, nível de portas lógicas ou inteiramente em software, verificação funcional de
caixa preta pode ser usada para mostrar que um modelo em particular implementa a intenção de
uma especificação, não importando sua forma de implementação.
É importante ressaltar que uma abordagem puramente de caixa preta é impraticável nos
grandes SoCs atuais. Um ASIC de milhões de portas possui tantos sinais e estados internos que é
efetivamente impossível verificar todas suas funcionalidades analisando somente sua periferia.
Verificação de caixa branca
Como o nome sugere, a abordagem de caixa branca é dual à abordagem caixa preta e
apresenta visibilidade e controlabilidade completa da estrutura e da implementação do modelo sob
verificação. Este método tem a vantagem de ser capaz de criar rapidamente uma combinação de
estados e entradas interessantes, ou isolar uma determinada função. É possível observar os
20
resultados como o progresso da verificação facilmente e imediatamente reportar quaisquer
discrepâncias do comportamento esperado. Mas, o autor explica que esta abordagem é estreitamente
integrada à implementação do modelo a ser verificado, mudanças no componente podem requerer
mudanças no testbench. Também requer conhecimento detalhado da implementação do componente
para saber quais condições significantes deverão ser criadas e quais resultados deverão ser
observados.
A verificação de caixa branca é um complemento útil para a verificação de caixa preta. Esta
abordagem pode garantir que características específicas da implementação em baixo nível se
comportam corretamente, como contadores que continuam a contar após alcançarem o valor final da
contagem ou caminhos de dados sendo apropriadamente alinhado e seqüenciado. A abordagem de
caixa branca só pode ser usada para verificar a corretude de uma funcionalidade, enquanto ainda
conta com os estímulos de caixa preta ou cinza. Visto que um SoC é composto por cores pré-
verificados e desenvolvidos de forma independente, a verificação a nível de sistema normalmente é
cumprida tratando os componentes como uma coleção de caixas pretas. Porém, o sistema em si é
tratado como uma caixa branca, com controle e observação plenos.
Verificação de caixa cinza
Verificação de caixa cinza é a harmonização entre a versatilidade da verificação de caixa
preta e a dependência de implementação da verificação de caixa branca. Como na verificação de
caixa preta, a abordagem de caixa cinza controla e observa um modelo inteiramente através de sua
interface externa. Contudo, uma determinada verificação pode ser realizada para excitar
características específicas significantes da implementação. Um típico caso de teste de caixa cinza é
escrito para aumentar métricas de cobertura. O estímulo de entrada é desenvolvido para executar
linhas específicas do código ou criar um conjunto específico de condições no modelo.
Caso a estrutura do modelo sob verificação mude, o caso de teste de caixa cinza continuará
correto, mas não mais contribuirá para uma melhor cobertura do modelo.
As abordagens de caixa preta e de caixa cinza são as únicas que podem ser usadas se a
verificação funcional é implementada em paralelo com a implementação do modelo em nível de
transações. Porque não há uma implementação detalhada conhecida de antemão, estas duas
estratégias de verificação são as únicas alternativas possíveis.
21
2.2.6 Testbench
As simulações em projetos de hardware são concretizadas ou implementadas através de
elementos chamados testbenches. Segundo Bergeron (2003; 2006), o termo testbench normalmente
se refere ao código de simulação utilizado para criar uma seqüência pré-determinada de entradas de
um projeto e então, opcionalmente, observar as respostas geradas pelo projeto. Pessoa (2007) afirma
que um testbench é um artefato escrito em linguagem formal, usado para criar simulações para o
modelo do DUV que é representado em alguma linguagem de descrição de hardware.
A Figura 5 mostra como o testbench interage com o DUV. O testbench provê a entrada de
dados no projeto e observa a todas as saídas. Segundo Bergeron (2006), é possível notar como o
testbench é um sistema completamente fechado: não há entradas nem saídas. O testbench é
efetivamente um modelo do universo, tanto quanto o projeto é concebido. Bergeron (2006) ainda
afirma que o desafio da verificação reside em determinar quais padrões de entrada fornecidos ao
modelo sob verificação e qual a saída prevista de um modelo que funcione corretamente quando
submetido a esses padrões de entrada.
Figura 5. Estrutura genérica de um testbench e de um DUV
Fonte: Adaptado de Bergeron (2006).
O testbench cria estímulos que conseguem ativar as funcionalidades desejadas no DUV. Por
exemplo, se um DUV tem uma funcionalidade de fazer soma de números inteiros, um estímulo para
ele pode ser representado por dois números inteiros. O testbench é a estrutura lógica em volta do
DUV que confrontará a sua funcionalidade com o modelo de referência que pode ser até mesmo um
software escrito em alguma linguagem de alto nível como C++ ou Java (PESSOA, 2007, p.9).
Segundo Pessoa (2007), o modelo de referência apresenta as funcionalidades que foram
especificadas no projeto. Esse modelo pode ser visto como um projeto de software já testado
22
funcionalmente que está sendo usado para ser confrontado com o modelo de hardware. Segundo
Bergeron (2003), as características desejáveis em um testbench são:
• Escrito em uma linguagem de verificação de hardware;
• Não possui entradas nem saídas;
• Um modelo do universo em volta do projeto;
• Cria estímulos e verifica a resposta;
• Imprime mensagens e cria histórico (log) quando o DUV apresenta comportamento
inesperado;
• Auto-checagem;
• Dirigido por cobertura funcional; e
• Uso de estímulos aleatórios.
2.3 REDES-EM-CHIP
O foco deste trabalho está na avaliação do impacto do uso de técnicas de verificação
funcional no projeto de componentes para arquiteturas de comunicação de SoCs baseadas em redes
chaveadas, também chamadas de redes-em-chip ou NoCs – Networks-on-Chip. Dessa forma, de
modo a complementar a base teórica necessária ao desenvolvimento deste trabalho, esta seção
apresenta uma revisão de conceitos relacionados a este tema. São discutidas as arquiteturas atuais
utilizadas em SoCs e a motivação para o uso de NoCs. Após, são apresentados conceitos gerais
sobre NoCs e é descrita uma arquitetura de NoC que servirá de referência a este trabalho.
2.3.1 Conceitos sobre comunicação em SoCs
Segundo Zeferino (2003, p.58), a interconexão entre os núcleos de um SoC (System-on-
Chip) é tipicamente realizada por meio de canais multiponto ou de canais ponto-a-ponto. Em canais
multiponto a interligação ocorre através de um barramento compartilhado onde os núcleos são
conectados, enquanto nos canais ponto-a-ponto os núcleos são interligados por canais
dedicados.Essas interligações podem ser comparadas conforme os critérios abaixo:
23
• Paralelismo: os canais ponto-a-ponto permitem múltiplas conexões simultâneas
enquanto canais multiponto concorrem pelo uso do barramento, sendo que esta
concorrência é escalonada por um árbitro;
• Consumo de energia: o consumo de energia é menor em canais ponto-a-ponto, pois eles
têm menor taxa de utilização e menor capacitância por terem canais com fios menores;
• Freqüência de operação: por possuírem menor carga capacitiva os canais ponto-a-ponto
conseguem trabalhar em maiores freqüências de operação;
• Escalabilidade: em canais ponto-a-ponto, a adição de cada núcleo requer a
implementação de novos canais aumentando com isso a largura de banda do sistema, em
canais multiponto, novos núcleos são conectados aos canais já compartilhados pelos
demais núcleos, com isso a largura de banda não aumenta;
• Área: o custo em área de silício varia de acordo com a implementação do sistema, sendo
que em uma arquitetura ponto-a-ponto depende do número de núcleos, do número de
portas por núcleo e do tamanho dessas portas. Em uma arquitetura multi-ponto o número
de portas por núcleo e o tamanho delas é fixo. No entanto, o aumento do número de
núcleos resulta no aumento do custo do árbitro e do(s) circuito(s); e
• Reusabilidade: requisito fundamental no mercado de microeletrônica, pois implica
diretamente no time-to-market. Uma arquitetura ponto-a-ponto é fundamentada em uma
abordagem ad-hoc e o seu reuso é bastante restrito. Já as arquiteturas multiponto são
reutilizáveis.
Mesmo a arquitetura multiponto possuindo tantas desvantagens em relação à arquitetura
ponto-a-ponto, ela tem sido preferida devido à sua reusabilidade. Além disso, algumas soluções têm
sido adotadas para contornar suas limitações de desempenho, como, por exemplo, o uso de
hierarquias com múltiplos barramentos.
No entanto, na medida em que os requisitos de comunicação tornam-se maiores, as
limitações do barramento estão ficando mais evidentes e as alternativas de amenização dessas
limitações vêm agindo contra sua principal característica, a de reusabilidade. Por exemplo, a
implementação de barramentos separados interconectados por pontes leva à perda de flexibilidade e
generalidade do barramento. De acordo com Zeferino (2003), alguns exemplos de limitações do
barramento são:
24
• Consumo de energia: por possuírem fios longos e serem carregados por todos os núcleos
a ele conectados, o barramento possui taxa de comunicação próxima de 100% e intensa
atividade de chaveamento nos seus fios;
• Desempenho: no barramento, a largura de banda disponibilizada a cada núcleo se
degrada com a adição de um novo núcleo que irá competir com os outros núcleos pelo
mesmo canal de comunicação;
• Freqüência de operação: devido à alta carga capacitiva dos barramentos eles tendem a
possuir grandes tempos de transição, reduzindo a freqüência máxima de operação dos
canais; e
• Paralelismo: o barramento possui baixo paralelismo, pois uma transação bloqueia outras
comunicações que utilizem o mesmo canal de comunicação reservado para aquela
comunicação.
2.3.2 Redes-em-chip
Conforme Zeferino (2003, p. 67),
Uma forma de se obter uma arquitetura de comunicação reutilizável e com desempenho escalável consiste no uso de redes de interconexão chaveada, semelhantes àquelas utilizadas em computadores paralelos. Essas redes baseiam-se em ligações ponto-a-ponto, e apresentam boas características quanto ao paralelismo, consumo de energia, freqüência de operação e escalabilidade, atendendo ainda ao requisito de reusabilidade.
Essas redes, são mais comumente referenciadas pelo termo NoC – Network-on-Chip, o qual
pode ser traduzido para Redes-em-Chip ou Redes Intrachip.
Uma NoC pode ser definida como um conjunto de roteadores e canais ponto-a-ponto
dedicados que interconectam núcleos, formando uma rede desses elementos. A forma usual de
comunicação entre os núcleos é a troca de mensagens. Cada mensagem é formada por um cabeçalho
(iniciando o pacote), uma carga útil (incluindo o conteúdo da mensagem) e um terminador
(sinalizando o fim da mensagem). O formato da mensagem e a interconexão de núcleos são
ilustrados na Figura 6.
25
(a) (b)
Figura 6. Arquitetura de NoC: (a) formato da mensagem; e (b) interconexão de núcleos
Fonte: Adaptado de Zeferino (2003).
Uma NoC pode ser caracterizada pelo tipo de topologia adotada e pelas técnicas utilizadas
pelos mecanismos de controle de fluxo, roteamento, arbitragem, chaveamento e memorização,
conforme discutido por Zeferino (2003) e descrito nas subseções a seguir.
2.3.3 Topologia
As NoCs propostas na literatura utilizam topologias baseadas naquelas adotadas em redes de
interconexão para computadores paralelos. Uma rede de interconexão caracteriza-se pela estrutura
de interligação de seus roteadores, sendo que sua topologia agrupa-se em duas classes principais:
redes diretas e redes indiretas.
Redes Diretas
Redes diretas são compostas por pares processador-roteador conhecidos como “nodos”. Os
nodos são conectados a nodos vizinhos por ligações ponto-a-ponto. A troca de mensagens entre
nodos não vizinhos ocorre através de um ou mais nodos intermediários. Uma mensagem recebida
por um nodo não destino é repassada pelo roteador para algum dos seus nodos vizinhos para
aproximar-se do seu destinatário, sendo que essa aproximação conduzida por um algoritmo de
roteamento que decidirá a qual nodo vizinho a mensagem será repassada. Toda comunicação ocorre
através dos roteadores, não interferindo nos processadores dos nodos intermediários.
Uma rede completamente conectada seria uma rede direta ideal, não fosse sua restrição a
escalabilidade e ao alto custo em se implementar um grande número de canais por nodo. Por esse
motivo a maior parte das implementações práticas são restrita a alguns modelos com topologia
ortogonal. Uma topologia de rede ortogonal caracteriza-se por nodos arranjados em um espaço n-
26
dimensional e cada enlace entre nodos vizinhos produz um deslocamento em uma única dimensão.
As topologias de redes diretas ortogonais mais utilizadas são a grelha (ou malha) n-dimensional, o
toróide (ou k-ary n-cube) e o hipercubo ilustradas na Figura 7.
(a) (b) (c)
Figura 7. Redes diretas: (a) grelha (ou malha); (b) toróide; (c) hipercubo
Fonte: Adaptado de Zeferino (2003).
Redes indiretas
Os nodos em redes indiretas são processadores, módulos de memória ou sistemas completos
que possuem uma interface para uma rede de roteadores. Cada roteador possui um conjunto de
portas bidirecionais para ligações com outros roteadores e/ou com os nodos da máquina. Poucos
roteadores fazem conexões com nodos, sendo os únicos que podem servir de fonte ou destinatário
de mensagens. A topologia de rede é definida pela estrutura de interconexão desses roteadores.
Existem duas topologias clássicas de destaque para redes indiretas: crossbar e as redes
multiestágio, ilustradas na Figura 8:
• Crossbar: topologia ideal para conexão indireta de N nodos, pois consiste de um único
roteador com uma chave NxN, mais econômico que uma rede direta completamente
conectada, mas sua complexidade torna seu custo inviabilizante; e
• Rede multiestágio: usualmente redes regulares, ou seja, os roteadores são idênticos e são
organizados como um conjunto de estágios. Os estágios de entrada e de saída possuem
ligações para os nodos e para os estágios internos da rede. Esses, por sua vez, são
ligados aos seus estágios vizinhos através de padrões de conexão regulares. Redes
multiestágio também podem ser caracterizadas pelo número de estágios e pela forma
como eles são arranjados.
27
(a) (b)
Figura 8. Redes indiretas: (a) crossbar; (b) multiestágio
Fonte: Adaptado de Zeferino (2003).
2.3.4 Controle de fluxo
O mecanismo de controle de fluxo trata da alocação dos recursos necessários para uma
mensagem avançar pela rede, realizando a regulagem de tráfego nos canais. Essa regulação é feita
com o objetivo de evitar a perda indesejada de dados enviados de um emissor a um receptor. A
unidade sobre a qual é realizado o controle de fluxo é denominada flit (Flow Control Unit).
Tipicamente, um flit corresponde a uma palavra do canal físico (denominada phit – Physical Unit),
mas pode corresponder a mais de um phit.
Existem alguns tipos básicos de técnicas para controle de fluxo, resumidas na Tabela 3.
Tabela 3. Formas comuns de controle de fluxo de arquiteturas de comunicação intra-chip
Tipo Descrição Handshake O receptor retorna um sinal de confirmação quando um flit é consumido. Stop-and-Go O receptor retorna um sinal solicitando a interrupção ou o estabelecimento
fluxo de flits em função da sua disponibilidade para consumi-los. Crédito O receptor possui um contador de créditos (correspondente ao espaço
disponível na fila de entrada do receptor) que é decrementado quando um flit é enviado e incrementado quando o receptor consome esse flit.
Canais Virtuais Consiste na divisão do canal físico em dois ou mais canais lógicos e permite que, caso o fluxo lógico de um canal seja bloqueado, outro possa utilizar o canal físico.
Fonte: Adaptado de Zeferino (2003).
28
2.3.5 Roteamento
Segundo Zeferino, Bampi e Susin (1999), o roteamento é o método usado para escolher um
caminho na rede para a comunicação entre dois nodos, sendo que o desempenho da rede de
interconexão depende fortemente do algoritmo adotado. Esse algoritmo busca atender objetivos
específicos, influenciando diretamente algumas propriedades da rede, como (DUATO;
YALAMANCHILI; NI, 1997, p. 115):
• Conectividade: capacidade de rotear pacotes de qualquer nodo fonte (ou origem) para
qualquer nodo destinatário (ou destino);
• Liberdade de deadlock e livelock: capacidade de garantir que nenhum pacote ficará
bloqueado (em deadlock) ou circulando pela rede sem atingir o seu destinatário (em
livelock);
• Adaptatividade: capacidade de rotear pacotes através de caminhos alternativos quando
ocorrer congestionamento ou falha em algum componente do caminho em uso; e
• Tolerância a falhas: capacidade de rotear pacotes na presença de falhas em componentes.
Os algoritmos de roteamento são geral classificados por taxonomias como a apresentada na
Tabela 4.
Tabela 4. Classificação dos algoritmos de roteamento
Critério Tipo Descrição Número de destinos
Unicast A mensagem tem um único destino Multicast A mensagem tem múltiplos destinos
Local de roteamento
Centralizado O caminho da mensagem é determinado por um controlador centralizado
Fonte O núcleo emissor da mensagem define o caminho a ser utilizado Distribuído O caminho da mensagem é definido pelos roteadores
Implementação física
Tabela O roteamento é feito por consulta a uma tabela Algoritmo O roteamento é feito por um algoritmo de software ou de
hardware Adaptatividade Determinístico O roteamento fornece sempre o mesmo caminho entre um
determinado par fonte-destino Adaptativo O roteamento utiliza alguma informação a respeito do tráfego da
rede e/ou do estado dos canais, evitando regiões congestionadas ou com falha
Oblivious (Inconsciente)
O roteamento oferece mais de um caminho alternativo; mas não leva em conta o estado da rede, como no roteamento adaptativo
Fonte: Adaptado de Zeferino (2003).
29
2.3.6 Arbitragem
O mecanismo de arbitragem resolve conflitos internos da rede, quando duas ou mais
mensagens competem por um mesmo recurso (por exemplo, um canal de saída de um roteador).
Alguns dos esquemas de arbitragem mais utilizados em redes de interconexão e adotados em NoCs
são resumidos na Tabela 5.
Tabela 5. Tipos de arbitragem
Tipo Descrição Prioridades estáticas Cada canal de entrada possui uma prioridade fixa ao competir pelo canal
de saída Prioridades dinâmicas As prioridades variam a cada arbitragem realizada, tipicamente
implementada por uma fila circular Deadline A mensagem aguardando por mais tempo o canal de saída é selecionada LRS O canal de entrada menos recente é selecionado FIFO O primeiro canal de entrada a selecionar o canal de saída é selecionado
pelo árbitro Multinível Implementa em mais de um nível diferente esquemas de arbitragem
Fonte: Adaptado de Zeferino (2003).
2.3.7 Chaveamento
Chaveamento é o mecanismo responsável pela transferência dos dados do canal de entrada
para o canal de saída e exerce forte influência sobre a latência de rede.
As principais técnicas de chaveamento baseiam-se ou no estabelecimento de um circuito,
caminho completo entre a fonte e o destinatário da mensagem, ou na divisão das mensagens em
pacotes que irão reservar seus caminhos dinamicamente na medida em que avançam em direção ao
destinatário. A seguir são descritas as principais técnicas de chaveamento com base nas definições
apresentas por Duato, Yalamanchili e Ni (1997), Zeferino, Bampi e Susin (1999) e Zeferino (2003):
Chaveamento por circuito
O chaveamento por circuito baseia-se no estabelecimento de um caminho completo entre
fonte e destinatário, o qual é mantido até o término da comunicação. O circuito é estabelecido em
duas etapas:
• Primeira etapa: o nodo injeta um cabeçalho (uma única palavra) que avança pela rede,
reservando canais físicos. Quando o cabeçalho chega ao nodo destinatário, uma
30
informação de reconhecimento é enviada ao nodo fonte através do caminho de retorno
do circuito estabelecido;
• Segunda etapa: quando a informação de reconhecimento é recebida são enviados os
dados da mensagem. Para o cancelamento do circuito, um terminador é enviado ao
destinatário, liberando os recursos previamente alocados na medida em que passa pelos
roteadores.
O chaveamento por circuito se originou das redes telefônicas e se caracteriza por:
• Ausência de contenção no envio da mensagem após o estabelecimento do circuito;
• Necessita de apenas uma posição de buffer para manter o cabeçalho enquanto o próximo
canal desejado encontrar-se indisponível; e
• Os canais já alocados a um cabeçalho permanecem bloqueados e não podem ser
utilizados por outro circuito, o que reduz a utilização da rede e aumenta o tempo para o
estabelecimento dos caminhos, sendo esta a maior desvantagem desta técnica.
O uso do chaveamento por circuito se justifica nos casos em que as mensagens são longas e
pouco freqüentes.
Chaveamento por pacotes
Existem diferentes tipos de chaveamento por pacotes. Os principais são:
• SAF (Store-And-Forward): quando um roteador recebe um pacote, ele é armazenado em
uma fila do canal de entrada do roteador, analisando o destinatário e requisitando um
canal de saída. Essa requisição é escalonada por um árbitro que determina quando cada
canal de entrada será conectado ao canal de saída solicitado;
• VCT (Virtual Cut-Through): quando o cabeçalho do pacote contendo as informações de
roteamento chega a um roteador e o canal de saída desejado encontra-se indisponível, o
restante do pacote (carga útil e terminador) desvia a fila, reduzindo a latência da
comunicação. Um pacote só é armazenado na fila se o canal desejado estiver alocado a
outro pacote; e
• Wormhole: um pacote é dividido em flits que avançam pela rede em um modo pipeline.
Nas redes baseadas nesta técnica, as filas dos roteadores têm capacidade para armazenar
31
poucos flits, de modo que os flits de um pacote bloqueado são mantidos em diferentes
roteadores na rede, caso o tamanho do pacote seja maior que o espaço livre no buffer.
Como a informação de roteamento é incluída no flit de cabeçalho, os flits de dado devem
seguir o flit do cabeçalho através da rede.
2.3.8 Memorização
Todo roteador baseado no chaveamento por pacotes deve ser capaz de armazenar pacotes
bloqueados temporariamente em seu interior. Ou seja, pacotes destinados a canais de saída que já
estejam sendo utilizados por outros pacotes e que devem aguardar pela liberação do canal desejado.
Isso exige a implementação de algum esquema de memorização para a manutenção dos pacotes
bloqueados em filas dentro do roteador. As principais alternativas de mecanismos de memorização
são apresentadas na Tabela 6.
Tabela 6. Mecanismos de memorização
Tipo Descrição Memorização de entrada
O espaço de memória é distribuído sob a forma de partições implementadas através de filas independentes, as quais são associadas aos canais de entrada
Memorização de saída
O espaço de memória é distribuído sob a forma de partições implementadas através de filas independentes, as quais são associadas aos canais de saída
Memorização centralizada compartilhada
Uma fila central é utilizada para armazenar os pacotes bloqueados de todas as portas de entrada e o espaço de endereçamento é dinamicamente distribuído entre os pacotes bloqueados
Fonte: Adaptado de Zeferino (2003).
2.4 A REDE SOCIN
Esta seção apresenta a rede SoCIN – System-on-Chip Inteconnection Network, descrita por
Zeferino (2003), a qual servirá de referência para este trabalho. Em especial, é descrita a versão
mais recente da rede, a qual é denominada SoCINfp (SoCIN fully parameterizable) e é descrita por
Zeferino, Santo e Susin (2004).
2.4.1 Arquitetura da rede SoCINfp
A NoC SoCINfp utiliza uma topologia de rede ortogonal em malha 2-D. Seu roteador tem
até 5 portas de comunicação, sendo que uma delas é reservada para comunicação com o core local e
as outras com os roteadores vizinhos. Conforme a posição de um roteador instanciado na rede, nem
32
todas as 5 portas são necessárias, pois os roteadores da periferia da rede precisam de 2 a 3 portas
para comunicação com os nodos vizinhos.
A SoCINfp usa chaveamento de pacotes wormhole e as mensagens são enviadas por meio de
pacotes que são compostos por flits, sendo que, na SoCINfp, um flit tem o tamanho de um phit
(unidade física do canal). Na SoCINfp, pacotes são transferidos de uma maneira sem perdas e os
algoritmos de roteamento são limitados para as únicas possíveis formas de serem usadas em
topologias ortogonais 2-D. Para esses algoritmos, foi estabelecido um sistema de coordenadas em
que cada roteador na rede é identificado por um par de coordenadas (xid, yid), como mostra a Figura
9.
Figura 9. Sistema de coordenadas
Fonte: Zeferino, Santo e Susin (2004).
Quando um pacote é enviado por um core ligado a uma porta do roteador, o remetente deve
incluir, no cabeçalho do pacote, as coordenadas do roteador que está ligado ao core de destino (xdest,
ydest). Esta informação é utilizada para cada roteador no caminho do pacote, que compara o
endereço de destino com seu próprio endereço, para determinar qual canal de saída utilizar para
enviar o pacote adiante. Em abordagens parcialmente ou completamente adaptativas, o roteador
também leva em conta informações sobre a disponibilidade dos canais de saída para fazer o
roteamento.
O formato do pacote é ilustrado na Figura 10. O pacote é composto por um número de flits
ilimitado, cada um tendo n+2 bits de largura: n para dados e 2 para sinalizar início (bop – begin-of-
packet) e fim do pacote (eop – end-of-packet). O primeiro flit é aquele em que bop é igual a 1, e
corresponde ao cabeçalho do pacote. Este cabeçalho é composto por dois campos básicos: bits de
33
informação de roteamento (RIB – Routing Information Bits) e protocolo de nível superior (HLP –
Higher Level Protocol). O campo RIB carrega a informação usada para cada roteador para realizar
o roteamento do pacote, ou seja, as coordenadas do destino (subcampos: xdest e ydest). O campo HLP
é reservado para a implementação de protocolos de camadas superiores à camada de rede (eg.
informação para reordenação de pacotes), e não é processado pelos roteadores. O RIB tem uma
largura de m bits e, portanto, o tamanho da rede é limitado a 2m/2×2m/2 roteadores. O HLP tem uma
largura de (n-m) bits, e, se for necessário, pode ser estendido aos flits seguintes no pacote apenas
implementando o protocolo necessário para as interfaces de rede (wrappers) processarem o pacote.
Após o cabeçalho, os flits restantes no pacote compõem o payload, traduzido livremente como
carga útil, que apresenta comprimento ilimitado. O último flit da carga útil tem eop igual a 1, que
define este flit como o terminador do pacote. Na Figura 10, somente os bits que demarcam início e
fim do pacote e o RIB são destacados, pois são as únicas informações vistas pelos roteadores.
Figura 10. Formato do pacote da SoCINfp
Fonte: Adaptado de Zeferino, Santo e Susin (2004).
Os roteadores da rede SoCINfp são interligados por enlaces bidirecionais como o ilustrado
na Figura 11. Ele possui dois canais unidirecionais, cada um contendo: um canal de dados de n bits
(data), bits de enquadramento de pacote (bop e eop) e sinais de controle de fluxo (val e ret).
34
Figura 11. Enlace da SoCINfp
Fonte: Zeferino, Santo e Susin (2004).
No enlace ilustrado na Figura 11, o canal de dados possui largura parametrizável, sendo que
n pode ser configurado para diferentes tamanhos. Os sinais bop e eop marcam o início e o final do
pacote, respectivamente, conforme comentado no início desta subseção. Os sinais val e ret servem
para implementar qualquer protocolo de controle de fluxo de dois fios (handshake ou baseado em
créditos). O canal de dados mais os sinais de enquadramento constituem a unidade física do canal
(phit), a qual é, portanto, igual a n+2.
A SoCINfp herda várias funcionalidades da SoCIN (ZEFERINO, 2003). Contudo, para
oferecer maior flexibilidade, algumas mudanças precisaram ser feitas a fim de satisfazer o nível de
parametrização desejado. A maior diferença entre as NoCs reside no local em que o roteamento é
realizado. Na SoCIN, o remetente define a rota a ser usada pela mensagem, enquanto que na
SoCINfp, esta tarefa é uma responsabilidade dos roteadores. Isso permite implementar algoritmos
de roteamento diferentes, sejam eles determinísticos ou completamente adaptativos. Entretanto, a
implementação atual da SoCINfp é limitada a algoritmos de roteamento parcialmente adaptativos
baseado no modelo proposto no Glass e Ni (1992). A SoCINfp também é mais flexível do que a
SoCIN no que diz respeito a técnicas utilizadas para controle de fluxo, arbitragem e memorização,
tais comparações estão resumidas na Tabela 7. Comparação das características da SoCIN e da
SoCINfp.
35
Tabela 7. Comparação das características da SoCIN e da SoCINfp
Característica SoCIN SoCINfp Roteamento Fonte (somente determinístico) Distribuído (determinístico ou
parcialmente adaptativo Controle de fluxo Handshake Handshake ou baseado em
créditos Memorização Entrada Entrada e/ou saída Arbitragem Dinâmica (round-robin) Estática ou dinâmica (aleatória
ou round-robin) Sistema de coordenadas Não usado Usado Significado do campo RIB Número de enlaces usados nas
direções X e Y Coordenadas do roteador de destino na rede
Fonte: Zeferino, Santo e Susin (2004).
Como também pode ser visto na Tabela 7, SoCIN não utiliza qualquer sistema de
coordenadas, e o campo RIB incluía o número de enlaces a serem percorridos por uma mensagem
nas direções X e Y antes de chegar ao seu destinatário.
2.4.2 Arquitetura do roteador da rede SoCINfp
O bloco construtivo básico da rede SoCINfp é o roteador ParIS – Parameterizable
Interconnection Switch. Esse roteador foi implementado como um soft-core em VHDL baseado em
uma biblioteca de blocos parametrizáveis pré-modelados, incluindo abordagens/implementações
diferentes para cada técnica utilizada no envio de mensagens no chaveamento de pacote wormhole
em NoCs (controle de fluxo, roteamento, arbitragem e memorização). A seguir, a arquitetura deste
roteador é descrita de acordo com Zeferino, Santo e Susin (2004).
Organização do roteador
O roteador ParIS tem até 5 portas de comunicação compatíveis com o enlace da rede
SoCINfp, as quais são denominadas L, N, S, E e W. A primeira porta (Local) é reservada para
anexar um core ou um subsistema a rede, e as outras portas (que tem seus nomes derivados dos
pontos cardeais) são reservadas para conexões inter-roteadores.
Como mostra a Figura 12, o ParIS é internamente estruturado de forma distribuída, e cada
porta de comunicação tem dois módulos: canal de entrada e canal de saída, em que os maiores sub-
componentes são implementados. Por exemplo, a porta Local é composta pelos módulos chamados
Lin (o canal de entrada) e Lout (o canal de saída).
36
Figura 12. Organização do ParIS
Fonte: Zeferino, Santo e Susin (2004).
Dependendo da posição de uma instância do roteador ParIS na rede, nem todas as portas são
necessárias, e, portanto, os circuitos dos canais de entrada e de saída associados às portas não
necessárias não devem ser sintetizados. Para cumprir esta tarefa, há cinco parâmetros para sinalizar
o uso de cada porta.
Os blocos construtivos do roteador ParIS são descritos a seguir.
Controladores de Enlace (IFC e OFC)
Os controladores de enlace regulam o tráfego de flits na rede fazendo a tradução entre o
protocolo de controle de fluxo de enlace e a técnica de controle de fluxo utilizada dentro dos
roteadores. Há dois tipos de blocos relacionados a esta tarefa:
• IFC (Input Flow Controller – controlador do fluxo de entrada): regula o tráfego dos flits
que chegam ao canal de entrada; e
• OFC (Output Flow Control – Controlador de fluxo de saída): regula o tráfego dos flits
que saem pelo canal de saída.
37
Buffers FIFO
Os buffers FIFO (First-In First-Out) são utilizados para armazenar flits de mensagens
bloqueados temporariamente dentro do roteador e aguardando para serem enviados. O uso de FIFOs
em ambos os módulos de uma porta (canais de entrada e saída) é opcional. Por exemplo, para
configurar o compilador VHDL sintetizar roteadores utilizando somente memorização de entrada,
basta apenas atribuir um parâmetro de entrada para síntese.
Controladores de Agendamento (IC e OC)
Os controladores de agendamento realizam o agendamento de recursos dentro do roteador.
Há dois tipos e controladores:
• IC (Input Controller – controlador de entrada): Cada bloco IC detecta a presença de um
cabeçalho de pacote na saída do bloco FIFO associado, executa o algoritmo de
roteamento, seleciona um canal de saída pelo qual o pacote deve ser encaminhado e
envia uma requisição ao bloco OC (Output Controller – Controlador de saída) desse
canal de saída. Para roteamento adaptativo, o estado dos canais de saída (idle) deve ser
levado em conta quando há mais do que um canal de saída autorizado para ser requerido.
Uma vez que a conexão requerida é estabelecida, este bloco monitora a entrega do
terminador do pacote, e então restabelece a requisição concedida a fim de solicitar que o
bloco OC cancele a conexão; e
• OC: Cada bloco OC resolve conflitos que ocorrem quando duas ou mais requisições
(emitidas pelos blocos IC) são destinadas ao canal de saída associado. Ele seleciona uma
das requisições, mantendo a(s) outra(s) em espera, aguardando pela liberação do canal
de saída para ser(em) escalonada(s). A arbitragem é realizada a partir das requisições
recebidas dos blocos IC e com base em um critério de prioridades que pode ser estático
ou dinâmico. Quando a requisição concedida é restabelecida pelo bloco IC do canal de
entrada selecionado, o bloco OC cancela a conexão estabelecida e atribui o sinal de
estado idle.
Switches (ODS, OWS e IRS)
Os switches realizam o chaveamento do canal interconectando dados e sinais do controle de
fluxo interno dos canais de entrada e saída sob o comando dos sinais concedidos emitidos pelos
blocos OC. De fato, eles implementam um crossbar distribuído por meio de três tipos de switches:
38
• ODS (Output Data Switch – chave de saída de dados): conecta a porta de saída de dados
vinda do buffer do canal de entrada selecionado à porta de entrada de dados do buffer de
saída associado;
• OWS (Output Write Switch – chave de escrita na saída): é responsável por conectar o
sinal de status rok vindo do buffer do canal de entrada selecionado ao sinal de comando
wr do buffer de saída associado; e
• IRS (Input Read Switch – chave de leitura da entrada): conecta o sinal de status wok
vindo do buffer do canal de saída requerido e concedido ao sinal de comando rd do
buffer de entrada associado.
Os blocos ODS e OWS de um determinado canal de saída são comandados pelos sinais de
concessão emitidos pelo bloco OC associado. Contudo, o bloco IRS de um determinado canal de
entrada é comandado pelos sinais de concessão emitidos pelos blocos OC de todos os canais de
saída que aquele canal de entrada pode requerer.
Matriz de cruzamento (CPM)
A matriz de cruzamento (CPM, do inglês Crosspoint Matrix) é o bloco responsável por
configurar o compilador VHDL a fim de implementar somente as conexões permitidas pelo
algoritmo de roteamento utilizado. Dada uma estrutura de cruzamento para um algoritmo
selecionado, o bloco CPM prende os sinais de requisição e de concessão relacionados a conexões
não-permitidas pela abordagem de roteamento, enquanto encaminha diretamente os sinais
associados a conexões permitidas. Na Figura 13, é representada a matriz de cruzamento para cada
abordagem de roteamento implementada no ParIS.
(a) (b)
Figura 13. Matriz de cruzamento para abordagens diferentes de roteamento: (a) XY; (b) West-First
Fonte: Zeferino, Santo e Susin (2004).
39
Para o roteamento XY (Figura 13.a), somente as 16 conexões representadas por círculos são
permitidas. Por exemplo, não é permitido para um canal de entrada de uma determinada porta de
comunicação requerer o canal de saída da mesma porta. Além disso, não é permitido para os canais
de entrada que estão na direção Y (Nin and Sin) requererem canais de saída que estão na direção X
(Eout and Wout). O número de círculos em cada coluna da Figura 13.a corresponde ao número de
entradas nos blocos ODS e OWS do canal de saída associado (eg. switches 4x1 para Lout, e switches
2x1 para Wout). Por outro lado, o número de círculos em cada linha corresponde ao número de
entrada no bloco IRS do canal de entrada associado (eg. um switch 4x1 para Lin, e um switch 2x1
para Nin).
O outro esquema de roteamento implementado no ParIS (West-First) é menos restritivo, e
permite conectar canais de entrada na direção Y (Nin and Sin) a Eout (círculos de cor cinza na Figura
13.b), mas não pode se conectar a Wout. Esta abordagem pode melhorar a utilização dos canais, mas
também aumenta o custo do roteador devido ao crescimento no número de portas dos switches
associados com as conexões Y-to-Eout.
2.5 TRABALHOS RELACIONADOS
Nas pesquisas realizadas foram encontrados poucos trabalhos que descrevessem o uso de
técnicas de verificação funcional no projeto de Redes-em-Chip ou de SoCs baseados em NoCs,
destacando-se os artigos publicados por Kakoee et al.(2007) e Hahanov et al.(2007).
Kakoee et al. (2007) propõem uma metodologia de verificação de caixa branca baseada em
asserções para NoCs. Há um processador local de asserções (LAP – Local Assertion Processor) em
cada núcleo da rede, que é responsável por gerenciar as saídas geradas pelas asserções no núcleo
sob verificação. Para realizar o roteamento das saídas das asserções rumo ao LAP é utilizado um
mecanismo de varredura em cadeia, ilustrado na Figura 14.
40
Figura 14. Mecanismo de asserção em cadeia e processador local de asserções
Fonte: Kakoee et al. (2007).
Além disso, após detectar algum erro, cada LAP despacha um pacote chamado “error
packet” para um processador global de asserções (GAP – Global Assertion Processor) que recebe
pacotes de erro vindos de todos os núcleos e executa as ações necessárias em relação aos erros e
suas conseqüências. O método de verificação foi aplicado em uma estrutura de NoC para fins de
avaliação, tal estrutura é ilustrada na Figura 15.
Figura 15. Estrutura da NoC com verificação baseada em asserções
Fonte: Kakoee et al. (2007).
41
Em suma, o trabalho desenvolvido por Kakoee et al. (2007) não realiza a verificação
funcional no projeto da Rede-em-Chip, que é a proposta deste trabalho, mas utiliza a estrutura de
NoC para fazer a comunicação entre os processadores locais de asserções (LAPs) e o processador
global de asserções (GAP).
O artigo de Hahanov et al. (2007), analisa e compara várias arquiteturas de Redes-em-Chip
baseado em várias características como escalabilidade, complexidade e topologia. Os autores
também analisam protocolos de comunicação em rede como OCP (Open Core Protocol) e
discorrem sobre as abordagens e desafios da verificação. Enfim, Hahanov et al. (2007) realiza um
estudo comparativo entre algumas arquiteturas de Redes-em-Chip e abordagens de verificação
utilizadas em sistemas baseados em arquiteturas de Redes-em-Chip.
Ambos os artigos destacam o uso de asserções como melhor alternativa para verificação
funcional, tanto para utilizar a estrutura de NoC como forma de comunicação, como para realizar a
verificação de sistemas integrados baseados em NoC. Nenhum dos artigos descreve a verificação
sendo utilizada na implementação dos roteadores, que são os blocos que constituem a rede.
3 DESENVOLVIMENTO
O objetivo geral deste trabalho foi o de avaliar o impacto do uso de técnicas de verificação
funcional no projeto de roteadores para Redes-em-Chip. Para tal, foram implementados os
testbenches dos blocos construtivos do roteador ParIS da rede SoCIN, simulados em um ambiente
de simulação e avaliados comparando-os com o método de validação utilizando diagramas de
formas de onda.
Neste capítulo é apresentada uma visão geral do projeto, o levantamento de requisitos da
aplicação e da avaliação do processo de verificação funcional e os aspectos relativos à
implementação, validação e avaliação dos testbenches.
3.1 VISÃO GERAL
O objetivo geral deste projeto é avaliar o impacto da utilização de verificação funcional no
desenvolvimento de um roteador para Redes-em-Chip. Como o roteador já foi implementado, as
técnicas de verificação foram aplicadas para validar essa implementação, o foco do trabalho está no
estudo e na avaliação do processo de verificação.
Em resumo, no escopo do trabalho, foram desenvolvidos testbenches para verificação
funcional do roteador e dos seus blocos construtivos. Como o roteador foi implementado utilizando
uma abordagem bottom-up, os componentes de menor nível hierárquico foram os primeiros a serem
verificados. No planejamento do desenvolvimento, definiu-se que, a cada subida no nível de
hierarquia, na integração dos componentes, seria realizada a validação dessa integração.
Aplicou-se as técnicas de verificação funcional sobre o roteador ParIS utilizando uma
metodologia de desenvolvimento1 abordada na Seção 3.3. Para tal, foram utilizadas técnicas de
engenharia reversa no modelo em VHDL já desenvolvido para uma identificação das características
do roteador de modo a definir os requisitos que servirão de referência para a construção dos
testbenches, os quais foram implementados em SystemVerilog. Porém, devido ao tipo de licença
do software utilizado na verificação, que não suporta simulação mista (utilizando mais de uma
1 Inicialmente, havia a intenção de se utilizar a metodologia de desenvolvimento e as ferramentas do ipPROCESS, abordado na Fundamentação Teórica. Contudo, não foi possível obter o acesso aos softwares necessários e optou-se então pelo ambiente de simulação ModelSim-Altera®.
43
linguagem), os modelos originais dos componentes do roteador ParIS descritos em VHDL e que
seriam usados como DUVs (Designs Under Verification) tiveram que ser traduzidos para Verilog, o
que acarretou em um significativo atraso no cronograma do projeto.
Como resultado, buscou-se avaliar o impacto da utilização da verificação funcional no
processo de desenvolvimento de roteadores para uma NoC. Essa avaliação, que foi feita de forma
qualitativa, analisou a contribuição do uso da verificação funcional ao processo tradicional de
validação utilizado no Laboratório de Sistemas Embarcados e Distribuídos (LSED), ao qual este
projeto está relacionado. Esse processo consiste basicamente de três etapas: (i) especificação
manual de um diagrama de formas de onda com estímulos de entrada; (ii ) execução de uma
simulação; e (iii ) análise visual pelo projetista dos resultados da simulação.
É importante ressaltar que, em equipes pequenas, é comum que a mesma equipe que
implementou o core execute as simulações usando diagramas em formas de onda para verificar as
funcionalidades do núcleo desenvolvido. Há, portanto, maior dificuldade em garantir um núcleo
livre de erros de projeto e/ou de implementação, pois a validação pode não verificar condições não
tratadas pelo projetista. Quando se utiliza uma abordagem de verificação funcional aliada à
simulação por formas de onda, tem-se mais garantias de que o circuito implementa o que foi
especificado, pois a verificação funcional possibilita uma maior abrangência de estímulos a
determinadas funcionalidades.
Como hipótese de pesquisa, considerou-se que a verificação funcional iria introduzir um
custo adicional no processo de validação, por conta do tempo para a construção dos testbenches,
mas aumentaria a taxa de cobertura da validação do componente sob verificação.
3.2 ANÁLISE DE REQUISITOS
Devido à natureza deste projeto, que é tratar da avaliação de um processo ao invés do
desenvolvimento de um produto (de software ou de hardware), o levantamento de requisitos se
torna mais dificultoso. Dessa forma, nessa seção, busca-se identificar os requisitos mínimos a serem
considerados na aplicação e na avaliação do processo de verificação funcional.
3.2.1 Requisitos Funcionais (RF)
• RF01: Todos os blocos que compõem o roteador devem ser cobertos pela verificação;
• RF02: Os testbenches não deverão possuir nem entradas e nem saídas;
44
• RF03: Os testbenches deverão criar estímulos e verificar as respostas;
• RF04: Os testbenches deverão utilizar tanto estímulos determinísticos, reproduzindo
fluxos de comunicação típicos, como estímulos aleatórios, reproduzindo
comportamentos não previstos; e
• RF05: Os testbenches deverão imprimir mensagens e criar histórico (log) quando o DUV
apresentar comportamento inesperado.
Requisitos não-funcionais (RNF)
• RNF01: Os testbenches deverão ser desenvolvidos em SystemVerilog; e
• RNF02: O processo de verificação funcional seguirá o processo adotado na metodologia
ipPROCESS.
3.3 IMPLEMENTAÇÃO
A metodologia utilizada nesse trabalho foi a bottom-up, em que os componentes são
integrados do nível mais baixo para o nível mais alto da hierarquia do projeto.
Foi utilizada a linguagem SystemVerilog para desenvolvimento dos testbenches e, conforme
já discutido, foi necessário traduzir os modelos VHDL do roteador para a linguagem Verilog devido
a limitações do simulador utilizado.
A Figura 16 ilustra um dos blocos construtivos do ParIS, o bloco OWS (Output Write
Switch). Este bloco é basicamente um multiplexador 4x1 baseado na codificação one-hot, no qual
cada bit do seletor é responsável por uma entrada do multiplexador. A metodologia de verificação
utilizada será abordada nesta seção utilizando o bloco OWS como exemplo, visto que ele apresenta
um baixo nível de complexidade.
45
Figura 16. Bloco construtivo OWS
O bloco foi traduzido para Verilog utilizando uma descrição comportamental. O código-
fonte desenvolvido pode ser visto na Figura 17. O bloco é descrito como um módulo VERILOG
que inclui uma declaração de sua interface de entrada e de saída e o seu comportamento (descrito
por uma estrutura if-then-else.
Figura 17. Bloco OWS descrito em Verilog
46
Foi planejado que a verificação de um DUV deveria conter uma estrutura genérica de
desenvolvimento composta por seis partes e que poderia ser distribuída em mais de um arquivo. As
suas partes incluem: (i) instanciação do DUV; (ii ) inicialização da simulação e caso de teste;
(iii ) geração de estímulos; (iv) inserção do comportamento esperado; (v) verificação de resultados; e
(vi) encerramento da simulação. Cada parte será exemplificada a seguir.
Instanciação do DUV
Para produzir estímulos, monitorar e verificar as saídas do DUV é necessário instanciar o
componente no código do testbench. Para tal, no testbench, são criados registradores e fios que são
ligados aos pinos de entrada e de saída do DUV, respectivamente. Tal representação pode ser vista
na Figura 18, que ilustra a declaração dos sinais (fios e registradores) e o mapeamento desses sinais
à interface do DUV.
Figura 18. Instanciação do DUV
Inicialização da simulação e caso de teste
A verificação precisa seguir um roteiro que guia o fluxo de comunicação de dados a fim de
verificar uma determinada funcionalidade. A este roteiro dá-se o nome de caso de teste (do inglês,
test case). O roteiro normalmente começa com a preparação de um ambiente de simulação, no qual
se inicializam os registradores, assegurando a ausência de valores residuais que possam levar a
resultados inesperados. A inicialização dos registradores e o caso de teste podem ser vistos na
Figura 19. O caso de teste é composto por segmentos que definem um valor para o seletor (ex. sel
= 4’b0001 ), configuram um número de ciclos (ex. repeat (8) ), e aplicam esse valor pelo
número de ciclos definido (ex. begin @(negedge clk) end ).
47
(a) (b)
Figura 19. Simulação: (a) inicialização; (b) caso de teste
Geração de estímulos
Normalmente, a geração de estímulos ocorre no próprio caso de teste. Na Figura 19 (b), é
possível notar que o valor de sel é alterado a cada oito ciclos de clock, entretanto, não é a única área
de código que permite a geração de estímulos.
É importante ressaltar que a geração de todas as entradas possíveis para um determinado
DUV apresenta um custo inviável. Por isso os testbenches possibilitam a geração de estímulos
determinísticos e/ou aleatórios. Estímulos determinísticos foram utilizados, em sua maioria, para
alimentar os canais de entrada com comandos de controle, no exemplo sel[3:0], para que fosse
possível reproduzir fluxos de comunicação típicos. Já os estímulos aleatórios foram utilizados, em
sua maioria, para alimentar os canais de entrada que não comprometiam a reprodução de fluxos
comunicação esperados, no exemplo wrin[3:0], pois estímulos randômicos podem reproduzir
comportamentos não previstos.
Na Figura 20, é possível notar a geração de entradas para wrin em um trecho de código
diferente de onde o caso de teste está situado, pois se trata de uma geração aleatória de estímulos
que independe do fluxo de comunicação escolhido pelo teste.
48
Figura 20. Geração aleatória de estímulos
Inserção do comportamento esperado
Para a correta verificação de um componente sob teste, é necessário haver um modelo lógico
que contenha os resultados esperados e que sirva de referência para o DUV. Esse modelo é,
denominado modelo de referência, como já descrito na Seção 2.2.6. Nesta etapa, o código de
referência é alimentado pelas mesmas entradas do DUV, para posteriormente serem comparados.
Como ilustra a Figura 21, o modelo de referência descreve o comportamento esperado do DUV.
Figura 21. Lógica de referência
Verificação de resultados
Esta etapa é responsável por verificar, através de comparações, se o DUV apresenta o
mesmo comportamento do modelo de referência. Na Figura 22, caso a saída vinda do modelo de
referência (wrout_compare) seja diferente da saída vinda do DUV (wrout), uma mensagem de erro
é criada, é atribuído o valor ‘1’ ao flag duv_error e a simulação é finalizada. É possível perceber
que a geração de estímulos como o da Figura 20 são sensíveis à borda de subida do clock, enquanto
que a verificação das saídas é sensível à borda de descida2 do clock, essa diferença é necessária para
2 Do ponto de vista de um simulador, a descrição de um elemento sensível à borda de descida de um sinal de relógio pode ser simulada com sucesso; entretanto, a ferramenta de síntese poderá não sintetizar a descrição por falta de um elemento desse tipo no mundo físico (D’AMORE, 2005).
49
evitar que o verificador (do inglês, checker) eventualmente capture um sinal que está em transição,
ocasionando, aparentemente, um erro funcional.
Figura 22. Verificação de resultados
Encerramento da simulação
A última parte da estrutura genérica de um testbench é responsável por encerrar a simulação
e reportar o estado geral da simulação (PASSED ou FAILED) baseada no valor do flag duv_error,
como ilustra a Figura 23.
Figura 23. Encerramento da simulação
3.4 VALIDAÇÃO
Na fase de validação, além dos scripts dos testbenches, também se fez necessário validar os
blocos construtivos do ParIS, agora descritos em Verilog. Para os blocos construtivos,
primeiramente, a validação foi realiza através da simulação por diagramas de formas de onda e
através da comparação dos diagramas RTL gerados pelos códigos em Verilog com os códigos
originais que já haviam sido pré-verificados e pré-validados. Para tal comparação, foi utilizada a
50
ferramenta de EDA (Electronic Design Automation) Quartus II da Altera. O diagrama RTL do
bloco OWS é ilustrado na Figura 24.
Figura 24. Diagrama RTL do bloco OWS
Após a etapa de validação por diagramas de formas de onda, os componentes tiveram suas
funcionalidades avaliadas utilizando a técnica de verificação funcional no ambiente de simulação
ModelSim, seguindo a metodologia descrita na Seção 3.3. O histórico de uma das simulações do
bloco OWS pode ser visto na Figura 25.
Figura 25. Log de simulação de um testbench automatizado
Para garantir que o testbench e o DUV desempenhem as funções esperadas, foi necessário
um processo cíclico de aprimoramento, como mostra a Figura 26. O DUV era sintetizado e
verificado, caso a verificação assinalasse algum erro, o DUV era corrigido e verificado, reiniciando
ao ciclo. Além disso, propositalmente foram inseridos erros no DUV para assegurar que o
testbench, mais precisamente o checker, descobriria tal falha.
Figura 26. Processo de verificação
51
3.5 AVALIAÇÃO
Durante a avaliação das técnicas de verificação funcional, foi possível analisar, que apesar
da verificação funcional aumentar a carga de trabalho do projeto, ela apresenta vantagens em
relação à verificação manual baseada na especificação de vetores de teste via diagramas de formas
de onda. Nesta, os vetores de teste são desenhados manualmente como diagramas de formas de
onda, cujos nodos são pinos de E/S e registradores de componentes recém-compilados. Isso
impossibilita a reusabilidade, já que cada diagrama é desenhado exclusivamente para um
determinado componente, apresentando nenhuma possibilidade de generalização. Entretanto, um
testbench descrito para uma verificação funcional, por ser implementado em uma linguagem de
descrição de hardware, apresenta um maior índice de reusabilidade, influindo diretamente no tempo
de projeto.
A verificação automática dos resultados vindos do DUV com os resultados vindos do
modelo de referência se caracteriza como um aspecto altamente positivo da verificação funcional,
visto que o resultado não é passível a má interpretação, ou seja, erro humano. Por outro lado, os
diagramas de formas de onda de saída de simulação abundam em informações e dificultam a
identificação de comportamentos inesperados. Além disso, na verificação funcional, as simulações
rodam sem gerar mensagens de sucesso a cada passo, diminuindo o número de informações
presentes na tela, para que a atenção do projetista esteja toda sobre as mensagens de erro,
facilitando a depuração.
Outra limitação da verificação manual baseada na especificação de vetores de teste via
diagramas de formas de onda é que construir esses diagramas se torna impraticável para um grande
volume de transações, visto que os estímulos são gerados manualmente e a complexidade da análise
é diretamente proporcional ao número de transações a serem analisadas. A verificação funcional,
por sua vez, utiliza algoritmos que automatizam a geração de estímulos para um grande número de
transações.
Contudo, a verificação manual baseada na especificação de vetores de teste via diagramas de
formas de onda permite a visualização de sinais internos do DUV, o que não é possível na
abordagem de verificação funcional do tipo caixa preta. Por isso, alguns autores (BERGERON,
2003; PIZIALI, 2004) afirmam que os diagramas de formas de onda devem ser utilizados
exclusivamente para fins de depuração.
52
Em suma, o uso de técnicas de verificação funcional se configura como uma alternativa
efetiva para garantir que um DUV apresente o comportamento esperado e influi diretamente no
tempo de projeto (devido à reusabilidade do código), no custo (um erro detectado no início é mais
barato de ser corrigido do que um detectado apenas no final do projeto) e na qualidade do projeto
porque garante um circuito livre de erros de projeto e/ou de implementação.
3.6 DISCUSSÃO
Devido às limitações encontradas no desenvolvido deste TCC, já discutidas previamente,
não foi possível implementar todos os blocos construtivos e testbenches do roteador estudado. Até o
a data da entrega deste relatório foram implementados cerca de 70% dos blocos e dos seus
testbenches.
Até a data da entrega deste relatório, quase todos os requisitos funcionais estabelecidos para
este TCC foram cumpridos, excetuando-se o RF01 (Todos os blocos que compõem o roteador
devem ser cobertos pela verificação), devido ao atraso no cronograma ocasionado pela necessidade
de tradução dos modelos de VHDL para Verilog. Dentre os requisitos não-funcionais, o RF02 (O
processo de verificação funcional seguirá o processo adotado na metodologia ipPROCESS) não foi
atendido devido à indisponibilidade de acesso às ferramentas utilizadas no ipPROCESS.
53
4 CONCLUSÕES
Este trabalho apresentou uma revisão bibliográfica sobre projeto de sistemas integrados,
verificação funcional e Redes-em-Chip. Também foi descrita a arquitetura da rede SoCIN e do seu
roteador, sobre os quais foi realizada uma pesquisa sobre como as técnicas de verificação funcional
podem ser aplicadas no projeto de roteadores para Rede-em-Chip, avaliando-se o impacto do uso
dessas técnicas na qualidade e no tempo de execução do projeto.
Dos objetivos específicos definidos para este TCC, foram integralmente cumpridos os
Objetivos 1 e 2, referentes à análise da teoria associada ao projeto, e parcialmente atendido o
Objetivo 3, referente à aplicação das técnicas de verificação funcional no projeto de um roteador.
Isso porque, ainda não foi possível concluir a construção dos testbenches de todos os componentes
do roteador, uma vez que foi necessário traduzir seus modelos de VHDL para Verilog.
Com relação ao Objetivo 4 (avaliar o impacto da verificação funcional na qualidade e no
tempo de projeto), foi possível realizar a avaliação qualitativa a partir dos modelos então
construídos. Sendo que, no texto, a avaliação foi feita com base no modelo de menor complexidade.
Por outro lado, o Objetivo 5 (Validar o modelo de roteador em dispositivo físico) não foi cumprido,
pois ele dependeria da disponibilidade de um modelo operacional completo do roteador. Porém,
entende-se que o não cumprimento desse objetivo não acarreta em prejuízos ao trabalho, pois o foco
do TCC está na avaliação da técnica de verificação funcional em comparação com a técnica
tradicionalmente utilizada baseada na especificação manual de vetores de teste utilizando diagramas
de formas de onda.
Espera-se que a experiência obtida e análise realizada possam ser utilizadas para aprimorar a
metodologia de projeto de Redes-em-Chip utilizada pelos pesquisadores do Laboratório de Sistemas
Embarcados e Distribuídos da Univali.
Este trabalho não tratou de análise da cobertura funcional dos testbenches, então, como
trabalho futuro propõe-se que essa análise seja realizada e, adicionalmente, que seja feito um estudo
sobre técnicas de construção de tesbenches que assegurem uma taxa de cobertura máxima da
verificação funcional. Outra proposta de trabalho futuro reside no cumprimento do Objetivo 5, ou
seja, validar o modelo do roteador em um dispositivo físico.
54
REFERÊNCIAS BIBLIOGRÁFICAS
ANDRIAHANTENAINA, A. et al. SPIN: a scalable, packet switched on-chip micro-network. In: DATE, 2003, Munich. Proceedings... Los Alamitos: IEEE CS Press, 2003. p. 70 73.
BERGERON, J. et al. Verification methodology manual for SystemVerilog. Secaucus. Springer-Verlag New York, Inc, 2005.
BERGERON, J. Writing testbenches: functional verification of HDL models. 2 ed. Norwell: Kluwer Academic Publishers, 2003.
BERGERON, J. Writing testbenches using SystemVerilog.New York: Springer, 2006.
D’AMORE, Roberto. VHDL : descrição e síntese de circuitos digitais , Rio de Janeiro, LTC, 2005.
DUATO, J.; YALAMANCHILI, S; NI, L. Interconnection networks: an engineering approach. Los Alamitos: IEEE Computer Society, 1997. 515 p.
GLASS, C. J.; NI, L. The Turn Model for Adaptive Routing. In: 19th INTERNATIONAL SYMPOSIUM ON CIRCUITS AND SYSTEMS, 1992, Queensland. Proceedings… New York: ACM Press, 1992. p. 278-287.
GUPTA, R. K.; ZORIAN, Y. Introducing core-based system design. IEEE Design & Test of Computers, New York, v. 14, n. 4, p. 15-25, Oct.-Dec. 1997.
HAHANOV, V.; YEGOROV, O.; MOSTOVA, K; KOVALYOV, E.; Verification challenges of NoC architectures. In: CAD SYSTEMS IN MICROELECTRONICS (CADSM), 2007. Proceedings… [S.l.: s.n.], 2007. p.266-269.
JANTSCH, A.; TENHUNEN, H. (Eds.). Networks on Chip. Boston: Kluwer, 2003. 303p.
JERRAYA, A.A.; WOLF, W. Multiprocessor systems-on-chip: the Morgan Kaufmann series in systems on silicon. San Francisco: Elsevier, 2005. 597p.
KAKOEE, Mohammad Reza; NEISHABURI, M.H.; DANESHTALAB, Masoud; SAFARI, Saeed; NAVABI, Zainalabedin. On Chip verification of NoCs using assertion processors. In: EUROMICRO CONFERENCE ON DIGITAL SYSTEM DESIGN ARCHITECTURES, METHODS AND TOOLS (DSD), 10., 2007. Proceedings… [S.l.: s.n.], 2007. p. 535-538.
KEATING, M.; BRICAUD, P. Reuse methodology manual for system -on-a-chip designs. Boston: Kluwer, 2002. 291p.
KEUTZER, K. et al. System-level design: orthogonalization of concerns and platform-based design. IEEE Transactions on Computer-Aided Design of Integrated Circuits, New York, v. 19, n. 12, p. 1523-1543, Dec. 2000.
LIMA, M. S. M. ; SANTOS, F. ipPROCESS: A Development Process for Soft IP-Core with Prototyping in FPGA. In: FDL - Forum on Specification & Design Languages, 2005, Lausanne. Forum on Specification & Design Languages. Lausanne, 2005. p. 487-498.
55
MORAES, F. et al. A low area overhead packet-switched Network-on-Chip: architecture and prototyping. In: IFIP WG 10.5 VLSI-SOC, 2003, Darmstadt. Proceedings… Darmstadt: Technische Universität Darmstadt, 2003. p. 318-323.
PESSOA, I. M. Geração semi-automática de Testbenches para Circuitos Integrados Digitais. 2007. 52 p. Dissertação (Mestrado) – Curso de Pós-Graduação em Ciência da Computação, Universidade Federal de Campina Grande, Campina Grande, 2007.
PIZIALI, A.. Functional Verification Coverage Measurement and Analysis. New York: Springer, 2004. 400p.
RASHINKAR, P.; PATERSON, P.; SINGH, L. System-on-a-chip verification: methodology and techniques. Boston: Kluwer, 2002. 372p.
SPEM - Software Process Engineering Metamodel. version 1.0. Disponível em: http://www.uml.org.
TEDESCO, Leonel Pablo. Uma proposta para geração de tráfego e avaliação de desempenho para NoCs. 2005. 126p. Dissertação (Mestrado)– Programa de Pós-Graduação em Ciência da Computação, PUC-RS, Porto Alegre, 2005.
VAHID, Frank; GIVARGIS, Tony. Embedded system design: a unified hardware/software introduction. New York: Wiley, 2002. 324p.
VAHID, Frank; GIVARGIS, Tony. Platform tuning for embedded systems design. IEEE Computer, v. 34, n. 3, p. 112-114, mar 2001.
WILE, B.; GOSS, J. C.; ROESNER, W. Comprehensive functional verification: the complete industry cycle. San Francisco: Elsevier, 2005. 702p.
ZEFERINO, C. A.; BAMPI, S.; SUSIN, A. A. A study on interconnection networks for high performance parallel computers. In: MICROELECTRONICS SEMINAR, SIM, 14, 1999, Pelotas. Proceedings... Porto Alegre: Instituto de Informática da UFRGS, 1999. p. 33-40.
ZEFERINO, C. A. Redes-em-Chip: Arquiteturas e Modelos para Avaliação de Área e Desempenho. 2003. 242 p. Tese (Doutorado) – Programa de Pós-Graduação em Ciência da Computação, Universidade Federal do Rio Grande do Sul, Porto Alegre, 2003.
ZEFERINO, Cesar Albenes; BRUCH, Jaison Valmor ; PEREIRA, Thiago Felski ; KREUTZ, M. E.; SUSIN, A. A . Avaliação de Desempenho de Rede-em-Chip Modelada em SystemC. 2007.
ZEFERINO, Cesar Albenes; SANTO, F. G. M. E.; SUSIN, A. A. . ParIS: A Parameterizable Interconnect Switch for Networks-on-Chip. In: 17th (INT.) SYMPOSIUM ON INTEGRATED CIRCUITS AND SYSTEMS, 2004, Porto de Galinhas. Proceedings... New York : ACM Press, 2004. p. 204-209.
