Professional Documents
Culture Documents
Data de Depsito:
Assinatura:________________________
______
USP So Carlos
Fevereiro de 2013
D948f
Agradecimentos
minha esposa Uiara pelo total apoio durante todo o mestrado, principalmente nos meses que estive ausente.
Ao meu orientador Prof. Dr. Vanderlei Bonato por suas valiosas contribuies durante a elaborao deste trabalho.
Aos meus colegas do laboratrio LCR, do Instituto de Cincias Matemticas
e de Computao, e do laboratrio SPeCS, da Faculdade de Engenharia da
Universidade do Porto, pela tima convivncia.
s funcionrias da secretaria de ps-graduao do Instituto de Cincias Matemticas e de Computao, que sempre foram muito atenciosas.
Coordenao de Aperfeioamento de Pessoal de Nvel Superior pelo auxlio financeiro que possibilitou minha dedicao exclusiva ao mestrado.
Resumo
Abstract
The continuous advancement of integrated circuits capacity and the need for
embedded systems even more complex to deal with current problems, with
shorter time-to-market, are driving the development of integrated circuits systems to environments with high level abstraction more and more distant from
the hardware details. The use of high level languages to assist the embedded
systems development is a current trend for such an approach tends to reduce
the complexity and development time. This work proposes the development
of a new tool in Bluespec to generate hardware architectures in a graphical
environment using UML diagrams. This tool allows the designer to describe
the behavior using finite state machine in UML 2.0 standard, where each state
can contain the coding behavior with Bluespec and C languages. Given a state
machine, it is translated to Bluespec language through a compiler and templates. As a result is presented the generation of two hardware architectures
in order to demonstrate the advantages and limitations of the developed tool.
Sumrio
Sumrio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii
Lista de Figuras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
xv
1.1 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1.1 Objetivo Geral
. . . . . . . . . . . . . . . . . . . . . . . . . .
4
4
. . . . . . . . . . . . . . . . . . . . . .
1.2 Justificativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2 Fundamentao Terica
23
3.1 JavaCC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2 Apache Velocity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.3 Bluespec SystemVerilog . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.4 Padro IP-XACT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
xi
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
31
33
33
38
41
44
47
48
.
.
.
.
.
.
53
53
54
57
59
60
64
Concluso
67
Referncias Bibliogrficas
69
xii
85
Lista de Figuras
1.1 Diagrama de blocos dos principais elementos do projeto RoboArch com o destaque do mdulo onde este trabalho est situado.
2.2 Exemplo de uma MEF tipo Moore para detectar a sequncia 11.
11
2.3 Exemplo de uma MEF tipo Mealy para detectar a sequncia 11. . 12
2.4 Elementos de um diagrama ASM adaptado de (Brown, 2005).
. . 12
4.1 Fluxo do processo de gerao automtica da ferramenta proposta. A entrada do fluxo recebe um modelo em UML, no formato XMI, e interpretado pela UML2BSV que, com o suporte
do compilador C2BSV, so responsveis pela gerao de cdigo
Bluespec automaticamente. . . . . . . . . . . . . . . . . . . . . . . 32
4.2 Definio de tipos de dados utilizando classes. . . . . . . . . . . . 34
4.3 Ao actionTrafficLight do diagrama de atividades que est relacionada mquina de estados que controla o tempo de um semforo. Na borda do elemento grfico que representa uma ao
encontram-se as declaraes dos sinais de entrada, sada e variveis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.4 Diagrama de estados representando o controle de tempo de um
semforo. Dentro de cada estado existe a referncia para o cdigo
que descreve seu comportamento. . . . . . . . . . . . . . . . . . . . 37
4.5 Diagrama de classes que representa a estrutura da modelagem
do circuito. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.6 Estrutura de templates de um mdulo BSV. . . . . . . . . . . . . . 45
4.7 Representao de um conjunto de estados e suas respectivas definies em Bluespec. O cdigo na parte inferior da imagem representa a declarao de um novo tipo de dado State, da categoria enumerator, onde esto includos todos os estados da modelagem. E o cdigo direita mostra trecho das rules para cada
estado que foi modelado. . . . . . . . . . . . . . . . . . . . . . . . . 48
4.8 Definio de um estado inicial por meio de uma transio de um
pseudo-estado, representado por um crculo preto, para um estado comum. Na parte inferior da figura ilustrado o cdigo BSV
correspondente que cria e inicializa a varivel state. . . . . . . . . 48
4.9 Parte do diagrama de estados mostrando uma transio com a
condio count == 20. Abaixo da figura destacado o trecho de
cdigo BSV dentro da rule onde uma verificao condicional
realizada. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.10 Instruo resultado = 9/(1 + 3) 4 + 5; representada no formato da
AST gerada pelo frontend. . . . . . . . . . . . . . . . . . . . . . . . . 50
4.11 Representaes de estruturas de decises e laos como mquina
de estados. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.1 Definio dos tipos de dados utilizados na modelagem do processador. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.2 Diagrama de estados do processador. . . . . . . . . . . . . . . . . . 56
5.3 Ao que representa o processador com as variveis utilizadas
localmente na regio inferior. . . . . . . . . . . . . . . . . . . . . . . 57
xiv
xv
61
61
63
64
65
Lista de Tabelas
xvii
Lista de Cdigos
xix
24
24
28
38
42
43
43
44
46
46
49
51
57
58
65
75
79
85
Lista de Abreviaturas
xxi
CAPTULO
1
Introduo
EDA (Electronic Design Automation) que por meio de um ambiente de programao visual, possvel modelar sistemas, realizar verificaes e snteses.
O uso de linguagens grficas para modelar sistemas embarcados uma
abordagem que tem sido adotada por ferramentas comerciais e acadmicas,
uma vez que elas ajudam os desenvolvedores a visualizar e organizar sistemas
complexos.
A UML uma das linguagens grficas mais adotadas atravs de seus diversos diagramas. Isto pode ser observado nos trabalhos de Moreira et. al.
(2010); Wood et. al. (2008); Rieder et. al. (2006); Xi et. al. (2005) no qual usam
os diagramas de Classes, Objetos, Pacotes e Estados para projetar hardware.
Entretanto, outros trabalhos tem utilizado outras abordagens para representar um modelo graficamente como em Abdel-Hamid et. al. (2004) que usa
a linguagem DOT, ou ento atravs do uso de ferramentas de terceiros para
desenhar diagramas, como em de Pablo et. al. (2007), que desenvolveram um
compilador para o diagrama ASM, e Tran et. al. (2005), onde os autores desenvolveram um complemento baseado em VBA (Visual Basic for Applications),
ambos utilizando a ferramenta Microsoft Visio.
As vantagens por utilizar a linguagem UML que ela j um padro bem
estabelecido, tem uma popularidade alta dentre os desenvolvedores e existem diversas ferramentas de modelagens disponveis, tanto comerciais quanto
livres.
Alm de trabalhos acadmicos, algumas companhias importantes tambm
mostram interesse nesta rea, desenvolvendo ferramentas como Aldec (2010);
Mentor Graphics Corporation (2006); HDL Works (2011), fornecendo aos programadores um ambiente completo para modelar complexos sistemas, realizar
simulaes interativas e na gerao de cdigo de descrio de hardware como
VHDL e Verilog.
Nesta mesma linha, tambm h projetos open source como Duffner e Strobel (2010); University of Mannheim - Computer Architecture Group (2010)
que fornecem no apenas boas solues de sistemas mas tambm, por serem
livres, permitem adicionar novas extenses ampliando suas funcionalidades.
Este trabalho est inserido no projeto RoboArch (Bonato e Marques, 2009),
que teve incio em 2008 durante o ps-doutoramento de Bonato com apoio da
FAPESP (processo 2008/03446-1), e teve continuidade durante o desenvolvimento deste trabalho com um novo apoio da FAPESP (processo 2010/127481). O RoboArch, representado na figura 1.1, uma ferramenta baseada em
componentes para desenvolvimento de arquitetura de hardware para robs
mveis. Ela fornece uma plataforma de desenvolvimento em um ambiente visual baseado em componentes. Ainda na figura 1.1 possvel visualizar em
destaque onde este trabalho est situado.
2
Modelagem UML
UML2BSV
C2BSV
( * synt hesi ze *)
modul e mkTr af f i cLi ght ( Empt y) ;
Reg#( St at e) st at e <- mkReg( G) ;
r ul e gr een ( st at e == G) ;
....
1.1
Objetivos
Nesta seo ser apresentado o objetivo geral deste projeto assim como seus
objetivos especficos.
1.1.1
Objetivo Geral
1.1.2
Objetivos Especficos
1.2
Justificativa
Com sistemas embarcados cada vez mais complexos e prazos de desenvolvimento cada vez menores, os desenvolvedores dependem cada vez mais de
ferramentas geis no sentido de acelerar o desenvolvimento por meio da abstrao dos detalhes do hardware e da automatizao do processo de gerao
e otimizao dos sistemas implementados. Para isso, linguagens de programao de alto nvel so necessrias. O mercado est guiando a rea de sistemas embarcados neste sentido, sendo necessrio criar novas tecnologias para
acompanhar esta demanda.
Assim, como a linguagem C trouxe grandes vantagens para se desenvolver
sistemas complexos de forma mais simples e rpida em relao ao assembly,
o mesmo est acontecendo na rea de hardware onde existem vrias linguagens que fornecem ao programador um nvel maior de abstrao, saindo do
RTL (VHDL ou Verilog) e indo, por exemplo, para o SystemC (OSCI, 2010) ou
Handel-C (Mentor Graphics, 2010). Se por um lado, quanto mais alto o nvel de abstrao mais passos e ferramentas de suporte so necessrios para
alcanar o grande desafio que deixar a parte de sntese automatizada, por
outro lado, ganha-se em produtividade, acelerando o processo de desenvolvimento.
5
Uma das formas utilizadas para diminuir a complexidade no desenvolvimento de sistemas embarcados atravs da modelagem visual utilizando diagramas de mquina de estado em conjunto com uma linguagem de programao amplamente utilizada como, por exemplo, a linguagem C (Edwards,
2006; TIOBE Software, 2010; DedaSys LLC, 2010). Outra caracterstica que
pode contribuir no desenvolvimento de arquiteturas em hardware determinar partes do sistema que podem ser executadas em paralelo, sem a necessidade do projetista conhecer detalhes tcnicos de como a implementao em
hardware, bastando apenas colocar o respectivo cdigo dentro de um estado.
Alis, esta caracterstica de paralelizar cdigos, comum em sistemas digitais,
est caminhando para a computao de uso geral, uma vez que os processadores de um nico ncleo chegaram no limite de seu desempenho, dando
incio a era multicore (Fuller e Millett, 2011).
Existem ferramentas comerciais como ActiveHDL (Aldec, 2010) e QFSM
(Duffner e Strobel, 2010), open source, onde o objetivo gerar cdigo por meio
de uma modelagem visual. Porm, elas utilizam como entrada uma linguagem de descrio de hardware (HDL), como Verilog ou VHDL, e a sada segue
a mesma linguagem utilizada na entrada. J a proposta deste trabalho ter
como entrada, alm de Bluespec, a linguagem C e sada a linguagem Bluespec.
A escolha pela utilizao de mquina de estado se deve ao fato de que ela
pode simplificar consideravelmente o processo de desenvolvimento de sistemas mais complexos, deixando bem definida as tarefas a serem realizadas.
A grande vantagem de gerar cdigo Bluespec que ele permite realizar simulaes muito rpidas, se comparado com VHDL ou Verilog, reaproveitar os
testbenchs para outras finalidades, melhorar o desempenho e detectar erros
de forma mais fcil, fazer explorao e verificao da arquitetura e posteriormente gerar um cdigo RTL. Alm disso, ela totalmente sintetizvel e o
hardware gerado pelo compilador Bluespec considerado eficiente, segundo
Gruian e Westmijze (2008) e Agarwal (2009).
1.3
Organizao do Texto
Este trabalho est organizado como segue: O Captulo 2 apresenta uma reviso dos assuntos que esto ligados diretamente com este projeto e alguns
trabalhos relacionados. O Captulo 3 aborda as ferramentas que foram utilizadas neste trabalho. No Captulo 4, encontra-se a implementao desta
ferramenta. No Captulo 5 so demonstradas as aplicaes desta ferramenta.
Por fim, o texto finalizado com a Concluso e trabalhos futuros.
CAPTULO
2
Fundamentao Terica
Alguns conceitos utilizados neste trabalho sero descritos nas prximas sees deste captulo, assim como alguns trabalhos relacionados gerao de
cdigo a partir de uma linguagem visual.
2.1
Toda a definio da UML est descrita em dois documentos: um de infraestrutura e outro de superestrutura. O primeiro define as construes bsicas
da linguagem e mais direcionado aos desenvolvedores de ferramentas de modelagem. J o segundo aborda todos os elementos da UML disponveis para a
modelagem de sistemas (Grssle, 2005).
A figura 2.1 ilustra um diagrama de classes onde esto representados todos
os 14 diagramas da UML. Eles esto divididos em duas categorias principais,
onde metade deles so classificados como estruturais e a outra metade como
comportamentais.
que podem possuir atributos e operaes, e seus respectivos relacionamentos com as outras classes do diagrama;
Diagrama de objeto: a viso, em um momento de tempo especfico, das
instncias de classes;
Diagrama de pacote: utilizado para mostrar a diviso lgica dos mdulos
de um sistema e suas respectivas dependncias;
Diagrama de estrutura composta: mostra a estrutura interna de uma
classe;
Diagrama de componente: mostra como as classes de sistema so divididas em componentes e suas dependncias;
Diagrama de implantao: utilizado para descrever os equipamentos e o
ambiente de execuo utilizado na implantao do sistema;
Diagrama de perfil: utilizado para definio de perfis atravs de esteritipos.
J os diagramas comportamentais tem foco nas atividades, operaes, fluxos das informaes, lgica de negcios que devem ocorrer no sistema, onde
possvel detalhar passo a passo o comportamento em cada etapa. Ainda
nesta categoria, existe uma sub-categoria com 4 diagramas onde possvel
representar o fluxo de controle e dos dados de um sistema. Os diagramas da
categoria dos comportamentais, so:
Diagrama de caso de uso: representa um sistema baseado em atores e
seus respectivos relacionamentos com os casos de uso;
Diagrama de estado: descreve um sistema por meio de uma mquina de
estados;
Diagrama de atividade: mostra o passo a passo de todos os fluxos de
atividades que ocorrem em um sistema;
Diagrama de sequncia: mostra a comunicao entre os objetos por meio
de uma sequncia de mensagens;
Diagrama de comunicao: mostra como se d a interao entre os objetos;
Diagrama panormico de interao: fornece uma viso geral no qual os
ns representam diagramas de comunicao;
9
2.2
O estudo de mquina de estados finitos (MEF) faz parte da teoria dos autmatos. Uma MEF tem o objetivo de modelar o comportamento de um sistema que
pode ser representado por um nmero finito de estados. Mquina de estado
est relacionada a modelos matemticos que tentam abstrair fenmenos fsicos. Elas so muito utilizadas na rea de projeto de circuito digitais e na rea
de compiladores para realizar a anlise lxica de cdigo fonte. Porm, o uso
de MEF no restrito a rea da computao, podendo ser aplicado tambm
em problemas de vrios campos de investigao, como na biologia, medicina
e administrao (Gill, 1962).
Atravs de um modelo matemtico, uma MEF M pode ser representada
formalmente pela sxtupla M = (, , Q, q0 , , ), onde:
o alfabeto (conjunto) de entrada
o alfabeto (conjunto) de sada
Q um conjunto finito de estados
q0 o estado inicial de Q
a funo de transio de estados: : Q Q
a funo de sada, onde:
: Q (modelo Moore)
: Q (modelo Mealy).
10
0
0
1
C
Figura 2.2: Exemplo de uma MEF tipo Moore para detectar a sequncia 11.
Na figura 2.3, encontra-se um exemplo de uma mquina de estado do tipo
Mealy baseado no mesmo exemplo anterior da mquina do tipo Moore (figura
11
2.2). Neste caso pode-se observar que foram necessrios utilizar apenas dois
estados para manter o mesmo comportamento do exemplo anterior.
A
0/0
1/0
0/0
1/1
Figura 2.3: Exemplo de uma MEF tipo Mealy para detectar a sequncia 11.
A principal vantagem na utilizao do modelo de Mealy em relao ao de
Moore que, como as sadas de um modelo de Mealy so em funes tanto da
entrada quanto do estado, o projetista tem mais flexibilidade na concepo de
funes de sada e de transio de estados, e com isso poder ter uma MEF
com menos estados do que uma MEF equivalente no modelo de Moore (Nelson
et. al., 1995). Alm disso, nada impede que o projetista utilize um modelo
misto de Moore e Mealy.
A outra maneira de representar uma MEF graficamente atravs do diagrama ASM, que parecido com um fluxograma e possui trs elementos
bsicos, mostrados na figura 2.4.
2.2.1
Minimizao de estados
Nos projetos iniciais de MEF mais complexas, as primeiras verses podem resultar no uso de mais estados do que o necessrio. Minimizar o uso de estados
importante pois com isso o circuito gerado ser menor e ocupar menos espao em um dispositivo lgico. Dizer que o nmero de estados de uma MEF
13
Entrada
0
1
0
1
0
1
Prximo Estado
A
B
A
C
A
C
Sada
0
0
0
1
0
1
podem ser reduzidos afirmar que alguns estados podem ser considerados
equivalentes no mbito geral do comportamento da MEF.
Gill (1962) formaliza esta definio utilizando a notao M1 |i e M2 |j que
deve ser compreendida como mquina M no estado . Assim, ele define
que um estado i de uma mquina M1 e um estado j de uma mquina M2
so ditas equivalentes se para cada sequncia de entrada em M1 |i e M2 |j for
produzida uma sequncia de sada idntica. M1 e M2 podem se referir a uma
mesma mquina.
2.3
Compiladores
O estudo de compiladores envolve o conhecimento de diversas reas como linguagens formais, autmatos finitos, estrutura de dados, matemtica discreta,
teoria de linguagens e gramtica. Quando os primeiros compiladores comearam a surgir nos anos 50, eles eram considerados programas extremamente
difceis de serem implementados. Mas com o passar das dcadas, foram aperfeioadas diversas tcnicas e ambientes de programao que tem facilitado
muito a construo destes programas (Aho et. al., 1986).
Compilador pode ser definido como um programa que faz traduo de um
outro programa de entrada escrito em uma linguagem (cdigo fonte) para um
programa de sada equivalente em outra linguagem (cdigo objeto) (Delamaro,
2004). Durante este processo podem ocorrer erros e, neste caso, o compilador
deve ser capaz de informar ao usurio qual foi o erro e em que local ele foi
gerado (Parr, 2007).
Os compiladores tem uma importncia muito grande na computao pois
ele precisa garantir que o cdigo objeto gerado produza o mesmo comportamento esperado pelo programador. Alm disso, o compilador pode tambm
melhorar o programa objeto realizando diversas medidas de otimizaes do
cdigo, algo que essencial em sistemas embarcados, visando ter um cdigo
mais enxuto onde o tempo de execuo, tamanho e consumo de energia sejam
14
15
2.3.1
Frontend
2.3.2
Backend
Em alguns compiladores possvel definir qual o grau de otimizao desejado, porm quanto maior for o grau, maior ser o tempo gasto na etapa de
otimizao, podendo consumir boa parte de todo o tempo gasto na compilao. Otimizaes simples, que no consomem muito tempo, j podem trazer
resultados significativos na melhoria do cdigo gerado (Aho et. al., 1986).
A ltima etapa da fase de compilao a gerao de cdigo, que utiliza
o cdigo intermedirio como entrada e tem como sada o cdigo objeto. O
cdigo gerado especfico para uma mquina, mesmo que virtual, e para um
determinado sistema operacional. Espera-se tambm que o cdigo gerado
utilize de forma efetiva os recursos disponveis na arquitetura alvo.
2.4
RoboArch
2.5
Trabalhos Relacionados
2.5.1
ASM++
O ASM++ uma linguagem grfica proposta por de Pablo et. al. (2007) baseada no diagrama de estado algortmico (ASM chart) desenvolvida na Universidade de Valladolid, Espanha, pelo Departamento de Tecnologia Eletrnica. A
finalidade dessa nova linguagem aumentar suas possibilidades no desenvolvimento de circuitos RTL complexos. Na figura 2.10, encontra-se um exemplo
da notao grfica da linguagem ASM++ onde pode ser observado a extenso da linguagem em relao ao ASM tradicional nos elementos localizados
esquerda da figura.
Para isso foi desenvolvido o compilador ASM++, que recebe como entrada
um diagrama ASM++ e gera dois arquivos intermedirios: o VDO, que uma
lista de objetos detectados no arquivo VDX; e o A++, que a verso textual
do diagrama. Os diagramas ASM++ devem estar no formato VDX, utilizado
pelo MS Visio2003/2007 e ConceptDraw. Estes arquivos intermedirios so
utilizados para localizar e detectar erros. O processo termina na gerao dos
arquivos VHDL e/ou Verilog, que podem ser utilizados para realizar simulao
ou sntese em um dispositivo como FPGA. Esta ferramenta se limita apenas a
produzir arquivos na mesma linguagem em que foram escritos os comporta19
Figura 2.10: Exemplo da notao ASM++. Adaptado de (Pablo et. al., 2010).
mentos no processo de modelagem.
2.5.2
Moreira et. al. (2010) prope estender as funcionalidades da ferramenta GenERTiCA (Generation of Embedded Real-Time Code based on Aspects) (Wehrmeister et. al., 2008) desenvolvendo um novo conjunto de regras de mapeamento, para que ela possa gerar automaticamente cdigo VHDL a partir de
um diagrama UML para posteriormente ser utilizado em dispositivos FPGAs.
As regras de mapeamento relacionam elementos da linguagem UML em
construes em VHDL. Por exemplo, as Classes so mapeadas no par Entidade
e Arquitetura (entity-architecture) do VHDL, os atributos pblicos e privados
da Classe so mapeados em portas e sinais na Entidade do cdigo VHDL, os
mtodos so mapeados em processos, e assim por diante.
O processo para a gerao do cdigo VHDL divido em quatro etapas,
mostradas na figura 2.11. Primeiro feito o processo de anlise e identificao
de requisitos para em seguida realizar a modelagem do sistema utilizando
a linguagem UML. A terceira etapa consiste em gerar um novo modelo, que
far o papel da representao intermediria, chamado de DERCS (Distributed
Embedded Compact Specification) (Wehrmeister et. al., 2008). Nesta etapa
tambm so verificadas se h algum tipo de inconsistncia no modelo gerado
para s ento seguir para a ltima etapa, que consiste na gerao do cdigo
VHDL baseado em um conjunto de regras de mapeamento.
Este trabalho contempla apenas o mapeamento de classes e atributos mas
foi o suficiente para desenvolver um pequeno sistema como estudo de caso.
Ainda fica faltando completar o mapeamento UML/VHDL introduzindo o conceito de herana, polimorfismo e associaes. Tambm no realizado ne20
Figura 2.11: Viso geral do processo de gerao de cdigo VHDL a partir de especificaes UML utilizando a ferramenta GenERTiCA. Adaptado de (Moreira
et. al., 2010).
nhum tipo de otimizao do cdigo gerado automaticamente, como por exemplo, reduo de estados. Alm disso a ferramenta tambm se limita a ter como
sada a mesma linguagem de programao utilizada na entrada, j que as
regras de mapeamento se limita em montar a estrutura do cdigo fonte.
21
CAPTULO
3
Material e Mtodos
Este captulo apresenta uma descrio de alguns conceitos e ferramentas utilizados durante a elaborao deste trabalho.
3.1
JavaCC
Este projeto utiliza a ferramenta JavaCC para dar suporte a realizao das
tarefas do frontend do compilador e utilizar a anlise resultante (AST) para a
gerao do backend.
O JavaCC se encaixa na categoria de "Compilador de Compiladores", ou
seja, uma ferramenta utilizada para auxiliar na criao de compiladores. Ele
foi implementado utilizando a linguagem Java e o cdigo por ele gerado tambm apenas na linguagem Java 1 (Norvell, 2007).
Ele foi criado por dois funcionrios que trabalhavam na empresa Sun Microsystems: Sreeni Viswanadha e Sriram Sankar. Desde junho de 2003 ele
um projeto de cdigo aberto e mantido por desenvolvedores da comunidade,
na qual esto includos os autores iniciais.
A funo do JavaCC gerar programas que iro fazer a anlise lxica e
sinttica tendo como entrada uma gramtica definida pelo usurio. Dessa
forma possvel criar um compilador para qualquer linguagem, at mesmo
aquelas que no sejam de programao.
O compilador gerado pelo JavaCC ir ler uma cadeia de caracteres (cdigo
fonte), gerando uma sequncia de objetos conhecidos por tokens baseado na
1
23
3.2
Apache Velocity
package $fsmName;
(* synthesize *)
module mk${fsmName}(Empty);
Reg#(State) state <- mkReg($resetState);
endmodule: mk${fsmName}
endpackage: $fsmName
package ExemploFSM;
2
24
2
3
4
5
6
(* synthesize *)
module mkExemploFSM(Empty);
Reg#(State) state <- mkReg(ESTADO_X);
endmodule: mkExemploFSM
endpackage: ExemploFSM
3.3
Bluespec SystemVerilog
O Bluespec SystemVerilog (BSV) (Bluespec Inc, 2010) uma linguagem de descrio de hardware de alto-nvel e totalmente sintetizvel para hardware que
foi criada pelo prof. Arvind, do Massachusetts Institute of Technology (MIT),
tendo como influncia as linguagens SystemVerilog e Haskell. O objetivo desta
linguagem acelerar o desenvolvimento de sistemas digitais, facilitando a explorao da arquitetura, verificao e desenvolvimento do software, tendo um
ganho de produtividade de 2 a 10 vezes mais rpido em relao ao desenvolvimento em RTL (Bluespec Inc, 2007). Tal desempenho abre possibilidades
para que atividades que antigamente no eram viveis possam ser colocadas
em prtica. Alm disso, o hardware gerado pelo compilador do Bluespec
considerado eficiente (Gruian e Westmijze, 2008; Agarwal, 2009).
Esta linguagem de programao faz parte da ferramenta Bluespec que tambm inclui um compilador, um simulador e um ambiente de desenvolvimento
integrado (IDE). O fluxo de desenvolvimento de um sistema em Bluespec
mostrado na figura 3.1. O compilador do Bluespec recebe como entrada o
cdigo-fonte em BSV. O usurio pode optar por gerar um programa para ser
simulado pelo Bluesim ou gerar o cdigo RTL em Verilog para posterior simulao ou sntese.
Um dos grandes destaques do Bluespec a velocidade nas simulaes dos
sistemas fora de um dispositivo FPGA, atravs do simulador Bluesim, acelerando a execuo de trs at seis ordens de magnitude (Nikhil e Czeck, 2010).
Outra caracterstica marcante no Bluespec so as transaes atmicas (Rules), utilizadas para evitar conflitos no acesso a interfaces dos mdulos, aumentando significativamente o nvel de abstrao de concorrncia que frequentemente a fonte de muitas dificuldades e erros de programao.
Um tpico programa escrito em BSV composto por algumas sees, sendo
que algumas delas so opcionais. Ele pode comear com uma declarao de
pacote (package <nome-do-pacote>). Apesar de no ser obrigatrio, esta uma
25
Figura 3.2: Ilustrao para representar a complexidade de desenvolver precisando fazer o controle de recursos compartilhados e a simplicidade proporcionada pelo Bluespec permitindo ao desenvolvedor focar-se apenas em uma
parte de seu sistema (Bluespec Inc, 2010).
O Bluespec Workstation uma IDE para auxiliar o programador no gerenciamento de um projeto, sendo possvel adicionar vrios mdulos no projeto,
27
Figura 3.3: Bluespec Workstation (janela superior), editor de texto Vim (janela
inferior) e lista de arquivos que fazem parte do projeto (janela esquerda).
O Bluespec oferece o pacote de biblioteca StmtFSM, que uma sub-linguagem para facilitar a representao bem estruturada de mquina de estado
finita. No momento da compilao o Bluespec expande esta sub-linguagem em
regras, da mesma forma que se fosse programar uma MEF sem o auxlio da
StmtFSM. Esta biblioteca permite gerar de forma bem rpida laos no estilo
da linguagem C, blocos paralelos e sequenciais e condies. A listagem 3.3
mostra um exemplo de cdigo Bluespec utilizando a biblioteca de mquina de
estado finita.
Listagem 3.3: Exemplo de cdigo Bluespec utilizando a biblioteca de mquina de estado
finita (Nikhil e Czeck, 2010).
1
2
3
4
5
6
7
28
seq
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
3.4
Padro IP-XACT
29
CAPTULO
4
Implementao da Ferramenta
Proposta
A implementao desta ferramenta foi dividida em dois projetos distintos denominados UML2BSV e C2BSV. O primeiro responsvel por realizar toda a
anlise da modelagem UML e gerar o respectivo hardware de controle da mquina em Bluespec. E o segundo, traduz cdigo descrito em linguagem C para
hardware comportamental, tambm em Bluespec.
A figura 4.1 ilustra de forma detalhada todo o fluxo de processamento, que
tem incio com a exportao no formato XMI 2.1 de uma modelagem UML. Este
arquivo XMI utilizado como entrada para a ferramenta UML2BSV iniciar o
processo de gerao de cdigo BSV. Neste processo realizado um parser
no arquivo XMI onde todos os elementos da modelagem so identificados e,
em conjunto com templates, o cdigo fonte gerado. Durante o processo de
parser, ocorrem chamadas ao compilador C2BSV sempre que houver cdigos
escritos na linguagem C junto com o modelo UML. passado ao compilador
o cdigo C e o retorno o respectivo cdigo traduzido para Bluespec. Os
detalhes envolvidos em cada etapa deste processo ser explorado no decorrer
deste captulo.
A diviso desta ferramenta em dois projetos distintos permite a utilizao
das mesmas de forma independente. Nos casos em que o projetista no utilize cdigo C para descrever o comportamento de algum estado, o UML2BSV
capaz de gerar o hardware sozinho. Porm, nesse caso o comportamento
do modelo tambm dever ser escrito em Bluespec, havendo assim somente a
cpia do mesmo para o local correto no cdigo fonte e integrado com o controle
gerado da UML. Da mesma forma, o compilador C2BSV pode ser utilizado na
31
Modelagem UML
Exportar XMI
Documento XMI
UML2BSV
C2BSV
Parser XMI
Frontend
Diagrama de Classe
Templates
AST
Backend
Renderizar templates
Cdigo BSV
Gerar IP-XACT
Repositrio
RoboArch
(IP-XACT)
Compilador Bluespec
Verilog
Ferramenta de Sntese
32
4.1
UML2BSV
4.1.1
Modelagem UML
A classe com o esteritipo dataType (figura 4.2(b)) utilizada para definir vetores. Cada tipo Vetor declarado tem um nome que o referencia e sua
classe possui dois atributos:
size: define a quantidade de elementos que o vetor ir comportar;
type: declara qual ser o tipo de elementos do vetor.
importante lembrar que para definir um vetor necessrio antes definir
um tipo de dado (primitive) para que este possa ser utilizado na declarao
do vetor. A declarao desta classe resultar em uma construo do tipo
Vector#(size, type), utilizada no Bluespec.
A classe sem nenhum esteritipo, (figura 4.2(c)) utilizada para definir uma
memria do tipo BRAM. Ela possui quatro atributos para sua configurao:
addrWidth: define a largura do endereamento que ser utilizado;
dataWidth: define o tamanho dos dados que sero armazenados;
dualPort: define se a BRAM ser do tipo dual port, atribuindo valor 1 ou
single port atribuindo valor 0;
format: utilizado caso queira especificar um arquivo texto a ser lido com
o contedo inicial que a memria deve ter. As opes permitidas para
este parmetro so:
None: caso no seja necessrio carregar na memria dados de um
arquivo texto;
Hex: caso os dados no arquivo texto estejam em codificao hexadecimal. Por padro o arquivo texto a ser lido ser o nome da memria
com extenso hex (<nome-memria>.hex);
Binary: caso os dados no arquivo texto estejam em codificao binria. Por padro o arquivo texto a ser lido ser o nome da memria
com extenso bin (<nome-memria>.bin);
35
Diagrama de Atividades
Como no h uma forma de representar as entradas, sadas e declaraes de
variveis diretamente no diagrama de estados, e um dos objetivos de no
criar extenses na linguagem UML mantendo-a original, a alternativa encontrada foi a de sub-utilizar o diagrama de atividades para este fim. Embora o
diagrama de atividades visa modelar os fluxos de um processamento atravs
de atividades e decises, ele tambm permite a modelagem de sinais de entrada e sada e declarao de variveis. Neste diagrama tambm encontram-se
as aes, que sero representadas pelo diagrama de estados.
No momento de mapear este diagrama para a linguagem BSV, os sinais de
entrada e sada sero declarados como interface e ser gerado seus respectivos
mtodos de escrita e leitura.
Na figura 4.3 esto representados os elementos utilizados do diagrama de
atividades. O retngulo define uma ao, identificada pelo nome actionTrafficLight, que representa um mdulo em Bluespec. O comportamento desta
ao est representado por um diagrama de estados identificado pelo nome
fsmTrafficLight, que ser abordado na prxima seo. Os sinais de entrada e
sada so posicionados na esquerda e na direita respectivamente, e as variveis ocupam a parte inferior.
Figura 4.3: Ao actionTrafficLight do diagrama de atividades que est relacionada mquina de estados que controla o tempo de um semforo. Na borda
do elemento grfico que representa uma ao encontram-se as declaraes
dos sinais de entrada, sada e variveis.
36
Diagrama de Estados
O diagrama de estados utilizado para modelar o controle e comportamento
de circuitos e composto de um nmero finito de estados, transies e suas
respectivas aes. Como a UML 2 no d suporte para a declaraes de sinais
de entrada e sada, estes devem ser feitos no diagrama de atividades onde esta
mquina de estado est inserida.
As aes que iro ocorrer em cada estado da mquina podem ser escritas tanto em BSV quanto em um subconjunto do C, mas no os dois em
um mesmo estado. Cada ao encontrada na modelagem transformada em
uma rule da linguagem BSV. As condies declaradas nas transies iro fazer parte da condio associada a uma determinada rule que ir determinar o
momento da mesma ser disparada.
A figura 4.4 mostra a modelagem de uma mquina de estado que controla
o tempo em que cada estgio do semforo ficar ligado. Os retngulos representam os estados com seus respectivos nomes aparecendo na parte superior.
No restante do retngulo aparece uma referncia ao comportamento a ser executado em cada estado. As transies esto representadas por setas e as
condies relacionadas aparecem prximas a cada uma delas. Este diagrama
omite alguns detalhes, por exemplo, o cdigo escrito em cada estado, com o
intuito de deixar a modelagem com um visual mais simples. O pequeno crculo preto representa um pseudo-estado e utilizado para indicar qual ser o
estado inicial quando a mquina iniciar sua execuo.
37
4.1.2
XMI
Assim como a UML, o padro XMI tambm foi definido pela OMG com o objetivo de facilitar a troca de metadados usando como estrutura o XML. O seu
uso mais comum na troca de informaes entre ferramentas de modelagem
UML. Com isso, atravs do XMI possvel que uma modelagem feita em uma
determinada ferramenta possa ser utilizada por outras. A escolha do padro
XMI foi devido a esta caracterstica de no deixar o desenvolvedor limitado a
uma ferramenta especfica, tendo que observar apenas se h suporte exportao de XMI na verso 2.1.
Apesar do arquivo XMI ser gerado automaticamente pela ferramenta de
modelagem, importante conhecer como esto estruturadas as informaes
neste padro para tornar mais fcil o prximo passo que a de extrair as
informaes da modelagem.
A listagem 4.1 mostra um exemplo de um arquivo XMI referente modelagem da mquina de estados do semforo. Devido ao fato do arquivo XMI
gerado ser muito verboso tornando-o muito extenso, que uma caracterstica
do XML, esta listagem foi simplificada para melhor visualizao sem prejudicar o entendimento.
Foram retirados trechos que se repetiam e longas strings que so utilizadas
como identificador de cada elemento da modelagem. Tambm foram excludas as tags especficas da ferramenta de modelagem utilizada que guardavam
informaes que no so necessrias para gerar o cdigo BSV, como por exemplo, a posio e o tamanho dos elementos na tela.
Para deixar o texto com uma leitura mais leve, sero omitidas a explicao
de algumas tags j que o objetivo deste trabalho no a de esgotar todo o
assunto sobre XMI.
Listagem 4.1: Trecho de um arquivo XMI do circuito modelado para controlar o tempo
de um semforo.
1
2
3
4
5
7
8
38
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
doGreen visibility=public>
<body>source code goes here</body>
<language>BSV</language>
</doActivity>
</subvertex>
<subvertex xmi:type=uml:Pseudostate xmi:id=... visibility=
public/>
<transition xmi:type=uml:Transition xmi:id=... visibility=
public source=... target=... guard=...>
<ownedRule xmi:type=uml:Constraint xmi:id=... name=
condition_goYellow visibility=public>
<specification xmi:type=uml:OpaqueExpression xmi:id=...
visibility=public>
<body>time == 20</body>
<language>BSV</language>
</specification>
</ownedRule>
</transition>
</region>
</ownedBehavior>
<node xmi:type=uml:CallBehaviorAction xmi:id=... name=
actionTrafficLight visibility=public behavior=...>
<argument xmi:type=uml:ValuePin xmi:id=... name=tempo
visibility=public>
<type xmi:type=uml:PrimitiveType href=http://.../uml.xml#
Integer>
<xmi:Extension extender=MagicDraw UML 17.0>
<referenceExtension referentPath=UML Standard Profile::
UML2 referentType=PrimitiveType/>
</xmi:Extension>
</type>
</argument>
<argument xmi:type=uml:InputPin xmi:id=... name=reset
visibility=public>
<type xmi:type=uml:PrimitiveType href=http://.../uml.xml#
Integer>
<xmi:Extension extender=MagicDraw UML 17.0>
<referenceExtension referentPath=UML Standard Profile::
UML2 referentType=PrimitiveType/>
</xmi:Extension>
</type>
</argument>
<result xmi:type=uml:OutputPin xmi:id=... name=out_red
visibility=public>
<type xmi:type=uml:PrimitiveType href=http://.../uml.xml#
Integer>
<xmi:Extension extender=MagicDraw UML 17.0>
<referenceExtension referentPath=UML Standard Profile::
UML2 referentType=PrimitiveType/>
39
44
45
46
47
48
49
50
</xmi:Extension>
</type>
</result>
</node>
</packagedElement>
</uml:Model>
</xmi:XMI>
4.1.3
Parser do XMI
Listagem 4.2: Trecho de um arquivo XMI do circuito modelado para controlar o tempo
de um semforo.
1
2
3
4
5
6
7
8
9
10
3
4
5
6
7
8
9
As funes findUmlStates, que aparece na listagem 4.4, e findUmlTransitions so bem semelhantes, distinguindo-se apenas no fato de que a primeira
responsvel por instanciar um objeto Estado, seus respectivos atributos e
adicion-lo no ArrayList correspondente e a segunda por instanciar cada transio encontrada, criar o relacionamento com os respectivos estados no qual
ela est associada e tambm adicion-la no respectivo ArrayList. Devido a esta
dependncia necessrio percorrer duas vezes este trecho da rvore.
Listagem 4.4: Cdigo utilizado para localizar os elementos que representam estados no
arquivo XMI.
1
2
3
4
5
6
7
8
9
10
11
12
13
43
4.1.4
Gerao de cdigo
Esta a ltima etapa no fluxo da UML2BSV para gerar o cdigo fonte. Neste
momento todos os elementos representados no arquivo XMI foram identificados e instanciados em seus respectivos objetos. Qualquer inconsistncia ou
erro no arquivo XMI que possa ter ocorrido ser reportado antes deste passo.
A abordagem escolhida para a gerao de cdigo foi com a utilizao de
templates, que representam as estruturas de um cdigo fonte em BSV. O uso
destes templates facilitada pela biblioteca Velocity, um projeto open source
mantido pela Apache Software Foundation, que se adaptou muito bem nas
necessidades deste trabalho.
O primeiro passo foi definir os templates a serem utilizados, abstraindo
uma estrutura padro encontrada em um cdigo BSV. O Velocity possui um
sistema de templates bem flexvel atravs do uso de sua prpria linguagem,
VTL. Esta caracterstica importante pois desta forma cada template fica com
um tamanho reduzido, facilitando o entendimento e manuteno dos mesmos.
Os templates so formados por: constantes, que so textos que no iro
sofrer mudanas durante o processo de renderizao e que, neste caso, representam a estrutura do cdigo fonte; por variveis, que so os trechos de
cdigos que representam a lgica da programao; e por estruturas de cdigo
da linguagem VTL como IFs ou LOOPs.
O diagrama representado pela figura 4.6 mostra como est organizada a
estrutura de templates responsvel pela gerao do cdigo deste trabalho. Ela
formada por um template principal que representa todo o mdulo de um
cdigo em BSV e que engloba templates menores, fazendo chamadas a eles
durante o processo de renderizao. Estes templates filhos foram criados para
simplificar o desenvolvimento, deixando o template principal com menos linhas de cdigo. Eles representam determinados trechos de um mdulo como
interface, enumerator (utilizado para a representar os estados) e as regras.
A listagem 4.5 mostra o contedo do template que representa um mdulo
em BSV. Na linha 1 pode-se observar um exemplo simples do funcionamento
do sistema de templates do Velocity. A palavra-chave package aparece como
uma constante e a varivel $fsmName ser substituda pelo nome do pacote
do mdulo a ser gerado.
Listagem 4.5: Cdigo de um template na linguagem VTL que representa um mdulo em
BSV, com chamadas outros templates.
1
package $fsmName;
2
3
4
5
6
44
Mdulo BSV
Interface
Enumerator
Rules
Methods
#parse ("templates/interface.vm")
9
10
11
12
13
14
(* synthesize *)
module mk${fsmName}(I_${fsmName});
#if ($thereIsBRAM)BRAM_Configure cfg = defaultValue;#end
15
16
#parse ("templates/bram.vm")
17
18
19
20
#parse ("templates/rule.vm")
21
22
#parse ("templates/methods.vm")
23
24
endmodule: mk${fsmName}
25
26
endpackage: $fsmName
5
6
#end
Voltando ao exemplo referente primeira linha da listagem 4.5, a informao do nome do pacote armazenada em uma estrutura de HashMap na qual
os elementos inseridos nela so sempre aos pares, chave e valor. Neste caso,
a chave tem o valor fsmName e o valor o retorno de uma String da funo
getName() pertencente classe FSM. O valor a ser inserido neste HashMap
pode ser qualquer objeto, por exemplo, uma string, um estado ou at mesmo
uma coleo de transies.
Na listagem 4.7 demonstrado como tornar essas informaes disponveis
para o template. Na linha 4 passado ao Velocity qual o template principal
que ser utilizado para gerar o cdigo. Na linha 5 instanciado um objeto
do tipo VelocityContext que utiliza uma estrutura de HashMap, explicada anteriormente, onde sero armazenados todas as informaes relacionadas
mquina de estado modelada. Este o objeto que faz a ligao entre as informaes que esto em memria e os templates. Em seguida pode-se ter uma
ou mais chamadas ao mtodo put para inserir o par chave/valor no HashMap.
Neste exemplo so armazenados no VelocityContext o nome da mquina de
estado (como string) e a lista de estados e transies (ambos como List). E
por ltimo feita a chamada que ir gerar o cdigo baseado nas informaes
passadas ao template, onde o resultado fica armazenado em um objeto do tipo
StringWriter que poder ser salvo em um arquivo ou, como acontece neste
exemplo, o contedo enviado para a console.
Listagem 4.7: Trecho de cdigo utilizado para passar as informaes coletadas durante
o parser do arquivo XMI para os templates do Velocity.
1
46
2
3
4
5
6
7
8
9
10
11
12
4.1.5
Figura 4.7: Representao de um conjunto de estados e suas respectivas definies em Bluespec. O cdigo na parte inferior da imagem representa a declarao de um novo tipo de dado State, da categoria enumerator, onde esto
includos todos os estados da modelagem. E o cdigo direita mostra trecho
das rules para cada estado que foi modelado.
4.2
Compilador C2BSV
49
-root
- AssignEqual [=]
- Identifier [resultado]
- Addition [+]
Divison [/]
Int [9]
Multiplication [*]
Addition [+]
Int [1]
Int [3]
Int [4]
Int [5]
-root
- While
- Condition
Equal [==]
Identifier [x]
Int [1]
- Do
Statement
9
10
Atualmente este compilador abrange somente um subconjunto da linguagem C. Apesar da gramtica utilizada estar bem completa, apenas parte das
instrues foram implementadas. A tabela 4.2 mostra os ns da AST que
foram implementados at o momento.
Tabela 4.2: Ns da AST do compilador C2BSV que foram implementados.
ASTStatement
ASTUnaryExpression
ASTNegative
ASTDivision
ASTMultiplication
ASTInt
ASTAND
ASTEqual
ASTGreater
ASTLess
ASTIf
ASTElse
ASTAssignEqual
ASTPositive
ASTAddition
ASTSubtraction
ASTIdentifier
ASTCondition
ASTOR
ASTNotEqual
ASTGreaterOrEqual
ASTLessOrEqual
ASTThen
ASTPosition
52
CAPTULO
5
Aplicaes da Ferramenta Proposta
5.1
Processador
O processador desenvolvido foi baseado no mesmo que utilizado na disciplina Elementos de Lgica Digital II (SSC-113) no Instituto de Cincias Matemticas e de Computao (ICMC).
O processador tem a arquitetura do tipo RISC com instrues de 16 bits,
possui 8 registradores de uso geral e uma nica memria dividida em duas
partes, sendo o incio reservado para as instrues e o restante para os da1
Mais detalhes sobre o kit de desenvolvimento Terasic DE2-70 pode ser encontrado no site:
http://www.terasic.com.tw/cgi-bin/page/archive.pl?No=226
53
5.1.1
Modelagem do processador
Significado
RX RY
RX MEM(RY)
MEM(RY) RX
RX #N R
STOREIMED
MEM(RX) #N R
Opcode
110011|RX|RY|xxx|x
111100|RX|RY|xxx|x
111101|RX|RY|xxx|x
111000|RX|xxx|xxx|x
NR
111001|RX|xxx|xxx|x
NR
Significado
RX RY + RZ
RX RY - RZ
RX RY * RZ
RX RY / RZ
Opcode
100000|RX|RY|RZ|0
100001|RX|RY|RZ|0
100010|RX|RY|RZ|0
100011|RX|RY|RZ|0
Opcode
000000|x|xxxxxxxxx
001111|x|xxxxxxxxx
5.1.2
Resultados
1110000000000000
0000001001000001
1110000010000000
0000000000111011
1110000100000000
0001101001011110
1110010010000000
1111111111111111
//
//
//
//
//
//
//
//
LOADIMED RX
577
LOADIMED RY
59
LOADIMED RZ 6750
6750
STOREIMED RY 65535
65535
57
RX <- 577
RY <- 59
RZ <- 6750
MEM(RY) <- 65535
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
1111000110010000
1000000000010100
1100110000110000
1000010000100010
0000000000000000
0011110000000000
...
0000000000011101
0000000000000000
0000000000000011
0000000000000100
0000000000000101
0000000000000110
0000000000000111
...
//
//
//
//
//
//
LOADINDEX RT RY
ADD RX RY RZ
MOV RX RT
SUB RX RZ RY
NOP
HALT
RT
RX
RX
RX
<<<<-
MEM(RY)
59 + 6750
RT
RZ - RY
A validao do processador foi realizada atravs da simulao com o Bluesim. Durante a simulao observou-se as sadas impressas no terminal com
os valores dos registradores a cada instruo para avaliar se estavam corretos. Todas as instrues implementadas tiveram o comportamento esperado e
o programa foi executado com sucesso.
Tambm foi realizada a sntese na ferramenta Quartus II do cdigo Verilog
gerado a partir da compilao do cdigo BSV pelo Bluespec. O resultado da
sntese encontra-se na listagem 5.2
Listagem 5.2: Resultado da sntese do processador pela ferramenta Quartus II.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
Fitter Summary
-----------------------------------------------------------------------Fitter Status
Successful - Thu Feb 14 23:49:29 2013
Quartus II 32-bit Version
11.1 Build 173 11/01/2011 SJ Web
Revision Name
processador
Top-level Entity Name
mkProcessor
Family
Cyclone II
Device
EP2C70F896C6
Timing Models
Final
Total logic elements
1,363 / 68,416 ( 2 % )
Total combinational functions 1,343 / 68,416 ( 2 % )
Dedicated logic registers
256 / 68,416 ( < 1 % )
Total registers
256
Total pins
7 / 622 ( 1 % )
Total virtual pins
0
Total memory bits
1,024 / 1,152,000 ( < 1 % )
Embedded Multiplier 9-bit elements 2 / 300 ( < 1 % )
Total PLLs
0 / 4 ( 0 % )
19
20
21
58
22
23
24
25
26
27
28
29
-----------------------------------------------------------------------Resource
Usage
-----------------------------------------------------------------------M4Ks
1 / 250 ( < 1 % )
Total block memory bits
1,024 / 1,152,000 ( < 1 % )
Total block memory implementation bits
4,608 / 1,152,000 ( < 1 % )
Embedded Multiplier 9-bit elements
2 / 300 ( < 1 % )
PLLs
0 / 4 ( 0 % )
30
31
32
33
34
35
36
No apndice A encontra-se o cdigo fonte BSV completo gerado pela ferramenta UML2BSV deste processador.
5.2
0
0
0
1
2
1
104 76 68
121 87 111
117 91 106
106 103 102
100 92 106
112 87 106
..
..
..
..
.
.
.
.
156 156 116 98 103 118
96
152
146
135
134
156
..
.
118
130
128
139
141
139
..
.
140
134
101
109
106
109
108
115
1 0 1
2 0 2
1 0 1
w
166
..
..
.. .. .. . .
.
.
.
. . .
5.2.1
Quando o sinal start recebido, a transio para o estado For_j disparada. Neste ponto possvel observar a utilizao dos estados For_j e For_i
para formar um lao aninhado. O que seria a condio do lao representada
pela condio na transio entre os estados. As inicializaes das variveis de
controle so feitas no estado anterior e seu incremento feito nos respectivos
estados.
Em seguida vem um conjunto de estados do Step1 ao Step9. Neles carregada a janela de pixels utilizada para calcular um pixel da imagem destino.
Note que foram necessrios todos estes estados pois s possvel ler um pixel
a cada ciclo de relgio. Uma verso alternativa deste filtro seria utilizar uma
memria dual port, assim num nico ciclo de relgio seria possvel ler dois
pixels da memria de endereos distintos.
Depois de carregados os pixels necessrios, so realizados os dois clculos,
um para convoluo horizontal e o outro para a vertical. Como estas operaes
no tem dependncia de dados entre si, possvel realiz-las em paralelo. Os
estados seguintes complementam a operao do filtro Sobel e o ltimo passo,
deste ciclo, termina no estado Result.
Neste caso, onde a simulao deste hardware foi realizada num computador, optou-se por imprimir diretamente na tela o valor do pixel calculado.
Assim, na hora de simular, toda a sada foi direcionada para um arquivo para
posteriormente ser analisado e validar o resultado. Alternativamente, este estado poderia ser responsvel por armazenar todos os pixels de sada em uma
segunda memria.
Depois de passar pelo estado Result, a execuo retorna ao estado For_i.
Caso ainda tenha colunas de pixels a serem processadas ele incrementa sua
varivel de controle e passa novamente para o Step1 e assim sucessivamente.
Caso contrrio ele retorna ao estado For_j que tambm verifica se ainda h
linhas a serem processadas. Existindo, a sua varivel de controle incrementada e ele volta ao estado For_i, caso contrrio a execuo desviada para o
estado final.
No estado EndSobel, o sinal ready ativado, indicando que toda a imagem
j foi processada, assim o processo encerrado.
O diagrama de estados da figura 5.5 mostra apenas os estados e transies,
ocultando todas as instrues que definem o comportamento de cada estado.
Afim de ilustrar melhor como definido o comportamento de cada estado,
a figura 5.6 mostra uma captura de tela da ferramenta UML utilizada neste
trabalho.
Esta uma janela de propriedades referente ao estado CalcHV, onde possvel observar duas delas em destaque:
Language, onde definida qual a linguagem utilizada para descrever o
62
Figura 5.7: Ao que representa o filtro Sobel com os sinais de entrada localizados esquerda, os de sada direita e as variveis de uso local na regio
inferior.
i, j Int#32
kernelH, kernelV Int#32
pixelOut Int#32
5.2.2
Resultados
Como forma de testar o filtro Sobel gerado pela ferramenta UML2BSV, a partir
da modelagem UML, foi utilizada uma imagem colorida (5.8(a)) com dimenses
128x128 pixels.
Para que seja possvel realizar a simulao do filtro Sobel necessrio antes trabalhar com a imagem para carreg-la na memria em codificao hexadecimal. Nesta tarefa foi utilizado o software GNU Octave, sendo necessrio
executar os seguintes passos:
abrir o arquivo contendo a imagem atravs da funo fopen();
fazer a leitura do contedo do arquivo com a funo fread(). O resultado
desta funo uma matriz contendo os valores de cada pixel da imagem;
rotacionar a imagem para que ela fique na posio correta. Isto pode ser
feito achando a transposta da matriz da imagem;
salvar esta matriz em um arquivo no formato texto com o comando save.
Neste exemplo, o contedo que ser carregado na memria deve estar no
formato hexadecimal. Portanto necessrio converter os valores de cada pixel da matriz. Para isto foi desenvolvido um pequeno script em Python para
converter nmeros da base decimal para hexadecimal.
64
Depois que o filtro Sobel foi aplicado, necessrio ler a matriz resultante
e realizar o processo inverso, gerando a imagem a partir desta matriz. Novamente utilizando o GNU Octave, primeiro a matriz lida, depois utilizada a
funo reshape() para deixar a imagem com as dimenses corretas e por fim
utilizada a funo imagesc() para visualizar a imagem resultante.
Pelo fato da imagem utilizada ser colorida, o filtro Sobel precisa ser aplicado
nos trs canais (R, G, B) separadamente, portanto so necessrios realizar os
passos descritos anteriormente para cada canal de cor da imagem.
O resultado da aplicao do filtro Sobel pode ser visualizado na figura
5.8(b).
(b) Imagem aps a aplicao do filtro Sobel nos trs canais R, G e B, separadamente
Figura 5.8: Resultado da aplicao do filtro Sobel na imagem (a) pelo circuito
modelado em UML na figura 5.5.
O resultado da sntese realizada na ferramenta Quartus II do cdigo Verilog
gerado a partir da compilao do cdigo BSV pelo Bluespec encontra-se na
listagem 5.3
Listagem 5.3: Resultado da sntese do filtro Sobel pela ferramenta Quartus II.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
Fitter Summary
-----------------------------------------------------------------------Fitter Status
Successful - Thu Feb 14 22:51:20 2013
Quartus II 32-bit Version
11.1 Build 173 11/01/2011 SJ Web
Revision Name
sobel
Top-level Entity Name
mkSobelFSM
Family
Cyclone II
Device
EP2C70F896C6
Timing Models
Final
Total logic elements
1,459 / 68,416 ( 2 % )
Total combinational functions 1,287 / 68,416 ( 2 % )
Dedicated logic registers
574 / 68,416 ( < 1 % )
Total registers
574
Total pins
75 / 622 ( 12 % )
Total virtual pins
0
65
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
No apndice B encontra-se o cdigo fonte BSV completo gerado pela ferramenta UML2BSV do filtro Sobel.
66
Concluso
Este trabalho apresentou uma nova ferramenta capaz de gerar cdigo Bluespec SystemVerilog atravs de uma modelagem UML. A ferramenta tambm
permite a utilizao de um subconjunto da linguagem C para descrever o comportamento dos estados. Para isso, tambm foi desenvolvido um compilador
que realiza a traduo da linguagem C para cdigo BSV.
Uma das preocupaes deste trabalho foi a de no realizar extenso na
UML. Desta forma, utilizando apenas os diagramas e seus respectivos elementos da UML padro possvel modelar e gerar arquiteturas de hardware
por meio de qualquer ferramenta de modelagem UML que tenha suporte a
exportao no formato XMI 2.1.
Apesar das duas ferramentas trabalharem de forma bem integrada, o desenvolvimento delas foi pensado em deix-las independentes. Portanto, tanto
a UML2BSV quanto o compilador C2BSV podem ser utilizados em outros projetos de pesquisa.
Como validao da ferramenta foram implementados dois casos bem distintos: um processador de propsito geral e um elemento de processamento
do filtro Sobel. Nos dois casos foi possvel perceber que a ferramenta facilitou a gerao de hardware. Um programador que conhea a linguagem C,
mquina de estados e que tenha o mnimo de noo de hardware capaz de
gerar circuitos como os utilizados neste exemplo.
Outra facilidade proporcionada pela ferramenta a programao de cdigo
em paralelo, ficando a cargo do programador a anlise do que pode ser executado no mesmo ciclo de relgio, e colocar estas instrues em um mesmo
estado.
Durante o desenvolvimento deste trabalho foram observadas algumas melhorias e novas funcionalidades que agregariam ainda mais funcionalidades a
esta ferramenta. O principal seria o desenvolvimento para dar suporte execuo de mquinas de estados paralelas. At o momento apenas uma Ao
modelada no diagrama de atividades. Como cada Ao est associada a
67
68
Referncias Bibliogrficas
B LUESPEC I NC
Complete set of Training Slides for BSV.
http://
www.bluespec.com/forum/viewtopic.php?t=7, [Online; acessado em 12Maro-2010], 2007.
B LUESPEC I NC
The Synthesizable Modeling Company.
http://www.
bluespec.com/, [Online; acessado em 10-Outubro-2010], 2010.
B OBDA , C.
2007.
Berlin: Springer,
McGraw-
Birmingham,
G RUIAN , F.; W ESTMIJZE , M. VHDL vs. Bluespec system verilog: a case study
on a Java embedded architecture. In: Proceedings of the 2008 ACM
symposium on Applied computing, SAC 08, New York, NY, USA: ACM,
2008, p. 14921497 (SAC 08, v.).
H AUCK , S.; D E H ON , A. Reconfigurable computing: the theory and practice of FPGA-based computation. San Diego: Morgan Kaufmann, 2008.
HDL W ORKS EASE Graphical HDL Entry. [On-line].
Disponvel em:
<http://www.hdlworks.com/products/ease/index.
html/>.
H OPCROFT, J. E.; M OTWANI , R.; U LLMAN , J. D. Introduction to automata
theory, languages, and computation. 2nd ed.. Addison Wesley, 2000.
M ARQUES F ILHO , O.; N ETO , H.
port, 1999.
M AR TIN , G.; B AILEY, B.; P IZIALI , A. ESL Design and Verification: A Prescription for Electronic System Level Methodology (Systems on Silicon).
Morgan Kaufmann, 2007.
M EALY, G. A method for synthesizing sequential circuits. Bell Systems
Technical Journal, v. 34, n. 5, p. 10451079, september, 1955.
M ENTOR G RAPHICS Handel-C Synthesis Methodology. http://www.mentor.
com/products/fpga/handel-c/, [Online; acessado em 19-Novembro2010], 2010.
M ENTOR G RAPHICS C ORPORATION HDL Designer. [On-line].
Disponvel em: <http://www.mentor.com/products/fpga/hdl_design/
hdl_designer_series/>.
71
In: Auto-
M OREIRA , T.; W EHRMEISTER , M.; P EREIRA , C.; P ETIN , J.-F.; L EVRAT, E. Automatic code generation for embedded systems: From UML specifications to
VHDL code. In: Industrial Informatics (INDIN), 2010 8th IEEE International Conference on, 2010, p. 1085 1090.
M UCHNICK , S. Advanced compiler design and implementation.
ego: Morgan Kaufmann, 1997.
N ELSON , V. P.; N AGLE , H. T.; C ARROLL , B. D.; I RWIN , D.
circuit analysis and design. Prentice Hall, 1995.
San Di-
Digital logic
DE
P ABLO , S.; C CERES , S.; C EBRIN , J.; S ANZ , F. Diseo de Circuitos Digitales
a Nivel de Registro empleando Diagramas ASM++. Informacin Tecnolgica, v. 21, n. 2, p. 91102, march, 2010.
P ARR , T. The definitive antlr reference: Building domain-specific languages (pragmatic programmers). Pragmatic Bookshelf, 2007.
P ILONE , D.; P ITMAN , N. UML 2.0 in a Nutshell. OReilly, 2005.
R IEDER , M.; S TEINER , R.; B ER THOUZOZ , C.; C OR THAY, F.; S TERREN , T.
Synthesized UML, a Practical Approach to Map UML to VHDL. In: G UELFI ,
N.; S AVIDIS , A., eds. Rapid Integration of Software Engineering Techniques, v. 3943 de Lecture Notes in Computer Science.
Springer Berlin
Heidelberg, 2006. p. 203217.
Disponvel em: <http://dx.doi.org/10.1007/11751113_15>.
S AFONOV, V. O. Trustworthy compilers (quantitative software engineering series). Wiley, 2010.
72
S HUKLA , S.; P IXLEY, C.; S MITH , G. Guest Editors Introduction: The True
State of the Art of ESL Design. Design Test of Computers, IEEE, v. 23,
n. 5, p. 335 337, maio, 2006.
TIOBE S OFTWARE
TIOBE Programming Community Index for November
2010.
http://www.tiobe.com/index.php/content/paperinfo/tpci/
index.html, [Online; acessado em 29-Novembro-2010], 2010.
T RAN , V.-A.; Q IN , S.; C HIN , W. An Automatic Mapping from Statecharts to
Verilog. In: L IU , Z.; A RAKI , K., eds. Theoretical Aspects of Computing ICTAC 2004, v. 3407 de Lecture Notes in Computer Science. Springer Berlin
Heidelberg, 2005. p. 187203.
Disponvel em: <http://dx.doi.org/10.1007/978-3-540-31862-0_15>
.
U NIVERSITY OF M ANNHEIM - C OMPUTER A RCHITECTURE G ROUP FSMDesigner4 - A high-level design entry tool. [On-line].
Disponvel em: <http://sourceforge.net/projects/fsmdesigner/>.
W EHRMEISTER , M.; F REITAS , E.; P EREIRA , C.; R AMMIG , F. Genertica: A
tool for code generation and aspects weaving. In: Object Oriented RealTime Distributed Computing (ISORC), 2008 11th IEEE International
Symposium on, Los Alamitos, CA, USA: IEEE Computer Society, 2008, p.
234 238.
W OLF, W.
2005.
Computers as components.
W OOD , S.; A KEHURST, D.; U ZENKOV, O.; H OWELLS , W.; M C D ONALD -M AIER ,
K. A Model-Driven Development Approach to Mapping UML State Diagrams
to Synthesizable VHDL. Computers, IEEE Transactions on, v. 57, n. 10,
p. 1357 1371, oct., 2008.
X I , C.; H UA , L. J.; Z U C HENG , Z.; YAO H UI , S. Modeling SystemC design in
UML and automatic code generation. In: Design Automation Conference,
2005. Proceedings of the ASP-DAC 2005. Asia and South Pacific, 2005,
p. 932 935 Vol. 2.
73
A PNDICE
A
Cdigo fonte BSV do Processador
gerado automaticamente pela
ferramenta UML2BSV
package Processor;
2
3
4
5
import Vector::*;
import BRAM::*;
function BRAMRequest#(Bit#(6), Bit#(16)) makeRequest(Bool write, Bit#(6)
addr, Bit#(16) data);
return BRAMRequest { write: write, responseOnWrite: False, address:
addr, datain: data };
endfunction
8
9
10
11
12
(* synthesize *)
module mkProcessor(Empty);
13
14
15
16
17
75
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
LOADIMED1;
STOREIMED1;
LOADINDEX1;
STOREINDEX;
MOV;
ADD;
SUB;
MUL;
DIV;
NOP;
HALT;
58
59
60
61
62
63
64
65
66
76
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
77
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
endmodule
133
134
endpackage
78
A PNDICE
B
Cdigo fonte BSV do filtro Sobel
gerado automaticamente pela
ferramenta UML2BSV
package SobelFSM;
2
3
4
import BRAM::*;
function BRAMRequest#(Bit#(14), Int#(32)) makeRequest(Bool write, Bit
#(14) addr, Int#(32) data);
return BRAMRequest { write: write, responseOnWrite: False, address:
addr, datain: data };
endfunction
7
8
9
10
11
12
13
interface I_SobelFSM;
method Action in_start(Bit#(1) p_start);
method Action in_cols(Int#(32) p_cols);
method Action in_rows(Int#(32) p_rows);
method Bit#(1) out_ready();
endinterface: I_SobelFSM
14
15
16
17
(* synthesize *)
79
18
module mkSobelFSM(I_SobelFSM);
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
80
66
67
68
mOriginal.portA.request.put(makeRequest(False, truncate(pack((i+(
j*cols)+2))), ?));
state <= STEP4;
endrule
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
81
108
109
110
mOriginal.portA.request.put(makeRequest(False, truncate(pack((i+(
j*cols)+cols+2))), ?));
state <= STEP6;
endrule
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
82
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
endmodule: mkSobelFSM
173
174
endpackage: SobelFSM
83
A PNDICE
C
Gramtica do compilador C2BSV
DOCUMENT START
TOKENS
<DEFAULT> SKIP : {
" "
| "\t"
| "\n"
| "\r"
| <"//" (~["\n","\r"])* ("\n" | "\r" | "\r\n")>
| <"/*" (~["*"])* "*" ("*" | ~["*","/"] (~["*"])* "*")* "/">
| "#" : PREPROCESSOR_OUTPUT
}
13
14
15
16
<PREPROCESSOR_OUTPUT> SKIP : {
"\n" : DEFAULT
}
17
18
19
20
21
22
<PREPROCESSOR_OUTPUT> MORE : {
"\\\n"
| "\\\r\n"
| <~[]>
}
23
24
25
<DEFAULT> TOKEN : {
<INTEGER_LITERAL: <DECIMAL_LITERAL> (["l","L"])? | <HEX_LITERAL> (["l","L
"])? | <OCTAL_LITERAL> (["l","L"])?>
85
26
27
28
29
30
31
32
|
|
|
|
33
34
35
36
37
38
39
40
41
42
43
<DEFAULT> TOKEN : {
<RETURN: "return">
| <STRUCT: "struct">
| <WHILE: "while">
| <FLOAT: "float">
| <ELSE: "else">
| <VOID: "void">
| <INT: "int">
| <IF: "if">
}
44
45
46
47
48
49
50
<DEFAULT> TOKEN : {
<IDENTIFIER: <LETTER> (<LETTER> | <DIGIT>)*>
| <#LETTER: ["$","A"-"Z","_","a"-"z"]>
| <#DIGIT: ["0"-"9"]>
| <SEMICOLON: ";">
}
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
NON-TERMINALS
TranslationUnit := ( ExternalDeclaration )+
ExternalDeclaration := ( StatementList | Declaration )
FunctionDefinition := ( DeclarationSpecifiers )? Declarator (
DeclarationList )? CompoundStatement
Declaration := DeclarationSpecifiers ( InitDeclaratorList )? ";"
DeclarationList := ( Declaration )+
DeclarationSpecifiers := TypeSpecifier ( DeclarationSpecifiers )?
TypeSpecifier := ( <VOID> | <INT> | <FLOAT> | StructSpecifier )
StructSpecifier := ( <STRUCT> ) ( ( ( <IDENTIFIER> ) )? "{"
StructDeclarationList "}" | <IDENTIFIER> )
StructDeclarationList := ( StructDeclaration )+
InitDeclaratorList := InitDeclarator ( "," InitDeclarator )*
InitDeclarator := Declarator ( "=" Initializer )?
StructDeclaration := SpecifierQualifierList StructDeclaratorList ";"
SpecifierQualifierList := TypeSpecifier ( SpecifierQualifierList )?
StructDeclaratorList := StructDeclarator ( "," StructDeclarator )*
86
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
87
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
DOCUMENT END
88