Gera¸c˜
ao de Especifica¸c˜
oes
Execut´
aveis para o Projeto de
M´
odulos para Sistemas em “Chips”
Rafael Nunes Linhares Papa
Belo Horizonte
Rafael Nunes Linhares Papa
Gera¸c˜
ao de Especifica¸c˜
oes
Execut´
aveis para o Projeto de
M´
odulos para Sistemas em “Chips”
Disserta¸c˜ao apresentada ao Curso de Mestrado do Programa de P´os-Gradua¸c˜ao em Engenharia El´etrica da Universidade Federal de Minas Gerais, como requisito parcial `a obten¸c˜ao do t´ıtulo de Mestre em Engenharia da Computa¸c˜ao.
´
Area de Concentra¸c˜ao: Engenharia de
Computa¸c˜ao e Telecomunica¸c˜oes
Linha de Pesquisa: Sistemas de Computa¸c˜ao Orientador: Prof. Dr. Di´ogenes C. da Silva Jr. Universidade Federal de Minas Gerais
Belo Horizonte
Dedicat´
oria
`
Agradecimentos
Primeiramente a toda minha fam´ılia e em todos aqueles que acreditaram em mim, em especial ao meu irm˜ao Daniel Nunes e `a minha av´o Jutay.
Aos professores e funcion´arios do PPGEE (CPDEE/UFMG), bem como aos colegas do LABSCI (Laboratorio de Sistemas Computacionais Integrados) Ramon , Alair, Adriano e Sandro.
Ao colega Breno Rocha de Almeida pelos coment´arios, cr´ıticas e sugest˜oes que ajudaram enriquecer este trabalho.
Ao CNPq e ao Projeto BRAZILIP pelo suporte financeiro.
“O mar n˜ao ´e um obst´aculo:
´
e um caminho”
Resumo
A crescente demanda por componentes eletrˆonicos esta fazendo com que o mercado destinado a circuitos integrados cres¸ca a uma velocidade alarmante. Chegou-se a tal ponto que, em no m´aximo dois ou quatro anos, ser´a poss´ıvel encontrar circuitos compostos por at´e um bilh˜ao de transistores. Essa capacidade de integra¸c˜ao ´e a respons´avel pelo surgimento de um novo conceito, o de Sistema “on chip” (SoC), no qual um sistema computacional completo ´e abrigado dentro de um ´unico circuito integrado.
A alta complexidade no processo de integra¸c˜ao e interconex˜ao dos m´odulos que comp˜oem um SoC, chamados de propriedade intelectual (IP - Intellectual Property), faz com que os fabricantes desses componentes invistam cada vez mais nos setores destinados `a produ¸c˜ao e ao desenvolvimento de novas tecnologias de projeto. O tempo desperdi¸cado durante o processo de desenvolvimento do projeto de SoC tamb´em ´e um dos fatores que contribuem para que novas metodologias de desenvolvimento de projeto sejam continuamente propostas.
Este trabalho apresenta a proposta de uma nova metodologia de desenvolvimento de
SoC’s que possibilitar´a uma diminui¸c˜ao no tempo de desenvolvimento e teste do projeto por meio da gera¸c˜ao de uma especifica¸c˜ao execut´avel que ser´a utilizada como modelo de referˆencia. A metodologia utiliza-se de diagramas da linguagem UML para a modelagem e descri¸c˜ao do sistema. Para descri¸c˜ao dos m´odulos em seus diversos n´ıveis de abstra¸c˜ao, a metodologia faz uso do ambiente de desenvolvimento da linguagem de descri¸c˜ao de hardware SystemC.
Palavras-chave: Projeto de Sistemas Embutidos; Descri¸c˜ao UML; Modelo de Referˆencia;
Abstract
The increasing demand for electronic components is driving the integrated circuit market to an unexpected growth. In the about two to four years it will be possible to find circuits composed of a billion transistors. This capacity of integration is the responsible for the emergence of a new concept, System-on-a-chip (SoC), in which a complete computational system is embedded into an single integrated circuit.
The high complexity of the process of integration and the interconnection of the modules, named Intellectual Property (IP), that composes a SoC, are demanding that the designers of these modules to invest more and more time in the search of new design methodologies. The time spent in the development process of SoC design is also one of the main factors that contribute to the need of new design methodologies.
This work presents the proposal of a new SoC design methodology that will make possible a considerable reduction in the time of development and test of the SoC design process through the generation of an executable specification that will be used as a reference model. The methodology utilizes UML diagrams for the system description. For the description of the modules in their levels of abstraction, the methodology makes use of the hardware description language SystemC environment.
keywords: Embedded System Design; UML Description; Reference Models; System-on-a-chip
Sum´
ario
1 Introdu¸c˜ao 1
1.1 Motiva¸c˜ao . . . 5
1.2 Objetivo . . . 6
1.3 Organiza¸c˜ao do Documento . . . 6
2 Revis˜ao da Literatura 8 3 Metodologia 18 3.1 Ferramentas Associadas . . . 19
3.1.1 A Linguagem UML . . . 19
3.1.2 Umbrello UML Modeller . . . 20
3.1.3 SystemC . . . 21
3.2 N´ıveis de Abstra¸c˜ao . . . 23
3.2.1 Especifica¸c˜ao . . . 24
3.2.2 Descri¸c˜ao UML . . . 24
3.2.3 Especifica¸c˜ao Execut´avel . . . 25
3.2.4 Fluxo de Dados (Data Flow - DF) . . . 25
3.2.5 Descri¸c˜ao Comportamental . . . 26
3.2.6 RTL . . . 26
3.3 Fluxo de Projeto . . . 27
3.3.1 An´alise de Requisitos . . . 28
3.3.2 Modelagem UML . . . 31
3.3.3 Descri¸c˜ao UML (Umbrello) para SystemC. . . 35
3.3.4 Implementa¸c˜ao da funcionalidade do processo . . . 37
4 Estudo de Caso 40
4.1 An´alise de Requisitos . . . 41
4.1.1 Vis˜ao Global . . . 41
4.1.2 Especifica¸c˜ao . . . 47
4.2 Modelagem UML . . . 49
4.2.1 Diagrama de Casos de Uso . . . 49
4.2.2 Diagrama de Seq¨uˆencia . . . 52
4.2.3 Diagrama de Classes . . . 53
4.3 Gera¸c˜ao do C´odigo. . . 54
4.4 Modelo Execut´avel. . . 63
4.5 Teste e Valida¸c˜ao. . . 66
4.6 Resultados . . . 69
5 Conclus˜ao 76 A Anexos 83 A.1 C´odigo Esqueleto . . . 83
A.2 C´odigo Funcional . . . 85
Lista de Figuras
1.1 Aumento da capacidade de integra¸c˜ao de transistores representado pela
evolu¸c˜ao dos processadores Intel [27]. . . 2
2.1 N´ıveis de Abstra¸c˜ao Propostos por Arnout [2] . . . 8
2.2 N´ıveis de Abstra¸c˜ao Propostos pela Synopsys [26] . . . 9
2.3 Fluxo de Projeto SLOOP - Proposto por Zhu [28] . . . 11
2.4 Fluxo de Projeto em Y - Proposto por Dumoulin [5] . . . 12
2.5 Fluxo de Projeto utilizando MDA - Proposto por Riccobene [22] . . . 14
2.6 Fluxo de Projeto utilizando MDA - Proposto por Nguyen [18] . . . 16
3.1 Compara¸c˜ao do tempo de simula¸c˜ao entre SystemC e VHDL [17] . . . 22
3.2 Compara¸c˜ao entre a ´area efetiva gasta na s´ıntese de c´odigo VHDL e SystemC [17] 23 3.3 N´ıveis de Abstra¸c˜ao alvo da Metodologia . . . 24
3.4 Fluxo de Projeto proposto pela Metodologia . . . 27
3.5 Exemplo da organiza¸c˜ao das informa¸c˜oes identificadas . . . 30
3.6 Exemplo de Caso de Uso Detalhado . . . 31
3.7 Equivalˆencia entre as representa¸c˜oes das classes do Umbrello - M´odulo (SystemC) x Classe (UML) . . . 32
3.8 Caso de Uso Detalhado . . . 32
3.9 Diagrama de Caso de Uso - Representa¸c˜ao Gr´afica . . . 33
3.10 Interface - Exemplo de Modelagem . . . 33
3.11 Exemplo de um Diagrama de Seq¨uˆencia . . . 34
3.12 Exemplo de um Diagrama de Classes . . . 35
3.13 Tipos Padr˜ao do SystemC no Umbrello . . . 36
3.14 Menu de Sele¸c˜ao de linguagem ativa . . . 36
3.15 Menu de Sele¸c˜ao de Classes do “Code Generation Wizard” . . . 37
4.2 Requisito Funcional 001 . . . 45
4.3 Requisito Funcional 002 . . . 46
4.4 Requisito Funcional 003 . . . 46
4.5 Requisito Funcional 004 . . . 47
4.6 Detalhamento dos Casos de Uso . . . 48
4.7 Caso de Uso - Obter Caracteres . . . 50
4.8 Caso de Uso - Converter C´odigo ASCII em Matriz de Pontos . . . 50
4.9 Caso de Uso - Gerar Seq¨uˆencia de Pixels . . . 51
4.10 Caso de Uso - Gerar Sinais de Controle . . . 51
4.11 Gerador de Caracteres - Diagrama de Caso de Uso . . . 52
4.12 Gerador de Caracteres - Diagrama de Seq¨uˆencia . . . 53
4.13 Gerador de Caracteres - Diagrama de Classes . . . 54
4.14 Exemplo de msg no Diagrama de Seq¨uˆencia - A Orienta¸c˜ao da seta pode indicar o tipo de interface entre m´odulos . . . 55
4.15 Umbrello - Adicionando interfaces aos m´odulos . . . 57
4.16 Representa¸c˜ao do caractere ASCII “u” na ROM . . . 58
4.17 Diagrama de Classes - Defini¸c˜ao das interfaces . . . 60
4.18 Umbrello - Acesso ao gerador de c´odigo (“Code Generation Wizard”) . . . 61
4.19 Umbrello - Sele¸c˜ao de M´odulos para a Gera¸c˜ao de c´odigo SystemC . . . 61
4.20 Umbrello - Indica¸c˜ao do local de grava¸c˜ao dos arquivos fonte e leitura do cabe¸calho . . . 62
4.21 Umbrello - Aguardando a confirma¸c˜ao para gerar o c´odigo . . . 62
4.22 Umbrello - C´odigo gerado com sucesso . . . 63
4.23 Teste e valida¸c˜ao do Modelo de Referˆencia . . . 67
4.24 Resultados - Diagrama de Caso de Uso . . . 71
4.25 Resultados - Diagrama de Seq¨uˆencia . . . 72
4.26 Resultados - Diagrama de Classes . . . 73
4.27 Resultado - Quadro gerado pelo simulador de v´ıdeo . . . 74
Lista de C´
odigos Fonte
3.1 C´odigo Esqueleto - Indica¸c˜ao de onde deve ser implementada a funcionalidade
do Processo . . . 37
4.1 Gerador de Caracteres - C´odigo Esqueleto gerado pela ferramenta . . . 63
4.2 Gerador de Caracteres - Implementa¸c˜ao da funcionalidade do processo . . . 64
4.3 Como construir um Programa principal “main.cpp” em SystemC . . . . 68
A.1 C´odigo Esqueleto - Gerador de Caracteres . . . 83
A.2 C´odigo Esqueleto - Mem´oria . . . 84
A.3 C´odigo Esqueleto - ROM de Caracteres . . . 84
A.4 C´odigo Funcional - Gerador de Caracteres . . . 85
A.5 C´odigo Funcional - Mem´oria . . . 87
A.6 C´odigo Funcional - ROM de Caracteres . . . 89
A.7 C´odigo Funcional - Makefile . . . 91
A.8 C´odigo Funcional - M´odulo Controlador (envia os endere¸cos a mem´oria) . 92 A.9 C´odigo Funcional - Gerador de Sinais de Video . . . 93
A.10 C´odigo Funcional - Buffer de armazenamento e atualiza¸c˜ao de quadros . . 96
A.11 C´odigo Funcional - Simulador de Video . . . 100
Lista de Abreviaturas
SoC System on a Chip
RAM Random Access Memory
ROM Read Only Memory
CI Circuito Integrado
SIA Semiconductor Industry Association
DFT Design for Testability
NoC Network on a Chip
OCP-IP Open Core Protocol International Partnership
IP Intelectual Property (core)
RTL Register Transfer Level
CAD Computer Aided Design
UML Unified Modeling Language
HDL Hardware Description Language
OSCI Open SystemC Initiative
FPGA Field Programmable Gate Array
ISP Intensive Signal Processing
ISS Instruction Set Simulator
FIFO First In First Out
TLM Transaction Level Modeling
UDF Untimed Data Flow
TDF Timed Data Flow
OMG Object Management Group
CRT Cathode Ray Tube
ASCII American Standard Code for Information Interchange
VCD Value Change Dump
Cap´ıtulo 1
Introdu¸c˜
ao
O constante avan¸co tecnol´ogico observado por Gordon E. Moore na d´ecada de 1960 [24]
e o aumento da demanda do mercado por dispositivos eletrˆonicos, tˆem contribu´ıdo cada
vez mais para que as atividades rotineiras realizadas pelo homem sejam automatizadas.
Os sistemas computacionais, formados por meio da uni˜ao entre hardware e software,
constituem uma forma moderna de prover essa automatiza¸c˜ao e s˜ao chamados de SoCs
- System on a Chip. Os SoCs s˜ao sistemas computacionais completos que, apesar de
possu´ırem uma estrutura interna similar ao de um computador, formados por microprocessadores,
mem´orias RAM (Random Access Memory) e ROM (Read Only Memory), barramentos
e dotados de software, s˜ao caracterizados pela sua capacidade de n˜ao serem percebidos
como tal pelo o usu´ario final [7]. A t´ıtulo de exemplo, podemos citar como uma de suas
aplica¸c˜oes, a verifica¸c˜ao em tempo real da press˜ao dos pneus de um ve´ıculo, um processo
totalmente automatizado que j´a ´e realizado pela maioria dos sistemas de controle dos
ve´ıculos considerados de luxo. Atualmente, conforme foi previsto por Moore, estes sistemas
s˜ao compostos por milh˜oes de transistores embutidos em um ´unico circuito integrado (CI).
A FIG. 1.1 abaixo representa, atrav´es da evolu¸c˜ao dos processadores do fabricante Intel, o
Figura 1.1: Aumento da capacidade de integra¸c˜ao de transistores representado pela evolu¸c˜ao dos processadores Intel [27].
Nos ´ultimos vinte anos, o avan¸co da tecnologia de fabrica¸c˜ao de CIs continua sendo
impulsionada pela lei de Moore que mant´em a afirmac˜ao de que o n´umero de transistores
por ´area de chip dobra a cada 18 meses [25]. Estima-se que em menos de 4 anos estar˜ao
dispon´ıveis no mercado, circuitos integrados compostos por mais de um bilh˜ao de transistores [19] [10],
que se comparado ao estado atual, tornar´a ainda mais complexa a tarefa de integra¸c˜ao e
interconex˜ao dos m´odulos que comp˜oem um sistema dessa grandeza, incluindo os SoCs.
Al´em disso, o tempo entre o desenvolvimento de um produto e seu lan¸camento no mercado
(Time-to-Market), tende a ser cada vez menor [21].
Todos os fatores citados contribuem para a diminui¸c˜ao do tempo dispon´ıvel para a
equipe na concep¸c˜ao e valida¸c˜ao de um projeto de SoC. As etapas compreendidas entre
a concep¸c˜ao e os testes de SoCs s˜ao as que demandam a maior parte do tempo estimado
durante o planejamento [20]. Qualquer tipo de erro pode gerar custos e atrasar o cronograma.
Isso faz com que cada vez mais, este se torne um problema de responsabilidade das equipes
integrantes do projeto.
A Semiconductor Industry Association (SIA)prevˆe que em torno de 2015, o custo para
se testar um CI com essa complexidade ir´a exceder o custo necess´ario para desenvolvˆe-lo,
Esse fator justifica a necessidade em estar constantemente desenvolvendo novas metodologias
que auxiliem durante as fases de especifica¸c˜ao e teste de projetos deSoCs [3]. Novos fluxos
de desenvolvimento de projeto tamb´em est˜ao sendo pesquisados e aplicados. A maior
parte deles visando combater o desperd´ıcio de tempo e baseando-se no conceito de projeto
voltado para testes, ou Design for Testability (DFT).
A pr´opria utiliza¸c˜ao efetiva de SoCs tem se mostrado ´util na tentativa de minimizar
alguns desses problemas. Por´em, o tempo empregado no desenvolvimento e concep¸c˜ao
do seu projeto continua sendo um de seus fatores cr´ıticos. As suas principais vantagens
sobre as demais tecnologias s˜ao: diminui¸c˜ao da ´area efetiva total gasta pelo hardware e a
diminui¸c˜ao no tempo de comunica¸c˜ao entre diferentes m´odulos. V´arias t´ecnicas est˜ao sendo
empregadas com o prop´osito de maximiz´a-las. Dentre as mais comuns podemos listar:
1. padroniza¸c˜ao e melhoramento dos meios de interconex˜ao entre m´odulos do projeto;
2. reuso de m´odulos ou reutiliza¸c˜ao;
3. aumento nos n´ıveis de abstra¸c˜ao do projeto;
A padroniza¸c˜ao das interconex˜oes busca melhorar a eficiˆencia na troca de dados e informa¸c˜oes entre os m´odulos. A medida que o n´umero de m´odulos contidos em umSoC
aumenta, crescem tamb´em os problemas para interconect´a-los. A utiliza¸c˜ao de barramentos
simples j´a n˜ao ´e t˜ao eficiente. Al´em de ser um meio compartilhado, existem s´erias restri¸c˜oes
relacionadas a sua forma de comunica¸c˜ao, que se resume a uma mensagem a cada instante.
Barramentos hier´arquicos e aplica¸c˜ao do conceito de redes de computadores vem sendo
utilizados como tentativa de solu¸c˜ao. UmaNetwork on a Chip (NoC), como s˜ao chamadas
essas redes de comunica¸c˜ao, tende a ser mais eficiente [15] por evitarem situa¸c˜oes bloqueantes
na comunica¸c˜ao entre dois m´odulos. Ela os trata como se fossem objetos reais de uma rede,
gerenciando a comunica¸c˜ao entre eles por meio de camadas de protocolos.
gasto no projeto. Por´em na maioria dos casos, esses m´odulos ainda n˜ao disp˜oem de uma
interface padronizada. Como foi visto anteriormente, o avan¸co na produ¸c˜ao e o aumento
na capacidade dos CIs est´a permitindo que um maior n´umero de m´odulos ou n´ucleos IP
sejam agregados em um ´unicoSoC. A grande quantidade e a falta de interfaces de conex˜ao
padronizadas, tornam a reutiliza¸c˜ao em novos projetos uma tarefa bastante complexa.
O aumento nos n´ıveis de abstra¸c˜ao tamb´em ´e um dos meios utilizados para tentar diminuir o tempo gasto na concep¸c˜ao de projetos. Al´em disso, ´e visto como uma
das formas de aumentar a sua eficiˆencia. A complexidade de se desenvolver ou alterar
qualquer m´odulo no n´ıvel de transferˆencia de registradores (Register Transfer Level - RTL)
´e alta. Quando se eleva os n´ıveis a um patamar onde o projetista n˜ao precisa mais se
preocupar com determinados tipos de detalhes de implementa¸c˜ao, a tarefa de descrever as
funcionalidades de um m´odulo, bem como suas conex˜oes e interfaces, torna-se muito mais
f´acil. Atualmente n˜ao existe uma defini¸c˜ao ou padroniza¸c˜ao para determinar os n´ıveis que
devem estar compreendidos entre a descri¸c˜ao no n´ıvel de sistema e o RTL.
A escolha correta das ferramentas de CAD (Computer Aided Design) tamb´em se tornou
um fator importante durante o processo de desenvolvimento deSoCs. Veremos no decorrer
dos cap´ıtulos que este trabalho utiliza-se dos recursos de apenas duas ferramentas. O
Umbrello UML Modeller, que d´a suporte a linguagem de modelagem UML, e SystemC,
uma linguagem de descri¸c˜ao de hardware.
AUnified Modeling Language(UML)´e uma linguagem de modelagem de prop´osito geral que j´a vem sendo amplamente utilizada pela comunidade de engenharia de software
como“framework”para documenta¸c˜ao de software. Ela provˆe suporte a projetos orientados
a objetos, o qual indiretamente, encoraja a reutiliza¸c˜ao de componentes, pois apresenta
diversas vis˜oes do sistema que est´a sendo projetado com uma grande diversidade de
diagramas estruturais e comportamentais. Anteriormente pensava-se que ela havia sido
de software. Hoje, UML est´a se tornando atrativa tamb´em para a descri¸c˜ao de sistemas
embutidos e de tempo real [14].
SystemC ´e uma linguagem de descri¸c˜ao de hardware (Hardware Description Language - HDL) dec´odigo aberto, baseada em C++. Ela vem sendo desenvolvida por um grupo de empresas que formam a Open SystemC Initiative (OSCI), reconhecida recentemente
como novo padr˜ao, IEEE P1666 (“SystemC Language Reference Manual”). Foi criada com
a finalidade de atender as necessidades anteriormente descritas de eleva¸c˜ao dos n´ıveis de
abstra¸c˜ao de um projeto de SoC. Al´em disso SystemC permite que hardware e software
sejam descritos simultaneamente em um ambiente homogˆeneo, proporcionando ao projetista
a capacidade de verifica¸c˜ao de erros funcionais ainda nas etapas iniciais de desenvolvimento
e uma maior compreens˜ao do projeto como um todo.
1.1
Motiva¸c˜
ao
O n´ıvel de integra¸c˜ao e o n´umero de funcionalidades embutidos em um ´unico circuito
integrado est´a tornando muito complexa a tarefa de desenvolvimento deSoCs. Conseq¨uentemente
o tempo gasto e os custos empregados no decorrer do projeto est˜ao aumentando. Sendo
assim, para cada novo projeto deSoC, devemos buscar novos m´etodos para tentar diminuir
o esfor¸co empregado nas suas etapas de concep¸c˜ao e valida¸c˜ao.
Al´em de levar em considera¸c˜ao a possibilidade do reuso de m´odulos em projetos futuros,
deve-se preocupar principalmente em garantir a sua qualidade e a confiabilidade. As
t´ecnicas de modelagem s˜ao utilizadas para garantir estes quesitos e juntamente com a
metodologia proposta pode trazer diversas vantagens:
• Um melhor entendimento do projeto;
• Facilidade de altera¸c˜ao sem custos elevados;
• Diminui¸c˜ao do tempo gasto compreendido entre o per´ıodo de concep¸c˜ao e valida¸c˜ao
da primeira descri¸c˜ao execut´avel;
• Facilidade de documenta¸c˜ao, facilitando o reuso de m´odulos.
1.2
Objetivo
O objetivo deste trabalho ´e elaborar uma metodologia de desenvolvimento de SoCs
que minimize os esfor¸cos gastos pelos projetistas no decorrer das etapas de concep¸c˜ao e
valida¸c˜ao do projeto.
A proposta ´e partir de uma especifica¸c˜ao do SoC em alto n´ıvel, em conjunto com a sua
descri¸c˜ao UML, e chegar a um modelo de referˆencia execut´avel. Inicialmente, pretende-se
gerar c´odigo esqueleto para SystemC com a finalidade de facilitar o trabalho do projetista
durante os diversos refinamentos sucessivos dos m´odulos at´e a sua implementa¸c˜ao.
Em conseq¨uˆencia deste trabalho foi desenvolvida uma ferramenta para tradu¸c˜ao automatizada
de descri¸c˜oesUML(deSoCs) em c´odigo SystemC. Ela ´e um“plug-in”que deve ser instalado
juntamente com a ferramenta Umbrello1
de modelagemUML.
N˜ao ´e objetivo deste trabalho explorar os detalhes de implementa¸c˜ao do projeto na
ferramenta SystemC em seus diversos n´ıveis de abstra¸c˜ao.
1.3
Organiza¸c˜
ao do Documento
O texto deste trabalho esta organizado da seguinte forma:
• No capitulo 2 ´e apresentada uma revis˜ao da literatura contendo as diversas propostas de metodologias e fluxos de projeto para o desenvolvimento de SoCs ao longo dos
1
´
ultimos 4 anos.
• O capitulo 3 apresenta a metodologia. Nela s˜ao apresentados os n´ıveis de abstra¸c˜ao no qual o projetista deve focalizar para a correta aplica¸c˜ao dos m´etodos e o fluxo de projeto que deve ser seguido. As ferramentas tamb´em s˜ao brevemente apresentadas.
• O capitulo 4 mostra a aplica¸c˜ao da metodologia em um estudo de caso. Nele ´e apresentado o desenvolvimento de um gerador de caracteres para um display de video.
• No capitulo 5 ´e feita uma avalia¸c˜ao dos resultados obtidos.
Cap´ıtulo 2
Revis˜
ao da Literatura
Uma das primeiras propostas a apresentar alguma mudan¸ca no processo de desenvolvimento
de SoCs, utilizando SystemC como linguagem de descri¸c˜ao de hardware, foi descrita por
Arnout [2] em 2002. Ele propˆos dois novos n´ıveis de abstra¸c˜ao intermedi´arios entre a
especifica¸c˜ao e o RTL. O n´ıvel n˜ao temporizado buscava a descri¸c˜ao funcional do projeto sem a precis˜ao temporal e n˜ao havia separa¸c˜ao entre hardware e software, enquanto
que o transacional descrevia a funcionalidade de cada m´odulo de forma abstrata e a comunica¸c˜ao entre eles era baseada em ciclos de transa¸c˜oes. Arnout tinha como objetivo
a diminui¸c˜ao do tempo total gasto no desenvolvimento do projeto.
Nesse mesmo ano, uma outra proposta de eleva¸c˜ao nos n´ıveis de abstra¸c˜ao foi apresentada
pela Synopsys [26]. Foram propostos dois novos n´ıveis de abstra¸c˜ao al´em daqueles apresentados
por Arnout. Essa nova abordagem proporcionava ao projetista uma vis˜ao de quatro n´ıveis
de abstra¸c˜ao superiores ao RTL: on˜ao temporizado, otemporizado, ode transa¸c˜ao
e o comportamental.
Figura 2.2: N´ıveis de Abstra¸c˜ao Propostos pela Synopsys [26]
O n´ıvel de abstra¸c˜ao n˜ao temporizado proposto ´e utilizado para a captura, verifica¸c˜ao e
otimiza¸c˜ao dos algoritmos que representam a funcionalidade do sistema. O n´ıvel temporizado
descreve esses mesmos algoritmos, mas com uma pequena diferen¸ca. Eles passam a ser
dotados de atraso, computacionais ou de comunica¸c˜ao, e s˜ao utilizados para analisar quais
ser˜ao as conseq¨uˆencias causadas pelo impacto da temporiza¸c˜ao no comportamento e na
arquitetura do sistema. O n´ıvel de transa¸c˜ao descreve o comportamento do m´odulo em
termos de transa¸c˜oes e o tempo pode ser representado com precis˜ao de ciclos de rel´ogio
ou n˜ao. Ainda n˜ao existe o detalhamento no n´ıvel de porta como no RTL. O n´ıvel
comportamental descreve o modelo funcional, mas agora composto pela suas interfaces
parece com a implementa¸c˜ao estrutural final do RTL, mas j´a pode se tornar sintetiz´avel.
Para transformar um modelo no n´ıvel comportamental em blocos totalmente sintetiz´aveis,
´e necess´ario alterar o c´odigo para que o mesmo esteja de acordo com o atual conjunto de
regras de codifica¸c˜ao necess´arias para a s´ıntese na ferramenta que ser´a utilizada. Segundo
a Synopsys [26], os ganhos na produtividade do projeto de SoC por meio da s´ıntese do
c´odigo no n´ıvel comportamental s˜ao maiores do que no n´ıvel RTL.
O grande n´umero de propostas de eleva¸c˜ao nos n´ıveis de abstra¸c˜ao fez com que os
projetistas encontrassem novas formas de tentar reduzir ainda mais a complexidade e o
tempo gasto no desenvolvimento de projetos de SoC. A maioria das pesquisas voltaram
suas aten¸c˜oes para propostas de novos fluxos de projeto e novas metodologias.
Zhu et al. [28] propuseram uma metodologia de projeto de SoC baseada no conceito
de orienta¸c˜ao a objetos. SLOOP (System Level Design with Object-Oriented Process),
como foi chamada, emprega t´ecnicas de modelagem, avalia¸c˜ao de desempenho de sistemas
Figura 2.3: Fluxo de Projeto SLOOP - Proposto por Zhu [28]
A metodologia prop˜oe quatro modelos para o desenvolvimento de SoC que s˜ao utilizados
nas etapas anteriores `a implementa¸c˜ao do software e do hardware, s˜ao eles: o conceitual, ofuncional, o de arquitetura e o de desempenho. Cada um detalha trˆes aspectos do sistema alvo: funcionalidade, estrutura e temporiza¸c˜ao. O modelo conceitual descreve o
resultado da an´alise dos requisitos que foi feita com cliente por meio de uma descri¸c˜aoUML.
O funcional utiliza redes de processos Kahn1
para criar um modelo capaz de descrever a
estrutura da funcionalidade sem se preocupar com a arquitetura f´ısica ou temporiza¸c˜ao.
O modelo de arquitetura representa os recursos f´ısicos da arquitetura, como barramentos,
1
mem´orias e processadores. O modelo de desempenho organiza os processos descritos no
modelo funcional em forma de recursos de processamento dentro do modelo de arquitetura,
ou seja, gera um modelo execut´avel que servir´a de base para a avalia¸c˜ao do sistema.
Segundo os autores o modelo execut´avel gerado auxilia os projetistas a encontrar poss´ıveis
gargalos e problemas da arquitetura que foi escolhida, al´em de melhorar o sistema para
que ele satisfa¸ca os requisitos de desempenho especificados no projeto.
Dumoulin [5] propˆos uma nova abordagem para o desenvolvimento de projeto de SoC
utilizando os recursos da arquitetura dirigida a modelo (MDA2
) [16] e do“Y-chart” proposto
por Gajski [8]. O trabalho apresenta uma proposta de modelo de desenvolvimento de
projeto em forma de “Y” conforme FIG. 2.4.
Figura 2.4: Fluxo de Projeto em Y - Proposto por Dumoulin [5]
A partir de dois metamodelos independente de plataforma3
(PIM4
) previamente descritos,
2
MDA foi inicialmente proposta pela OMG [1] com a finalidade de auxiliar no desenvolvimento de softwares. Ela ´e composta basicamente por modelos que descrevem o sistema a ser desenvolvido. Cada um representa um n´ıvel de abstra¸c˜ao diferente. Essa arquitetura promove a separa¸c˜ao entre a l´ogica fun-damental do sistema, que ´e descrita na especifica¸c˜ao, e suas opera¸c˜oes, que ser˜ao implementadas em uma determinada tecnologia. Sua principal meta ´e aumentar a reutiliza¸c˜ao e reduzir o tempo no desenvolvi-mentos de novos componentes de software.
3
Plataforma ´e um conjunto de subsistemas e tecnologias que prevˆeem um conjunto coerente de fun-cionalidades atrav´es de interfaces.
4
o de aplica¸c˜ao e o da arquitetura de hardware, ´e proposto o desenvolvimento de um terceiro
que far´a a uni˜ao entre eles. O modelo no n´ıvel de aplica¸c˜ao descreve uma maneira de
representar as dependˆencias de dados do sistema (funcionalidade), enquanto que o modelo
no n´ıvel de arquitetura de hardware apresenta uma descri¸c˜ao voltada para sua estrutura.
O metamodelo de associa¸c˜ao, como foi chamado, far´a a importa¸c˜ao de ambos os modelos
previamente descritos. O modelo resultante ser´a um metamodelo de plataforma especifica
(PSM5
) capaz de se transformar automaticamente em um modelo de qualquer plataforma
de desenvolvimento deSoC. Como estudo de caso os autores utilizaram um “profile UML6
”
j´a pronto de um ISP (“intensive signal processing”) [6]. A ferramenta para a tradu¸c˜ao
autom´atica de modelos encontra-se em fase de desenvolvimento e o resultado do trabalho
se resume na proposta de utiliza¸c˜ao da MDA como forma de modelagem.
Outra abordagem para o desenvolvilmento de SoCs utilizando os conceitos daMDAfoi
apresentada em 2004 por Riccobene [22]. O trabalho prop˜oe um novo fluxo de projeto e
apresenta o “UML profile” para SystemC que foi desenvolvido.
5
PSM ´e uma vis˜ao do sistema a partir do ponto de vista de uma plataforma especifica. Combina a descri¸c˜ao do PIM com os detalhes de implementa¸c˜ao de uma plataforma em particular.
6
Figura 2.5: Fluxo de Projeto utilizando MDA - Proposto por Riccobene [22]
O fluxo de projeto utiliza uma especifica¸c˜ao descrita em linguagem natural para gerar
um representa¸c˜ao algor´ıtmica do sistema, que pode ser implementada em uma linguagem
de programa¸c˜ao de software (como C/C++) ou em uma ferramenta de modelagem (como
simulink[www.mathworks.com/products/simulink/] por exemplo). O segundo est´agio consiste
na separa¸c˜ao entre os requisitos de hardware e software, que s˜ao desenvolvidos paralelamente
ao longo do projeto. O software ´e compilado para a plataforma que foi definida e gera como
resultado um c´odigo objeto, enquanto o hardware ´e apenas descrito emRTL. A partir desses
resultados ´e feita uma co-simula¸c˜ao entre o hardware (em RTL) e as partes do software
que est˜ao rodando no simulador (Instruction Set Simulator - ISS) para a verifica¸c˜ao dos
poss´ıveis erros causados pelo c´odigo RTLna tradu¸c˜ao para o n´ıvel de portas l´ogicas.
O “UML profile” paraSystemC foi baseado na especifica¸c˜ao da vers˜ao 2.0 da linguagem
define os estere´otipos do n´ucleo SystemC, ou camada 0 (zero), que podem ser utilizados
nos diagramas estruturais UML, respons´aveis pelos elementos de estrutura e comunica¸c˜ao
(m´odulos, interfaces, portas e canais). A segunda parte ´e respons´avel pela defini¸c˜ao dos
tipos de dados, representados atrav´es dos diagramas de classes, enquanto que a terceira
parte descreve o comportamento e a sincroniza¸c˜ao entre os m´odulos atrav´es dos diagramas
comportamentais. A ´ultima parte prove conceitos para a defini¸c˜ao de canais, interfaces
e portas que s˜ao pr´e-definidos na linguagem. Como exemplo podemos citar os canais do
tipo first in first out(FIFO). Os resultados se resumem nos benef´ıcios de se utilizar UML
Profiles para especificar, analisar, projetar, construir, visualizar e documentar sistemas
tanto em hardware quanto em software para o projeto de SoC.
O trabalho de Nguyen et al. [18] apresenta um mecanismo de descri¸c˜ao no n´ıvel de
sistema, baseado em nota¸c˜oes UML, que ´e capaz de gerar c´odigoSystemC no n´ıvel transacional
(Transaction Level Modeling - TLM). Esta referˆencia utiliza dois dos diversos diagramas
UML para representar o sistema, o diagrama de classes e o diagrama de transi¸c˜ao de
estados. A ferramenta escolhida para a especifica¸c˜ao do sistema atrav´es dos diagramas, foi o
Rhapsody7
, plataforma de colabora¸c˜ao, desenvolvimento de aplica¸c˜ao e projeto de sistemas,
compat´ıvel com UML. Os autores tiveram que incorporar estere´otipos na ferramenta Rhapsody
para que ela conseguisse capturar algumas das primitivas de comunica¸c˜ao da linguagem
SystemC, como interfaces e canais. Tamb´em foi necess´ario a utiliza¸c˜ao de uma outra
ferramenta, chamada Velocity8
, para a tradu¸c˜ao dos modelos gerados em c´odigoSystemC.
A FIG. 2.6 abaixo resume o fluxo de projeto proposto.
7
http://www.ilogix.com
8
Figura 2.6: Fluxo de Projeto utilizando MDA - Proposto por Nguyen [18]
Na modelagem UML, o diagrama de classes ´e respons´avel pela descri¸c˜ao da estrutura
dos componentes, enquanto que o diagrama de transi¸c˜ao de estados ´e utilizado para
representar o comportamento. Esse modelo inicial, deve ser dotado de estere´otipos para
suprir a necessidade de representa¸c˜ao de algumas entidades SystemC. Para a gera¸c˜ao do
documento XMI ´e necess´ario a utiliza¸c˜ao de umtoolkit da ferramenta Rhapsody. A fun¸c˜ao
dele ´e transformar as informa¸c˜oes contidas no modelo gr´afico e no conjunto de estere´otipos
em um documento padr˜ao XMI. Os autores tamb´em desenvolveram um parser XMI que
agrega mais informa¸c˜oes ao documento gerado e o transforma em uma ´arvore abstrata. Ela
servir´a como modelo de entrada para a ferramentaVelocity. S´o assim o c´odigo ser´a gerado.
Os autores afirmam que, ap´os todos esses passos e ferramentas que foram utilizadas, para
detalhado, ser´a necess´ario apenas fazer altera¸c˜oes nos modelos (ou templates) gerados
Cap´ıtulo 3
Metodologia
A presente metodologia tem como principal objetivo diminuir o tempo e os esfor¸cos
gastos pelos projetistas na gera¸c˜ao da primeira especifica¸c˜ao execut´avel. No desenvolvimento
de SoCs, problemas de funcionalidade e de comunica¸c˜ao, dificilmente s˜ao detectados logo
nas primeiras etapas do projeto e os testes, geralmente s˜ao realizados em um ponto onde
as alternativas para prov´aveis corre¸c˜oes s˜ao poucas e de custo elevado. Na maioria dos
casos, as decis˜oes que s˜ao tomadas durante estas etapas, compreendidas entre a concep¸c˜ao
e valida¸c˜ao do projeto, podem gerar um impacto grande na adequa¸c˜ao daquilo que foi
especificado ao que ser´a efetivamente implementado. Um planejamento inicial m´ınimo,
daquilo que se est´a projetando, faz-se necess´ario. ´E por meio dele que o projetista consegue
obter um melhor entendimento do projeto e conseq¨uentemente pode evitar altera¸c˜oes
desnecess´arias, diminuindo custos e evitando desperd´ıcio de tempo.
A metodologia prop˜oe um fluxo de projeto que favorece a vis˜ao geral do o sistema.
Poss´ıveis erros, antes s´o detectados nos n´ıveis de abstra¸c˜ao que j´a possu´ıam um consider´avel
n´ıvel de detalhamento, como o RTL, poder˜ao ser previstos. Para tanto, a metodologia faz
uso de alguns recursos dispon´ıveis nas t´ecnicas de modelagem UML, como documentos e
do desenvolvimento do projeto como tamb´em favorecem a reutiliza¸c˜ao de m´odulos.
Ao final do fluxo de proposto, o projetista ter´a dispon´ıvel uma especifica¸c˜ao funcional
SystemC, execut´avel, para utilizar como modelo de referˆencia ao longo dos sucessivos
refinamentos que ter´a que fazer durante os n´ıveis de abstra¸c˜ao. A metodologia tamb´em
apresenta um“plug-in” SystemC desenvolvido especialmente para a ferramenta Umbrello.
Ele ´e capaz de gerar c´odigo SystemC a partir da modelagem do SoC em diagramas UML.
Para aplicar a metodologia de forma eficiente ´e importante que se compreenda todas as
etapas e seus respectivos objetivos, a importˆancia de cada uma delas e como trabalham em
conjunto para garantir que os resultados esperados sejam alcan¸cados da melhor maneira
poss´ıvel. Um bom conhecimento das ferramentas, UML e SystemC, tamb´em garantem
um melhor resultado. A pr´oxima se¸c˜ao apresenta um breve resumo de cada uma das
ferramentas. A se¸c˜ao 3.2 descreve os n´ıveis de abstra¸c˜ao e a se¸c˜ao 3.3 apresenta o fluxo
de projeto proposto que ´e a pr´opria representa¸c˜ao da metodologia. Para um melhor
entendimento, o capitulo 4 apresenta um estudo de caso com a aplica¸c˜ao da metodologia.
3.1
Ferramentas Associadas
3.1.1
A Linguagem UML
A UML ´e uma linguagem de modelagem de prop´osito geral utilizada para representar
sistemas orientados a objetos que surgiu no final da d´ecada de 1990. UML 1.x ´e uma
combina¸c˜ao de elementos de Booch [4], OOSE [12] e OMT [23]. A vers˜ao 2.0 se encontra
em fase final de aprova¸c˜ao pela OMG (Object Management Group) e inclui melhoramentos
em todas as ´areas. Ela possui treze tipos de diagramas capazes de descrever v´arios aspectos
estruturais, comportamentais e f´ısicos de um sistema. Cada diagrama possui um prop´osito
diferente durante o processo de desenvolvimento, por isso ´e importante ter em mente que
metodologia de projeto.
A especifica¸c˜ao comportamental em UML, em alto n´ıvel, geralmente se inicia a partir
da identifica¸c˜ao dos casos de uso para um sistema e dos atores envolvidos. Estes s˜ao
denominados Diagramas de Casos de Uso. Por´em, para uma descri¸c˜ao comportamental
detalhada, costuma-se usar os Diagramas de Transi¸c˜ao de Estado [11], que s˜ao capazes de
representar m´aquinas de estado finitas. O Diagrama de Classes ´e provavelmente o mais
conhecido dentro da modelagem UML. Ele descreve os aspectos estruturais de um sistema
em termos de classes e como essas classes se relacionam entre si atrav´es de associa¸c˜oes. Uma
classe pode ou n˜ao possuir atributos e/ou opera¸c˜oes. Al´em disso, interfaces e generaliza¸c˜oes
podem ser utilizadas para introduzir hierarquia entre os objetos criados. A ferramenta
atualmente mais utilizada para este tipo de modelagem ´e o Rational Rose da IBM1
, tamb´em
existem outras ferramentas, dentre as quais podemos citar:
• Rhapsody da I-logix (voltado para sistemas de tempo real);
• Together (comprado recentemente pela Borland para incorporar-se no seu ambiente de desenvolvimento);
• Enterprise Architect (de custo mais acess´ıvel);
• Umbrello (livre distribui¸c˜ao e c´odigo aberto);
3.1.2
Umbrello UML Modeller
O Umbrello UML Modeller2
´e uma ferramenta de modelagem de diagramas UML
que foi desenvolvida em 2001 por Paul Hensgen em um de seus projetos universit´arios.
Originalmente foi criada para auxiliar no processo de desenvolvimento de software e seu
nome original era “Modelador UML”. Como era conhecido apenas por “UML”, um nome
muito gen´erico, causou problemas com algumas distribui¸c˜oes de software que possu´ıam o
mesmo nome e teve que ser mudado. A mudan¸ca ocorreu em Setembro de 2002. O projeto
1
http://www.ibm.com
2
foi todo revisado pela Universidade onde Paul estudava e passou a ser de livre distribui¸c˜ao
e de c´odigo aberto. A vers˜ao 1.0 j´a oferecia muitas funcionalidades, mas com as diversas
contribui¸c˜oes passou a ter suporte a um n´umero maior de diagramas UML, o formato de
arquivo passou de bin´ario para XML, o aplicativo agregou funcionalidades como gera¸c˜ao de
c´odigo automatizada e importa¸c˜ao de c´odigo. Paul retirou-se da equipe de desenvolvimento
em meados de 2002, mas o software est´a sendo mantido por um grupo de desenvolvedores
de diferentes partes do mundo e continua em constante desenvolvimento.
3.1.3
SystemC
SystemC ´e uma linguagem de descri¸c˜ao de hardware (HDL), c´odigo aberto, baseada em
C++, que vem sendo desenvolvida por um grupo de empresas que formam aOpen SystemC
Initiative (OSCI - IEEE P1666). Al´em de possuir uma estrutura de programa¸c˜ao simples
e intuitiva, uma das principais caracter´ısticas desta ferramenta ´e que ela possui um n´ucleo
exclusivo para a simula¸c˜ao e provˆe suporte `a concorrˆencia e `a hierarquia de m´odulos. Sua
principal vantagem em rela¸c˜ao `as outras linguagens de descri¸c˜ao de hardware ´e que ela
permite a descri¸c˜ao e teste de m´odulos em v´arios n´ıveis de abstra¸c˜ao [9]. O projetista n˜ao
precisa aprender, nem ao menos precisa utilizar mais de um ambiente de programa¸c˜ao `a
medida que prossegue nas etapas de desenvolvimento de seu modulo.
Testes realizados por Moreno [17] mostraram queSystemC obteve ganhos consider´aveis
na velocidade de simula¸c˜ao se comparada a uma das principais linguagens de descri¸c˜ao
de hardware, VHDL. Utilizou-se para o teste o algoritmo de ordena¸c˜ao “bubble sort”.
O tamanho da mem´oria de valores a serem ordenados, tamanho do vetor, foi alterado
Figura 3.1: Compara¸c˜ao do tempo de simula¸c˜ao entre SystemC e VHDL [17]
Este ganho de velocidade na simula¸c˜ao se deve ao fato de que o simulador padr˜ao
da linguagem SystemC permite a simula¸c˜ao em diferentes n´ıveis de abstra¸c˜ao. SystemC
tamb´em favorece a programa¸c˜ao intuitiva, permitindo a programa¸c˜ao em alto n´ıvel por
meio da linguagem C/C++. VHDL, por outro lado, necessita de uma programa¸c˜ao na
qual o projetista tem de se preocupar com o alto n´ıvel de detalhamento imposto pela
linguagem.
Abaixo podemos observar outros resultados, ainda do mesmo trabalho, de testes obtidos
atrav´es da s´ıntese em FPGA de c´odigo VHDL e SystemC. Eles demonstraram que SystemC
Figura 3.2: Compara¸c˜ao entre a ´area efetiva gasta na s´ıntese de c´odigo VHDL e SystemC [17]
3.2
N´ıveis de Abstra¸c˜
ao
N´ıvel de abstra¸c˜ao ´e a descri¸c˜ao do projeto com uma determinada quantidade de
detalhamento. O aumento (ou eleva¸c˜ao) nos n´ıveis de abstra¸c˜ao tamb´em ´e um dos meios
utilizados para tentar diminuir o tempo gasto na concep¸c˜ao de projetos. Al´em disso, ´e visto
como uma das formas de aumentar a sua eficiˆencia. A complexidade de se desenvolver ou
alterar qualquer m´odulo no n´ıvel de transferˆencia de registradores ´e alta. Quando se eleva
os n´ıveis a um patamar onde o projetista n˜ao precisa mais se preocupar com determinados
tipos de detalhes de implementa¸c˜ao, a tarefa de descrever as funcionalidades de um m´odulo,
bem como suas conex˜oes e interfaces, torna-se muito mais f´acil.
A FIG. 3.3 abaixo apresenta a divis˜ao dos n´ıveis de abstra¸c˜ao de um projeto de SoC e
destaca aqueles onde a metodologia ir´a auxiliar o projetista no desenvolvimento da primeira
Figura 3.3: N´ıveis de Abstra¸c˜ao alvo da Metodologia
3.2.1
Especifica¸c˜
ao
A especifica¸c˜ao ´e o n´ıvel onde est˜ao detalhadas as caracter´ısticas e funcionalidades dos
m´odulos do sistema. N˜ao existe distin¸c˜ao entre hardware e software, e a temporiza¸c˜ao
n˜ao ´e representada. Todos os requisitos do projeto bem como os detalhes relacionados
a custos, riscos e restri¸c˜oes s˜ao cuidadosamente documentados. O diagrama de casos de
uso ´e muito utilizado nesse n´ıvel de detalhamento. O que se descreve ´e uma representa¸c˜ao
quase algor´ıtmica de como os m´odulos do sistema se comportam (casos de uso) e com quais
outros m´odulos (atores) se relacionam.
3.2.2
Descri¸c˜
ao UML
A descri¸c˜ao UML ´e praticamente um detalhamento dos requisitos apresentados no
n´ıvel de especifica¸c˜ao, geralmente com o aux´ılio de uma ferramenta de modelagem com
comportamentais e estruturais que representam a sua funcionalidade e o comportamento.
Neste n´ıvel o que se obt´em ´e um refinamento da especifica¸c˜ao que proporciona uma vis˜ao
geral e uma representa¸c˜ao mais detalhada do comportamento sistema. Por meio dessa
descri¸c˜ao ´e poss´ıvel identificar prov´aveis erros de concep¸c˜ao e conflitos futuros. A divis˜ao
entre hardware e software, e a temporiza¸c˜ao tamb´em n˜ao s˜ao representados.
3.2.3
Especifica¸c˜
ao Execut´
avel
A especifica¸c˜ao execut´avel ´e a implementa¸c˜ao da descri¸c˜ao UML na linguagem de
descri¸c˜ao de hardware SystemC. O resultado obtido neste n´ıvel ´e um modelo funcional
e execut´avel dessa descri¸c˜ao que pode ser simulado. Esse n´ıvel de detalhamento permite
que problemas de execu¸c˜ao e de comportamento sejam identificados e solucionados. Este
´e um n´ıvel de grande relevˆancia, pois ´e utilizado como base para o refinamento dos demais
e pode ser utilizado como referˆencia em qualquer plataforma de desenvolvimento adotada.
3.2.4
Fluxo de Dados (Data Flow - DF)
Neste n´ıvel de abstra¸c˜ao tamb´em se descreve as funcionalidade dos m´odulos do sistema,
por´em, o que o difere dos demais vistos anteriormente ´e que o modelo agora apresenta de
forma clara a troca de mensagens entre m´odulos. Ele est´a dividido em dois est´agios. O
primeiro, caracterizado como “Untimed Data Flow” (UDF) descreve a funcionalidade do
m´odulo sem a no¸c˜ao de temporiza¸c˜ao e o segundo, “Timed Data Flow” (TDF), descreve o
m´odulo em rela¸c˜ao ao tempo, com a inser¸c˜ao de atrasos temporais na sua implementa¸c˜ao.
Abaixo est˜ao descritos em detalhes os dois est´agios:
algoritmo funcional devido a elimina¸c˜ao da preocupa¸c˜ao desnecess´aria com detalhes de temporiza¸c˜ao. O projetista ´e obrigado a sincronizar os m´odulos somente com a¸c˜oes (eventos), favorecendo (ou destacando) quest˜oes diretamente ligadas `a funcionalidade.
• TDF - O modelo de fluxo de dados temporizado tem capacidade para representar a no¸c˜ao de tempo. Agora existe a preocupa¸c˜ao com o sincronismo dos eventos e das opera¸c˜oes realizadas pelo m´odulo no espa¸co de tempo, bem como os respectivos atrasos de processamento e de comunica¸c˜ao. Por meio dela torna-se poss´ıvel analisar como os efeitos de latˆencia poderiam influenciar no comportamento final do m´odulo, se realmente ele esta gerando as respostas de acordo com a especifica¸c˜ao dada e se os resultados esperados est˜ao sendo realmente gerados em tempo h´abil para sua valida¸c˜ao.
3.2.5
Descri¸c˜
ao Comportamental
O n´ıvel Comportamental ´e uma descri¸c˜ao algor´ıtmica do comportamento do sistema.
Ele geralmente ´e descrito na forma de precis˜ao de ciclos e ainda n˜ao apresenta a estrutura
RTL esperada para a implementa¸c˜ao final. A principal diferen¸ca entre esses dois n´ıveis,
Comportamental e RTL, est´a relacionada com a temporiza¸c˜ao. Enquanto o RTL tem
sua sincroniza¸c˜ao definida em termos de ciclos de “clock”, oComportamental ´e geralmente
sincronizado atrav´es da utiliza¸c˜ao de passos computacionais. Como exemplo, a sincroniza¸c˜ao
entre os processos de um sistema no n´ıvel Comportamental pode ser feita utilizando o
comando “wait”, cuja a fun¸c˜ao ´e aguardar at´e que um evento (ou processo) seja conclu´ıdo
antes de se passar ao pr´oximo, ou inserindo atrasos temporais. As descri¸c˜oes no n´ıvel
Comportamental s˜ao compactas e mais f´aceis de entender do que descri¸c˜oes em RTL. As
simula¸c˜oes tamb´em s˜ao mais r´apidas, devido ao n´ıvel de abstra¸c˜ao ser mais alto.
3.2.6
RTL
Segundo Jerraya [13] este n´ıvel de abstra¸c˜ao ´e visto como o ´ultimo na descri¸c˜ao do
projeto de hardware. ´E nele onde a maioria das ferramentas de s´ıntese trabalham. O
clock. Toda a comunica¸c˜ao entre processos ocorre ´unica e exclusivamente atrav´es de sinais. O comportamento, ou funcionalidade, ´e representado pelo fluxo dos dados atrav´es
de blocos funcionais (“datapath”) habilitados por sinais gerados pela unidade de controle, geralmente implementada por m´aquina de estado finitas.
3.3
Fluxo de Projeto
A FIG. 3.4 abaixo resume o fluxo de projeto que representa a metodologia proposta.
3.3.1
An´
alise de Requisitos
Inspirada nos conceitos utilizados no desenvolvimento de software, a an´alise de requisitos
tem como objetivo descrever o que o cliente espera que o sistema fa¸ca. Requisitos s˜ao os
objetivos e as restri¸c˜oes relacionados ao sistema que se pretende desenvolver. O projetista
deve ter em mente que esse conjunto de informa¸c˜oes pode ser definido como uma condi¸c˜ao
ou uma fun¸c˜ao do SoC que ser´a respons´avel pela resolu¸c˜ao de problemas previamente
especificados. A an´alise de requisitos est´a dividida em dois grandes est´agios. O primeiro
apresenta os m´etodos utilizados para se construir uma vis˜ao global do sistema enquanto
que o segundo especifica, detalha e prioriza as informa¸c˜oes obtidas.
Vis˜ao Global
O objetivo desse est´agio ´e a identifica¸c˜ao dos requisitos doSoC que se deseja desenvolver,
fornecendo todas as informa¸c˜oes necess´arias para o entendimento do projeto por parte do
desenvolvedor.
Abaixo est˜ao enumeradas a seq¨uˆencia de atividades que o projetista deve seguir a fim
de obter este documento:
1. Capturar o m´aximo de informa¸c˜oes relevantes ao projeto por meio da entrevista com o cliente;
2. Revisar e verificar se algum ponto deixou de ser identificado;
3. Classificar as informa¸c˜oes em requisitos funcionais e n˜ao-funcionais;
4. Organizar as informa¸c˜oes em um documento relacionando os requisitos funcionais `as suas respectivas restri¸c˜oes;
O respons´avel pela entrevista deve ter em mente, ou em forma de question´ario, uma
lista de perguntas necess´arias para se extrair o maior n´umero de informa¸c˜oes poss´ıveis
do projeto com o cliente. Deve-se preocupar em n˜ao induzir o mesmo a tomar decis˜oes
influenciadas pelo conhecimento pr´evio do entrevistador em rela¸c˜ao a implementa¸c˜ao do
revis˜ao das quest˜oes que foram abordadas e verificar se algum ponto importante para a
documenta¸c˜ao deixou de ser contemplado. A classifica¸c˜ao das informa¸c˜oes obtidas deve
ser feita considerando os aspectos funcionais e n˜ao-funcionais dos requisitos segundo as
descri¸c˜oes abaixo:
• Requisitos Funcionais - descrevem a funcionalidade desejada do SoC. Deve-se determinar o que se espera que oSoC fa¸ca sem a preocupa¸c˜ao de detalhar como isso
deve ser feito:
– “oSoC deve ser capaz de gerar imagens”;
– “oSoC deve ser capaz de comunicar com a interface do LCD”; – “oSoC deve possibilitar a entrada de dados atrav´es de um teclado”; – “oSoC deve possibilitar o c´alculo da soma de dois n´umeros reais”;
• Requisitos N˜ao-Funcionais - descrevem as restri¸c˜oes impostas para a realiza¸c˜ao de um requisito funcional:
– “a imagem deve ser do tipo bmp”;
– “a imagem n˜ao deve ultrapassar a resolu¸c˜ao m´axima de 800x600”;
– “a interface com o LCD deve utilizar o protocolo OCP-IP para comunica¸c˜ao”; – “o tempo de resposta doSoC ao teclado n˜ao deve ultrapassar 10 ms”;
– “o SoC deve permitir a representa¸c˜ao de n´umeros reais com um m´aximo de 4 casas decimais”;
– “o cronograma de desenvolvimento n˜ao deve ultrapassar doze meses”;
A vis˜ao global ´e a etapa daan´alise de requisitos onde se definem exatamente quais s˜ao
as principais funcionalidades do sistema.
Conforme apresentado anteriormente, o documento resultante desse est´agio ´e composto
pelo conjunto de requisitos funcionais e suas respectivas restri¸c˜oes. Cada funcionalidade
Figura 3.5: Exemplo da organiza¸c˜ao das informa¸c˜oes identificadas
Especifica¸c˜ao
Ap´os a etapa de vis˜ao global deve-se analisar os requisitos a fim de refin´a-los e estrutur´a-los
em um modelo que defina precisamente os atores e os casos de uso do sistema.
Por meio deste modelo ´e feita uma an´alise para identificar quais s˜ao os pontos considerados
cr´ıticos no desenvolvimento do projeto. O resultado ´e um documento composto pela an´alise
detalhada dos casos de uso e a descri¸c˜ao dos pontos cr´ıticos do projeto.
Para a gera¸c˜ao do documento desta etapa o projetista dever´a seguir a seq¨uˆencia de
tarefas a seguir:
1. Identificar os atores
O ator ´e qualquer entidade que interaja com o sistema na realiza¸c˜ao de uma tarefa ou fun¸c˜ao. (m´odulos, interfaces, componentes e outros sistemas) Exemplos: LCD, teclado, interface OCP-IP.
2. Identificar os casos de uso
O caso de uso ´e um documento narrativo que descreve uma seq¨uˆencia de eventos (a¸c˜oes) que representa uma funcionalidade, ou seja, descreve uma tarefa a qual o sistema dar´a suporte. A maioria dos requisitos funcionais listados na vis˜ao global s˜ao candidatos a se tornarem casos de uso. Exemplos: Gerar Imagem bmp e Calcular Soma de N´umeros Reais
O projetista deve fazer uma an´alise e definir quais atores se relacionam com cada caso. A partir dessa an´alise ´e poss´ıvel detalhar a seq¨uˆencia de eventos realizada pelo caso em rela¸c˜ao a seus respectivos atores (FIG. 3.6). Os requisitos funcionais atendidos pelo caso tamb´em devem ser referenciados. Essa ´e uma forma de verificar se os requisitos solicitados pelo cliente est˜ao sendo atendidos.
Figura 3.6: Exemplo de Caso de Uso Detalhado
4. Identificar os pontos cr´ıticos
Por meio do detalhamento dos casos de uso e da experiˆencia do projetista ´e poss´ıvel selecionar (mensurar) quais s˜ao aqueles com a pior rela¸c˜ao entre custo, tempo gasto e benef´ıcio em seu desenvolvimento. Esses casos ter˜ao prioridade sobre os outros no decorrer do projeto e demandam aten¸c˜ao especial. O projetista deve descrever um documento apontando todas essas caracter´ısticas. O objetivo deste documento ´e auxiliar os projetistas a tomarem decis˜oes nos refinamentos futuros tais como: (1) Utilizar ou n˜ao um m´odulo pronto para determinada funcionalidade? (2) O desenvolvimento deste m´odulo realmente vale o investimento? Todas essas observa¸c˜oes dever˜ao ser feitas a t´ıtulo de compara¸c˜ao.
3.3.2
Modelagem UML
Como SoCs s˜ao projetados para terem utilidade em algo presente no mundo real, ´e
importante que se compreenda a necessidade da modelagem UML descrita nesta etapa. Ela
´e uma ferramenta capaz de representar, atrav´es de diagramas, um cen´ario muito pr´oximo
da realidade, o que favorece um melhor entendimento do sistema. Neste fase o projetista
dever´a utilizar a ferramenta Umbrello para a modelagem. Como o “plug-in” SystemC para Umbrello utiliza a pr´opria nota¸c˜ao UML que est´a descrita na ferramenta, n˜ao ´e necess´ario
a cria¸c˜ao de estere´otipos para a representa¸c˜ao de estruturas da linguagem alvo (SystemC).
Classe UML modelados no Umbrello. O projetista deve ficar atento `a esta compara¸c˜ao.
Figura 3.7: Equivalˆencia entre as representa¸c˜oes das classes do Umbrello - M´odulo (SystemC) x Classe (UML)
Apenas trˆes dos diagramas da linguagem UML ser˜ao usados na modelagem proposta
na metodologia:
1. Casos de uso: Defini¸c˜ao da Funcionalidade e das Interfaces
Partindo dos documentos que foram obtidos na an´alise de requisitos o projetista dever´a modelar primeiro o diagrama de casos de uso. Cada caso de uso descrito textualmente no est´agio especifica¸c˜ao, da fase de an´alise de requisitos(FIGs. 3.8), equivale a um caso de uso do diagrama UML(3.9). Os atores que foram identificados anteriormente tamb´em devem ser representados.
Figura 3.9: Diagrama de Caso de Uso - Representa¸c˜ao Gr´afica
Posteriormente o diagrama deve ser refinado at´e que o projetista identifique com clareza a funcionalidade do sistema. As interfaces de comunica¸c˜ao tamb´em devem ser modeladas como atores, evitando problemas com a falta de padroniza¸c˜ao entre os m´odulos e facilitando a sua visualiza¸c˜ao. A figura FIG. 3.10 abaixo apresenta um exemplo de como as interfaces devem ser modeladas no diagrama.
Figura 3.10: Interface - Exemplo de Modelagem
2. Diagrama de Seq¨uˆencia: Defini¸c˜ao da seq¨uˆencia de eventos
quanto casos podem se transformar em componentes do diagrama. A FIG. 3.11 abaixo apresenta a troca de mensagens entre duas entidades,Rede “on-chip” eGerar Imagem.
Figura 3.11: Exemplo de um Diagrama de Seq¨uˆencia
As mensagens representadas entre os objetos definem uma cronologia de eventos atrav´es da numera¸c˜ao, em ordem crescente, e atrav´es da posi¸c˜ao da mensagem. As mensagens nas posi¸c˜oes inferiores do diagrama ocorrem posteriormente as mensagens superiores.
3. Diagrama de Classes: Defini¸c˜ao da Estrutura
Figura 3.12: Exemplo de um Diagrama de Classes
3.3.3
Descri¸c˜
ao UML (
Umbrello
) para SystemC
O“plug-in” SystemC paraUmbrellosuporta todos os tipos de dados padr˜ao da linguagem.
Esse suporte ´e habilitado assim que a op¸c˜ao de linguagem SystemC ´e ativada no menu
“Code/Active Language”. A FIG. 3.13 apresenta a tela de defini¸c˜ao de “ports” e
Figura 3.13: Tipos Padr˜ao do SystemC no Umbrello
Ap´os a modelagem, o projetista dever´a primeiramente selecionar a linguagem padr˜ao,
no caso SystemC (Ver FIG. 3.14), por meio do menu “Code/Active Language”.
Figura 3.14: Menu de Sele¸c˜ao de linguagem ativa
Para a gera¸c˜ao do c´odigo esqueleto ele dever´a acessar o menu “Code/Code Generation
Wizard” e selecionar as classes (m´odulos) que ele deseja converter (FIG. 3.15). Note que
Figura 3.15: Menu de Sele¸c˜ao de Classes do “Code Generation Wizard”
3.3.4
Implementa¸c˜
ao da funcionalidade do processo
Como a metodologia n˜ao prevˆe a gera¸c˜ao autom´atica da funcionalidade do processo,
o projetista dever´a implementar todos os processos que foram definidos na modelagem.
Para isso ele dever´a acessar o arquivo com a extens˜ao (“.h”) e preencher a lacuna entre as
chaves do processo definido abaixo das interfaces, conforme o trecho de c´odigo apresentado
abaixo C ´OD. 3.1.
C´odigo Fonte 3.1: C´odigo Esqueleto - Indica¸c˜ao de onde deve ser implementada a
funcionalidade do Processo
1 #i f n d e f CONTROLADOR H 2 #define CONTROLADOR H 3 #include <systemc . h>
4
6
7 s c f i f o o u t<T> end ;
8
9 void p r o c e s s ( ){ 10
11 // Implemente a f u n c i o n a l i d a d e do p r o c e s s o a q u i ! 12
13 } 14
15 SC CTOR( C o n t r o l a d o r ) { SC THREAD( p r o c e s s ) ; } 16 };
17 #endif //CONTROLADOR H
3.3.5
M´
odulo funcional execut´
avel
Embora n˜ao apresente qualquer tipo de funcionalidade, o c´odigo apresentado na se¸c˜ao
anterior (C ´OD 3.1) ´e execut´avel. Isso ´e poss´ıvel devido `a ferramenta gerar uma estrutura
de c´odigo “correta” capaz de ser interpretada pelo compilador sem erros.
O projetista dever´a implementar as funcionalidades dos processos definidos, construir
as liga¸c˜oes dos m´odulos no “main” e simular o modelo de acordo com as instru¸c˜oes da
linguagem SystemC, ou seja, fazendo uso de benchmarking3
para valida¸c˜ao dos m´odulos.
Os m´odulos que est˜ao sendo avaliados necessitam de uma carga inicial de entrada de
dados para serem estimulados. Durante a simula¸c˜ao utiliza-se um m´odulo monitor para a
visualiza¸c˜ao e armazenamento dos resultados.
Terminada a simula¸c˜ao ´e feita uma compara¸c˜ao dos resultados obtidos com os resultados
esperados. Se os resultados obtidos estiverem de acordo com os esperados o m´odulo ´e
validado como funcional. 3
O estudo de caso a seguir apresenta detalhes para a interconex˜ao dos m´odulos no arquivo
Cap´ıtulo 4
Estudo de Caso
O presente estudo de caso tem como finalidade demonstrar a maneira correta da
aplica¸c˜ao da metodologia. As se¸c˜oes deste capitulo apresentam a sua aplica¸c˜ao no projeto
de concep¸c˜ao e valida¸c˜ao de um gerador de caracteres para um “display” de v´ıdeo. O
produto final deste estudo de caso apresenta uma especifica¸c˜ao execut´avel e funcional em
SytemC da modelagem do SoC. No decorrer do cap´ıtulo o projetista deve ficar atento
a cada uma das etapas, pois elas representam a vis˜ao da metodologia proposta para o
projeto de SoCs. Essas fases est˜ao divididas de acordo com a descri¸c˜ao apresentada no
cap´ıtulo 3. Nelas est˜ao descritas informa¸c˜oes de como utilizar a metodologia, em conjunto
com as ferramentas adequadas, para se obter um melhor resultado. A se¸c˜ao 4.1 apresenta
o detalhamento da An´alise de Requisitos do Gerador de Caracteres. A se¸c˜ao 4.2 apresenta como deve ser feita a modelagemUMLde acordo com a descri¸c˜ao da metodologia
e utilizando os recursos dos diagramas UML apresentados, na se¸c˜ao 4.3 ´e apresentada a
maneira correta para se fazer a tradu¸c˜ao destes modelos (emUML) para o c´odigoSystemC
utilizando o “plug-in” que foi desenvolvido. A se¸c˜ao 4.4 descreve o como gerar o modelo
4.1
An´
alise de Requisitos
Conforme visto na descri¸c˜ao da metodologia, a etapa de An´alise de Requisitos ´e a
respons´avel pela captura das funcionalidades e das restri¸c˜oes do projeto de sistema que
se deseja desenvolver, no caso deste trabalho, um Gerador de Caracteres. Dividida em duas etapas, Vis˜ao Global e Especifica¸c˜ao, a An´alise de Requisitos procura resumir
em documentos, todas as caracter´ısticas funcionais e n˜ao-funcionais do projeto, al´em de
identificar os principais atores do sistema.
4.1.1
Vis˜
ao Global
Em um primeiro momento, o projetista respons´avel (ou a equipe) deve se preocupar
em reunir o maior n´umero de informa¸c˜oes relevantes sobre oSoC com o cliente ou mesmo
atrav´es de pesquisas. As informa¸c˜oes contidas no documento devem estar diretamente
ligadas a todo e qualquer tipo de requisito, sendo ele funcional ou n˜ao. A ordem em
que a captura ´e feita n˜ao tem relevˆancia. O objetivo principal desta etapa ´e detalhar,
atrav´es dos requisitos, todas as funcionalidades do SoC que se deseja desenvolver. Uma
vez capturadas, as informa¸c˜oes devem estar organizadas de forma ordenada e numerada.
Abaixo podemos ver o primeiro documento da Analise de Requisitos, uma lista contendo
todos os requisitos capturados e que possuem rela¸c˜ao direta com o projeto do Gerador de
Caracteres.
Gerador de Caracteres - Requisitos capturados:
1. O m´odulo deve ser capaz de enviar caracteres para um “display” de v´ıdeo;
2. O m´odulo deve ser capaz de converter um c´odigo ASCII para o padr˜ao de visualiza¸c˜ao do“display” de v´ıdeo;
3. O “display” dever´a receber dados dos caracteres da linha de forma serial;
5. O m´odulo deve permitir a visualiza¸c˜ao de espa¸cos (inclu´ıdo ap´os a revis˜ao);
6. Os caracteres dever˜ao ser armazenados em mem´oria;
7. Os caracteres ser˜ao representados atrav´es do c´odigo ASCII;
8. Cada endere¸co de mem´oria equivaler´a a um c´odigo ASCII em particular;
9. O m´odulo deve ser capaz de ler um caractere armazenado mem´oria;
10. O“display” ou monitor ter´a a resolu¸c˜ao padr˜ao de uma imagem no formato QCIF(176Cx144L) - Detalhado no padr˜ao H.261 de compress˜ao de v´ıdeo;
11. O mem´oria deve ser capaz de armazenar uma tela completa;
12. O m´odulo deve ser capaz de gerar um quadro completo (ou varredura vertical) do
“display”;
13. O m´odulo dever´a controlar os sinais de v´ıdeo necess´arios para o funcionamento do
“display”;
14. O m´odulo dever´a gerar o sinal de sincronismo horizontal (inclu´ıdo ap´os a revis˜ao);
15. O m´odulo dever´a gerar o sinal de sincronismo vertical (inclu´ıdo ap´os a revis˜ao);
16. O m´odulo dever´a gerar o sinal de retra¸co horizontal (inclu´ıdo ap´os a revis˜ao);
17. O m´odulo dever´a gerar o sinal de retra¸co vertical (inclu´ıdo ap´os a revis˜ao);
18. O m´odulo dever´a formar uma linha de caracteres por vez (inclu´ıdo ap´os a revis˜ao);
19. O m´odulo dever´a ser capaz de transformar um c´odigo ASCII em uma matriz de pontos (pixels) 8x8 (inclu´ıdo ap´os a revis˜ao);
No primeiro documento obtido nem sempre se consegue alcan¸car o objetivo, que ´e
descrever todas as funcionalidades e restri¸c˜oes. Ap´os uma r´apida revis˜ao foi poss´ıvel
identificar que alguns requisitos n˜ao haviam sido abordados. Esses requisitos foram inclu´ıdos
apenas para conhecimento do leitor, mesmo sendo uma informa¸c˜ao desnecess´aria ao projeto.
Os requisitos relevantes devem constar nesta lista, mesmo que o projetista somente os
identifique algumas etapas adiante.
A tarefa ap´os a defini¸c˜ao da lista de requisitos ´e a de classifica¸c˜ao. Todo e qualquer
requisito foi classificado como requisito funcional ou n˜ao-funcional. A se¸c˜ao 3.3.1 descreve
O segundo documento ´e praticamente a mesma lista apresentada no primeiro, por´em
com a adi¸c˜ao de um campo contendo a classifica¸c˜ao de cada requisito (FIG. 4.1).
Gerador de Caracteres - Classifica¸c˜ao dos Requisitos
Figura 4.1: Classifica¸c˜ao dos Requisitos em funcionais e n˜ao-funcionais
Ap´os a classifica¸c˜ao deve-se separar cada requisito de acordo com a sua caracteriza¸c˜ao,
formando dois grandes grupos, o primeiro contendo os requisitos classificados como funcionais
e o outro contendo os n˜ao-funcionais. Deve-se tamb´em colocar um identificador para
diferenciar futuramente cada requisito, sendo ele funcional ou n˜ao.
No caso do Gerador de Caracteres foram utilizados os c´odigosRF-xxx para identificar
os requisitos funcionais (ex. RF-001 - Requisito Funcional 1) eRNF-xxx para identificar
os n˜ao-funcionais (ex. RNF-001 - Requisito N˜ao-Funcional 1). Essa ´e a descri¸c˜ao que
caracteriza as informa¸c˜oes contidas no terceiro documento da vis˜ao global, veja classifica¸c˜ao
abaixo:
Gerador de Caracteres - Separa¸c˜ao e Identifica¸c˜ao
• Funcionais:
– RF-002: “O m´odulo deve ser capaz de converter um c´odigo ASCII para o padr˜ao de visualiza¸c˜ao do“display” de v´ıdeo”;
– RF-003: “O m´odulo deve ser capaz de enviar caracteres para um “display” de v´ıdeo”;
– RF-004: “O m´odulo dever´a controlar os sinais de v´ıdeo necess´arios para o funcionamento do“display””;
• N˜ao-funcionais:
– RNF-001: “Os caracteres dever˜ao ser armazenados em mem´oria”;
– RNF-002: “Os caracteres ser˜ao representados atrav´es do c´odigo ASCII”;
– RNF-003: “Cada endere¸co da mem´oria equivaler´a a um c´odigo ASCII em particular”; – RNF-004: “O “display” de v´ıdeo ter´a a resolu¸c˜ao padr˜ao de uma imagem no
formato CIF(352Cx288L) - Detalhado no padr˜ao H.261 de compress˜ao de v´ıdeo”; – RNF-005: “O mem´oria deve ser capaz de armazenar uma tela completa”; (Requisito
Extra)
– RNF-006: “O “display” dever´a receber dados dos caracteres da linha de forma serial”;
– RNF-007: “O m´odulo deve permitir a visualiza¸c˜ao de caracteres mai´usculos e min´usculos”;
– RNF-008: “O m´odulo deve permitir a visualiza¸c˜ao de espa¸cos”;
– RNF-009: “O m´odulo deve ser capaz de gerar um quadro completo (ou varredura vertical) do“display””;
– RNF-010: “O m´odulo dever´a gerar o sinal de sincronismo horizontal”; – RNF-011: “O m´odulo dever´a gerar o sinal de sincronismo vertical”; – RNF-012: “O m´odulo dever´a gerar o sinal de retra¸co horizontal”; – RNF-013: “O m´odulo dever´a gerar o sinal de retra¸co vertical”;
– RNF-014: “O m´odulo dever´a enviar uma linha de caracteres por vez”;
– RNF-015: “O m´odulo dever´a ser capaz de transformar um c´odigo ASCII em uma matriz de pontos (pixels) 8x8”;
Classificados e devidamente identificados, o projetista deve relacionar os requisitos
n˜ao-funcionais e funcionais entre eles. Uma restri¸c˜ao, ou requisito n˜ao-funcional, pode
estar diretamente relacionada com uma funcionalidade (requisito funcional). Isso n˜ao ´e
regra, algumas restri¸c˜oes podem estar relacionadas a outros fatores, como por exemplo o
![Figura 1.1: Aumento da capacidade de integra¸c˜ao de transistores representado pela evolu¸c˜ao dos processadores Intel [27].](https://thumb-eu.123doks.com/thumbv2/123dok_br/15180487.18046/15.892.213.695.166.361/figura-aumento-capacidade-integra-transistores-representado-processadores-intel.webp)
![Figura 2.3: Fluxo de Projeto SLOOP - Proposto por Zhu [28]](https://thumb-eu.123doks.com/thumbv2/123dok_br/15180487.18046/24.892.217.693.160.573/figura-fluxo-de-projeto-sloop-proposto-por-zhu.webp)
![Figura 2.4: Fluxo de Projeto em Y - Proposto por Dumoulin [5]](https://thumb-eu.123doks.com/thumbv2/123dok_br/15180487.18046/25.892.174.744.530.772/figura-fluxo-projeto-em-proposto-dumoulin.webp)
![Figura 2.5: Fluxo de Projeto utilizando MDA - Proposto por Riccobene [22]](https://thumb-eu.123doks.com/thumbv2/123dok_br/15180487.18046/27.892.190.712.161.555/figura-fluxo-projeto-utilizando-mda-proposto-riccobene.webp)
![Figura 2.6: Fluxo de Projeto utilizando MDA - Proposto por Nguyen [18]](https://thumb-eu.123doks.com/thumbv2/123dok_br/15180487.18046/29.892.250.660.159.600/figura-fluxo-projeto-utilizando-mda-proposto-nguyen.webp)
![Figura 3.1: Compara¸c˜ao do tempo de simula¸c˜ao entre SystemC e VHDL [17]](https://thumb-eu.123doks.com/thumbv2/123dok_br/15180487.18046/35.892.254.655.161.391/figura-compara-ao-tempo-simula-entre-systemc-vhdl.webp)
![Figura 3.2: Compara¸c˜ao entre a ´area efetiva gasta na s´ıntese de c´odigo VHDL e SystemC [17]](https://thumb-eu.123doks.com/thumbv2/123dok_br/15180487.18046/36.892.234.674.153.400/figura-compara-entre-efetiva-intese-odigo-vhdl-systemc.webp)
