gera¸c˜ao de especifica¸c˜oes execut´aveis para o projeto
TRANSCRIPT
Geracao de Especificacoes
Executaveis para o Projeto de
Modulos para Sistemas em “Chips”
Rafael Nunes Linhares Papa
Belo Horizonte
2006
Rafael Nunes Linhares Papa
Geracao de Especificacoes
Executaveis para o Projeto de
Modulos para Sistemas em “Chips”
Dissertacao apresentada ao Curso de Mestrado
do Programa de Pos-Graduacao em Engenharia
Eletrica da Universidade Federal de Minas
Gerais, como requisito parcial a obtencao
do tıtulo de Mestre em Engenharia da
Computacao.
Area de Concentracao: Engenharia de
Computacao e Telecomunicacoes
Linha de Pesquisa: Sistemas de Computacao
Orientador: Prof. Dr. Diogenes C. da Silva Jr.
Universidade Federal de Minas Gerais
Belo Horizonte
2006
Dedicatoria
A minha mae Sandra e a minha amada namorada Erica
Agradecimentos
Primeiramente a toda minha famılia e em todos aqueles que acreditaram em mim, em
especial ao meu irmao Daniel Nunes e a minha avo Jutay.
Aos professores e funcionarios 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 comentarios, crıticas e sugestoes que ajudaram
enriquecer este trabalho.
Ao CNPq e ao Projeto BRAZILIP pelo suporte financeiro.
Um agradecimento mais do que especial ao meu orientador, Professor Diogenes C. da
Silva Jr., por sua dedicacao e competencia fundamentais na concretizacao deste trabalho.
“O mar nao e um obstaculo:
e um caminho”
— Amyr Klink
Resumo
A crescente demanda por componentes eletronicos esta fazendo com que o mercado
destinado a circuitos integrados cresca a uma velocidade alarmante. Chegou-se a tal ponto
que, em no maximo dois ou quatro anos, sera possıvel encontrar circuitos compostos por ate
um bilhao de transistores. Essa capacidade de integracao e a responsavel 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 integracao e interconexao dos modulos que compoem
um SoC, chamados de propriedade intelectual (IP - Intellectual Property), faz com que os
fabricantes desses componentes invistam cada vez mais nos setores destinados a producao
e ao desenvolvimento de novas tecnologias de projeto. O tempo desperdicado durante o
processo de desenvolvimento do projeto de SoC tambem 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 possibilitara uma diminuicao no tempo de desenvolvimento e teste do projeto
por meio da geracao de uma especificacao executavel que sera utilizada como modelo de
referencia. A metodologia utiliza-se de diagramas da linguagem UML para a modelagem
e descricao do sistema. Para descricao dos modulos em seus diversos nıveis de abstracao,
a metodologia faz uso do ambiente de desenvolvimento da linguagem de descricao de
hardware SystemC.
Palavras-chave: Projeto de Sistemas Embutidos; Descricao UML; Modelo de Referencia;
System-on-a-chip (SoC); SystemC.
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
(SoC); SystemC Design.
Sumario
1 Introducao 1
1.1 Motivacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2 Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3 Organizacao do Documento . . . . . . . . . . . . . . . . . . . . . . . . 6
2 Revisao 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 Abstracao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2.1 Especificacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2.2 Descricao UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2.3 Especificacao Executavel . . . . . . . . . . . . . . . . . . . . . . 25
3.2.4 Fluxo de Dados (Data Flow - DF) . . . . . . . . . . . . . . . . 25
3.2.5 Descricao Comportamental . . . . . . . . . . . . . . . . . . . . 26
3.2.6 RTL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.3 Fluxo de Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.3.1 Analise de Requisitos . . . . . . . . . . . . . . . . . . . . . . . . 28
3.3.2 Modelagem UML . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.3.3 Descricao UML (Umbrello) para SystemC . . . . . . . . . . . 35
3.3.4 Implementacao da funcionalidade do processo . . . . . . . . 37
3.3.5 Modulo funcional executavel . . . . . . . . . . . . . . . . . . . 38
viii
4 Estudo de Caso 40
4.1 Analise de Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.1.1 Visao Global . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.1.2 Especificacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.2 Modelagem UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.2.1 Diagrama de Casos de Uso . . . . . . . . . . . . . . . . . . . . 49
4.2.2 Diagrama de Sequencia . . . . . . . . . . . . . . . . . . . . . . . 52
4.2.3 Diagrama de Classes . . . . . . . . . . . . . . . . . . . . . . . . 53
4.3 Geracao do Codigo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.4 Modelo Executavel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.5 Teste e Validacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
4.6 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5 Conclusao 76
A Anexos 83
A.1 Codigo Esqueleto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
A.2 Codigo Funcional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
A.3 Diagrama de Classes - Todos os modulos . . . . . . . . . . . . . . . . . . . 107
Lista de Figuras
1.1 Aumento da capacidade de integracao de transistores representado pela
evolucao dos processadores Intel [27]. . . . . . . . . . . . . . . . . . . . . . 2
2.1 Nıveis de Abstracao Propostos por Arnout [2] . . . . . . . . . . . . . . . . 8
2.2 Nıveis de Abstracao 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 Comparacao do tempo de simulacao entre SystemC e VHDL [17] . . . . . . 22
3.2 Comparacao entre a area efetiva gasta na sıntese de codigo VHDL e SystemC [17] 23
3.3 Nıveis de Abstracao alvo da Metodologia . . . . . . . . . . . . . . . . . . . 24
3.4 Fluxo de Projeto proposto pela Metodologia . . . . . . . . . . . . . . . . . 27
3.5 Exemplo da organizacao das informacoes identificadas . . . . . . . . . . . . 30
3.6 Exemplo de Caso de Uso Detalhado . . . . . . . . . . . . . . . . . . . . . . 31
3.7 Equivalencia entre as representacoes das classes do Umbrello - Modulo (SystemC)
x Classe (UML) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.8 Caso de Uso Detalhado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.9 Diagrama de Caso de Uso - Representacao Grafica . . . . . . . . . . . . . . 33
3.10 Interface - Exemplo de Modelagem . . . . . . . . . . . . . . . . . . . . . . 33
3.11 Exemplo de um Diagrama de Sequencia . . . . . . . . . . . . . . . . . . . . 34
3.12 Exemplo de um Diagrama de Classes . . . . . . . . . . . . . . . . . . . . . 35
3.13 Tipos Padrao do SystemC no Umbrello . . . . . . . . . . . . . . . . . . . . 36
3.14 Menu de Selecao de linguagem ativa . . . . . . . . . . . . . . . . . . . . . . 36
3.15 Menu de Selecao de Classes do “Code Generation Wizard” . . . . . . . . . 37
4.1 Classificacao dos Requisitos em funcionais e nao-funcionais . . . . . . . . . 43
x
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 Codigo ASCII em Matriz de Pontos . . . . . . . . 50
4.9 Caso de Uso - Gerar Sequencia 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 Sequencia . . . . . . . . . . . . . . . 53
4.13 Gerador de Caracteres - Diagrama de Classes . . . . . . . . . . . . . . . . 54
4.14 Exemplo de msg no Diagrama de Sequencia - A Orientacao da seta pode
indicar o tipo de interface entre modulos . . . . . . . . . . . . . . . . . . . 55
4.15 Umbrello - Adicionando interfaces aos modulos . . . . . . . . . . . . . . . . 57
4.16 Representacao do caractere ASCII “u” na ROM . . . . . . . . . . . . . . . 58
4.17 Diagrama de Classes - Definicao das interfaces . . . . . . . . . . . . . . . . 60
4.18 Umbrello - Acesso ao gerador de codigo (“Code Generation Wizard”) . . . 61
4.19 Umbrello - Selecao de Modulos para a Geracao de codigo SystemC . . . . . 61
4.20 Umbrello - Indicacao do local de gravacao dos arquivos fonte e leitura do
cabecalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.21 Umbrello - Aguardando a confirmacao para gerar o codigo . . . . . . . . . 62
4.22 Umbrello - Codigo gerado com sucesso . . . . . . . . . . . . . . . . . . . . 63
4.23 Teste e validacao do Modelo de Referencia . . . . . . . . . . . . . . . . . . 67
4.24 Resultados - Diagrama de Caso de Uso . . . . . . . . . . . . . . . . . . . . 71
4.25 Resultados - Diagrama de Sequencia . . . . . . . . . . . . . . . . . . . . . 72
4.26 Resultados - Diagrama de Classes . . . . . . . . . . . . . . . . . . . . . . . 73
4.27 Resultado - Quadro gerado pelo simulador de vıdeo . . . . . . . . . . . . . 74
4.28 Resultado - Formas de onda referente aos sinais de sincronismo do vıdeo . 74
A.1 Diagrama de Classes Completo e Funcional . . . . . . . . . . . . . . . . . . 107
Lista de Codigos Fonte
3.1 Codigo Esqueleto - Indicacao de onde deve ser implementada a funcionalidade
do Processo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.1 Gerador de Caracteres - Codigo Esqueleto gerado pela ferramenta . . . . . 63
4.2 Gerador de Caracteres - Implementacao da funcionalidade do processo . . . 64
4.3 Como construir um Programa principal “main.cpp” em SystemC . . . . 68
A.1 Codigo Esqueleto - Gerador de Caracteres . . . . . . . . . . . . . . . . . . 83
A.2 Codigo Esqueleto - Memoria . . . . . . . . . . . . . . . . . . . . . . . . . . 84
A.3 Codigo Esqueleto - ROM de Caracteres . . . . . . . . . . . . . . . . . . . . 84
A.4 Codigo Funcional - Gerador de Caracteres . . . . . . . . . . . . . . . . . . 85
A.5 Codigo Funcional - Memoria . . . . . . . . . . . . . . . . . . . . . . . . . . 87
A.6 Codigo Funcional - ROM de Caracteres . . . . . . . . . . . . . . . . . . . . 89
A.7 Codigo Funcional - Makefile . . . . . . . . . . . . . . . . . . . . . . . . . . 91
A.8 Codigo Funcional - Modulo Controlador (envia os enderecos a memoria) . 92
A.9 Codigo Funcional - Gerador de Sinais de Video . . . . . . . . . . . . . . . . 93
A.10 Codigo Funcional - Buffer de armazenamento e atualizacao de quadros . . 96
A.11 Codigo Funcional - Simulador de Video . . . . . . . . . . . . . . . . . . . . 100
A.12 Codigo Funcional - Programa Principal (“Main”) . . . . . . . . . . . . . . 102
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
GNU General Public License
Capıtulo 1
Introducao
O constante avanco tecnologico observado por Gordon E. Moore na decada de 1960 [24]
e o aumento da demanda do mercado por dispositivos eletronicos, tem contribuıdo cada
vez mais para que as atividades rotineiras realizadas pelo homem sejam automatizadas.
Os sistemas computacionais, formados por meio da uniao entre hardware e software,
constituem uma forma moderna de prover essa automatizacao e sao chamados de SoCs
- System on a Chip. Os SoCs sao sistemas computacionais completos que, apesar de
possuırem uma estrutura interna similar ao de um computador, formados por microprocessadores,
memorias RAM (Random Access Memory) e ROM (Read Only Memory), barramentos
e dotados de software, sao caracterizados pela sua capacidade de nao serem percebidos
como tal pelo o usuario final [7]. A tıtulo de exemplo, podemos citar como uma de suas
aplicacoes, a verificacao em tempo real da pressao dos pneus de um veıculo, um processo
totalmente automatizado que ja e realizado pela maioria dos sistemas de controle dos
veıculos considerados de luxo. Atualmente, conforme foi previsto por Moore, estes sistemas
sao compostos por milhoes de transistores embutidos em um unico circuito integrado (CI ).
A FIG. 1.1 abaixo representa, atraves da evolucao dos processadores do fabricante Intel, o
aumento dessa capacidade de integracao ao longo dos anos.
1
Figura 1.1: Aumento da capacidade de integracao de transistores representado pelaevolucao dos processadores Intel [27].
Nos ultimos vinte anos, o avanco da tecnologia de fabricacao de CIs continua sendo
impulsionada pela lei de Moore que mantem a afirmacao de que o numero de transistores
por area de chip dobra a cada 18 meses [25]. Estima-se que em menos de 4 anos estarao
disponıveis no mercado, circuitos integrados compostos por mais de um bilhao de transistores [19] [10],
que se comparado ao estado atual, tornara ainda mais complexa a tarefa de integracao e
interconexao dos modulos que compoem um sistema dessa grandeza, incluindo os SoCs.
Alem disso, o tempo entre o desenvolvimento de um produto e seu lancamento no mercado
(Time-to-Market), tende a ser cada vez menor [21].
Todos os fatores citados contribuem para a diminuicao do tempo disponıvel para a
equipe na concepcao e validacao de um projeto de SoC. As etapas compreendidas entre
a concepcao e os testes de SoCs sao 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) preve que em torno de 2015, o custo para
se testar um CI com essa complexidade ira exceder o custo necessario para desenvolve-lo,
caso nao sejam empregadas novas metodologias voltadas para seu desenvolvimento [25].
2
Esse fator justifica a necessidade em estar constantemente desenvolvendo novas metodologias
que auxiliem durante as fases de especificacao e teste de projetos de SoCs [3]. Novos fluxos
de desenvolvimento de projeto tambem estao 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 propria utilizacao efetiva de SoCs tem se mostrado util na tentativa de minimizar
alguns desses problemas. Porem, o tempo empregado no desenvolvimento e concepcao
do seu projeto continua sendo um de seus fatores crıticos. As suas principais vantagens
sobre as demais tecnologias sao: diminuicao da area efetiva total gasta pelo hardware e a
diminuicao no tempo de comunicacao entre diferentes modulos. Varias tecnicas estao sendo
empregadas com o proposito de maximiza-las. Dentre as mais comuns podemos listar:
1. padronizacao e melhoramento dos meios de interconexao entre modulos do projeto;
2. reuso de modulos ou reutilizacao;
3. aumento nos nıveis de abstracao do projeto;
A padronizacao das interconexoes busca melhorar a eficiencia na troca de dados
e informacoes entre os modulos. A medida que o numero de modulos contidos em um SoC
aumenta, crescem tambem os problemas para interconecta-los. A utilizacao de barramentos
simples ja nao e tao eficiente. Alem de ser um meio compartilhado, existem serias restricoes
relacionadas a sua forma de comunicacao, que se resume a uma mensagem a cada instante.
Barramentos hierarquicos e aplicacao do conceito de redes de computadores vem sendo
utilizados como tentativa de solucao. Uma Network on a Chip (NoC), como sao chamadas
essas redes de comunicacao, tende a ser mais eficiente [15] por evitarem situacoes bloqueantes
na comunicacao entre dois modulos. Ela os trata como se fossem objetos reais de uma rede,
gerenciando a comunicacao entre eles por meio de camadas de protocolos.
O reuso de modulos que possuem uma funcionalidade previamente definida, chamados
de propriedade intelectual (Intellectual property - IP), tambem tendem a reduzir o tempo
3
gasto no projeto. Porem na maioria dos casos, esses modulos ainda nao dispoem de uma
interface padronizada. Como foi visto anteriormente, o avanco na producao e o aumento
na capacidade dos CIs esta permitindo que um maior numero de modulos ou nucleos IP
sejam agregados em um unico SoC. A grande quantidade e a falta de interfaces de conexao
padronizadas, tornam a reutilizacao em novos projetos uma tarefa bastante complexa.
O aumento nos nıveis de abstracao tambem e um dos meios utilizados para
tentar diminuir o tempo gasto na concepcao de projetos. Alem disso, e visto como uma
das formas de aumentar a sua eficiencia. A complexidade de se desenvolver ou alterar
qualquer modulo no nıvel de transferencia de registradores (Register Transfer Level - RTL)
e alta. Quando se eleva os nıveis a um patamar onde o projetista nao precisa mais se
preocupar com determinados tipos de detalhes de implementacao, a tarefa de descrever as
funcionalidades de um modulo, bem como suas conexoes e interfaces, torna-se muito mais
facil. Atualmente nao existe uma definicao ou padronizacao para determinar os nıveis que
devem estar compreendidos entre a descricao no nıvel de sistema e o RTL.
A escolha correta das ferramentas de CAD (Computer Aided Design) tambem se tornou
um fator importante durante o processo de desenvolvimento de SoCs. Veremos no decorrer
dos capıtulos que este trabalho utiliza-se dos recursos de apenas duas ferramentas. O
Umbrello UML Modeller, que da suporte a linguagem de modelagem UML, e SystemC,
uma linguagem de descricao de hardware.
A Unified Modeling Language(UML) e uma linguagem de modelagem de proposito
geral que ja vem sendo amplamente utilizada pela comunidade de engenharia de software
como “framework” para documentacao de software. Ela prove suporte a projetos orientados
a objetos, o qual indiretamente, encoraja a reutilizacao de componentes, pois apresenta
diversas visoes do sistema que esta sendo projetado com uma grande diversidade de
diagramas estruturais e comportamentais. Anteriormente pensava-se que ela havia sido
desenvolvida unica e exclusivamente para atender as demandas da comunidade de engenharia
4
de software. Hoje, UML esta se tornando atrativa tambem para a descricao de sistemas
embutidos e de tempo real [14].
SystemC e uma linguagem de descricao de hardware (Hardware Description Language
- HDL) de codigo aberto, baseada em C++. Ela vem sendo desenvolvida por um grupo
de empresas que formam a Open SystemC Initiative (OSCI), reconhecida recentemente
como novo padrao, IEEE P1666 (“SystemC Language Reference Manual”). Foi criada com
a finalidade de atender as necessidades anteriormente descritas de elevacao dos nıveis de
abstracao de um projeto de SoC. Alem disso SystemC permite que hardware e software
sejam descritos simultaneamente em um ambiente homogeneo, proporcionando ao projetista
a capacidade de verificacao de erros funcionais ainda nas etapas iniciais de desenvolvimento
e uma maior compreensao do projeto como um todo.
1.1 Motivacao
O nıvel de integracao e o numero de funcionalidades embutidos em um unico circuito
integrado esta tornando muito complexa a tarefa de desenvolvimento de SoCs. Consequentemente
o tempo gasto e os custos empregados no decorrer do projeto estao aumentando. Sendo
assim, para cada novo projeto de SoC, devemos buscar novos metodos para tentar diminuir
o esforco empregado nas suas etapas de concepcao e validacao.
Alem de levar em consideracao a possibilidade do reuso de modulos em projetos futuros,
deve-se preocupar principalmente em garantir a sua qualidade e a confiabilidade. As
tecnicas de modelagem sao utilizadas para garantir estes quesitos e juntamente com a
metodologia proposta pode trazer diversas vantagens:
• Um melhor entendimento do projeto;
• Facilidade de deteccao de erros logo nas primeiras etapas;
5
• Facilidade de alteracao sem custos elevados;
• Diminuicao do tempo gasto compreendido entre o perıodo de concepcao e validacao
da primeira descricao executavel;
• Facilidade de documentacao, facilitando o reuso de modulos.
1.2 Objetivo
O objetivo deste trabalho e elaborar uma metodologia de desenvolvimento de SoCs
que minimize os esforcos gastos pelos projetistas no decorrer das etapas de concepcao e
validacao do projeto.
A proposta e partir de uma especificacao do SoC em alto nıvel, em conjunto com a sua
descricao UML, e chegar a um modelo de referencia executavel. Inicialmente, pretende-se
gerar codigo esqueleto para SystemC com a finalidade de facilitar o trabalho do projetista
durante os diversos refinamentos sucessivos dos modulos ate a sua implementacao.
Em consequencia deste trabalho foi desenvolvida uma ferramenta para traducao automatizada
de descricoes UML (de SoCs) em codigo SystemC. Ela e um “plug-in” que deve ser instalado
juntamente com a ferramenta Umbrello1 de modelagem UML.
Nao e objetivo deste trabalho explorar os detalhes de implementacao do projeto na
ferramenta SystemC em seus diversos nıveis de abstracao.
1.3 Organizacao do Documento
O texto deste trabalho esta organizado da seguinte forma:
• No capitulo 2 e apresentada uma revisao da literatura contendo as diversas propostasde metodologias e fluxos de projeto para o desenvolvimento de SoCs ao longo dos
1http://uml.sourceforge.net
6
ultimos 4 anos.
• O capitulo 3 apresenta a metodologia. Nela sao apresentados os nıveis de abstracaono qual o projetista deve focalizar para a correta aplicacao dos metodos e o fluxo deprojeto que deve ser seguido. As ferramentas tambem sao brevemente apresentadas.
• O capitulo 4 mostra a aplicacao da metodologia em um estudo de caso. Nele eapresentado o desenvolvimento de um gerador de caracteres para um display devideo.
• No capitulo 5 e feita uma avaliacao dos resultados obtidos.
• O capitulo 6 apresenta as consideracoes finais sobre o trabalho e sugestoes sobrepossıveis trabalhos futuros
7
Capıtulo 2
Revisao da Literatura
Uma das primeiras propostas a apresentar alguma mudanca no processo de desenvolvimento
de SoCs, utilizando SystemC como linguagem de descricao de hardware, foi descrita por
Arnout [2] em 2002. Ele propos dois novos nıveis de abstracao intermediarios entre a
especificacao e o RTL. O nıvel nao temporizado buscava a descricao funcional do
projeto sem a precisao temporal e nao havia separacao entre hardware e software, enquanto
que o transacional descrevia a funcionalidade de cada modulo de forma abstrata e a
comunicacao entre eles era baseada em ciclos de transacoes. Arnout tinha como objetivo
a diminuicao do tempo total gasto no desenvolvimento do projeto.
Figura 2.1: Nıveis de Abstracao Propostos por Arnout [2]
8
Nesse mesmo ano, uma outra proposta de elevacao nos nıveis de abstracao foi apresentada
pela Synopsys [26]. Foram propostos dois novos nıveis de abstracao alem daqueles apresentados
por Arnout. Essa nova abordagem proporcionava ao projetista uma visao de quatro nıveis
de abstracao superiores ao RTL: o nao temporizado, o temporizado, o de transacao
e o comportamental.
Figura 2.2: Nıveis de Abstracao Propostos pela Synopsys [26]
O nıvel de abstracao nao temporizado proposto e utilizado para a captura, verificacao e
otimizacao dos algoritmos que representam a funcionalidade do sistema. O nıvel temporizado
descreve esses mesmos algoritmos, mas com uma pequena diferenca. Eles passam a ser
dotados de atraso, computacionais ou de comunicacao, e sao utilizados para analisar quais
serao as consequencias causadas pelo impacto da temporizacao no comportamento e na
arquitetura do sistema. O nıvel de transacao descreve o comportamento do modulo em
termos de transacoes e o tempo pode ser representado com precisao de ciclos de relogio
ou nao. Ainda nao 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
de comunicacao (clock, reset, dados e linhas de comandos). Internamente ele ainda nao se
9
parece com a implementacao estrutural final do RTL, mas ja pode se tornar sintetizavel.
Para transformar um modelo no nıvel comportamental em blocos totalmente sintetizaveis,
e necessario alterar o codigo para que o mesmo esteja de acordo com o atual conjunto de
regras de codificacao necessarias para a sıntese na ferramenta que sera utilizada. Segundo
a Synopsys [26], os ganhos na produtividade do projeto de SoC por meio da sıntese do
codigo no nıvel comportamental sao maiores do que no nıvel RTL.
O grande numero de propostas de elevacao nos nıveis de abstracao 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 atencoes 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 orientacao a objetos. SLOOP (System Level Design with Object-Oriented Process),
como foi chamada, emprega tecnicas de modelagem, avaliacao de desempenho de sistemas
e metodologia de exploracao de arquitetura para descrever o sistema.
10
Figura 2.3: Fluxo de Projeto SLOOP - Proposto por Zhu [28]
A metodologia propoe quatro modelos para o desenvolvimento de SoC que sao utilizados
nas etapas anteriores a implementacao do software e do hardware, sao eles: o conceitual,
o funcional, o de arquitetura e o de desempenho. Cada um detalha tres aspectos do
sistema alvo: funcionalidade, estrutura e temporizacao. O modelo conceitual descreve o
resultado da analise dos requisitos que foi feita com cliente por meio de uma descricao UML.
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 temporizacao.
O modelo de arquitetura representa os recursos fısicos da arquitetura, como barramentos,
1Uma rede de processos Kahn, ou apenas redes de processos, e um modelo de compucao que foi original-mente desenvolvido para a modelagem de sistemas distribuidos. Mostrou-se util tambem para a modelagemde sistemas de processamento de sinais. Consiste em um conjunto de processos que podem se comunicarapenas atraves de canais de comunicacao unidirecional, formando uma rede. Simplificando, poderıamospensar em um grafo direcionado onde os nos representam os processos e os arcos o meio de comunicacaoentre eles. Kahn foi o primeiro a introduzir este conceito em sua tese em 1974 (“The semantics of a simplelanguage for parallel programming”)
11
memorias 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 executavel que servira de base para a avaliacao do sistema.
Segundo os autores o modelo executavel gerado auxilia os projetistas a encontrar possıveis
gargalos e problemas da arquitetura que foi escolhida, alem de melhorar o sistema para
que ele satisfaca os requisitos de desempenho especificados no projeto.
Dumoulin [5] propos 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,
2MDA foi inicialmente proposta pela OMG [1] com a finalidade de auxiliar no desenvolvimento desoftwares. Ela e composta basicamente por modelos que descrevem o sistema a ser desenvolvido. Cadaum representa um nıvel de abstracao diferente. Essa arquitetura promove a separacao entre a logica fun-damental do sistema, que e descrita na especificacao, e suas operacoes, que serao implementadas em umadeterminada tecnologia. Sua principal meta e aumentar a reutilizacao e reduzir o tempo no desenvolvi-mentos de novos componentes de software.
3Plataforma e um conjunto de subsistemas e tecnologias que preveem um conjunto coerente de fun-cionalidades atraves de interfaces.
4PIM e uma visao do sistema a partir de um ponto de vista independente de plataforma. Descreve osistema, mas nao apresenta detalhes sobre a sua implementacao em determinada plataforma.
12
o de aplicacao e o da arquitetura de hardware, e proposto o desenvolvimento de um terceiro
que fara a uniao entre eles. O modelo no nıvel de aplicacao descreve uma maneira de
representar as dependencias de dados do sistema (funcionalidade), enquanto que o modelo
no nıvel de arquitetura de hardware apresenta uma descricao voltada para sua estrutura.
O metamodelo de associacao, como foi chamado, fara a importacao de ambos os modelos
previamente descritos. O modelo resultante sera um metamodelo de plataforma especifica
(PSM5) capaz de se transformar automaticamente em um modelo de qualquer plataforma
de desenvolvimento de SoC. Como estudo de caso os autores utilizaram um “profile UML6”
ja pronto de um ISP (“intensive signal processing”) [6]. A ferramenta para a traducao
automatica de modelos encontra-se em fase de desenvolvimento e o resultado do trabalho
se resume na proposta de utilizacao da MDA como forma de modelagem.
Outra abordagem para o desenvolvilmento de SoCs utilizando os conceitos da MDA foi
apresentada em 2004 por Riccobene [22]. O trabalho propoe um novo fluxo de projeto e
apresenta o “UML profile” para SystemC que foi desenvolvido.
5PSM e uma visao do sistema a partir do ponto de vista de uma plataforma especifica. Combina adescricao do PIM com os detalhes de implementacao de uma plataforma em particular.
6UML Profile - e uma forma especifica de utilizar a linguagem UML (utilizando mecanismos comoestereotipo e restricoes) para definir um metamodelo UML para um proposito em particular
13
Figura 2.5: Fluxo de Projeto utilizando MDA - Proposto por Riccobene [22]
O fluxo de projeto utiliza uma especificacao descrita em linguagem natural para gerar
um representacao algorıtmica do sistema, que pode ser implementada em uma linguagem
de programacao de software (como C/C++) ou em uma ferramenta de modelagem (como
simulink[www.mathworks.com/products/simulink/] por exemplo). O segundo estagio consiste
na separacao entre os requisitos de hardware e software, que sao desenvolvidos paralelamente
ao longo do projeto. O software e compilado para a plataforma que foi definida e gera como
resultado um codigo objeto, enquanto o hardware e apenas descrito em RTL. A partir desses
resultados e feita uma co-simulacao entre o hardware (em RTL) e as partes do software
que estao rodando no simulador (Instruction Set Simulator - ISS ) para a verificacao dos
possıveis erros causados pelo codigo RTL na traducao para o nıvel de portas logicas.
O “UML profile” para SystemC foi baseado na especificacao da versao 2.0 da linguagem
UML e foi organizado em quatro partes. A primeira parte, de estrutura e comunicacao,
14
define os estereotipos do nucleo SystemC, ou camada 0 (zero), que podem ser utilizados
nos diagramas estruturais UML, responsaveis pelos elementos de estrutura e comunicacao
(modulos, interfaces, portas e canais). A segunda parte e responsavel pela definicao dos
tipos de dados, representados atraves dos diagramas de classes, enquanto que a terceira
parte descreve o comportamento e a sincronizacao entre os modulos atraves dos diagramas
comportamentais. A ultima parte prove conceitos para a definicao de canais, interfaces
e portas que sao pre-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 descricao no nıvel de
sistema, baseado em notacoes UML, que e capaz de gerar codigo SystemC no nıvel transacional
(Transaction Level Modeling - TLM). Esta referencia utiliza dois dos diversos diagramas
UML para representar o sistema, o diagrama de classes e o diagrama de transicao de
estados. A ferramenta escolhida para a especificacao do sistema atraves dos diagramas, foi o
Rhapsody7, plataforma de colaboracao, desenvolvimento de aplicacao e projeto de sistemas,
compatıvel com UML. Os autores tiveram que incorporar estereotipos na ferramenta Rhapsody
para que ela conseguisse capturar algumas das primitivas de comunicacao da linguagem
SystemC, como interfaces e canais. Tambem foi necessario a utilizacao de uma outra
ferramenta, chamada Velocity8, para a traducao dos modelos gerados em codigo SystemC.
A FIG. 2.6 abaixo resume o fluxo de projeto proposto.
7http://www.ilogix.com8http://jakarta.apache.org/velocity/
15
Figura 2.6: Fluxo de Projeto utilizando MDA - Proposto por Nguyen [18]
Na modelagem UML, o diagrama de classes e responsavel pela descricao da estrutura
dos componentes, enquanto que o diagrama de transicao de estados e utilizado para
representar o comportamento. Esse modelo inicial, deve ser dotado de estereotipos para
suprir a necessidade de representacao de algumas entidades SystemC. Para a geracao do
documento XMI e necessario a utilizacao de um toolkit da ferramenta Rhapsody. A funcao
dele e transformar as informacoes contidas no modelo grafico e no conjunto de estereotipos
em um documento padrao XMI. Os autores tambem desenvolveram um parser XMI que
agrega mais informacoes ao documento gerado e o transforma em uma arvore abstrata. Ela
servira como modelo de entrada para a ferramenta Velocity. So assim o codigo sera gerado.
Os autores afirmam que, apos todos esses passos e ferramentas que foram utilizadas, para
qualquer alteracao ou refinamento que se deseja fazer para um nıvel de abstracao mais
16
detalhado, sera necessario apenas fazer alteracoes nos modelos (ou templates) gerados
como entrada para a ferramenta Velocity.
17
Capıtulo 3
Metodologia
A presente metodologia tem como principal objetivo diminuir o tempo e os esforcos
gastos pelos projetistas na geracao da primeira especificacao executavel. No desenvolvimento
de SoCs, problemas de funcionalidade e de comunicacao, dificilmente sao detectados logo
nas primeiras etapas do projeto e os testes, geralmente sao realizados em um ponto onde
as alternativas para provaveis correcoes sao poucas e de custo elevado. Na maioria dos
casos, as decisoes que sao tomadas durante estas etapas, compreendidas entre a concepcao
e validacao do projeto, podem gerar um impacto grande na adequacao daquilo que foi
especificado ao que sera efetivamente implementado. Um planejamento inicial mınimo,
daquilo que se esta projetando, faz-se necessario. E por meio dele que o projetista consegue
obter um melhor entendimento do projeto e consequentemente pode evitar alteracoes
desnecessarias, diminuindo custos e evitando desperdıcio de tempo.
A metodologia propoe um fluxo de projeto que favorece a visao geral do o sistema.
Possıveis erros, antes so detectados nos nıveis de abstracao que ja possuıam um consideravel
nıvel de detalhamento, como o RTL, poderao ser previstos. Para tanto, a metodologia faz
uso de alguns recursos disponıveis nas tecnicas de modelagem UML, como documentos e
diagramas. Esses fatores nao so contribuem com a diminuicao do tempo gasto no decorrer
18
do desenvolvimento do projeto como tambem favorecem a reutilizacao de modulos.
Ao final do fluxo de proposto, o projetista tera disponıvel uma especificacao funcional
SystemC, executavel, para utilizar como modelo de referencia ao longo dos sucessivos
refinamentos que tera que fazer durante os nıveis de abstracao. A metodologia tambem
apresenta um “plug-in” SystemC desenvolvido especialmente para a ferramenta Umbrello.
Ele e capaz de gerar codigo 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 importancia de cada uma delas e como trabalham em
conjunto para garantir que os resultados esperados sejam alcancados da melhor maneira
possıvel. Um bom conhecimento das ferramentas, UML e SystemC, tambem garantem
um melhor resultado. A proxima secao apresenta um breve resumo de cada uma das
ferramentas. A secao 3.2 descreve os nıveis de abstracao e a secao 3.3 apresenta o fluxo
de projeto proposto que e a propria representacao da metodologia. Para um melhor
entendimento, o capitulo 4 apresenta um estudo de caso com a aplicacao da metodologia.
3.1 Ferramentas Associadas
3.1.1 A Linguagem UML
A UML e uma linguagem de modelagem de proposito geral utilizada para representar
sistemas orientados a objetos que surgiu no final da decada de 1990. UML 1.x e uma
combinacao de elementos de Booch [4], OOSE [12] e OMT [23]. A versao 2.0 se encontra
em fase final de aprovacao pela OMG (Object Management Group) e inclui melhoramentos
em todas as areas. Ela possui treze tipos de diagramas capazes de descrever varios aspectos
estruturais, comportamentais e fısicos de um sistema. Cada diagrama possui um proposito
diferente durante o processo de desenvolvimento, por isso e importante ter em mente que
os diagramas por si so apenas proveem uma notacao e que deve ser acompanhada por uma
19
metodologia de projeto.
A especificacao comportamental em UML, em alto nıvel, geralmente se inicia a partir
da identificacao dos casos de uso para um sistema e dos atores envolvidos. Estes sao
denominados Diagramas de Casos de Uso. Porem, para uma descricao comportamental
detalhada, costuma-se usar os Diagramas de Transicao de Estado [11], que sao capazes de
representar maquinas 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 atraves de associacoes. Uma
classe pode ou nao possuir atributos e/ou operacoes. Alem disso, interfaces e generalizacoes
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, tambem
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 ambientede desenvolvimento);
• Enterprise Architect (de custo mais acessıvel);
• Umbrello (livre distribuicao e codigo 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 universitarios.
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 generico, causou problemas com algumas distribuicoes de software que possuıam o
mesmo nome e teve que ser mudado. A mudanca ocorreu em Setembro de 2002. O projeto
1http://www.ibm.com2http://uml.sourceforge.net
20
foi todo revisado pela Universidade onde Paul estudava e passou a ser de livre distribuicao
e de codigo aberto. A versao 1.0 ja oferecia muitas funcionalidades, mas com as diversas
contribuicoes passou a ter suporte a um numero maior de diagramas UML, o formato de
arquivo passou de binario para XML, o aplicativo agregou funcionalidades como geracao de
codigo automatizada e importacao de codigo. Paul retirou-se da equipe de desenvolvimento
em meados de 2002, mas o software esta 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 descricao de hardware (HDL), codigo aberto, baseada em
C++, que vem sendo desenvolvida por um grupo de empresas que formam a Open SystemC
Initiative (OSCI - IEEE P1666). Alem de possuir uma estrutura de programacao simples
e intuitiva, uma das principais caracterısticas desta ferramenta e que ela possui um nucleo
exclusivo para a simulacao e prove suporte a concorrencia e a hierarquia de modulos. Sua
principal vantagem em relacao as outras linguagens de descricao de hardware e que ela
permite a descricao e teste de modulos em varios nıveis de abstracao [9]. O projetista nao
precisa aprender, nem ao menos precisa utilizar mais de um ambiente de programacao a
medida que prossegue nas etapas de desenvolvimento de seu modulo.
Testes realizados por Moreno [17] mostraram que SystemC obteve ganhos consideraveis
na velocidade de simulacao se comparada a uma das principais linguagens de descricao
de hardware, VHDL. Utilizou-se para o teste o algoritmo de ordenacao “bubble sort”.
O tamanho da memoria de valores a serem ordenados, tamanho do vetor, foi alterado
gradativamente como mostra a FIG. 3.1.
21
Figura 3.1: Comparacao do tempo de simulacao entre SystemC e VHDL [17]
Este ganho de velocidade na simulacao se deve ao fato de que o simulador padrao
da linguagem SystemC permite a simulacao em diferentes nıveis de abstracao. SystemC
tambem favorece a programacao intuitiva, permitindo a programacao em alto nıvel por
meio da linguagem C/C++. VHDL, por outro lado, necessita de uma programacao 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
atraves da sıntese em FPGA de codigo VHDL e SystemC. Eles demonstraram que SystemC
obteve praticamente o mesmo desempenho que a linguagem VHDL(FIG. 3.2).
22
Figura 3.2: Comparacao entre a area efetiva gasta na sıntese de codigo VHDL eSystemC [17]
3.2 Nıveis de Abstracao
Nıvel de abstracao e a descricao do projeto com uma determinada quantidade de
detalhamento. O aumento (ou elevacao) nos nıveis de abstracao tambem e um dos meios
utilizados para tentar diminuir o tempo gasto na concepcao de projetos. Alem disso, e visto
como uma das formas de aumentar a sua eficiencia. A complexidade de se desenvolver ou
alterar qualquer modulo no nıvel de transferencia de registradores e alta. Quando se eleva
os nıveis a um patamar onde o projetista nao precisa mais se preocupar com determinados
tipos de detalhes de implementacao, a tarefa de descrever as funcionalidades de um modulo,
bem como suas conexoes e interfaces, torna-se muito mais facil.
A FIG. 3.3 abaixo apresenta a divisao dos nıveis de abstracao de um projeto de SoC e
destaca aqueles onde a metodologia ira auxiliar o projetista no desenvolvimento da primeira
especificacao executavel do sistema.
23
Figura 3.3: Nıveis de Abstracao alvo da Metodologia
3.2.1 Especificacao
A especificacao e o nıvel onde estao detalhadas as caracterısticas e funcionalidades dos
modulos do sistema. Nao existe distincao entre hardware e software, e a temporizacao
nao e representada. Todos os requisitos do projeto bem como os detalhes relacionados
a custos, riscos e restricoes sao cuidadosamente documentados. O diagrama de casos de
uso e muito utilizado nesse nıvel de detalhamento. O que se descreve e uma representacao
quase algorıtmica de como os modulos do sistema se comportam (casos de uso) e com quais
outros modulos (atores) se relacionam.
3.2.2 Descricao UML
A descricao UML e praticamente um detalhamento dos requisitos apresentados no
nıvel de especificacao, geralmente com o auxılio de uma ferramenta de modelagem com
suporte a linguagem UML. O sistema e modelado a partir de um conjunto de diagramas
24
comportamentais e estruturais que representam a sua funcionalidade e o comportamento.
Neste nıvel o que se obtem e um refinamento da especificacao que proporciona uma visao
geral e uma representacao mais detalhada do comportamento sistema. Por meio dessa
descricao e possıvel identificar provaveis erros de concepcao e conflitos futuros. A divisao
entre hardware e software, e a temporizacao tambem nao sao representados.
3.2.3 Especificacao Executavel
A especificacao executavel e a implementacao da descricao UML na linguagem de
descricao de hardware SystemC. O resultado obtido neste nıvel e um modelo funcional
e executavel dessa descricao que pode ser simulado. Esse nıvel de detalhamento permite
que problemas de execucao e de comportamento sejam identificados e solucionados. Este
e um nıvel de grande relevancia, pois e utilizado como base para o refinamento dos demais
e pode ser utilizado como referencia em qualquer plataforma de desenvolvimento adotada.
3.2.4 Fluxo de Dados (Data Flow - DF)
Neste nıvel de abstracao tambem se descreve as funcionalidade dos modulos do sistema,
porem, o que o difere dos demais vistos anteriormente e que o modelo agora apresenta de
forma clara a troca de mensagens entre modulos. Ele esta dividido em dois estagios. O
primeiro, caracterizado como “Untimed Data Flow” (UDF) descreve a funcionalidade do
modulo sem a nocao de temporizacao e o segundo, “Timed Data Flow” (TDF), descreve o
modulo em relacao ao tempo, com a insercao de atrasos temporais na sua implementacao.
Abaixo estao descritos em detalhes os dois estagios:
• UDF - Este estagio nao se utiliza de nenhum tipo de sinal de sincronismo ou qualquertipo de atraso temporal para sincronizar o modulo. O modelo de fluxo de dados ecompletamente orientado a eventos e o comportamento do modulo e verificado demaneira assıncrona, ou seja, cada acao dentro do mesmo ocorre apenas em decorrenciade estımulos gerados por eventos. Essa abordagem facilita a validacao do melhor
25
algoritmo funcional devido a eliminacao da preocupacao desnecessaria com detalhesde temporizacao. O projetista e obrigado a sincronizar os modulos somente com acoes(eventos), favorecendo (ou destacando) questoes diretamente ligadas a funcionalidade.
• TDF - O modelo de fluxo de dados temporizado tem capacidade para representara nocao de tempo. Agora existe a preocupacao com o sincronismo dos eventos edas operacoes realizadas pelo modulo no espaco de tempo, bem como os respectivosatrasos de processamento e de comunicacao. Por meio dela torna-se possıvel analisarcomo os efeitos de latencia poderiam influenciar no comportamento final do modulo,se realmente ele esta gerando as respostas de acordo com a especificacao dada ese os resultados esperados estao sendo realmente gerados em tempo habil para suavalidacao.
3.2.5 Descricao Comportamental
O nıvel Comportamental e uma descricao algorıtmica do comportamento do sistema.
Ele geralmente e descrito na forma de precisao de ciclos e ainda nao apresenta a estrutura
RTL esperada para a implementacao final. A principal diferenca entre esses dois nıveis,
Comportamental e RTL, esta relacionada com a temporizacao. Enquanto o RTL tem
sua sincronizacao definida em termos de ciclos de “clock”, o Comportamental e geralmente
sincronizado atraves da utilizacao de passos computacionais. Como exemplo, a sincronizacao
entre os processos de um sistema no nıvel Comportamental pode ser feita utilizando o
comando “wait”, cuja a funcao e aguardar ate que um evento (ou processo) seja concluıdo
antes de se passar ao proximo, ou inserindo atrasos temporais. As descricoes no nıvel
Comportamental sao compactas e mais faceis de entender do que descricoes em RTL. As
simulacoes tambem sao mais rapidas, devido ao nıvel de abstracao ser mais alto.
3.2.6 RTL
Segundo Jerraya [13] este nıvel de abstracao e visto como o ultimo na descricao do
projeto de hardware. E nele onde a maioria das ferramentas de sıntese trabalham. O
nıvel de detalhamento do modulo corresponde a sua sincronizacao atraves de sinais de
26
clock. Toda a comunicacao entre processos ocorre unica e exclusivamente atraves de
sinais. O comportamento, ou funcionalidade, e representado pelo fluxo dos dados atraves
de blocos funcionais (“datapath”) habilitados por sinais gerados pela unidade de controle,
geralmente implementada por maquina de estado finitas.
3.3 Fluxo de Projeto
A FIG. 3.4 abaixo resume o fluxo de projeto que representa a metodologia proposta.
Figura 3.4: Fluxo de Projeto proposto pela Metodologia
27
3.3.1 Analise de Requisitos
Inspirada nos conceitos utilizados no desenvolvimento de software, a analise de requisitos
tem como objetivo descrever o que o cliente espera que o sistema faca. Requisitos sao os
objetivos e as restricoes relacionados ao sistema que se pretende desenvolver. O projetista
deve ter em mente que esse conjunto de informacoes pode ser definido como uma condicao
ou uma funcao do SoC que sera responsavel pela resolucao de problemas previamente
especificados. A analise de requisitos esta dividida em dois grandes estagios. O primeiro
apresenta os metodos utilizados para se construir uma visao global do sistema enquanto
que o segundo especifica, detalha e prioriza as informacoes obtidas.
Visao Global
O objetivo desse estagio e a identificacao dos requisitos do SoC que se deseja desenvolver,
fornecendo todas as informacoes necessarias para o entendimento do projeto por parte do
desenvolvedor.
Abaixo estao enumeradas a sequencia de atividades que o projetista deve seguir a fim
de obter este documento:
1. Capturar o maximo de informacoes relevantes ao projeto por meio da entrevista como cliente;
2. Revisar e verificar se algum ponto deixou de ser identificado;
3. Classificar as informacoes em requisitos funcionais e nao-funcionais;
4. Organizar as informacoes em um documento relacionando os requisitos funcionais assuas respectivas restricoes;
O responsavel pela entrevista deve ter em mente, ou em forma de questionario, uma
lista de perguntas necessarias para se extrair o maior numero de informacoes possıveis
do projeto com o cliente. Deve-se preocupar em nao induzir o mesmo a tomar decisoes
influenciadas pelo conhecimento previo do entrevistador em relacao a implementacao do
projeto e as ferramentas que serao utilizadas. O responsavel deve fazer ainda uma rapida
28
revisao das questoes que foram abordadas e verificar se algum ponto importante para a
documentacao deixou de ser contemplado. A classificacao das informacoes obtidas deve
ser feita considerando os aspectos funcionais e nao-funcionais dos requisitos segundo as
descricoes abaixo:
• Requisitos Funcionais - descrevem a funcionalidade desejada do SoC. Deve-se
determinar o que se espera que o SoC faca sem a preocupacao de detalhar como isso
deve ser feito:
– “o SoC deve ser capaz de gerar imagens”;
– “o SoC deve ser capaz de comunicar com a interface do LCD”;
– “o SoC deve possibilitar a entrada de dados atraves de um teclado”;
– “o SoC deve possibilitar o calculo da soma de dois numeros reais”;
• Requisitos Nao-Funcionais - descrevem as restricoes impostas para a realizacao
de um requisito funcional:
– “a imagem deve ser do tipo bmp”;
– “a imagem nao deve ultrapassar a resolucao maxima de 800x600”;
– “a interface com o LCD deve utilizar o protocolo OCP-IP para comunicacao”;
– “o tempo de resposta do SoC ao teclado nao deve ultrapassar 10 ms”;
– “o SoC deve permitir a representacao de numeros reais com um maximo de 4casas decimais”;
– “o cronograma de desenvolvimento nao deve ultrapassar doze meses”;
A visao global e a etapa da analise de requisitos onde se definem exatamente quais sao
as principais funcionalidades do sistema.
Conforme apresentado anteriormente, o documento resultante desse estagio e composto
pelo conjunto de requisitos funcionais e suas respectivas restricoes. Cada funcionalidade
deve ser descrita de acordo com o modelo. (Ver FIG. 3.5)
29
Figura 3.5: Exemplo da organizacao das informacoes identificadas
Especificacao
Apos a etapa de visao global deve-se analisar os requisitos a fim de refina-los e estrutura-los
em um modelo que defina precisamente os atores e os casos de uso do sistema.
Por meio deste modelo e feita uma analise para identificar quais sao os pontos considerados
crıticos no desenvolvimento do projeto. O resultado e um documento composto pela analise
detalhada dos casos de uso e a descricao dos pontos crıticos do projeto.
Para a geracao do documento desta etapa o projetista devera seguir a sequencia de
tarefas a seguir:
1. Identificar os atores
O ator e qualquer entidade que interaja com o sistema na realizacao de uma tarefaou funcao. (modulos, 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 sequencia de eventos(acoes) que representa uma funcionalidade, ou seja, descreve uma tarefa a qual osistema dara suporte. A maioria dos requisitos funcionais listados na visao globalsao candidatos a se tornarem casos de uso. Exemplos: Gerar Imagem bmp e CalcularSoma de Numeros Reais
3. Detalhar os casos de uso
30
O projetista deve fazer uma analise e definir quais atores se relacionam com cadacaso. A partir dessa analise e possıvel detalhar a sequencia de eventos realizadapelo caso em relacao a seus respectivos atores (FIG. 3.6). Os requisitos funcionaisatendidos pelo caso tambem devem ser referenciados. Essa e uma forma de verificarse os requisitos solicitados pelo cliente estao 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 experiencia do projetista e possıvelselecionar (mensurar) quais sao aqueles com a pior relacao entre custo, tempo gastoe benefıcio em seu desenvolvimento. Esses casos terao prioridade sobre os outrosno decorrer do projeto e demandam atencao especial. O projetista deve descreverum documento apontando todas essas caracterısticas. O objetivo deste documentoe auxiliar os projetistas a tomarem decisoes nos refinamentos futuros tais como:(1) Utilizar ou nao um modulo pronto para determinada funcionalidade? (2) Odesenvolvimento deste modulo realmente vale o investimento? Todas essas observacoesdeverao ser feitas a tıtulo de comparacao.
3.3.2 Modelagem UML
Como SoCs sao 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, atraves de diagramas, um cenario muito proximo
da realidade, o que favorece um melhor entendimento do sistema. Neste fase o projetista
devera utilizar a ferramenta Umbrello para a modelagem. Como o “plug-in” SystemC para
Umbrello utiliza a propria notacao UML que esta descrita na ferramenta, nao e necessario
a criacao de estereotipos para a representacao de estruturas da linguagem alvo (SystemC).
A FIG. 3.7 abaixo apresenta as principais diferencas entre um modulo SystemC e uma
31
Classe UML modelados no Umbrello. O projetista deve ficar atento a esta comparacao.
Figura 3.7: Equivalencia entre as representacoes das classes do Umbrello - Modulo(SystemC) x Classe (UML)
Apenas tres dos diagramas da linguagem UML serao usados na modelagem proposta
na metodologia:
1. Casos de uso: Definicao da Funcionalidade e das Interfaces
Partindo dos documentos que foram obtidos na analise de requisitos o projetistadevera modelar primeiro o diagrama de casos de uso. Cada caso de uso descritotextualmente no estagio especificacao, da fase de analise de requisitos(FIGs. 3.8),equivale a um caso de uso do diagrama UML(3.9). Os atores que foram identificadosanteriormente tambem devem ser representados.
Figura 3.8: Caso de Uso Detalhado
32
Figura 3.9: Diagrama de Caso de Uso - Representacao Grafica
Posteriormente o diagrama deve ser refinado ate que o projetista identifique comclareza a funcionalidade do sistema. As interfaces de comunicacao tambem devemser modeladas como atores, evitando problemas com a falta de padronizacao entreos modulos e facilitando a sua visualizacao. A figura FIG. 3.10 abaixo apresenta umexemplo de como as interfaces devem ser modeladas no diagrama.
Figura 3.10: Interface - Exemplo de Modelagem
2. Diagrama de Sequencia : Definicao da sequencia de eventos
O diagrama de sequencia e necessario porque o diagrama de casos de uso nao e capazde representar nenhum tipo de temporalidade. Nao existe regra para a modelagemdeste diagrama. A unica restricao e a obrigatoriedade da descricao dos atores querepresentam interfaces no diagrama. O projetista deve se basear nas informacoesobtidas por meio da descricao e da modelagem previa do diagrama de casos de usopara representar a troca de mensagens e dados entre os modulos. Tanto atores
33
quanto casos podem se transformar em componentes do diagrama. A FIG. 3.11abaixo apresenta a troca de mensagens entre duas entidades, Rede “on-chip” e GerarImagem.
Figura 3.11: Exemplo de um Diagrama de Sequencia
As mensagens representadas entre os objetos definem uma cronologia de eventosatraves da numeracao, em ordem crescente, e atraves da posicao da mensagem. Asmensagens nas posicoes inferiores do diagrama ocorrem posteriormente as mensagenssuperiores.
3. Diagrama de Classes: Definicao da Estrutura
Diagrama de Classes e responsavel pela representacao e descricao da arquitetura (ouestrutura) do sistema. Similar ao diagrama de blocos, ele consegue demonstrar deforma intuitiva, como os modulos estao distribuıdos e como eles se relacionam. Noentanto ele nao implica em um tipo especıfico de implementacao final do SoC.
A FIG. 3.12 apresenta um exemplo de diagramas de classes retirado do proprio estudode caso.
34
Figura 3.12: Exemplo de um Diagrama de Classes
3.3.3 Descricao UML (Umbrello) para SystemC
O “plug-in” SystemC para Umbrello suporta todos os tipos de dados padrao da linguagem.
Esse suporte e habilitado assim que a opcao de linguagem SystemC e ativada no menu
“Code/Active Language”. A FIG. 3.13 apresenta a tela de definicao de “ports” e “inter-
faces” na qual o tipo de dado deve ser selecionado.
35
Figura 3.13: Tipos Padrao do SystemC no Umbrello
Apos a modelagem, o projetista devera primeiramente selecionar a linguagem padrao,
no caso SystemC (Ver FIG. 3.14), por meio do menu “Code/Active Language”.
Figura 3.14: Menu de Selecao de linguagem ativa
Para a geracao do codigo esqueleto ele devera acessar o menu “Code/Code Generation
Wizard” e selecionar as classes (modulos) que ele deseja converter (FIG. 3.15). Note que
a linguagem padrao continua sendo a selecionada (SystemC).
36
Figura 3.15: Menu de Selecao de Classes do “Code Generation Wizard”
3.3.4 Implementacao da funcionalidade do processo
Como a metodologia nao preve a geracao automatica da funcionalidade do processo,
o projetista devera implementar todos os processos que foram definidos na modelagem.
Para isso ele devera acessar o arquivo com a extensao (“.h”) e preencher a lacuna entre as
chaves do processo definido abaixo das interfaces, conforme o trecho de codigo apresentado
abaixo COD. 3.1.
Codigo Fonte 3.1: Codigo Esqueleto - Indicacao de onde deve ser implementada a
funcionalidade do Processo
1 #ifndef CONTROLADORH
2 #define CONTROLADORH
3 #include <systemc . h>
4
5 template <class T> SC MODULE( Controlador ) {
37
6
7 s c f i f o o u t <T> end ;
8
9 void proce s s ( ) {
10
11 // Implemente a func i ona l i dade do processo aqui !
12
13 }
14
15 SC CTOR( Controlador ) { SC THREAD( proce s s ) ; }
16 } ;
17 #endif //CONTROLADORH
3.3.5 Modulo funcional executavel
Embora nao apresente qualquer tipo de funcionalidade, o codigo apresentado na secao
anterior (COD 3.1) e executavel. Isso e possıvel devido a ferramenta gerar uma estrutura
de codigo “correta” capaz de ser interpretada pelo compilador sem erros.
O projetista devera implementar as funcionalidades dos processos definidos, construir
as ligacoes dos modulos no “main” e simular o modelo de acordo com as instrucoes da
linguagem SystemC, ou seja, fazendo uso de benchmarking3 para validacao dos modulos.
Os modulos que estao sendo avaliados necessitam de uma carga inicial de entrada de
dados para serem estimulados. Durante a simulacao utiliza-se um modulo monitor para a
visualizacao e armazenamento dos resultados.
Terminada a simulacao e feita uma comparacao dos resultados obtidos com os resultados
esperados. Se os resultados obtidos estiverem de acordo com os esperados o modulo e
validado como funcional.
3Processo sistematico e contınuo de avaliacao dos produtos, servicos e processos de trabalho
38
O estudo de caso a seguir apresenta detalhes para a interconexao dos modulos no arquivo
“main”.
39
Capıtulo 4
Estudo de Caso
O presente estudo de caso tem como finalidade demonstrar a maneira correta da
aplicacao da metodologia. As secoes deste capitulo apresentam a sua aplicacao no projeto
de concepcao e validacao de um gerador de caracteres para um “display” de vıdeo. O
produto final deste estudo de caso apresenta uma especificacao executavel 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 visao da metodologia proposta para o
projeto de SoCs. Essas fases estao divididas de acordo com a descricao apresentada no
capıtulo 3. Nelas estao descritas informacoes de como utilizar a metodologia, em conjunto
com as ferramentas adequadas, para se obter um melhor resultado. A secao 4.1 apresenta
o detalhamento da Analise de Requisitos do Gerador de Caracteres. A secao 4.2
apresenta como deve ser feita a modelagem UML de acordo com a descricao da metodologia
e utilizando os recursos dos diagramas UML apresentados, na secao 4.3 e apresentada a
maneira correta para se fazer a traducao destes modelos (em UML) para o codigo SystemC
utilizando o “plug-in” que foi desenvolvido. A secao 4.4 descreve o como gerar o modelo
funcional executavel do SoC e como devemos interconectar seus modulos.
40
4.1 Analise de Requisitos
Conforme visto na descricao da metodologia, a etapa de Analise de Requisitos e a
responsavel pela captura das funcionalidades e das restricoes do projeto de sistema que
se deseja desenvolver, no caso deste trabalho, um Gerador de Caracteres. Dividida
em duas etapas, Visao Global e Especificacao, a Analise de Requisitos procura resumir
em documentos, todas as caracterısticas funcionais e nao-funcionais do projeto, alem de
identificar os principais atores do sistema.
4.1.1 Visao Global
Em um primeiro momento, o projetista responsavel (ou a equipe) deve se preocupar
em reunir o maior numero de informacoes relevantes sobre o SoC com o cliente ou mesmo
atraves de pesquisas. As informacoes contidas no documento devem estar diretamente
ligadas a todo e qualquer tipo de requisito, sendo ele funcional ou nao. A ordem em
que a captura e feita nao tem relevancia. O objetivo principal desta etapa e detalhar,
atraves dos requisitos, todas as funcionalidades do SoC que se deseja desenvolver. Uma
vez capturadas, as informacoes 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 relacao direta com o projeto do Gerador de
Caracteres.
Gerador de Caracteres - Requisitos capturados:
1. O modulo deve ser capaz de enviar caracteres para um “display” de vıdeo;
2. O modulo deve ser capaz de converter um codigo ASCII para o padrao de visualizacaodo “display” de vıdeo;
3. O “display” devera receber dados dos caracteres da linha de forma serial;
4. O modulo deve permitir a visualizacao de caracteres maiusculos e minusculos;
41
5. O modulo deve permitir a visualizacao de espacos (incluıdo apos a revisao);
6. Os caracteres deverao ser armazenados em memoria;
7. Os caracteres serao representados atraves do codigo ASCII;
8. Cada endereco de memoria equivalera a um codigo ASCII em particular;
9. O modulo deve ser capaz de ler um caractere armazenado memoria;
10. O “display” ou monitor tera a resolucao padrao de uma imagem no formato QCIF(176Cx144L)- Detalhado no padrao H.261 de compressao de vıdeo;
11. O memoria deve ser capaz de armazenar uma tela completa;
12. O modulo deve ser capaz de gerar um quadro completo (ou varredura vertical) do“display”;
13. O modulo devera controlar os sinais de vıdeo necessarios para o funcionamento do“display”;
14. O modulo devera gerar o sinal de sincronismo horizontal (incluıdo apos a revisao);
15. O modulo devera gerar o sinal de sincronismo vertical (incluıdo apos a revisao);
16. O modulo devera gerar o sinal de retraco horizontal (incluıdo apos a revisao);
17. O modulo devera gerar o sinal de retraco vertical (incluıdo apos a revisao);
18. O modulo devera formar uma linha de caracteres por vez (incluıdo apos a revisao);
19. O modulo devera ser capaz de transformar um codigo ASCII em uma matriz depontos (pixels) 8x8 (incluıdo apos a revisao);
No primeiro documento obtido nem sempre se consegue alcancar o objetivo, que e
descrever todas as funcionalidades e restricoes. Apos uma rapida revisao foi possıvel
identificar que alguns requisitos nao haviam sido abordados. Esses requisitos foram incluıdos
apenas para conhecimento do leitor, mesmo sendo uma informacao desnecessaria ao projeto.
Os requisitos relevantes devem constar nesta lista, mesmo que o projetista somente os
identifique algumas etapas adiante.
A tarefa apos a definicao da lista de requisitos e a de classificacao. Todo e qualquer
requisito foi classificado como requisito funcional ou nao-funcional. A secao 3.3.1 descreve
as informacoes necessarias para auxiliar o projetista durante esta tarefa.
42
O segundo documento e praticamente a mesma lista apresentada no primeiro, porem
com a adicao de um campo contendo a classificacao de cada requisito (FIG. 4.1).
Gerador de Caracteres - Classificacao dos Requisitos
Figura 4.1: Classificacao dos Requisitos em funcionais e nao-funcionais
Apos a classificacao deve-se separar cada requisito de acordo com a sua caracterizacao,
formando dois grandes grupos, o primeiro contendo os requisitos classificados como funcionais
e o outro contendo os nao-funcionais. Deve-se tambem colocar um identificador para
diferenciar futuramente cada requisito, sendo ele funcional ou nao.
No caso do Gerador de Caracteres foram utilizados os codigos RF-xxx para identificar
os requisitos funcionais (ex. RF-001 - Requisito Funcional 1) e RNF-xxx para identificar
os nao-funcionais (ex. RNF-001 - Requisito Nao-Funcional 1). Essa e a descricao que
caracteriza as informacoes contidas no terceiro documento da visao global, veja classificacao
abaixo:
Gerador de Caracteres - Separacao e Identificacao
• Funcionais :
– RF-001: “O modulo deve ser capaz de ler um caractere armazenado”;
43
– RF-002: “O modulo deve ser capaz de converter um codigo ASCII para o padraode visualizacao do “display” de vıdeo”;
– RF-003: “O modulo deve ser capaz de enviar caracteres para um “display” devıdeo”;
– RF-004: “O modulo devera controlar os sinais de vıdeo necessarios para ofuncionamento do “display””;
• Nao-funcionais:
– RNF-001: “Os caracteres deverao ser armazenados em memoria”;
– RNF-002: “Os caracteres serao representados atraves do codigo ASCII”;
– RNF-003: “Cada endereco da memoria equivalera a um codigo ASCII em particular”;
– RNF-004: “O “display” de vıdeo tera a resolucao padrao de uma imagem noformato CIF(352Cx288L) - Detalhado no padrao H.261 de compressao de vıdeo”;
– RNF-005: “O memoria deve ser capaz de armazenar uma tela completa”; (RequisitoExtra)
– RNF-006: “O “display” devera receber dados dos caracteres da linha de formaserial”;
– RNF-007: “O modulo deve permitir a visualizacao de caracteres maiusculos eminusculos”;
– RNF-008: “O modulo deve permitir a visualizacao de espacos”;
– RNF-009: “O modulo deve ser capaz de gerar um quadro completo (ou varreduravertical) do “display””;
– RNF-010: “O modulo devera gerar o sinal de sincronismo horizontal”;
– RNF-011: “O modulo devera gerar o sinal de sincronismo vertical”;
– RNF-012: “O modulo devera gerar o sinal de retraco horizontal”;
– RNF-013: “O modulo devera gerar o sinal de retraco vertical”;
– RNF-014: “O modulo devera enviar uma linha de caracteres por vez”;
– RNF-015: “O modulo devera ser capaz de transformar um codigo ASCII emuma matriz de pontos (pixels) 8x8”;
Classificados e devidamente identificados, o projetista deve relacionar os requisitos
nao-funcionais e funcionais entre eles. Uma restricao, ou requisito nao-funcional, pode
estar diretamente relacionada com uma funcionalidade (requisito funcional). Isso nao e
regra, algumas restricoes podem estar relacionadas a outros fatores, como por exemplo o
tempo de projeto.
44
O quarto e ultimo documento da visao global deve descrever essas relacoes de forma
clara. Dependendo do projeto, deve-se construir o modelo ou o documento que sera
utilizado para essa relacao. A metodologia sugere um modelo de fichas, pois e bastante
funcional e simples. Cada ficha e responsavel pela descricao de uma funcionalidade e suas
respectivas restricoes. O projetista, no ato de preenchimento das fichas com as relacoes,
deve identificar o impacto gerado por cada restricao no projeto. As FIGs. 4.2, 4.3, 4.4 e
4.5 compoem o documento final desta etapa.
Gerador de Caracteres - Organizacao final (Visao Global):
Figura 4.2: Requisito Funcional 001
45
Figura 4.3: Requisito Funcional 002
Figura 4.4: Requisito Funcional 003
46
Figura 4.5: Requisito Funcional 004
4.1.2 Especificacao
A especificacao consiste na analise do documento que foi obtido na Visao Global. Esta
etapa tem com o objetivo de identificacao dos atores e dos casos de uso que farao parte do
sistema. Como dica, pode-se afirmar que os requisitos funcionais sao grandes candidatos
a se tornarem casos de uso e suas restricoes podem conter indıcios dos provaveis atores.
Os conceitos e detalhes a respeito de atores e casos de uso estao descritos na metodologia,
secao 3.3.1.
O primeiro documento deste estagio e uma lista com a descricao dos atores e dos casos
de uso identificados para o projeto do Gerador de Caracteres.
• Gerador de Caracteres - Atores identificados:
– Memoria
– Display
– Interface
– ROM de caracteres
47
• Gerador de Caracteres - Casos de uso identificados:
– Obter caractere da memoria
– Converter codigo ASCII em uma matriz de pontos
– Gerar sequencia de pixels para cada linha
– Gerar sinais de controle
A tarefa de detalhamento dos casos de uso consiste na descricao da sequencia de
eventos, realizada pelo caso e seus atores, que descreve determinada funcionalidade. Neste
documento, um pouco mais elaborado, deve-se relacionar os casos de uso identificados com
os respectivos atores, alem de apontar quais requisitos funcionais foram atendidos. Este
segundo documento da especificacao deve estar organizado como demonstra a FIG. 4.6
abaixo.
Gerador de Caracteres - Casos de uso detalhados:
Figura 4.6: Detalhamento dos Casos de Uso
Dentre todos os casos de uso descritos, o projetista deve selecionar aqueles considerados
crıticos para o desenvolvimento do projeto. Deve-se analisar a viabilidade da implementacao
destes casos, tanto em relacao ao custo quanto a sua complexidade e o tempo gasto para
48
implementa-lo. Quanto maior a experiencia do responsavel em projetos dessa grandeza,
maiores as possibilidades de sucesso na escolha dos casos realmente crıticos.
Os dois casos considerados crıticos no projeto do Gerador de Caracteres foram escolhidos
devido a sua complexidade de implementacao. Ainda assim, eles sao considerados viaveis
para o seu desenvolvimento no projeto.
Gerador de Caracteres - Casos de uso considerados crıticos:
• Gerar sequencia de Pixels para cada linha
• Gerar sinais de controle
4.2 Modelagem UML
A proxima etapa no projeto e a modelagem UML do Gerador de Caracteres na ferramenta
Umbrello. Deve-se fazer uso dos diagramas UML apontados na metodologia (Diagrama de
Casos de Uso, de Sequencia e de Classes).
4.2.1 Diagrama de Casos de Uso
O diagrama de casos de uso sera modelado utilizando como referencia os documentos da
Especificacao contidos na Analise de Requisitos. A primeira etapa consiste na modelagem
dos casos identificados. Eles sao representados na ferramenta atraves de um cırculo com o
nome do respectivo caso de uso. Se necessario, pode-se resumir os nomes de cada um, desde
que nao altere o seu sentido. Na segunda etapa deve-se modelar os atores, representados
pela linguagem UML por meio “bonecos”.
A ultima etapa a ser modelada sao os relacionamentos, tambem chamados de associacao.
O projetista deve relacionar os atores a seus respectivos casos. Deve-se ficar atento ao que
foi descrito no documento de detalhamento dos casos de uso (neste projeto representado
pela FIG. 26 da sessao 4.1.2).
49
Nota-se que em cada relacionamento do diagrama apresentado abaixo (FIGs. 4.7, 4.8, 4.9
e 4.10), existe um ator chamado “interface”. Ele representa o tipo de comunicacao que sera
implementada. Mesmo que ela ainda nao esteja definida, e obrigatoria a sua representacao,
pois alem de facilitar a visualizacao do projeto sera util nos nıveis de abstracao inferiores,
no qual sao implementadados os meios de comunicacao.
Figura 4.7: Caso de Uso - Obter Caracteres
Figura 4.8: Caso de Uso - Converter Codigo ASCII em Matriz de Pontos
50
Figura 4.9: Caso de Uso - Gerar Sequencia de Pixels
Figura 4.10: Caso de Uso - Gerar Sinais de Controle
Quanto maior o projeto, maior as chances de os casos de uso possuırem atores em
comum em seus relacionamentos. Esses casos devem ser analisados cuidadosamente. Se
existir alguma relacao entre eles, deve-se agrupa-los em unico caso, conforme e demonstrado
no diagrama de caso de uso abaixo do Gerador de Caracteres (FIG. 4.11).
51
Figura 4.11: Gerador de Caracteres - Diagrama de Caso de Uso
4.2.2 Diagrama de Sequencia
O Diagrama de Sequencia deve ser descrito com o objetivo de demonstrar a possıvel
comunicacao entre o SoC (Gerador de Caracteres) e os sistemas ou modulos que se relacionam
com ele. Todos os atores devem estar representados, inclusive as interfaces de comunicacao.
A troca de informacoes entre eles deve ser representada atraves de mensagens e elas devem
estar numeradas em ordem cronologica de acontecimento, pois esta e a forma utilizada
pelo diagrama para representar o momento em que uma determinada mensagem ocorre em
relacao as outras. O projetista deve rever este diagrama quantas vezes forem necessarias,
tentando representar da melhor maneira a funcionalidade que se deseja atingir.
52
Figura 4.12: Gerador de Caracteres - Diagrama de Sequencia
4.2.3 Diagrama de Classes
Tendo como base os diagramas anteriores, deve-se representar a estrutura final do
modulo. O diagrama de classes, muito parecido com o diagrama de blocos, deve ser
utilizado para esta finalidade. O projetista nao deve se preocupar ainda com os atributos
e operacoes que deveriam estar complementando as classes deste diagrama, pois isso sera
detalhado na proxima secao.
53
Figura 4.13: Gerador de Caracteres - Diagrama de Classes
4.3 Geracao do Codigo
Para este trabalho, desenvolveu-se um simulador de um display de vıdeo contendo
todos os sinais de sincronismo de um monitor CRT (Cathode Ray Tube) padrao o qual sera
apresentado na proxima secao (4.4), porem o escopo deste trabalho e o desenvolvimento
de um gerador de caracteres. Para a implementacao dos demais modulos, o projetista deve
ter em maos a referencia que informa quais serao os sinais e os tipos de dados que o SoC
em desenvolvimento ira controlar.
A ferramenta de traducao de codigo necessita que o projetista informe nos modulos
descritos no diagrama de classes quais serao as interfaces de comunicacao. Por mais simples
que possa parecer, esta e uma das tarefas mais complexas. Alem de utilizar todo o conceito
do projeto, que pode ser abstraıdo dos diagramas descritos nas etapas anteriores, deve-se ter
um mınimo de conhecimento previo da estrutura da linguagem (SystemC ) e dos processos
de desenvolvimento de SoC.
Como a metodologia abrange o nıvel de abstracao onde toda e qualquer informacao
54
(dados) e sincronizada por meio de “eventos”, deve-se utilizar somente FIFO’s (sc fifo in
e sc fifo out) como canais de comunicacao (“channels”) entre os modulos. A maneira
mais simples de identifica-los e atraves das informacoes contidas no diagrama de sequencia,
porem e aconselhavel que o projetista tambem faca um pequeno esboco, contendo o
diagrama de blocos referente ao projeto, descrevendo passo a passo a funcionalidade do
SoC como um todo.
A orientacao de cada mensagem no diagrama de sequencia pode informar o tipo de
interface que deve ser utilizada (entrada/saıda). Quando se identifica que uma mensagem
do diagrama e realmente um provavel “channel” a ser utilizado no projeto, deve observar
o sentido de orientacao das mensagens. O inıcio de uma seta indica que o modulo de onde
ela partiu possui uma interface de saıda (sc fifo out). A extremidade final da seta indica
que o modulo apontado possui uma interface do mesmo tipo de dados, porem de entrada
(sc fifo in), conforme podemos observar na FIG. 4.14.
Figura 4.14: Exemplo de msg no Diagrama de Sequencia - A Orientacao da seta podeindicar o tipo de interface entre modulos
O nome representado da mensagem no diagrama pode ajudar a definir o nome de
um “channel” que ira interconectar dois modulos. Para evitar erros em uma futura
interconexao destes modulos dentro do arquivo “main” e recomendado que se utilize o
mesmo nome de interface (reveja FIG. 4.14), lembrando que uma sera de entrada e a outra
de saıda.
55
Conforme foi visto, as etapas descritas nos paragrafos abaixo descrevem os passos
utilizados no estudo de caso para a definicao das interfaces dos modulos por meio da
analise do diagrama de sequencia (FIG. 4.12) da secao 4.2.2.
A primeira mensagem do diagrama, “1: Endereco”, , esta indicando um fluxo de dados
que vai do gerador de caracteres para a memoria. O projetista experiente logo ira
questionar onde e como esses enderecos serao gerados e/ou armazenados. Como nao foi
informado na especificacao o formato da entrada de dados, definiu-se que os enderecos
ficarao armazenados em outro modulo que sera definido na proxima secao (4.4). Isso
elimina a possibilidade de uma interface de saıda com este nome para o modulo gerador
de caracteres.
Mesmo que nao seja o gerador de caracteres o responsavel pelo envio dos enderecos,
eles ainda deverao ser recebidos na memoria. Conforme a descricao, ela e a responsavel
pelo armazenamento dos codigos ASCII que serao representados no display. A partir dessa
informacao obtem-se a primeira interface de entrada, chamada de “end” (abreviacao de
“endereco”). Ela devera ser incluıda no modulo que representa a memoria no diagrama
de classes como “sc fifo in<T>end”. Para inserir uma interface em um modulo do
diagrama de classes basta clicar com o botao direito do mouse e acessar propriedades.
Clique em atributos na tela a esquerda e insira um novo atributo. Selecione a interface
sc fifo in<T> em tipo e forneca o nome “end” no formulario (FIG. 4.15).
56
Figura 4.15: Umbrello - Adicionando interfaces aos modulos
A mensagem “2: ASCII” - indica uma funcionalidade que foi descrita na especificacao.
Apos o fornecimento de um endereco, a memoria envia uma mensagem contendo o codigo
ASCII de um caractere para que o gerador de caracteres construa sua matriz de pixels.
Esta mensagem caracteriza um “channel” entre a memoria e o gerador de caracteres. As
interfaces que constituem este “channel” sao: ASCII de saıda na memoria e ASCII de
entrada no gerador de caracteres (“sc fifo out<T>ASCII”, “sc fifo in<T>ASCII”).
Mensagem “3: ASCII” - Como a ROM de caracteres armazenas todos os codigos que
constituem a tabela ASCII, o gerador de caracteres necessita transformar o codigo recebido
da memoria (ASCII ) em um endereco valido que possa ser lido na ROM. Alem disso, se
fosse utilizado o nome “ASCII” para representar este “channel”, terıamos duas interfaces
de mesmo nome no modulo gerador de caracteres, uma de entrada, recebendo dados da
memoria e outra de saıda, enviando dados para a ROM. Por esse motivo utilizou-se “ad-
dress” ao inves de “ASCII” para representar este “channel”. Ele e composto pelas seguintes
57
interfaces: “address” de saıda do gerador de caracteres e “address” de entrada na ROM
de caracteres.
Mensagens “4: Matriz de Pontos”, “5: Armazena Linha de Caracteres” e “6: Sequencia
de Pixels” - O gerador de caracteres, segundo a especificacao, e o responsavel pela formacao
da linha a ser enviada ao display. Para manter essa afirmacao o modulo deveria ser
capaz de armazenar uma grande quantidade de linhas a serem mostradas. Isso somente
seria possıvel se fosse introduzido um buffer (area de armazenamento) dentro do proprio
modulo, e ele deveria ser capaz de realizar escrita e leitura simultaneas, aumentando a
complexidade de implementacao. Para facilitar o desenvolvimento e evitar erros, optou-se
pelo desenvolvimento de um modulo com esta funcao de armazenamento de linhas e quadros
separadamente. A funcionalidade da ROM foi mantida, porem ela nao retornara a linha
de pixels para o gerador de caracteres e sim para um modulo de armazenamento. Para
este estudo de caso definiu-se que a representacao de cada codigo ASCII sera realizada
por meio de uma matriz de pixels 8x8 de zeros(0) e um(1). Estes valores sao responsaveis
pela representacao da forma, ou seja, desenho de cada caractere no display como mostra a
FIG. 4.16.
Figura 4.16: Representacao do caractere ASCII “u” na ROM
Para este modulo o nome dado a interface de saıda foi “character line”. Como cada
linha de um caractere possui 8 pontos e cada ponto pode representar apenas 0 (zero) ou
1 (um), o tipo escolhido foi o sc bv<8>(Bit value de tamanho 8). Este tipo armazena
58
apenas zeros e 1(um) e permite operacoes com outros tipos padrao do SystemC.
A ultima mensagem restante, “6: Sinais de Controle”, acontece simultaneamente com a
mensagem “6: Sequencia de Pixels” ja apresentada. Devido a complexidade e quantidade
de sinais de controle necessarios ao funcionamento correto do display, chegou-se a decisao
que este tambem deveria ser um modulo a parte. Esta mensagem nao representa um tipo
isolado de interface, mas diversas.
A memoria por si mesma nao define automaticamente uma area de armazenamento.
Para armazenar os caracteres ASCII que serao lidos atraves da interface “end” criou-se um
buffer unidimensional de inteiros de 32 bits, de tamanho ainda a ser definido no “main”
(sc int<32>buffer[TAMBUFFER]).
Em cada modulo adicionou-se um processo. Ele e o responsavel pela descricao da
funcionalidade de cada modulo em particular. O metodo de implementacao dessa funcionalidade
sera descrita na proxima secao. Para adicionar um processo ao modulo, acesse “propriedades”
e clique em “operations”. Preencha o formulario com o nome do processo e clique em OK.
Este processo e similar a adicao de interfaces. Utilize como referencia a FIG. 4.15.
A FIG. 4.17 abaixo apresenta o resultado do diagrama de classes contendo todos os
modulos e suas respectivas interfaces.
59
Figura 4.17: Diagrama de Classes - Definicao das interfaces
Esta etapa deve ser refeita quantas vezes forem necessarias. Para gerar o codigo Sys-
temC por meio da ferramenta acesse o “code generation wizard” no menu “code”. Antes,
verifique se a linguagem SystemC esta configurada como padrao no menu “code/active
language”.
60
Figura 4.18: Umbrello - Acesso ao gerador de codigo (“Code Generation Wizard”)
Selecionar as classes que contem interfaces para a geracao do codigo e clicar em “next”.
Figura 4.19: Umbrello - Selecao de Modulos para a Geracao de codigo SystemC
Indicar o caminho onde o codigo SystemC sera gravado em “write all generated files
to folder”. Indicar o caminho do cabecalho dos arquivos fontes “include heading files from
folder”. Clicar em “next”.
61
Figura 4.20: Umbrello - Indicacao do local de gravacao dos arquivos fonte e leitura docabecalho
Os modulos selecionados serao mostrados com a informacao de que ainda nao foram
gerados (“Not Yet Generated”) .
Figura 4.21: Umbrello - Aguardando a confirmacao para gerar o codigo
Clicar em “Generate”. A tela ira confirmar a geracao do codigo com “Code Generated”.
62
Figura 4.22: Umbrello - Codigo gerado com sucesso
Na pasta onde os fontes foram gravados, deve-se descartar os arquivos com a extensao
“*.sc”. Para cada um dos modulos havera um arquivo de extensao “*.h” contendo o codigo
SystemC.
4.4 Modelo Executavel
O codigo gerado pela ferramenta encontra-se nos anexos deste trabalho com o tıtulo de
codigo esqueleto. O projetista deve acessar cada modulo e implementar o codigo na area
definida, linha numero 12 do COD. 4.1 abaixo.
Codigo Fonte 4.1: Gerador de Caracteres - Codigo Esqueleto gerado pela ferramenta
1 #ifndef GERADOR DE CARACTERES H
2 #define GERADOR DE CARACTERES H
3 #include <systemc . h>
4
5 template <class T> SC MODULE( Gerador de Caracteres ) {
6 s c f i f o i n <T> ASCII ;
7 s c f i f o o u t <T> address ;
63
8
9
10 void proce s s ( ) {
11
12 // Implemente a func i ona l i dade do processo aqui !
13
14 }
15 SC CTOR( Gerador de Caracteres ) { SC THREAD( proce s s ) ; }
16 } ;
17 #endif //GERADOR DE CARACTERES H
Todas as informacoes descritas na secao anterior (4.3) auxiliaram na definicao da
funcionalidade dos processos dos modulos. Sera apresentado apenas uma explicacao linha
a linha da definicao da funcionalidade do processo do gerador de caracteres (COD. 4.2). A
implementacao completa do projeto pode ser encontrada para consulta no apendice, com
o nome de codigo funcional.
Codigo Fonte 4.2: Gerador de Caracteres - Implementacao da funcionalidade do processo
1 void proce s s ( ) {
2
3 while (1 ) {
4 wait (CB CLOCK) ;
5 T ASCII value = ASCII . read ( ) ;
6 T addre s s va lue ;
7 for (T s c an l i n e v a l u e = 0 ; s c an l i n e v a l u e < 8 ;
s c a n l i n e v a l u e++) {
8 addre s s va lue = ASCII value ∗ 8 + s c an l i n e v a l u e ;
9 cout << "tempo = " << sc t ime stamp ( ) ;
10 cout << " address = " << addre s s va lue << endl ;
11 address . wr i t e ( addre s s va lue ) ;
12 CG CLOCK. no t i f y ( ) ;
64
13 }
14 }
15
16 }
Abaixo temos a descricao, linha por linha, das funcoes e comandos utilizados para a
implementacao do processo:
1. Linha 3
O sincronismo dos modulos acontece somente atraves da notificacao de eventos. O
“while(1)” garante que o processo vai executar durante todo o processo de simulacao,
mas ele apenas sera ativado com a notificacao da ocorrencia de um evento.
2. Linha 4
O comando “wait” esta aguardando o evento, CB CLOCK, ser notificado por outro
modulo. Neste caso, a memoria e a responsavel pela informacao de que o dado, ASCII,
esta pronto para ser lido. Todos os eventos estao definidos no arquivo “main.cpp”.
3. Linha 5
Le a informacao da interface e armazena localmente no modulo.
4. Linha 6
E uma variavel local que foi criada para armazenar o “address” que sera enviado a
ROM de caracteres.
5. Linha 7
A ROM de caracteres armazena uma matriz de pontos 8x8 de cada caractere. Para
cada ASCII recebido, o gerador de caracteres precisa ler as oito linhas que estao
armazenadas.
65
6. Linha 8
Os enderecos na ROM estao alocados unidimensionalmente e linha a linha, ou seja,
cada caractere ocupa oito posicoes. A equacao permite a leitura exata de cada linha.
Ex.: O ASCII 85, caractere “u”. Ocupa as posicoes 680 a 687 da ROM.
7. Linha 9
Funcao para verificar em que tempo esta ocorrendo a leitura (Debug).
8. Linha 10
Funcao para verificar se o “address” esta sendo passado corretamente (Debug).
9. Linha 11
Escreve o “address” na interface de saıda para a ROM de caracteres.
10. Linha 12
Linha 12: Utiliza este evento para notificar que o dado agora esta disponıvel. A ROM
utiliza este evento para saber que o dado esta pronto para leitura.
4.5 Teste e Validacao
Para que um SoC seja simulado em SystemC e preciso definir um modulo para a geracao
de dados de entrada (E. - “Estimulo”) e outro para a visualizacao dos resultados(M.
- “Monitor”). A FIG. 4.23 abaixo apresenta a forma correta para se validar um modulo
quando nao se tem uma referencia, para fins comparativos, do proprio modelo.
66
Figura 4.23: Teste e validacao do Modelo de Referencia
Primeiramente cria-se um vetor de teste onde as saıdas sao conhecidas. No projeto do
gerador de caracteres foi criado um vetor de numeros inteiros, contendo 4 posicoes para
abrigar os seguintes caracteres ASCII: 85 (“u”), 70 (“f”), 77(“m”) e 71(“g”). Posteriormente
o projetista deve implementar no monitor a visualizacao dos dados de forma que se
possa comparar com o resultado esperado, caracterizando assim um “benchmark”, onde os
dados (ou cargas) de entrada e de saıda sao conhecidos. Para o SoC em desenvolvimento
utilizou-se um simulador de display e o GTKWave para a visualizacao dos sinais em forma
de onda.
Por este motivo definiu-se que os enderecos enviados para memoria seriam gerados por
um outro modulo que nao fosse o proprio gerador de caracteres. Nao e aconselhavel que o
modulo principal do projeto seja tambem seu proprio fornecedor de dados. A este modulo
deu-se o nome de “controlador”(ver anexos).
Os demais modulos citados anteriormente (secao 4.3) estao na descricao seguinte:
67
• Refresh Mem - Modulo responsavel pelo armazenamento das linhas e dos quadros
a serem mostrados no “display”.
• Gerador de Sinais de Vıdeo - Modulo responsavel pela geracao dos sinais de
sincronismo do vıdeo
• Simulador de Vıdeo - Modulo responsavel pela simulacao do “display”
O arquivo para interconexao dos modulos foi chamado de “main.cpp”. Como o foco
deste trabalho nao e o aprendizado da programacao em linguagem SystemC, a implementacao
do mesmo, juntamente com os demais modulos, pode ser conferida nos anexos. No entanto,
formulou-se o COD. 4.3 abaixo como referencia para o projetista.
Codigo Fonte 4.3: Como construir um Programa principal “main.cpp” em SystemC
1 //INCLUIR A BIBLIOTECA PADRAO DO SYSTEMC
2 #include <systemc . h>
3
4 //INCLUIR AS DECLARACOES DOS MODULOS
5 #include "modulo1.h"
6
7 //INCLUIR AS DEFINICOES
8 #define DEFINICAO 01 100 , SC NS
9
10 //DECLARAR AS CONSTANTES
11 const int constante1 = 100 ;
12
13 //DECLARAR A FUNCAO PRINCIPAL ”MAIN”
14 int sc main ( int argc , char ∗agv [ ] )
15 {
16 //DECLARACOES DOS CANAIS ( Channels−> ” s c f i f o and s c s i g n a l ”)
17 //DECLARACOES DE VARIAVEIS ( ” s c b i t , s c i n t , . . . , e t c .” )
18 //DECLARACOES DAS INSTANCIAS DOS MODULOS
68
19 //CONEXOES DAS PORTAS DOS MODULOS
20 //DEFINICAO DO TEMPO DE SIMULACAO
21 //CONFIGURACAO DO ARQUIVO ”TRACEFILE”
22 //INICIAR A SIMULACAO ( ” s c s t a r t (TEMPO SIMUL)” )
23 return 0 ;
24 }
4.6 Resultados
Os resultados finais e os mais relevantes de cada etapa estao descritos novamente abaixo
como forma de simplificar a visualizacao do projeto.
Identificacao e Classificacao dos Requisitos
• Funcionais :
– RF-001: “O modulo deve ser capaz de ler um caractere armazenado”;
– RF-002: “O modulo deve ser capaz de converter um codigo ASCII para o padraode visualizacao do “display” de vıdeo”;
– RF-003: “O modulo deve ser capaz de enviar caracteres para um “display” devıdeo”;
– RF-004: “O modulo devera controlar os sinais de vıdeo necessarios para ofuncionamento do “display””;
• Nao-funcionais:
– RNF-001: “Os caracteres deverao ser armazenados em memoria”;
– RNF-002: “Os caracteres serao representados atraves do codigo ASCII”;
– RNF-003: “Cada endereco da memoria equivalera a um codigo ASCII em particular”;
– RNF-004: “O “display” de vıdeo tera a resolucao padrao de uma imagem noformato CIF(352Cx288L) - Detalhado no padrao H.261 de compressao de vıdeo”;
– RNF-005: “O memoria deve ser capaz de armazenar uma tela completa”; (RequisitoExtra)
– RNF-006: “O “display” devera receber dados dos caracteres da linha de formaserial”;
69
– RNF-007: “O modulo deve permitir a visualizacao de caracteres maiusculos eminusculos”;
– RNF-008: “O modulo deve permitir a visualizacao de espacos”;
– RNF-009: “O modulo deve ser capaz de gerar um quadro completo (ou varreduravertical) do “display””;
– RNF-010: “O modulo devera gerar o sinal de sincronismo horizontal”;
– RNF-011: “O modulo devera gerar o sinal de sincronismo vertical”;
– RNF-012: “O modulo devera gerar o sinal de retraco horizontal”;
– RNF-013: “O modulo devera gerar o sinal de retraco vertical”;
– RNF-014: “O modulo devera enviar uma linha de caracteres por vez”;
– RNF-015: “O modulo devera ser capaz de transformar um codigo ASCII emuma matriz de pontos (pixels) 8x8”;
Identificacao dos Casos e dos Atores
• Gerador de Caracteres - Atores identificados:
– Memoria
– Display
– Interface
– ROM de caracteres
• Gerador de Caracteres - Casos de uso identificados:
– Obter caractere da memoria
– Converter codigo ASCII em uma matriz de pontos
– Gerar sequencia de pixels para cada linha
– Gerar sinais de controle
70
Descricao do Diagrama de Caso de Uso
Figura 4.24: Resultados - Diagrama de Caso de Uso
71
Descricao do Diagrama de Sequencia
Figura 4.25: Resultados - Diagrama de Sequencia
72
Descricao do Diagrama de Classes
Figura 4.26: Resultados - Diagrama de Classes
A visualizacao dos resultados e feita de duas maneiras. A primeira e por meio do proprio
simulador de vıdeo que foi implementado e pode ser encontrado nos anexos (simulador video).
A segunda, e atraves da visualizacao das formas de ondas geradas pelo arquivo “tracefile”
definido no “main”. O arquivo com extensao “*.vcd” (“Value Change Dump”) gerado
pode ser visualizado no programa “GTKWave”, de licenca publica (“GNU - General Public
License”).
A FIG. 4.27 abaixo apresenta a tela resultado da simulacao do gerador de caracteres
em conjunto com o simulador de vıdeo.
73
Figura 4.27: Resultado - Quadro gerado pelo simulador de vıdeo
Observe que o caractere “-” no simulador representa o pixel apagado e o caracter
“w” representa o pixel aceso. A memoria do gerador de caracteres foi preenchida com os
caracteres ASCII que formam a palavra “ufmg”.
Para fins de teste, definiu-se que a tela suportaria 4 linhas x 8 colunas de caracteres.
Como cada caractere e representado por uma matriz de pontos 8x8, entao o simulador de
vıdeo implementa um quadro que contem 32x64 pontos. O sincronismo de cada quadro do
“display” pode ser conferido na FIG. 4.28 abaixo.
Figura 4.28: Resultado - Formas de onda referente aos sinais de sincronismo do vıdeo
A varredura horizontal (“HSYNC”) somente e ativada apos a varredura de todas as
colunas da linha (“PX COL”), 64 pontos. A varredura vertical(“VSYNC”) somente e
74
ativada apos a varredura horizontal de todas as 32 linhas de pontos (“PX LINE”), formando
assim um quadro completo para a visualizacao na tela.
75
Capıtulo 5
Conclusao
O presente trabalho apresentou uma visao geral (overview) das mais recentes pequisas
em desenvolvimento de projeto de SoC’s, das propostas de novas metodologias de projeto
e das ferramentas de geracao de codigo SystemC. Demonstrou tambem a necessidade e a
importancia de novas metodologias serem continuamente propostas.
A contribuicao cientıfica deste trabalho pode ser resumida em dois aspectos principais:
a proposta de uma nova metodologia de desenvolvimento de SoC’s a partir de descricoes
UML e a ferramenta para traducao de codigo executavel para SystemC, ambas validadas
funcionalmente por meio do estudo de caso apresentado (capıtulo 4).
A metodologia proposta (capıtulo 3) teve como fator principal de motivacao a necessidade
de diminuicao no tempo gasto durante as fases de concepcao e validacao do projeto.
O desenvolvimento do “plug-in” UML-SystemC foi motivado, alem da importancia da
documentacao e organizacao das informacoes, pela necessidade de criacao de uma ferramenta
que desse suporte ao projetista desde a fase de concepcao ao primeiro modelo executavel do
projeto. Nao menos importante dos que os fatores citados e o fato dela ter sido desenvolvida
a partir de um software livre e de codigo aberto, o que permitira o seu aprimoramento por
meio do auxilio da comunidade, podendo ate surgir uma versao livre para outros sistemas
76
operacionais disponıveis.
O autor, por meio da experiencia adquirida como monitor da linguagem SystemC no
Laboratorio de Sistemas Computacionais Integrados (LABSCI) do CPDEE, afirma que
existe uma grande dificuldade por parte dos novos projetistas de SoC em desenvolver
especificacoes executaveis para novos projetos. A maioria parte diretamente para programacao,
sem qualquer tipo de documentacao e/ou esboco do que se pretende implementar. Frequentemente
refazem o mesmo trabalho varias vezes ate conseguir resultados na simulacao, isso quando
realmente conseguem.
Embora o trabalho nao apresente resultados com fins comparativos, o objetivo principal,
de diminuicao no tempo gasto ate a primeira especificacao executavel foi alcancado. A
ferramenta que foi desenvolvida, alem de diminuir o tempo de desperdicado por um projetista
de SoC’s na programacao do codigo, diminui tambem o tempo gasto no aprendizado da
linguagem. A geracao de codigo automatizado diminui os riscos de erros de sintaxe na
compilacao do codigo gerado. Pode-se dizer tambem que a metodologia proposta obriga
o projetista a trabalhar no nıvel mais alto de abstracao suportado pela linguagem, bem
acima do RTL, facilitando a implementacao e consequentemente diminuindo mais uma vez
o tempo de programacao.
As limitacoes da ferramenta foram os fatores principais de motivacao para a listagem
de trabalhos futuros abaixo:
• Avaliacao da metodologia proposta em um numero maior de projetos relacionados
ao desenvolvimento de SoC ;
• Avaliacao e comparacao do desempenho da ferramenta em diferentes tipos de projetos
de SoC ;
• Acrescentar novos recursos a ferramenta: (i) automatizar o processo de interconexao
entre os modulos dentro de um arquivo “main.cpp”; (ii) permitir a descricao comportamental
77
dos modulos; (iii) permitir que a simulacao SystemC seja iniciada no proprio Umbrello;
(iv) automatizar o processo de geracao de vetores de teste; (v) utilizar o diagrama
de transicao de estados para tentar abstrair a funcionalidade dos processos;
Como contribuicao final, podemos pensar ainda em uma ferramenta capaz de gerar
descricoes RTL sintetizaveis diretamente para FPGA partindo de uma modelagem em alto
nıvel. Porem, o contexto de projeto de hardware ainda precisa estar bem definido em
uma ferramenta de modelagem visual que tenha robustez suficiente para representar toda
e qualquer estrutura e/ou comunicacao entre hardware e software de forma transparente
para o projetista.
78
Referencias Bibliograficas
[1] OMG Architecture Board. Model Driven Architecture (MDA). Technical Report
ormsc/2001-07-01, OMG, (2001).
[2] Arnout, G. Eda moving up, again! 6th European SystemC Users Group (2002).
[3] Bhasker, J. A SystemC Primer. Star Galaxy Publishing, 2002.
[4] Booch, G. Object-Oriented Analysis and Design with Applications (3rd Edition).
Addison Wesley Longman Publishing Co., Inc., Redwood City, CA, USA, 1994.
[5] Dumoulin, C., Boulet, P., Dekeyser, J., and Marquet, P. Mda for soc
design, intensive signal processing experiment. Forum on Design Languages (FDL’03),
Frankfurt am Main, Germany (2003).
[6] Dumoulin, C., Boulet, P., Dekeyser, J., and Marquet, P. Uml 2.0 structure
diagram for intensive signal processing application specication. Tech. rep., INRIA,
March 2003. Research Report RR-4766.
[7] Edwards, S., Lavagno, L., Lee, E. A., and Vincentelli, A. S. Design of
embedded systems: Formal models, validation and synthesis. Proceedings of the IEEE
(1997), pages 366–390.
[8] Gajski, D. D., and Kuhn, R. Guest editor introduction: New vlsi-tools. IEEE
Computer (December 1983).
79
[9] Grotker, T., Liao, S., Martin, G., and Swan, S. System Design with SystemC.
Kluwer Academic Publishers, 2002.
[10] Hammond, L., Nayfeh, B. A., and Olukotun, K. A single-chip multiprocessor.
IEEE Computer (September 1997), pages 79–85.
[11] Harel, D., and Naamad, A. The statemate semantics of statecharts. ACM Trans.
Softw. Eng. Methodol. 5, 4 (1996), 293–333.
[12] Jacobson, I. Object-Oriented Software Engineering: A Use Case Driven Approach.
Addison Wesley Longman Publishing Co., Inc., Redwood City, CA, USA, 1992.
[13] Jerraya, A. A., Svarstad, K., Ben-Fredj, N., and Nicolescu, G. A higher
level system communication model for object-oriented specification and design of
embedded systems. In: Conference on Asia South Pacific Design Automation Con-
ference - ASPDAC (2001), 69–77.
[14] Lavagno, L., Martin, G., and Selic, B. UML for Real: Design Embedded Real-
Time Systems. Kluwer Academic Publishers, Norwell, MA, 2003.
[15] Micheli, G. D., and Benini, L. Network on chips: A new soc paradigm. IEEE
Computer vol. 35-1 (2002), pages 70–78.
[16] Miller, J., and Mukerji, J. (editors). MDA Guide (Draft Version 0.2) - Captured
at http://www.omg.org/docs/ab/03-01-03.pdf, (2003).
[17] Moreno, E. I., Rodolfo, T. A., and Calazans, N. L. V. Modelagem e
descricao de socs em diferentes nıveis de abstracao. In: X WORKSHOP IBERCHIP
- Cartagena 1 (2004), 1–11.
80
[18] Nguyen, K. D., Sun, Z., Thiagarajan, P. S., and Wong, W. Model-driven soc
design via executable uml to systemc. Real-Time Systems Symposium. Proceedings.
25th IEEE International (December 2004), 459–468.
[19] Patt, Y. N., Patel, S. J., Evers, M., Friendly, D. H., and Stark, J. One
billion transistors, one uniprocessors, one chip. IEEE Computer (September 1997),
pages 51–57.
[20] Rajsuman, R. System on a Chip Design and Test, 1st ed. Artech House, Inc
Norwood, MA, USA, 2000. 277.
[21] Rauscher, T. G. Time to market problems - the organiza-tion is the real cause.
Proceedings of the IEEE Interna-tional Engineering Management Conference (1994),
pages 338–345.
[22] Riccobene, E., Rosti, A., and Scandurra, P. Improving soc design flow
by means of mda and uml profiles. 3rd Workshop on Software Model Engineering
(WiSME)@UML (October 2004).
[23] Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F., and Lorensen, W.
Object-oriented modeling and design. Prentice-Hall, Inc., Upper Saddle River, NJ,
USA, 1991.
[24] Schaller, R. R. Moore’s law: past, present and future. IEEE Spectrum vol. 34-6
(1997), pages 52–59.
[25] SIA. International techology roadmap for semiconductors. World Semiconductor
Council, Edition 1999, Captured at http://public.itrs.net (1999). (Semiconductor
Industry Association).
81
[26] Synopsys. Cocentric system studio enables verification at multiple levels of
abstraction with systemc. Captured at http://www.synopsys.com/products/cocentric
studio/cocentric studi wp.pdf (January 2002).
[27] Yu, A. The future of microprocessors: Intel’s head of microprocessor products looks
10 years ahead to 2006. IEEE MICRO (1996).
[28] Zhu, Q., Matsuda, A., Kuwamura, S., Nakata, T., and Shoji, M. An
object-oriented design process for system-on-chip using uml. 15th International Sym-
posium on System Synthesis (ISSS) , Kyoto, Japan (2002), pages 249–254.
82
Apendice A
Anexos
A.1 Codigo Esqueleto
Codigo Fonte A.1: Codigo Esqueleto - Gerador de Caracteres
1 #ifndef GERADOR DE CARACTERES H
2 #define GERADOR DE CARACTERES H
3 #include <systemc . h>
4
5 template <class T> SC MODULE( Gerador de Caracteres ) {
6 s c f i f o i n <T> ASCII ;
7 s c f i f o o u t <T> address ;
8
9
10 void proce s s ( ) {
11
12 // Implemente a func i ona l i dade do processo aqui !
13
14 }
15 SC CTOR( Gerador de Caracteres ) { SC THREAD( proce s s ) ; }
16 } ;
83
17 #endif //GERADOR DE CARACTERES H
Codigo Fonte A.2: Codigo Esqueleto - Memoria
1 #ifndef MEMORIA H
2 #define MEMORIA H
3 #include <systemc . h>
4
5 template <class T> SC MODULE(Memoria ) {
6 s c f i f o i n <T> end ;
7 s c f i f o o u t <T> ASCII ;
8 s c i n t <32> bu f f e r [TAMBUFFER] ;
9
10 void proce s s ( ) {
11
12 // Implemente a func i ona l i dade do processo aqui !
13
14 }
15 SC CTOR(Memoria ) { SC THREAD( proce s s ) ; }
16 } ;
17 #endif //MEMORIA H
Codigo Fonte A.3: Codigo Esqueleto - ROM de Caracteres
1 #ifndef ROM DE CARACTERES H
2 #define ROM DE CARACTERES H
3 #include <systemc . h>
4
5 template <class T> SC MODULE( ROM de Caracteres ) {
6 s c f i f o i n <T> address ;
7 s c f i f o o u t <sc bv<8> > c h a r a c t e r l i n e ;
8
9
84
10 void proce s s ( ) {
11
12 // Implemente a func i ona l i dade do processo aqui !
13
14 }
15 SC CTOR( ROM de Caracteres ) { SC THREAD( proce s s ) ; }
16 } ;
17 #endif //ROM DE CARACTERES H
A.2 Codigo Funcional
Codigo Fonte A.4: Codigo Funcional - Gerador de Caracteres
1 /∗ ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗
2 g e r ado r d e ca ra c t e r e s . h − Copyright roo t
3
4 Here you can wr i t e a l i c e n s e f o r your code , some comments or any o ther
5 in format ion you want to have in your genera ted code . To to t h i s s imply
6 con f i gu r e the ” headings ” d i r e c t o r y in uml to po in t to a d i r e c t o r y
7 where you have your heading f i l e s .
8
9 or you can j u s t r ep l a c e the con ten t s o f t h i s f i l e wi th your own .
10 I f you want to do t h i s , t h i s f i l e i s l o c a t e d at
11
12 /usr / share /apps/ umbre l lo / headings / heading . h
13
14 −−>Code Generators searches f o r heading f i l e s based on the f i l e e x t ens ion
15 i . e . i t w i l l l ook f o r a f i l e name ending in ” . h” to inc l ude in C++ header
16 f i l e s , and f o r a f i l e name ending in ” . java ” to inc l ude in a l l genera ted
17 java code .
18 I f you name the f i l e ” heading .< ex tens ion >”, Code Generator w i l l a lways
85
19 choose t h i s f i l e even i f t h e r e are o ther f i l e s wi th the same ex t ens ion in
the
20 d i r e c t o r y . I f you name the f i l e something e l s e , i t must be the on ly one
with t ha t
21 ex t ens ion in the d i r e c t o r y to guarantee t ha t Code Generator w i l l choose
i t .
22
23 you can use v a r i a b l e s in your heading f i l e s which are rep l aced at genera t ion
24 t ime . p o s s i b l e v a r i a b l e s are : author , date , time , f i l ename and f i l e p a t h .
25 j u s t wr i t e %var iab le name%
26
27 This f i l e was generated on Wed Aug 9 2006 at 16 :19 :43
28 The o r i g i n a l l o c a t i o n o f t h i s f i l e i s
29 ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗ ∗/
30
31 #ifndef GERADOR DE CARACTERES H
32 #define GERADOR DE CARACTERES H
33 #include <systemc . h>
34
35 template <class T> SC MODULE( Gerador de Caracteres ) {
36
37 s c f i f o i n <T> ASCII ;
38 s c f i f o o u t <T> address ;
39
40 void proce s s ( ) {
41
42 while (1 ) {
43 wait (CB CLOCK) ;
44 T ASCII value = ASCII . read ( ) ;
45 T addre s s va lue ;
86
46 for (T s c an l i n e v a l u e = 0 ; s c an l i n e v a l u e < 8 ;
s c a n l i n e v a l u e++) {
47 addre s s va lue = ASCII value ∗ 8 +
s c an l i n e v a l u e ;
48 cout << "tempo = " << sc t ime stamp ( ) ;
49 cout << " address = " << addre s s va lue <<
endl ;
50 address . wr i t e ( addre s s va lue ) ;
51 CG CLOCK. no t i f y ( ) ;
52 }
53 }
54
55 }
56 SC CTOR( Gerador de Caracteres ) { SC THREAD( proce s s ) ; }
57 } ;
58 #endif //GERADOR DE CARACTERES H
Codigo Fonte A.5: Codigo Funcional - Memoria
1 /∗ ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗
2 memoria . h − Copyright roo t
3
4 Here you can wr i t e a l i c e n s e f o r your code , some comments or any o ther
5 in format ion you want to have in your genera ted code . To to t h i s s imply
6 con f i gu r e the ” headings ” d i r e c t o r y in uml to po in t to a d i r e c t o r y
7 where you have your heading f i l e s .
8
9 or you can j u s t r ep l a c e the con ten t s o f t h i s f i l e wi th your own .
10 I f you want to do t h i s , t h i s f i l e i s l o c a t e d at
11
12 /usr / share /apps/ umbre l lo / headings / heading . h
13
87
14 −−>Code Generators searches f o r heading f i l e s based on the f i l e e x t ens ion
15 i . e . i t w i l l l ook f o r a f i l e name ending in ” . h” to inc l ude in C++ header
16 f i l e s , and f o r a f i l e name ending in ” . java ” to inc l ude in a l l genera ted
17 java code .
18 I f you name the f i l e ” heading .< ex tens ion >”, Code Generator w i l l a lways
19 choose t h i s f i l e even i f t h e r e are o ther f i l e s wi th the same ex t ens ion in
the
20 d i r e c t o r y . I f you name the f i l e something e l s e , i t must be the on ly one
with t ha t
21 ex t ens ion in the d i r e c t o r y to guarantee t ha t Code Generator w i l l choose
i t .
22
23 you can use v a r i a b l e s in your heading f i l e s which are rep l aced at genera t ion
24 t ime . p o s s i b l e v a r i a b l e s are : author , date , time , f i l ename and f i l e p a t h .
25 j u s t wr i t e %var iab le name%
26
27 This f i l e was generated on Wed Aug 9 2006 at 16 :19 :43
28 The o r i g i n a l l o c a t i o n o f t h i s f i l e i s
29 ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗ ∗/
30
31 #ifndef MEMORIA H
32 #define MEMORIA H
33 #include <systemc . h>
34
35 template <class T> SC MODULE(Memoria ) {
36 s c f i f o i n <T> end ;
37 s c f i f o o u t <T> ASCII ;
38
39 s c i n t <32> bu f f e r [TAMBUFFER] ;
40
41 void proce s s ( ) {
88
42
43 bu f f e r [ 0 ] = 85 ; //u
44 bu f f e r [ 1 ] = 70 ; // f
45 bu f f e r [ 2 ] = 77 ; //m
46 bu f f e r [ 3 ] = 71 ; //g
47 while (1 ) {
48 wait (CRT CLOCK) ;
49 T end value = end . read ( ) ;
50 T ASCII value = bu f f e r [ end value ] ;
51 cout << "tempo = " << sc t ime stamp ( ) ;
52 cout << " end = " << end value << " ASCII = " <<
ASCII value << endl ;
53 ASCII . wr i t e ( ASCII value ) ;
54 CB CLOCK. no t i f y ( ) ;
55 }
56 }
57 SC CTOR(Memoria ) { SC THREAD( proce s s ) ; }
58 } ;
59 #endif //MEMORIA H
Codigo Fonte A.6: Codigo Funcional - ROM de Caracteres
1 /∗ ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗
2 rom de carac te re s . h − Copyright roo t
3
4 Here you can wr i t e a l i c e n s e f o r your code , some comments or any o ther
5 in format ion you want to have in your genera ted code . To to t h i s s imply
6 con f i gu r e the ” headings ” d i r e c t o r y in uml to po in t to a d i r e c t o r y
7 where you have your heading f i l e s .
8
9 or you can j u s t r ep l a c e the con ten t s o f t h i s f i l e wi th your own .
10 I f you want to do t h i s , t h i s f i l e i s l o c a t e d at
89
11
12 /usr / share /apps/ umbre l lo / headings / heading . h
13
14 −−>Code Generators searches f o r heading f i l e s based on the f i l e e x t ens ion
15 i . e . i t w i l l l ook f o r a f i l e name ending in ” . h” to inc l ude in C++ header
16 f i l e s , and f o r a f i l e name ending in ” . java ” to inc l ude in a l l genera ted
17 java code .
18 I f you name the f i l e ” heading .< ex tens ion >”, Code Generator w i l l a lways
19 choose t h i s f i l e even i f t h e r e are o ther f i l e s wi th the same ex t ens ion in
the
20 d i r e c t o r y . I f you name the f i l e something e l s e , i t must be the on ly one
with t ha t
21 ex t ens ion in the d i r e c t o r y to guarantee t ha t Code Generator w i l l choose
i t .
22
23 you can use v a r i a b l e s in your heading f i l e s which are rep l aced at genera t ion
24 t ime . p o s s i b l e v a r i a b l e s are : author , date , time , f i l ename and f i l e p a t h .
25 j u s t wr i t e %var iab le name%
26
27 This f i l e was generated on Wed Aug 9 2006 at 16 :19 :43
28 The o r i g i n a l l o c a t i o n o f t h i s f i l e i s
29 ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗ ∗/
30
31 #ifndef ROM DE CARACTERES H
32 #define ROM DE CARACTERES H
33 #include <systemc . h>
34
35 #include "8x8.txt"
36
37 template <class T> SC MODULE( ROM de Caracteres ) {
38
90
39 s c f i f o i n <T> address ;
40 s c f i f o o u t <sc bv<8> > c h a r a c t e r l i n e ;
41
42 void proce s s ( ) {
43
44 while (1 ) {
45 wait (CG CLOCK) ;
46 T addre s s va lue = address . read ( ) ;
47 sc bv<8> c h a r a c t e r l i n e v a l u e = char s e t [
addre s s va lue ] ;
48 cout << "tempo = " << sc t ime stamp ( ) ;
49 cout << " character_line = " << c h a r a c t e r l i n e v a l u e
<< endl ;
50 c h a r a c t e r l i n e . wr i t e ( c h a r a c t e r l i n e v a l u e ) ;
51 CR CLOCK. no t i f y ( ) ;
52 }
53 }
54 SC CTOR( ROM de Caracteres ) { SC THREAD( proce s s ) ; }
55 } ;
56 #endif //ROM DE CARACTERES H
Codigo Fonte A.7: Codigo Funcional - Makefile
1 TARGET ARCH = l inux
2
3 CC = /usr / l o c a l / gcc295 /bin /g++
4 OPT = −O3
5 DEBUG = −g
6 OTHER = −Wall
7 CFLAGS = $ (OPT) $ (OTHER)
8 # CFLAGS = $ (DEBUG) $ (OTHER)
9
91
10 MODULE = Mode lo de Referenc ia
11 SRCS = main . cpp
12 OBJS = $ (SRCS : . cpp=.o )
13
14 i n c lude . / Make f i l e . d e f s
Codigo Fonte A.8: Codigo Funcional - Modulo Controlador (envia os enderecos a memoria)
1 /∗ ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗
2 con t ro l ador . h − Copyright roo t
3
4 Here you can wr i t e a l i c e n s e f o r your code , some comments or any o ther
5 in format ion you want to have in your genera ted code . To to t h i s s imply
6 con f i gu r e the ” headings ” d i r e c t o r y in uml to po in t to a d i r e c t o r y
7 where you have your heading f i l e s .
8
9 or you can j u s t r ep l a c e the con ten t s o f t h i s f i l e wi th your own .
10 I f you want to do t h i s , t h i s f i l e i s l o c a t e d at
11
12 /usr / share /apps/ umbre l lo / headings / heading . h
13
14 −−>Code Generators searches f o r heading f i l e s based on the f i l e e x t ens ion
15 i . e . i t w i l l l ook f o r a f i l e name ending in ” . h” to inc l ude in C++ header
16 f i l e s , and f o r a f i l e name ending in ” . java ” to inc l ude in a l l genera ted
17 java code .
18 I f you name the f i l e ” heading .< ex tens ion >”, Code Generator w i l l a lways
19 choose t h i s f i l e even i f t h e r e are o ther f i l e s wi th the same ex t ens ion in
the
20 d i r e c t o r y . I f you name the f i l e something e l s e , i t must be the on ly one
with t ha t
21 ex t ens ion in the d i r e c t o r y to guarantee t ha t Code Generator w i l l choose
i t .
92
22
23 you can use v a r i a b l e s in your heading f i l e s which are rep l aced at genera t ion
24 t ime . p o s s i b l e v a r i a b l e s are : author , date , time , f i l ename and f i l e p a t h .
25 j u s t wr i t e %var iab le name%
26
27 This f i l e was generated on Wed Aug 9 2006 at 16 :19 :43
28 The o r i g i n a l l o c a t i o n o f t h i s f i l e i s
29 ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗ ∗/
30
31 #ifndef CONTROLADORH
32 #define CONTROLADORH
33 #include <systemc . h>
34
35 template <class T> SC MODULE( Controlador ) {
36
37 s c f i f o o u t <T> end ;
38
39 void proce s s ( ) {
40
41 cout << endl ;
42 for (T end value = 0 ; end value < TAMBUFFER; end value++) {
43 end . wr i t e ( end value ) ;
44 CRT CLOCK. no t i f y (2 , SC NS) ;
45 }
46
47 }
48
49 SC CTOR( Controlador ) { SC THREAD( proce s s ) ; }
50 } ;
51 #endif //CONTROLADORH
93
Codigo Fonte A.9: Codigo Funcional - Gerador de Sinais de Video
1 /∗ ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗
2 g e r a d o r d e s i n a i s v i d e o . h − Copyright roo t
3
4 Here you can wr i t e a l i c e n s e f o r your code , some comments or any o ther
5 in format ion you want to have in your genera ted code . To to t h i s s imply
6 con f i gu r e the ” headings ” d i r e c t o r y in uml to po in t to a d i r e c t o r y
7 where you have your heading f i l e s .
8
9 or you can j u s t r ep l a c e the con ten t s o f t h i s f i l e wi th your own .
10 I f you want to do t h i s , t h i s f i l e i s l o c a t e d at
11
12 /usr / share /apps/ umbre l lo / headings / heading . h
13
14 −−>Code Generators searches f o r heading f i l e s based on the f i l e e x t ens ion
15 i . e . i t w i l l l ook f o r a f i l e name ending in ” . h” to inc l ude in C++ header
16 f i l e s , and f o r a f i l e name ending in ” . java ” to inc l ude in a l l genera ted
17 java code .
18 I f you name the f i l e ” heading .< ex tens ion >”, Code Generator w i l l a lways
19 choose t h i s f i l e even i f t h e r e are o ther f i l e s wi th the same ex t ens ion in
the
20 d i r e c t o r y . I f you name the f i l e something e l s e , i t must be the on ly one
with t ha t
21 ex t ens ion in the d i r e c t o r y to guarantee t ha t Code Generator w i l l choose
i t .
22
23 you can use v a r i a b l e s in your heading f i l e s which are rep l aced at genera t ion
24 t ime . p o s s i b l e v a r i a b l e s are : author , date , time , f i l ename and f i l e p a t h .
25 j u s t wr i t e %var iab le name%
26
27 This f i l e was generated on Wed Aug 9 2006 at 16 :19 :43
94
28 The o r i g i n a l l o c a t i o n o f t h i s f i l e i s
29 ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗ ∗/
30
31 #ifndef GERADOR DE SINAIS VIDEO H
32 #define GERADOR DE SINAIS VIDEO H
33 #include <systemc . h>
34
35 #include <s t d i o . h>
36
37 template <class T> SC MODULE( Gerador de S ina i s V ideo ) {
38
39 s c i n <s c b i t > r e f r e s h b i t ;
40 sc out<s c b i t > l inha , quadro , enable ;
41 sc out<T> pxl ine , pxco l ;
42
43 void proce s s ( ) {
44
45 s c b i t enab l e va lue ;
46 s c b i t pxclk , hsynk , vsynk ;
47 wait (DELAY VIDEO) ;
48
49 while (1 ) {
50
51 vsynk = 0 ;
52
53 for (T px l i n e va l u e = 0 ; px l i n e va l u e < NUMLINES∗8 ;
px l i n e va l u e++) {
54 hsynk = 0 ;
55
56 for (T pxco l va lue = 0 ; pxco l va lue <
NUMCOLS∗8 ; pxco l va lue++) {
95
57 pxclk = 0 ;
58 px l i n e . wr i t e ( px l i n e va l u e ) ;
59 pxcol . wr i t e ( pxco l va lue ) ;
60 wait (DELAY PIXEL) ;
61 enab l e va lue = r e f r e s h b i t . read ( ) ;
62
63 pxclk = 1 ;
64 wait (DELAY PIXEL) ;
65
66 enable . wr i t e ( enab l e va lue ) ;
67 l i nha . wr i t e ( hsynk ) ;
68 VSG CLOCK. no t i f y ( ) ;
69
70 }
71 hsynk = 1 ;
72 l i nha . wr i t e ( hsynk ) ;
73 wait (DELAY HSYNK) ;
74 quadro . wr i t e ( vsynk ) ;
75
76 }
77 vsynk = 1 ;
78 quadro . wr i t e ( vsynk ) ;
79 wait (DELAY VSYNK) ;
80 }
81 }
82 SC CTOR( Gerador de S ina i s V ideo ) { SC THREAD( proce s s ) ; }
83 } ;
84 #endif //GERADOR DE SINAIS VIDEO H
Codigo Fonte A.10: Codigo Funcional - Buffer de armazenamento e atualizacao de quadros
1 /∗ ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗
96
2 refresh mem . h − Copyright roo t
3
4 Here you can wr i t e a l i c e n s e f o r your code , some comments or any o ther
5 in format ion you want to have in your genera ted code . To to t h i s s imply
6 con f i gu r e the ” headings ” d i r e c t o r y in uml to po in t to a d i r e c t o r y
7 where you have your heading f i l e s .
8
9 or you can j u s t r ep l a c e the con ten t s o f t h i s f i l e wi th your own .
10 I f you want to do t h i s , t h i s f i l e i s l o c a t e d at
11
12 /usr / share /apps/ umbre l lo / headings / heading . h
13
14 −−>Code Generators searches f o r heading f i l e s based on the f i l e e x t ens ion
15 i . e . i t w i l l l ook f o r a f i l e name ending in ” . h” to inc l ude in C++ header
16 f i l e s , and f o r a f i l e name ending in ” . java ” to inc l ude in a l l genera ted
17 java code .
18 I f you name the f i l e ” heading .< ex tens ion >”, Code Generator w i l l a lways
19 choose t h i s f i l e even i f t h e r e are o ther f i l e s wi th the same ex t ens ion in
the
20 d i r e c t o r y . I f you name the f i l e something e l s e , i t must be the on ly one
with t ha t
21 ex t ens ion in the d i r e c t o r y to guarantee t ha t Code Generator w i l l choose
i t .
22
23 you can use v a r i a b l e s in your heading f i l e s which are rep l aced at genera t ion
24 t ime . p o s s i b l e v a r i a b l e s are : author , date , time , f i l ename and f i l e p a t h .
25 j u s t wr i t e %var iab le name%
26
27 This f i l e was generated on Wed Aug 9 2006 at 16 :19 :43
28 The o r i g i n a l l o c a t i o n o f t h i s f i l e i s
29 ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗ ∗/
97
30
31 #ifndef REFRESH MEM H
32 #define REFRESH MEM H
33 #include <systemc . h>
34
35 template <class T> SC MODULE( Refresh Mem ) {
36
37 s c f i f o i n <sc bv<8> > c h a r a c t e r l i n e ;
38
39 s c i n <T> pxl ine , pxco l ;
40 sc out<s c b i t > r e f r e s h b i t ;
41
42 s c b i t MEM[NUMLINES∗ 8 ] [NUMCOLS∗ 8 ] ;
43
44 void wr i t e p r o c e s s ( ) {
45
46 sc bv<8> c h a r a c t e r l i n e v a l u e ;
47
48 while (1 ) {
49 for (T l i n = 0 ; l i n < NUMLINES; l i n++) {
50 for (T co l = 0 ; c o l < NUMCOLS; c o l++) {
51 for (T i = 0 ; i < 8 ; i++) {
52 wait (CR CLOCK) ;
53 c h a r a c t e r l i n e v a l u e =
ch a r a c t e r l i n e . read ( ) ;
54 for (T j = 0 ; j < 8 ; j++){
55 MEM[ l i n ∗ 8 + i ] [ c o l
∗ 8 + j ] =
c h a r a c t e r l i n e v a l u e
[ 7 − j ] ;
56 cout << "tempo = "
98
<< sc t ime stamp
( ) ;
57 cout << " MEM[" <<
l i n ∗8+ i << "][" ;
58 cout << c o l ∗8+ j << "
] = " ;
59 cout << MEM[ l i n ∗8+ i
] [ c o l∗8+ j ] <<
endl ;
60 }
61 }
62 }
63 }
64 }
65 }
66
67 void r e ad p ro c e s s ( ) {
68
69 wait(−3+DELAY VIDEO) ;
70
71 while (1 ) {
72 wait (DELAY READ) ;
73 T px l i n e va l u e = px l i n e . read ( ) ;
74 T pxco l va lue = pxcol . read ( ) ;
75 s c b i t r e f r e s h b i t v a l u e = MEM[ px l i n e va l u e ] [
pxco l va lue ] ;
76 r e f r e s h b i t . wr i t e ( r e f r e s h b i t v a l u e ) ;
77 }
78 }
79
80 SC CTOR( Refresh Mem ) {
99
81
82 SC THREAD( wr i t e p r o c e s s ) ;
83 SC THREAD( r ead p ro c e s s ) ;
84
85 }
86 } ;
87 #endif //REFRESH MEM H
Codigo Fonte A.11: Codigo Funcional - Simulador de Video
1 /∗ ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗
2 s imu lador v ideo . h − Copyright roo t
3
4 Here you can wr i t e a l i c e n s e f o r your code , some comments or any o ther
5 in format ion you want to have in your genera ted code . To to t h i s s imply
6 con f i gu r e the ” headings ” d i r e c t o r y in uml to po in t to a d i r e c t o r y
7 where you have your heading f i l e s .
8
9 or you can j u s t r ep l a c e the con ten t s o f t h i s f i l e wi th your own .
10 I f you want to do t h i s , t h i s f i l e i s l o c a t e d at
11
12 /usr / share /apps/ umbre l lo / headings / heading . h
13
14 −−>Code Generators searches f o r heading f i l e s based on the f i l e e x t ens ion
15 i . e . i t w i l l l ook f o r a f i l e name ending in ” . h” to inc l ude in C++ header
16 f i l e s , and f o r a f i l e name ending in ” . java ” to inc l ude in a l l genera ted
17 java code .
18 I f you name the f i l e ” heading .< ex tens ion >”, Code Generator w i l l a lways
19 choose t h i s f i l e even i f t h e r e are o ther f i l e s wi th the same ex t ens ion in
the
20 d i r e c t o r y . I f you name the f i l e something e l s e , i t must be the on ly one
with t ha t
100
21 ex t ens ion in the d i r e c t o r y to guarantee t ha t Code Generator w i l l choose
i t .
22
23 you can use v a r i a b l e s in your heading f i l e s which are rep l aced at genera t ion
24 t ime . p o s s i b l e v a r i a b l e s are : author , date , time , f i l ename and f i l e p a t h .
25 j u s t wr i t e %var iab le name%
26
27 This f i l e was generated on Wed Aug 9 2006 at 16 :19 :43
28 The o r i g i n a l l o c a t i o n o f t h i s f i l e i s
29 ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗ ∗/
30
31 #ifndef SIMULADOR VIDEO H
32 #define SIMULADOR VIDEO H
33 #include <systemc . h>
34
35 // B i b l i o t e c a padrao para entrada e sa ida
36 #include <s t d i o . h>
37
38 template <class T> SC MODULE( Simulador Video ) {
39
40 s c i n <s c b i t > enab le va lue , hsync , vsync ;
41
42 void proce s s ( ) {
43
44 s c b i t enable px ;
45 s c b i t muda linha , muda quadro ;
46
47 muda linha = 0 ;
48 muda quadro = 0 ;
49
50 while (1 ) {
101
51
52 while ( muda quadro == 0) {
53
54 while ( muda linha == 0) {
55 wait (VSG CLOCK) ;
56 enable px = enab l e va lue . read ( ) ;
57 muda linha = hsync . read ( ) ;
58
59 i f ( enable px == 0)
60 cout << "-" ;
61 else i f ( enable px == 1)
62 cout << "W" ;
63 }
64
65 cout << endl ;
66 muda linha = hsync . read ( ) ;
67 muda linha = 0 ;
68 muda quadro = vsync . read ( ) ;
69 }
70
71 cout << "Novo refresh!" << endl ;
72 muda quadro = 0 ;
73 }
74 }
75 SC CTOR( Simulador Video ) { SC THREAD( proce s s ) ; }
76 } ;
77 #endif //SIMULADOR VIDEO H
Codigo Fonte A.12: Codigo Funcional - Programa Principal (“Main”)
1 /∗−−−−−−−−−−−−−−−−−−−−−−∗/
2 /∗DEFINICOES∗/
102
3 /∗−−−−−−−−−−−−−−−−−−−−−−∗/
4 #define TEMPO SIMUL 100000 , SC NS
5 #define DELAY PIXEL 2 , SC NS
6 #define DELAY READ 2∗DELAY PIXEL
7 #define DELAY VIDEO 100 , SC NS
8 #define DELAY HSYNK 20 , SC NS
9 #define DELAY VSYNK 10 , SC NS
10
11 /∗−−−−−−−−−−−−−−−−−−−−−−∗/
12 /∗BIBLIOTECAS∗/
13 /∗−−−−−−−−−−−−−−−−−−−−−−∗/
14 #include <systemc . h>
15
16 /∗Modulos do Contro lador ∗/
17 #include "controlador.h"
18 #include "memoria.h"
19 #include "gerador_de_caracteres.h"
20 #include "rom_de_caracteres.h"
21 #include "refresh_mem.h"
22 #include "gerador_de_sinais_video.h"
23
24 #include "simulador_video.h" //Simulador
25
26 /∗−−−−−−−−−−−−−−−−−−−−−−∗/
27 /∗CONSTANTES∗/
28 /∗−−−−−−−−−−−−−−−−−−−−−−∗/
29 const int TAMBUFFER = 4 ; // tamanho do b u f f e r de ca rac t e r e s
30 const int NUMLINES = 4 ; // numero de l i n h a s do d i s p l a y
31 const int NUMCOLS = 8 ; // numero de co lunas do d i s p l a y
32 /∗−−−−−−−−−−−−−−−−−−−−−−∗/
33
103
34 // Var iave i s g l o b a i s − eventos
35 s c even t CRT CLOCK;
36 s c even t CB CLOCK;
37 s c even t CG CLOCK;
38 s c even t CR CLOCK;
39 s c even t VSG CLOCK;
40
41 int sc main ( int argc , char ∗agv [ ] )
42 {
43
44 // In s t anc i a s dos Modulos
45 Controlador<int> Controlador ("Controlador" ) ;
46 Memoria<int> Memoria ("Memoria" ) ;
47 Gerador de Caracteres<int> Gerador de Caracteres ("
Gerador_de_Caracteres" ) ;
48 ROM de Caracteres<int> ROM de Caracteres ("ROM_de_Caracteres" ) ;
49 Refresh Mem<int> Refresh Mem ("Refresh_Mem" ) ;
50 Gerador de S ina i s Video<int> Gerador de S ina i s V ideo ("
Gerador_de_Sinais_Video" ) ;
51 Simulador Video<int> Simulador Video ("Simulador_Video" ) ;
52
53 // I n t e r f a c e s
54 s c f i f o <int> END("END" , 1) ;
55 s c f i f o <int> ASCII ("ASCII" , 1) ;
56 s c f i f o <int> ADDRESS("ADDRESS" , 1) ;
57 s c f i f o <sc bv<8> > CHARACTER LINE("CHARACTER_LINE" , 1) ;
58
59 // S ina i s de con t r o l e
60 s c s i g n a l <int> PXLINE;
61 s c s i g n a l <int> PXCOL;
62 s c s i g n a l <s c b i t > REFRESH BIT;
104
63 s c s i g n a l <s c b i t > ENABLE PX;
64 s c s i g n a l <s c b i t > HSYNC;
65 s c s i g n a l <s c b i t > VSYNC;
66
67
68 // Conexao dos Modulos
69 Controlador . end (END) ;
70 Memoria . end (END) ;
71 Memoria . ASCII (ASCII ) ;
72 Gerador de Caracteres . ASCII (ASCII ) ;
73 Gerador de Caracteres . address (ADDRESS) ;
74 ROM de Caracteres . address (ADDRESS) ;
75 ROM de Caracteres . c h a r a c t e r l i n e (CHARACTER LINE) ;
76 Refresh Mem . c h a r a c t e r l i n e (CHARACTER LINE) ;
77 Gerador de S ina i s V ideo . px l i n e (PXLINE) ;
78 Refresh Mem . px l i n e (PXLINE) ;
79 Gerador de S ina i s V ideo . pxco l (PXCOL) ;
80 Refresh Mem . pxco l (PXCOL) ;
81 Refresh Mem . r e f r e s h b i t (REFRESH BIT) ;
82 Gerador de S ina i s V ideo . r e f r e s h b i t (REFRESH BIT) ;
83 Gerador de S ina i s V ideo . enable (ENABLE PX) ;
84 Gerador de S ina i s V ideo . l i nha (HSYNC) ;
85 Gerador de S ina i s V ideo . quadro (VSYNC) ;
86 Simulador Video . enab l e va lue (ENABLE PX) ;
87 Simulador Video . hsync (HSYNC) ;
88 Simulador Video . vsync (VSYNC) ;
89
90 // Criacao do arqu ivo ∗ . vcd
91
92 s c t r a c e f i l e ∗ t f i l e = s c c r e a t e v c d t r a c e f i l e ("
Modelo_de_Referencia" ) ;
105
93 // s c t r a c e ( t f i l e , END, ”Endereco ”) ;
94 // s c t r a c e ( t f i l e , ASCII , ”ASCII”) ;
95 // s c t r a c e ( t f i l e , ADDRESS, ”Address ”) ;
96 // s c t r a c e ( t f i l e , CHARACTER LINE, ”Linha de Caracteres ”) ;
97 // s c t r a c e ( t f i l e , ENABLE PX, ”ENABLE PX”) ;
98 // s c t r a c e ( t f i l e , REFRESH BIT, ”REFRESH BIT”) ;
99 s c t r a c e ( t f i l e , PXLINE, "PXLINE" ) ;
100 s c t r a c e ( t f i l e , PXCOL, "PXCOL" ) ;
101 s c t r a c e ( t f i l e , HSYNC, "HSYNC" ) ;
102 s c t r a c e ( t f i l e , VSYNC, "VSYNC" ) ;
103
104 // I n i c i a a simulacao
105 s c s t a r t (TEMPO SIMUL) ;
106
107 cout << endl ;
108
109 // Fecha arqu ivo ∗ . vcd ∗/
110 s c c l o s e v c d t r a c e f i l e ( t f i l e ) ;
111
112 return 0 ;
113 }
106
A.3 Diagrama de Classes - Todos os modulos
Figura A.1: Diagrama de Classes Completo e Funcional
107