Uma ferramenta geradora de cdigo Bluespec

SystemVerilog a partir de mquina de estados

finitos descrita em UML e C

Srgio Henrique Moraes Durand

SERVIO DE PS-GRADUAO DO ICMC-USP

Data de Depsito:
Assinatura:________________________
______

Uma ferramenta geradora de cdigo Bluespec

SystemVerilog a partir de mquina de estados
finitos descrita em UML e C

Srgio Henrique Moraes Durand

Orientador: Prof. Dr. Vanderlei Bonato

Dissertao apresentada ao Instituto de Cincias

Matemticas e de Computao - ICMC-USP, como
parte dos requisitos para obteno do ttulo de Mestre
em Cincias - Cincias de Computao e Matemtica
Computacional. VERSO REVISADA

USP So Carlos
Fevereiro de 2013

Ficha catalogrfica elaborada pela Biblioteca Prof. Achille Bassi

e Seo Tcnica de Informtica, ICMC/USP,
com os dados fornecidos pelo(a) autor(a)

D948f

Durand, Srgio Henrique Moraes

Uma ferramenta geradora de cdigo Bluespec
SystemVerilog a partir de mquina de estados finitos
descrita em UML e C / Srgio Henrique Moraes Durand;
orientador Vanderlei Bonato. -- So Carlos, 2013.
88 p.
Dissertao (Mestrado - Programa de Ps-Graduao em
Cincias de Computao e Matemtica Computacional) -Instituto de Cincias Matemticas e de Computao,
Universidade de So Paulo, 2013.
1. ARQUITETURA RECONFIGURVEL. 2. COMPUTAO
RECONFIGURVEL. 3. CINCIA DA COMPUTAO. I. Bonato,
Vanderlei, orient. II. Ttulo.

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

O contnuo avano da capacidade dos circuitos integrados e a necessidade de

sistemas embarcados cada vez mais complexos para lidar com os problemas
atuais, com prazos cada vez mais curtos, esto direcionando o desenvolvimento de sistemas de circuitos integrados para ambientes de alto nvel de
abstrao cada vez mais distantes dos detalhes de hardware. O uso de linguagens de alto nvel para auxiliar o desenvolvimento de sistemas embarcados
uma tendncia atual pois tal abordagem tende a reduzir a complexidade e o
tempo de desenvolvimento. Este trabalho prope o desenvolvimento de uma
nova ferramenta para gerao de arquiteturas de hardware em Bluespec em
um ambiente grfico utilizando diagramas da UML. Esta ferramenta permite
que o projetista descreva o comportamento utilizando mquina de estados
finita no padro UML 2.0, onde cada estado pode conter a codificao do comportamento com as linguagens Bluespec e C. Dada uma mquina de estados,
a mesma traduzida para a linguagem Bluespec por meio de um compilador
e templates. Como resultado, apresentado a gerao de duas arquiteturas
de hardware a fim de demonstrar as vantagens e limitaes da ferramenta
desenvolvida.

Palavras-chave: Sistemas Embarcados, Bluespec, UML, ESL.

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.

Keywords: Embedded Systems, Bluespec, UML, ESL.

Sumrio

Sumrio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii
Lista de Figuras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

xv

Lista de Tabelas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii

Lista de Cdigos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xix
Lista de Abreviaturas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxi
1 Introduo

1.1 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1.1 Objetivo Geral

. . . . . . . . . . . . . . . . . . . . . . . . . .

1.1.2 Objetivos Especficos

4
4

. . . . . . . . . . . . . . . . . . . . . .

1.2 Justificativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.3 Organizao do Texto . . . . . . . . . . . . . . . . . . . . . . . . . .

2 Fundamentao Terica

2.1 Unified Modeling Language (UML) . . . . . . . . . . . . . . . . . . .

2.2 Mquina de Estados Finitos . . . . . . . . . . . . . . . . . . . . . . 10

2.2.1 Minimizao de estados . . . . . . . . . . . . . . . . . . . . . 13
2.3 Compiladores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3.1 Frontend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.3.2 Backend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.4 RoboArch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.5 Trabalhos Relacionados . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.5.1 ASM++ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.5.2 GenERTiCA com mapeamento em VHDL . . . . . . . . . . . 20
3 Material e Mtodos

23

3.1 JavaCC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2 Apache Velocity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.3 Bluespec SystemVerilog . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.4 Padro IP-XACT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
xi

4 Implementao da Ferramenta Proposta

4.1 UML2BSV . . . . . . . . . . . . . . . . . . . .
4.1.1 Modelagem UML . . . . . . . . . . . .
4.1.2 XMI . . . . . . . . . . . . . . . . . . . .
4.1.3 Parser do XMI . . . . . . . . . . . . . .
4.1.4 Gerao de cdigo . . . . . . . . . . .
4.1.5 Exemplos de gerao de cdigo BSV .
4.2 Compilador C2BSV . . . . . . . . . . . . . .

.
.
.
.
.
.
.

5 Aplicaes da Ferramenta Proposta

5.1 Processador . . . . . . . . . . . . . . . . . . . .
5.1.1 Modelagem do processador . . . . . . .
5.1.2 Resultados . . . . . . . . . . . . . . . .
5.2 Elemento de Processamento de Imagem Sobel
5.2.1 Modelagem do filtro Sobel . . . . . . . .
5.2.2 Resultados . . . . . . . . . . . . . . . .

.
.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.
.

31
33
33
38
41
44
47
48

.
.
.
.
.
.

53
53
54
57
59
60
64

Concluso

67

Referncias Bibliogrficas

69

A Cdigo fonte BSV do Processador gerado automaticamente pela ferramenta UML2BSV

75
B Cdigo fonte BSV do filtro Sobel gerado automaticamente pela ferramenta UML2BSV
79
C Gramtica do compilador C2BSV

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.

1.2 Viso geral do processo de gerao de cdigo Bluespec SystemVerilog. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.1 Diagrama de classes com a classificao dos 14 diagramas da

UML. Adaptado de (Fowler, 2003). . . . . . . . . . . . . . . . . . . .

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

2.5 Representao de um diagrama ASM (Nelson et. al., 1995). . . . . 13

2.6 Fases de um compilador. Adaptado de (Aho et. al., 1986). . . . . . 15
2.7 Analisador Lxico. Adaptado de (Norvell, 2007). . . . . . . . . . . . 16
2.8 Analisador Sinttico. Adaptado de (Norvell, 2007). . . . . . . . . . 17
2.9 Exemplo de simulao de sistema embarcado via Player/Stage. . 19
2.10 Exemplo da notao ASM++. Adaptado de (Pablo et. al., 2010). . . 20
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). . . . . . . . . . . . . . . . . . . . . . . . . 21
3.1 Fluxo de desenvolvimento do Bluespec. Adaptado de (Bluespec
Inc, 2007). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
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). 27
3.3 Bluespec Workstation (janela superior), editor de texto Vim (janela inferior) e lista de arquivos que fazem parte do projeto (janela
esquerda). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
xiii

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

5.4 Definio dos tipos de dados utilizados na modelagem do filtro

Sobel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.5 Diagrama de estados do filtro Sobel. . . . . . . . . . . . . . . . . .
5.6 Captura de tela da ferramenta UML onde o comportamento do
estado CalcHV definido utilizando a linguagem C. . . . . . . . .
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. . . . . . . . . . . . . . . . . . . . . . . . . .
5.8 Resultado da aplicao do filtro Sobel na imagem (a) pelo circuito
modelado em UML na figura 5.5. . . . . . . . . . . . . . . . . . . .

xv

61
61
63

64
65

Lista de Tabelas

2.1 Tabela de estado da MEF da figura 2.2 . . . . . . . . . . . . . . . . 14

4.1 Equivalncia entre os tipos de dados em C e Bluespec. . . . . . . 35
4.2 Ns da AST do compilador C2BSV que foram implementados. . . 51
5.1 Instrues de manipulao de dados. . . . . . . . . . . . . . . . . . 55
5.2 Instrues aritmticas. . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.3 Instrues de controle. . . . . . . . . . . . . . . . . . . . . . . . . . 56

xvii

Lista de Cdigos

3.1 Exemplo de um template do Apache Velocity. . . . . . . . . . . . .

3.2 Exemplo de um cdigo renderizado partir de um template do
Apache Velocity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3 Exemplo de cdigo Bluespec utilizando a biblioteca de mquina
de estado finita (Nikhil e Czeck, 2010). . . . . . . . . . . . . . . . .
4.1 Trecho de um arquivo XMI do circuito modelado para controlar o
tempo de um semforo. . . . . . . . . . . . . . . . . . . . . . . . . .
4.2 Trecho de um arquivo XMI do circuito modelado para controlar o
tempo de um semforo. . . . . . . . . . . . . . . . . . . . . . . . . .
4.3 Cdigo utilizado para localizar o elemento que representa um diagrama de atividade no arquivo XMI. . . . . . . . . . . . . . . . . .
4.4 Cdigo utilizado para localizar os elementos que representam estados no arquivo XMI. . . . . . . . . . . . . . . . . . . . . . . . . . .
4.5 Cdigo de um template na linguagem VTL que representa um
mdulo em BSV, com chamadas outros templates. . . . . . . . .
4.6 Exemplo de um template no qual realizada uma iterao em
uma coleo de regras da linguagem BSV. . . . . . . . . . . . . . .
4.7 Trecho de cdigo utilizado para passar as informaes coletadas
durante o parser do arquivo XMI para os templates do Velocity. .
4.8 Sada da AST gerada pelo frontend do compilador C2BSV. . . . .
4.9 Sada da AST indicando que uma instruo ainda no foi implementada. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.1 Instrues utilizadas para testar o processador. . . . . . . . . . . .
5.2 Resultado da sntese do processador pela ferramenta Quartus II.
5.3 Resultado da sntese do filtro Sobel pela ferramenta Quartus II. .
A.1 Cdigo gerado do Processador. . . . . . . . . . . . . . . . . . . . . .
B.1 Cdigo gerado do Sobel. . . . . . . . . . . . . . . . . . . . . . . . . .
C.1 Gramtica do compilador C2BSV. . . . . . . . . . . . . . . . . . . .

xix

24
24
28
38
42
43
43
44
46
46
49
51
57
58
65
75
79
85

Lista de Abreviaturas

ASM Algorithmic State Machine

AST Abstract Syntax Tree
BSV Bluespec SystemVerilog
EDA Electronic Design Automation
ESL Electronic System Level
FPGA Field-Programmable Gate Array
HDL Hardware Description Language
IDE Integrated Development Environment
IP Intellectual Property
MEF Mquina de Estados Finitos
OMG Object Management Group
RTL Register Transfer Level
UML Unified Modeling Language
VHDL VHSIC Hardware Description Language
VHSIC Very High Speed Integrated Circuit
XML eXtensible Markup Language

xxi

CAPTULO

1
Introduo

O contnuo avano da capacidade dos circuitos integrados e a necessidade de

arquiteturas de hardware cada vez mais complexas para lidar com os problemas atuais esto direcionando o desenvolvimento de sistemas digitais para
ambientes de alto nvel de abstrao cada vez mais distantes dos detalhes do
hardware (Shukla et. al., 2006). Inicialmente, os sistemas eram projetados no
nvel de portas lgicas (gates), mais adiante no nvel de registradores (RTL Register Transfer Language), e agora, est tornando-se cada vez mais comum
o desenvolvimento no nvel de sistema (ESL - Electronic System-Level) (Densmore e Passerone, 2006) (Martin et. al., 2007). As vantagens deste tipo de
desenvolvimento relacionam-se ao fato de facilitar o co-projeto de hardware e
software, explorao do espao de projeto, proporcionar maior velocidade na
simulao e permitir o teste e o ajuste da arquitetura do sistema em alto nvel.
Alm disso, permite o reuso do mesmo testbench tanto na fase de validao
do modelo como no teste da arquitetura do sistema.
Com o desenvolvimento a partir de modelos ESL, o software pode ser tanto
sintetizado para hardware como ser executado em processador embarcado
(Berger, 2001), permitindo que sistemas cada vez mais complexos sejam criados com tempo de desenvolvimento cada vez menor, pois os recursos avanados das linguagens ESL, como o suporte orientao a objetos, permitem uma
melhor estruturao do problema, incentiva o reuso de cdigo e ainda possibilita que projetistas de software desenvolvam e testem seus cdigos antes
mesmo da existncia da arquitetura de hardware. No entanto, este processo
na maioria das vezes exige o uso de metodologias e ferramentas extremamente
complexas e caras.
Avanando um degrau no nvel de abstrao, encontram-se as ferramentas

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

Figura 1.1: Diagrama de blocos dos principais elementos do projeto RoboArch

com o destaque do mdulo onde este trabalho est situado.

Este trabalho prope o desenvolvimento de uma ferramenta que permite

o projeto de arquiteturas de hardware modeladas com Mquinas de Estados
Finitos (MEF) representadas em UML (Unified Modeling Language). Esta ferramenta, denominada UML2BSV, capaz de traduzir automaticamente um
modelo UML para a linguagem de descrio de hardware em alto nvel Bluespec SystemVerilog (BSV) (Bluespec Inc, 2010). O cdigo gerado representa
todo o controle da mquina de estados, deixando o desenvolvedor responsvel por descrever o comportamento de cada estado utilizando a linguagem C.
A ferramenta tambm aceita cdigo BSV para descrever as aes no estado,
sendo nesse caso, a linguagem fonte a mesma de destino. Porm, com o controle das aes dado por meio da mquina de estados em UML.
Para traduzir a linguagem C, a ferramenta UML2BSV faz chamadas ao compilador C2BSV, que tambm faz parte deste trabalho, para traduzir o respectivo cdigo C em BSV e, desta forma, manter o cdigo gerado automaticamente
totalmente sintetizvel.
Uma viso geral do fluxo deste processo est representado na figura 1.2,
3

onde uma modelagem passada como parmetro de entrada ferramenta

UML2BSV. Durante o processo de gerao de cdigo, o compilador C2BSV
pode ser chamado diversas vezes pela UML2BSV . O resultado final o cdigo
BSV gerado automaticamente.

Modelagem UML

UML2BSV

C2BSV

package Tr af f i cLi ght ;

t ypedef enum {G, Y, R} St at e
der i vi ng( Bi t s, Eq) ;

Cdigo Bluespec SystemVerilog

( * 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) ;
....

Figura 1.2: Viso geral do processo de gerao de cdigo Bluespec SystemVerilog.

1.1

Objetivos

Nesta seo ser apresentado o objetivo geral deste projeto assim como seus
objetivos especficos.

1.1.1

Objetivo Geral

O objetivo deste trabalho gerar cdigo Bluespec SystemVerilog a partir de

modelagem de diagramas da UML em conjunto com a linguagem de programao C.
4

1.1.2

Objetivos Especficos

Os objetivos especficos deste trabalho so:

estudar os diagramas da UML para determinar quais deles sero necessrios durante o processo de desenvolvimento de um hardware;
pesquisar meios para que no seja necessria a criao de novas extenses na UML;
desenvolver uma ferramenta para interpretar uma modelagem UML e gerar o respectivo cdigo em Bluespec SystemVerilog;
definir uma representao intermediria da modelagem UML;
criar templates para auxiliar o processo de gerao de cdigo;
desenvolver um compilador para traduzir cdigo C para a linguagem Bluespec SystemVerilog;
realizar testes com estudos de caso para validar a ferramenta.

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

Unified Modeling Language (UML)

A UML uma linguagem grfica utilizada para especificar, visualizar, construir

e documentar sistemas por meio de seus diversos diagramas. Alm disso, com
o uso da UML, uma equipe de desenvolvimento passa a ter um padro permitindo a seus membros realizarem colaboraes atravs de uma linguagem
comum a todos (Pilone e Pitman, 2005).
Seu surgimento teve como base trs tcnicas que j estavam sendo aplicadas com sucesso na modelagem de sistemas. Estas tcnicas e seus respectivos
autores foram:
Projeto orientado a objeto (Object-oriented design), por Grady Booch;
Tcnica de modelagem de objetos (Object-modeling technique), por James
Rumbaugh;
Engenharia de software orientado a objetos (Object-oriented software engineering), por Ivar Jacobson.
A unio destes trs mtodos deu origem primeira verso da UML, em
1994. J em 1997, a UML passou a ser aceita como um padro pela OMG
(Object Management Group), um consrcio internacional sem fins lucrativos
responsvel por definir alguns padres adotados na indstria da computao.
7

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.

Figura 2.1: Diagrama de classes com a classificao dos 14 diagramas da

UML. Adaptado de (Fowler, 2003).
Com os diagramas estruturais possvel representar todas as caractersticas que um sistema deve possuir, onde so abordados aspectos das estruturas
de um sistema que est sendo modelado. Os diagramas que fazem parte desta
categoria, so:
Diagrama de classe: descreve a estrutura do sistema atravs de classes,
8

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

 Diagrama de tempo: representa as interaes de um sistema com o foco

nas restries de tempo.
Durante a modelagem de um sistema no necessrio utilizar todos os diagramas. Pelo contrrio, Fowler (2003) cita a mtica proporo de que 20% da
UML o suficiente para realizar 80% das tarefas. Alguns destes diagramas
tem suas funcionalidades bem parecidas e a escolha dentre eles acaba dependendo do foco que se deseja dar a um determinado aspecto da modelagem.
Esto disponveis diversas ferramentas para realizar modelagem UML que
vo desde aplicaes bem simples, oferecendo os recursos bsicos, at ambientes complexos com vrias funcionalidades. Tambm possvel realizar
a opo por ferramentas open source, onde normalmente recebe colaborao
de vrios desenvolvedores ao redor do mundo, ou ento verses comerciais,
normalmente utilizada por equipes de desenvolvimento nas empresas.

2.2

Mquina de Estados Finitos

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

Uma MEF tambm pode ser representada de forma grfica atravs de um

diagrama de estados ou por um diagrama algortmico (ASM), ambos mostrando os estados, entradas, sadas e transies. Uma mquina de estado
pode ser projetada a partir de dois modelos: Moore (1956) e Mealy (1955).
Esses nomes so em homenagem a Edward Moore e George Mealy que investigaram estes comportamentos na dcada de 50.
Na mquina de estado do tipo Moore, as sadas ocorrem depois que a transio para um novo estado completada e elas dependem apenas do estado
atual da mquina. Na mquina de estado do tipo Mealy, a sada gerada na
transio entre os estados e baseada em funo do estado atual e do valor
de suas entradas. Com isso, consegue-se uma maior flexibilidade durante o
projeto.
Uma mquina de estados formada por ns, que representam os estados
e so desenhados como crculos, e por arcos direcionados representando as
transies entre os estados. Uma expresso lgica associada a cada transio, representando uma condio especfica, e ela ocorre sempre que for
avaliada como verdadeira, como resposta a um evento de entrada. Uma transio pode estar associada a dois estados diferentes (qi , qj ) ou ao mesmo estado
(qi , qi ) (Hopcroft et. al., 2000).
Como forma de ilustrar um exemplo, na figura 2.2 apresentada uma
MEF do tipo Moore. Sua funo detectar a sequncia 11 na entrada. Para
isto, foram necessrios utilizar trs estados. A cada entrada 1 ocorre uma
transio para o prximo estado. Quando o estado C fica ativo significa que
foi detectada uma sequncia de 11 e a sada passa de 0 para 1.
0
A

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.

(a) Caixa de estado

(b) Caixa de deciso

(c) Caixa de sada

condicional

Figura 2.4: Elementos de um diagrama ASM adaptado de (Brown, 2005).

A caixa de estado (2.4(a)) o equivalente ao estado em uma MEF com seu

nome indicado fora da caixa. As sadas (no modelo Moore) e aes ficam
dentro do retngulo.
12

 A caixa de deciso (2.4(b)) indica a condio que ser testada na transio

de um estado para outro em relao s entradas da MEF. Ela representa
a transio em uma MEF.
A caixa de sada condicional (2.4(c)) representa os sinais de sada (no
modelo Mealy) dependendo do valor do estado e das entradas da MEF.
Este elemento fica localizado no caminho entre a caixa de deciso e a de
estado.
Com estes elementos possvel criar um diagrama ASM conforme ilustrado
na figura 2.5.

Figura 2.5: Representao de um diagrama ASM (Nelson et. al., 1995).

Embora um diagrama de estado descreva todo o comportamento de uma
MEF graficamente, pode ser conveniente representar estas informaes do
diagrama em um formato tabular. Esta outra forma de representao pode ser
til ao projetista na elaborao de uma MEF, por exemplo, durante o processo
de reduo de estados. A tabela de estados mostra todas as transies do
estado atual para o prximo, com diferentes valores de entrada, e a respectiva
sada. A tabela 2.1 mostra representao tabular da mquina de estado Moore
da figura 2.2.

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

Tabela 2.1: Tabela de estado da MEF da figura 2.2

Estado Atual
A
A
B
B
C
C

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

os menores possveis (Wolf, 2005).

O processo de compilao pode ser dividido em seis etapas, onde a sada
de uma etapa serve como entrada para a seguinte. As etapas so: anlise
lxica, anlise sinttica (tambm conhecida como parsing), anlise semntica, gerao de cdigo intermedirio, otimizao e a gerao de cdigo objeto.
Alm destas etapas, um compilador tambm possui uma tabela de smbolos
que est disponvel em todas as fases do processo de compilao (Muchnick,
1997).
As quatro primeiras compem o frontend do compilador e as duas ltimas
fazem parte do backend. No backend gerado o cdigo objeto a partir de uma
representao intermediria, alm de utilizar informaes importantes que
constam em uma estrutura de dados chamada Tabela de Smbolos, ambos
gerados no frontend (Aho et. al., 1986).
A figura 2.6 mostra as fases de um compilador e a respectiva diviso do
frontend e do backend. Esta diviso facilita na manuteno de um compilador,
onde, se for necessrio gerar um cdigo objeto para uma nova arquitetura,
possvel aproveitar o frontend e apenas criar um novo backend.

Figura 2.6: Fases de um compilador. Adaptado de (Aho et. al., 1986).

15

2.3.1

Frontend

no frontend onde se inicia o processo de compilao a partir de um arquivo

texto com o cdigo fonte que lido pelo analisador lxico e que sua funo
criar uma cadeia de tokens partir deste arquivo texto. Esta etapa est
ilustrada na figura 2.7.
Token pode ser definido como uma unidade primitiva de uma linguagem de
programao como identificadores, palavras-chave, nmeros, cadeias de caracteres, operadores e delimitadores (Safonov, 2010). Nesta fase so ignorados
os espaos em branco e os comentrios.

Figura 2.7: Analisador Lxico. Adaptado de (Norvell, 2007).

Na sequncia, essa cadeia de tokens enviada ao analisador sinttico onde
ser gerada uma estrutura de rvore representando a hierarquia do programa
a ser compilado. Outra funo importante nesta fase a de reportar erros
de sintaxe ao programador, como por exemplo, a falta de um parntese ou do
sinal ponto-e-vrgula. Esta etapa est representada na figura 2.8.
Ao final da anlise sinttica, tem-se a rvore sinttica abstrata (AST). Ela
uma importante estrutura de dados, fundamental para facilitar as tarefas do
analisador semntico, otimizador e do gerador de cdigo.
A anlise semntica, que vem em seguida, pode ser a ltima etapa realizada no frontend. Ela faz uso da AST para realizar a checagem de tipos, fluxo
de controle e ocorrncia de declaraes de variveis em duplicidade. Nesta
etapa pode ocorrer a coero, que quando o compilador realiza a converso
automtica de um tipo de dado para que ele fique adequado instruo, emitindo uma mensagem de alerta, mas no de erro, para o usurio no momento
da compilao.
16

Figura 2.8: Analisador Sinttico. Adaptado de (Norvell, 2007).

Opcionalmente, um compilador tambm pode gerar um cdigo intermedirio como um programa para uma mquina abstrata. Espera-se que esta
representao possua as caractersticas de ser facilmente gerada e facilmente
traduzida para o cdigo objeto, mitigando assim o trabalho que ser realizado
no backend.

2.3.2

Backend

As etapas finais do processo de compilao, compreendida por otimizao e

gerao de cdigo, ocorrem no backend.
A otimizao de cdigo, que uma etapa opcional neste processo de compilao, pode ser divida em duas categorias: as que so independentes de
plataforma e as que geram cdigo para uma arquitetura especfica. No caso
da primeira categoria, pode ocorrer eliminao de instrues redundantes, realizao de simplificaes algbricas, remoo de regio com cdigo que nunca
ser executado, entre outras. No caso de compilador dependente de uma arquitetura, podem ser realizadas otimizaes, por exemplo, analisando quais
so as variveis mais utilizadas e deix-las sempre que possvel em registradores. Neste caso, o compilador fica preso uma determinada arquitetura.
17

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

O projeto RoboArch (Bonato e Marques, 2009) prope um framework para

modelagem, simulao e sntese de sistemas embarcados para a robtica mvel baseado na combinao dos recursos de meta-modelagem, que permite
representar um sistema heterogneo em uma nica linguagem, e ESL, que
possibilita a aproximao dos aspectos de baixo nvel da arquitetura de um
sistema embarcado ao seu modelo abstrato. Desta forma, possvel criar um
fluxo de desenvolvimento completo, partindo das especificaes dos requisitos de hardware e software at chegar ao mapeamento das funcionalidades do
software aos servios fornecidos pelos recursos do hardware.
A ferramenta tem o propsito de acelerar o processo de construo e validao de arquitetura de hardware e software e incentivar o ensino e a pesquisa
nas reas de sistemas embarcados e robtica mvel, estando tudo isso apoiado em metodologias recentes de meta-modelagem e desenvolvimento ESL.
A modelagem da aplicao e da arquitetura de hardware se d atravs de
diagramas UML, onde o usurio poder gerar IPs em Bluespec seguindo a
padronizao do IP-XACT, a partir de diagrama de mquina de estado e gerar
modelos de hardware para sntese em dispositivos FPGAs. A ferramenta ainda
contar com o recurso de profiling para detectar gargalos de processamento.
O usurio poder realizar a simulao do modelo de modo integrado com
um ambiente de robs mveis, podendo a simulao ser integrada com sensores e atuadores de robs mveis por meio da plataforma Player, como observado na figura 2.9.

2.5

Trabalhos Relacionados

Nesta seo encontram-se os trabalhos que esto relacionados a este projeto.

Nenhum dos trabalhos esto ligados diretamente com gerao automtica de
18

Figura 2.9: Exemplo de simulao de sistema embarcado via Player/Stage.

cdigo Bluespec, porm eles sero teis como fonte de referncia de como
foram resolvidas as questes de compilao e de traduo de um diagrama de
mquina de estado para uma forma textual.
Os trabalhos de de Pablo et. al. (2007) e Moreira et. al. (2010), dentre todos os que foram apresentados na introduo, foram escolhidos para serem
apresentados com mais detalhes nesta seo.

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

GenERTiCA com mapeamento em VHDL

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

No momento da escrita deste trabalho h uma informao no site http://javacc.java.net/

de que o JavaCC tambm passar a gerar cdigo C/C++, e que em breve ser lanada uma
verso beta com este recurso.

23

gramtica na qual ele foi gerado.

Em seguida, o analisador sinttico ir ler esta sequncia de tokens e, em
conjunto com outras ferramentas, gerar a rvore de sintaxe abstrata (AST).
Como o JavaCC no gera a AST por si s, ele depende de ferramentas externas
para isso. Dentre as possibilidades para gerar a AST esto as ferramentas
JJTree e a JTB. Estas duas etapas representam a anlise lxica e sinttica e
esto representadas respectivamente nas figuras 2.7 e 2.8 do captulo 2.
O JJTree atua como um pr-processador para o JavaCC inserindo cdigos em diversas regies do JavaCC. Neste trabalho optou-se trabalhar com o
JJTree.

3.2

Apache Velocity

O Apache Velocity (Apache Software Foundation, 2010) uma ferramenta open

source feita em Java capaz de gerar cadeias de caracteres baseada em templates. Sua principal utilidade so nos casos em que se deseja gerar arquivos
no formato texto, como por exemplo cdigos fonte, baseado em alguma lgica.
No site Velocity Wiki 2 mantida uma lista de alguns projetos que fazem uso
desta ferramenta.
Para ilustrar o funcionamento do Velocity apresentado um pequeno exemplo. As strings em destaque na listagem 3.1 so os locais onde o Velocity ir
atuar durante a renderizao do template. Todo o texto restante ser simplesmente direcionado para a sada sem quaisquer modificao.
Na listagem 3.2 aparecem em destaque os valores que foram substitudos
pelo Velocity durante o processo de renderizao. Para que isso seja possvel, necessrio passar ao Velocity todas as variveis utilizadas no template
juntamente com seus respectivos valores. Neste exemplo, foram passadas as
variveis fsmName e resetName com os valores ExemploFSM e ESTADO_X,
respectivamente.
Listagem 3.1: Exemplo de um template do Apache Velocity.
1
2
3
4
5
6

package $fsmName;
(* synthesize *)
module mk${fsmName}(Empty);
Reg#(State) state <- mkReg($resetState);
endmodule: mk${fsmName}
endpackage: $fsmName

Listagem 3.2: Exemplo de um cdigo renderizado partir de um template do Apache

Velocity.
1

package ExemploFSM;
2

Disponvel em: http://wiki.apache.org/velocity/PoweredByVelocity

24

2
3
4
5
6

(* synthesize *)
module mkExemploFSM(Empty);
Reg#(State) state <- mkReg(ESTADO_X);
endmodule: mkExemploFSM
endpackage: ExemploFSM

Apesar do exemplo apresentado ser bem simples, onde acontecem apenas

substituio de valores, o Velocity bem poderoso. Ele possui uma linguagem
prpria, chamada de Velocity Template Language (VTL) na qual permite o uso
de variveis, estruturas de lao e chamadas a outros templates.

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.1: Fluxo de desenvolvimento do Bluespec. Adaptado de (Bluespec

Inc, 2007).
boa prtica de programao pois assim possvel manter vrios programas
organizados logicamente. Uma vez que tenha sido declarado um pacote, o
arquivo que contm o programa deve ter o mesmo nome deste pacote.
Em seguida pode vir a declarao da Interface. So por meio dos elementos declarados na interface que o hardware que est sendo desenvolvido se
comunicar com o meio externo. As Interfaces so desenvolvidas atravs de
mtodos e, neste bloco, so declaradas apenas as assinaturas destes mtodos.
Caso o programa em BSV tenha declarado uma interface, seus respectivos mtodos devem ser implementados dentro do mdulo correspondente.
Por ltimo, a declarao de um bloco de mdulo (module <nome-do-mdulo>
(nome-da-interface)). Na declarao do mdulo necessrio passar uma interface como parmetro. Caso no tenha sido definida nenhuma interface, ento
utiliza-se uma interface especial chamada Empty. Para ser sintetizado, o mdulo deve ser marcado com o atributo (* synthesize *), colocado imediatamente
antes de sua declarao.
Um mdulo composto por rules, mtodos (que implementam a interface),
declaraes de variveis e instncias de interfaces de outros mdulos.
As rules so blocos onde o programador descreve um comportamento de
um hardware em BSV. Elas podem ser declaradas com uma condio, que
so expresses booleanas, para garantir que ela seja executada somente no
momento certo. Pode-se comparar as rules com os blocos process ou always
do VHDL e Verilog respectivamente.
Existem trs caractersticas importantes a respeito das rules:
26

 Atomicidade: as rules so consideradas atmicas, ou seja, todas as

aes que fazem parte de uma rule sero executadas num mesmo ciclo
de relgio;
Execuo: caso a condio da rule seja verdadeira, ela ser executada
como um todo, e apenas uma vez, em um ciclo de relgio;
Conflitos: uma rule no pode entrar em conflito com outra. Esta situao de conflito verificada pelo compilador do Bluespec. Caso seja
detectado um conflito o programador deve optar por uma das duas opes:
declarar no cdigo fonte, atravs de parmetros, qual rule deve ter
prioridade em caso de conflito;
modificar a lgica empregada no cdigo afim de eliminar o conflito.
O Bluespec gera toda a lgica de controle automaticamente para coordenar
acessos aos recursos compartilhados. Ao invs do desenvolvedor se preocupar em controlar todos os recursos de seu sistema (figura 3.2(a)), que pode
ser uma tarefa complexa e suscetvel a erros, ele pode focar-se apenas em
uma parte do problema (figura 3.2(b)), deixando o Bluespec responsvel por
automatizar todo o controle. Com isso consegue-se a simplicidade necessria
para efetuar mudanas rpidas, incremento de funcionalidades, flexibilidade,
reusabilidade e um custo menor no desenvolvimento.

(a) Desenvolvimento complexo

(b) Desenvolvimento simples

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

compilar e simular sem a necessidade de usar um terminal (interface textual).

Alm disso a IDE fornece um visualizador de formas de onda e a integrao
com os editores de texto Vim, Emacs (estes dois primeiros com suporte syntax highlighting, realando o cdigo fonte com diferentes cores) ou qualquer
outro editor que seja de preferncia do usurio. A figura 3.3 mostra a tela do
Bluespec Workstation com um projeto simples aberto.

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

// Copyright 2010 Bluespec, Inc. All rights reserved.

package Tb;
import StmtFSM::*;
(* synthesize *)
module mkTb (Empty);
Reg#(Bool) complete <- mkReg(False);
Stmt test =

28

seq

8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

$display("I am now running at ", $time);

$display("I am now running one more step at ", $time);
$display("And now I will finish at", $time);
$finish;
endseq;
FSM testFSM <- mkFSM (test);
rule startit ;
testFSM.start();
endrule
rule alwaysrun;
$display("
and a rule fires at", $time);
endrule
endmodule
endpackage

Para utiliz-la necessrio criar um objeto instanciando a MEF atravs

do construtor mkFSM que recebe como parmetro a mquina de estado criada pelo usurio, entrando em execuo depois de chamado o mtodo start.
A biblioteca de mquina de estado tambm fornece um modo chamado de
AutoFSM que tem o funcionamento semelhante maquina instanciada pelo
construtor mkFSM, sendo que no necessrio chamar o mtodo start, pois
sua execuo inicia automaticamente logo aps o reset e ela finalizada assim
que completar sua primeira execuo.

3.4

Padro IP-XACT

IP-XACT (Accellera Organization Inc., 2011) um padro de formato XML que

descreve e representa componentes de sistemas eletrnicos. Ele foi criado pelo
consrcio SPIRIT como um padro para permitir a configurao e integrao
automtica entre ferramentas. Este padro foi aprovado como norma IEEE
1685-2009 (IPX, 2010).
O objetivo da padronizao ter uma interface comum entre vrios fornecedores permitindo acessar os metadados dos componentes e assim possibilitar
o reso entre ferramentas compatveis com o padro IP-XACT.
Para auxiliar no processo de gerao de um mdulo no padro IP-XACT
Ghosh (2012) desenvolveu ferramenta, disponibilizada gratuitamente, chamada IP-XACT Solutions, no qual possvel gerar uma interface no padro
IP-XACT para um mdulo desenvolvido em RTL.

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

Figura 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.

forma standalone ou ser acoplado a projetos de terceiros. Alm disso, cada

projeto pode evoluir de forma independente no futuro, de acordo com as necessidades de novas funcionalidades. At o momento da elaborao deste trabalho, foram geradas um total de 8.152 linhas de cdigo nos projetos FSM2BSV
e C2BSV, de acordo com o programa SLOCCount 1 .
Neste trabalho optou-se por utilizar apenas bibliotecas e frameworks livres
com suporte a multiplataformas para possibilitar que a ferramenta possa ser
utilizada nos mais diversos ambientes. H inteno de disponibiliz-la de
forma livre para que possa ser utilizada por outras instituies de ensino e
tambm receber contribuies em seu desenvolvimento.

O SLOCCount um programa utilizado para contar o nmero de linhas nos arquivos de

cdigo fonte de um projeto. Disponvel em http://www.dwheeler.com/sloccount/

32

4.1

UML2BSV

Neste trabalho optou-se por utilizar os diagramas da UML 2 para representar

o controle do hardware em alto nvel de abstrao. So utilizados os diagramas de estado, atividade e de classes para representar um circuito a ser
desenvolvido.
Um dos cuidados deste trabalho foi utilizar a linguagem UML padro, sem
que houvesse nenhum tipo de extenso na mesma. Assim, o usurio no
necessitar aprender uma nova linguagem e poder modelar seu circuito em
qualquer ferramenta que suporte a UML 2 e que tenha a funcionalidade de
exportar o modelo no padro XMI 2.1.
O XMI (XML Metadata Interchange) um padro desenvolvido pela OMG
(Object Management Group) que busca simplificar a troca de informaes por
XML (Extensible Markup Language) entre ferramentas de modelagem de empresas diferentes. Por ser um padro j consolidado, optou-se por sua utilizao para gerar o arquivo que ser lido pela ferramenta de gerao de cdigo
fonte em BSV.
O arquivo XMI exportado da modelagem UML utilizado como entrada
para a ferramenta, tendo como sada o cdigo fonte em BSV. A UML2BSV faz
a leitura deste arquivo, analisa toda a estrutura e, com essas informaes,
cria objetos que representam a modelagem, como por exemplo os estados e
transies.
A etapa final deste fluxo a gerao do cdigo BSV com auxlio de um sistema de templates. A ferramenta utiliza todos os objetos que foram extrados
do arquivo XMI e, juntamente com templates, que caracterizam a estrutura da
linguagem BSV, gera o produto final que o cdigo fonte em BSV.
Posteriormente, este cdigo poder ser armazenado na biblioteca de IPs
da ferramenta RoboArch ou ento ser compilado pelo Bluespec Compiler para
gerar cdigo Verilog sintetizvel para FPGA.
Nas prximas sees sero detalhadas cada etapa deste processo representado na figura 4.1 e, como forma de ilustrar melhor todo o funcionamento, ser
utilizado um exemplo simples de um controlador de semforo onde o circuito
modelado define um temporizador para os estgios deste semforo.

4.1.1

Modelagem UML

Uma das formas esperadas para diminuir a complexidade no desenvolvimento

de sistemas embarcados atravs da modelagem visual utilizando diagramas
UML para representar circuitos. Com a modelagem visual as chances de erros diminui pois o desenvolvedor fica limitado a utilizar os elementos visuais.
Alm disso, diminui a quantidade de linhas de cdigos a serem escritas e fa33

cilita a gerao da documentao dos modelos, o que ajuda no entendimento

do projeto por outros membros da equipe.
Neste trabalho so utilizados trs diagramas UML para a modelagem de um
circuito:
Diagrama de Classes: utilizado para definir os tipos de dados utilizados
na modelagem;
Diagrama de Atividades: que representa as entradas e sadas do circuito,
alm de definir uma ao, que ser representada por uma mquina de
estado;
Diagrama de Estados: que representa o comportamento do circuito com
seus estados e transies.
A seguir sero descritos como cada um destes trs diagramas foram utilizados neste trabalho e as orientaes de como trabalhar em cada um deles
durante o processo de modelagem.
Diagrama de Classes
O diagrama de classes foi utilizado como forma de apoiar a modelagem de uma
determinada arquitetura de hardware. Ele utilizado no contexto de definir
os tipos de dados que sero utilizados no modelo, pois a UML no fornece os
tipos necessrios ao desenvolvimento de hardware.
So definidas trs categorias para os tipos de dados. A distino entre as
categorias atravs do uso (ou no) de um determinado esteritipo na classe
como pode ser observado nos exemplos da figura 4.2.

(a) Classes definindo alguns

tipos de dados

(b) Classe definindo

um vetor

(c) Classe definindo uma

BRAM

Figura 4.2: Definio de tipos de dados utilizando classes.

A classe com o esteritipo primitive (figura 4.2(a)) utilizada para definir
tipos de dados Bit, Int e UInt do Bluespec e os tipos char, unsigned char, int e
unsigned int da linguagem C. Estes tipos da linguagem C foram adicionados
nesta ferramenta para facilitar o programador que no esteja familiarizado
com a linguagem BSV. Durante o processo de gerao do hardware estes tipos
34

so convertidos nos tipos reconhecidos pelo Bluespec, como mostra a tabela

4.1.
Tabela 4.1: Equivalncia entre os tipos de dados em C e Bluespec.
Tipo de Dado
C
Bluespec
char
Int#(8)
unsigned char UInt#(8)
int
Int#(32)
unsigned int
UInt#(32)

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

Os atributos addrWidth e dataWidth devem estar associados a um tipo de

dado declarado anteriormente.
A memria a nica que pode ser utilizada diretamente no diagrama de
estados, sem a necessidade de instanci-la no diagrama de atividades. Basta
utilizar o nome dado a ela para invocar os mtodos de leitura e escrita.

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.

Figura 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.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

<?xml version=1.0 encoding=UTF-8?>

2
3

4
5

7
8

<xmi:XMI xmi:version=2.1 xmlns:uml=http://www.omg.org/spec/UML

/20090901 xmlns:xmi=http://schema.omg.org/spec/XMI/2.1>
<uml:Model xmi:id=... name=Data visibility=public>
<packagedElement xmi:type=uml:Activity xmi:id=... name=
activityTrafficLight visibility=public classifierBehavior
=...>
<ownedBehavior xmi:type=uml:StateMachine xmi:id=... name=
fsmTrafficLight visibility=public>
<region xmi:type=uml:Region xmi:id=... visibility=public>
<subvertex xmi:type=uml:State xmi:id=... name=Green
visibility=public>
<doActivity xmi:type=uml:OpaqueBehavior xmi:id=... name=

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>

A primeira linha do arquivo XMI necessria para indiciar qual a verso

utilizada e, opcionalmente, declarar a codificao utilizada no conjunto de
caracteres do arquivo. O documento XMI inicia-se na linha 3, com a abertura
da tag XMI indicando, dentre outras informaes, a verso do padro adotado.
Esta tag um elemento raiz, englobando todos os elementos restantes.
A partir deste ponto as diferentes tags que compe o arquivo XMI so acompanhadas pelo atributo xmi:type o qual muito importante durante o processo
de parser. atravs do valor deste atributo que ser possvel identificar o que
cada tag representa. Portanto, ao invs de referenciar o nome da tag, ser citado o valor do atributo xmi:type. Outro atributo importante que aparece nas
tags o xmi:id, onde seu valor gerado de forma automtica pela ferramenta
de modelagem com um identificador nico. atravs deste valor de referncia
que utilizado na prxima etapa para relacionar os elementos, por exemplo,
os estados e as transies.
Continuando com a anlise do arquivo XMI, na linha 5 encontra-se a
declarao do diagrama de atividades identificado pelo atributo xmi:type =
uml:Activity. Abaixo deste n existem dois filhos: um uml:StateMachine na
linha 6, que representa o diagrama de estados e um uml:CallBehaviorAction
na linha 25 que representa uma ao do diagrama de atividades e que est
relacionado ao uml:StateMachine atravs do atributo behavior, que contm o
valor correspondente do atributo xmi:id do diagrama de estados.
Seguindo no n correspondente da mquina de estado encontram-se os estados (uml:State), transies (uml:Transition) e um pseudo-estado (uml: Pseudostate), este ltimo utilizado para indicar qual o estado inicial desta mquina de estados.
Na linha 8 encontra-se uma declarao de um estado e abaixo deste n
declarada a ao que ser realizada por ele. Esta ao representada pelo valor uml:OpaqueBehavior que possui duas tags filhas: body que ir armazenar
o cdigo que representa o comportamento deste estado e language que indica
qual foi a linguagem utilizada na tag body.
O valor uml:Transition (linha 15) representa uma transio que tambm
possui mais trs atributos importantes que so source e target que armazenam as referncias para os estados de origem e destino, respectivamente, e
o atributo guard que armazena a referncia para a declarao que contm
40

a condio indicando quando esta transio ser disparada. Esta condio

declarada como um elemento filho da transio identificado pelo atributo
uml:OpaqueExpression. Este elemento possui duas tags filhas, body e language, da mesma forma que ocorre na declarao de um estado.
O pseudo-estado representado pelo valor uml:Pseudostate (linha 14) e sua
construo bem simples, resumindo-se a apenas uma tag sem filhos. Ele
utilizado apenas para indicar qual o estado inicial da mquina de estados,
sendo relacionado ele uma transio para este estado.
Por fim, existe o n uml:CallBehaviorAction (linha 25) que um dos filhos
do elemento uml:Activity. Este elemento representa uma ao no diagrama
de atividades e seus filhos so as declaraes dos sinais de entrada e sada
identificados por uml:InputPin e uml:OutputPin respectivamente, e de variveis
que so identificadas por uml:ValuePin. Todos estes elementos tem filhos que
declaram qual o tipo de dado de cada elemento, representados pelo elemento
uml:PrimitiveType.

4.1.3

Parser do XMI

Esta etapa do processo se d atravs da anlise do contedo do arquivo XMI

exportado pela ferramenta de modelagem. Para fazer esta anlise foi utilizada
a biblioteca xmltool (Carbou, 2011) que fornece um conjunto de funcionalidades para auxiliar nas operaes comuns quando se manipula um arquivo
XML. Com essa biblioteca, que disponibilizada de forma open source sob a
Apache License 2.0, as funes mais utilizadas foram a de navegao entre os
ns do arquivo XMI e a leitura de tags e seus respectivos atributos.
Devido caracterstica de estrutura de rvore de um arquivo XML, onde
cada elemento est representado em um nvel diferente, a estratgia escolhida
para analisar o arquivo foi a de usar funes auxiliares responsveis por cada
parte desta rvore. Portanto, uma funo inicia a busca de um determinado
padro, por exemplo, o incio de uma mquina de estado. Neste momento
esta funo chama outra que responsvel por buscar os estados e assim por
diante. Cada funo fica responsvel por buscar e instanciar os elementos que
encontrar no arquivo XMI e adicion-los no objeto que representa a mquina
de estado.
A listagem 4.2 mostra o cdigo referente ao incio do processo onde instanciando um objeto que representa uma mquina de estado (objeto: fsm)
e que ser utilizado por este cdigo, sendo passado por parmetro para as
vrias funes que compe todo o cdigo. Nesta funo inicial so instanciadas estruturas de ArrayList que so responsveis por armazenar os Estados,
Transies, Variveis e Sinais de uma mquina de estados e cada ArrayList
associada ao respectivo atributo do objeto fsm.
41

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

public FSM Parser() {

FSM fsm = new FSM();
fsm.setStates(new ArrayList<State>());
fsm.setTransitions(new ArrayList<Transition>());
fsm.setVariables(new ArrayList<Variable>());
fsm.setSignals(new ArrayList<Signal>());
XMLTag doc = XMLDoc.from(new File("model/TrafficLight.xml"), true);
findUmlActivity(doc, fsm);
return fsm;
}

Ainda na funo principal, realizada a operao de abertura do arquivo

XMI invocando a funo from da biblioteca xmltool, que retorna um objeto do
tipo XMLTag contendo toda a estrutura de rvore do arquivo XMI e que ser
utilizado durante todo o processo. Para facilitar a gerao do cdigo optou-se
por criar uma representao intermediria do arquivo XMI com a estrutura
representada por um diagrama de classes ilustrado na figura 4.5, onde cada
elemento utilizado na modelagem est associado a uma classe ou a um atributo de uma classe deste diagrama. Nele observa-se a classe principal F SM
no qual est associada com as classes State e T ransition. Ainda foram utilizadas classes V ariable e Signal que mapeiam as variveis e os sinais, respectivamente. E estas duas classes fazem o uso de enumerators que possuem os
possveis tipos para uma varivel e o tipo e direo de um sinal.

Figura 4.5: Diagrama de classes que representa a estrutura da modelagem do

circuito.
Na sequncia feita uma chamada a funo findUmlActivity, responsvel
por localizar o n relativo declarao do diagrama de atividades, conforme
mostra o cdigo na listagem 4.3. Essa busca feita de forma recursiva, anali42

sando todos os ns e suas respectivas ramificaes. A cada chamada recursiva

feita uma verificao para identificar se foi encontrado o n desejado e, no
momento em que encontrado, chamada a funo findUmlStateMachine,
responsvel por localizar o n relativo mquina de estado, que tambm se
comporta de forma semelhante funo anterior, com a diferena que agora
a busca so pelos elementos de estados e as transies, nesta ordem, pois
quando for realizada a busca pelas transies ser necessrio j ter os objetos
Estados instanciados.
Listagem 4.3: Cdigo utilizado para localizar o elemento que representa um diagrama
de atividade no arquivo XMI.
1
2

3
4
5
6
7
8
9

public void findUmlActivity(XMLTag doc, FSM fsm) {

if ((doc.getCurrentTagName() == PACKAGE) && ((doc.getAttribute("xmi:
type").equals("uml:Activity")))) {
findUmlStateMachine(doc, fsm);
}
for (int i=1; i <= doc.getChildCount(); i++) {
findUmlActivity(doc.gotoChild(i), fsm);
doc.gotoParent();
}
}

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

public void findUmlStates(XMLTag doc, FSM fsm) {

for (int i=1; i<= doc.getChildCount(); i++) {
doc.gotoChild(i);
if (doc.getAttribute("xmi:type").equals("uml:State")) {
State e = new State();
e.setName(doc.getAttribute("name"));
e.setEnumName(e.getName());
e.setXmiId(doc.getAttribute("xmi:id"));
fsm.getStates().add(e);
}
doc.gotoParent();
}
}

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

#if ($thereIsVector)import Vector::*;

#end
#if ($thereIsBRAM)import BRAM::*;
#end

44

Mdulo BSV

Interface
Enumerator
Rules

Methods

Figura 4.6: Estrutura de templates de um mdulo BSV.

7
8

#parse ("templates/interface.vm")

9
10

typedef enum { #parse ("templates/enum.vm") } State deriving(Bits,Eq);

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

Reg#(State) state <- mkReg($resetState);

19
20

#parse ("templates/rule.vm")

21
22

#parse ("templates/methods.vm")

23
24

endmodule: mk${fsmName}

25
26

endpackage: $fsmName

Na linha 3 ocorre a chamada a um template filho que ser responsvel por

listar todos os estados que foram previamente modelados. Esta chamada
feita atravs da palavra-chave #parse que recebe como parmetro o nome do
arquivo deste outro template. Neste momento o Velocity passa a interpretar
o template chamado e todo o resultado da renderizao deste ser inserido
exatamente no ponto onde o template foi chamado.
Na listagem 4.6 observa-se um bom exemplo do uso da VTL de como fica
simples realizar iteraes de uma determinada coleo de objetos, neste caso
45

um conjunto de regras da linguagem BSV. Na linha 1 inicia-se o lao com

a palavra-chave #foreach. Este tipo de lao ir percorrer cada elemento da
coleo de dados $states e, a cada iterao, um elemento de $states ser
atribudo ao objeto $state, que da classe State. Na linha 2 observa-se as
chamadas dos mtodos getName() e getEnumName() a partir do objeto state
que, em ambos os casos, retornam uma String. Caso a coleo $states tenha
armazenado trs estados, todo esse bloco da listagem 4.6 ser repetido trs
vezes e o resultado da renderizao ser inserido na linha 10 da listagem 4.5,
local que foi chamado este template.
Listagem 4.6: Exemplo de um template no qual realizada uma iterao em uma coleo
de regras da linguagem BSV.
1
2
3
4

#foreach ($state in $states)

rule ${state.getName()} (state == ${state.getEnumName()});
${state.getDoTarget()}
endrule

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

public void GenBSV(FSM fsm) {

46

VelocityEngine ve = new VelocityEngine();

ve.init();
Template t = ve.getTemplate("templates/module.vm");
VelocityContext c = new VelocityContext();
c.put("fsmName", fsm.getName());
c.put("states", fsm.getStates());
c.put("transitions", fsm.getTransitions());
StringWriter sw = new StringWriter();
t.merge(c, sw);
System.out.println(sw.toString());

2
3
4
5
6
7
8
9
10
11
12

Neste ponto a gerao do cdigo BSV est concluda e o desenvolvedor pode

utilizar o Bluespec Compiler para compilar, simular e gerar o respectivo cdigo
Verilog para ser sintetizado. Tambm ser possvel armazenar o cdigo BSV
em um repositrio de IP da ferramenta RoboArch para ser utilizado como um
mdulo em outros projetos.

4.1.5

Exemplos de gerao de cdigo BSV

Esta seo ilustra alguns momentos durante a transformao da modelagem

UML para cdigo BSV. As figuras 4.7, 4.8 e 4.9 mostram alguns trechos de
cdigos que sero gerados por esta ferramenta.
A figura 4.7 mostra como um conjunto de estados so representados na linguagem BSV. Um tipo de dado State declarado atravs da instruo typedef.
Neste exemplo, est sendo criado um enumerator que possui como elementos todos os estados presentes no diagrama de estados. Tambm so geradas
rules para cada estado, seguidas com suas respectivas condies entre parnteses, que funcionam como um gatilho para controlar o momento certo em
que cada rule ser executada. Dessa forma, garantido que apenas uma rule
ser disparada em um mesmo ciclo de relgio.
A figura 4.8 mostra parte da modelagem da figura 4.4, focando na regio
onde definido qual o estado inicial da mquina de estados. Esta definio
feita por meio de uma transio do pseudo-estado (crculo preto) a um estado.
O resultado desta modelagem a gerao do cdigo BSV onde, o estado em
questo, anteriormente j definido pelo enumerator, passado como parmetro para o mkReg, que responsvel por inicializar a varivel state do tipo
State.
Por ltimo, a figura 4.9 mostra uma outra regio da modelagem UML da
figura 4.4 destacando a transio que ocorre do estado Green para o Yellow,
com a condio count == 20. Esta condio ir controlar a mudana de um
estado para o outro. Toda transio representada em BSV por meio de uma
instruo if cuja condio a mesma utilizada na transio. Esta verificao
47

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.

Figura 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.
realizada dentro de uma rule e, caso a condio seja verdadeira, o valor da
varivel state atualizado e no prximo ciclo de relgio um outro estado (rule)
ser executado.
Caso a modelagem tenha alguma transio sem nenhuma condio declarada, situao permitida desde que no cause nenhuma ambiguidade na
mquina de estados, a instruo if omitida e a varivel state atualizada
dentro da rule diretamente, sem nenhum tipo de verificao.

4.2

Compilador C2BSV

O compilador C2BSV a segunda parte do projeto. Como seu prprio nome

sugere, ele traduz cdigo C para a linguagem Bluespec SystemVerilog. Ele foi
48

Figura 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.
implementado utilizando a ferramenta JavaCC, j apresentada na seo 3.1,
juntamente com o JJTree. No apndice C encontra-se a gramtica utilizada
para construir o compilador C2BSV.
O desenvolvimento deste compilador foi realizado de forma a deix-lo independente do UML2BSV, permitindo futuras melhorias e implementao de
novos recursos sem a necessidade de alterar o projeto UML2BSV. Tambm
possvel utiliz-lo de forma standalone ou at ser incorporado em projetos de
terceiros.
A gramtica da linguagem C foi obtida do repositrio de contribuies do
site do JavaCC 2 , o qual foi modificada para se adequar s necessidades deste
trabalho. As principais mudanas necessrias foram realizar as anotaes
para que fosse possvel trabalhar com a AST gerada de forma mais otimizada
e a retirada de alguns ns da AST para simplificar a navegao pela rvore.
Para ilustrar como estruturada a AST gerada pelo frontend, considere a
seguinte instruo na linguagem C:
resultado = 9/(1 + 3) 4 + 5;
Esta instruo consiste em operaes aritmticas tradicionais e o resultado
do clculo atribudo varivel resultado. importante observar neste caso
que a precedncia dos operadores aritmticos foram obedecidos pelo compilador. Enviando esta instruo ao compilador possvel imprimir a AST gerada
pelo frontend, conforme a listagem 4.8.
2

Disponvel em: http://java.net/projects/javacc/downloads/directory/contrib/grammars

49

Listagem 4.8: Sada da AST gerada pelo frontend do compilador C2BSV.

1
2
3
4
5
6
7
8
9
10
11
12

-root
- AssignEqual [=]
- Identifier [resultado]
- Addition [+]
Divison [/]
Int [9]
Multiplication [*]
Addition [+]
Int [1]
Int [3]
Int [4]
Int [5]

Na figura 4.10 encontra-se uma outra forma de representar a AST referente

instruo utilizada como exemplo.

Figura 4.10: Instruo resultado = 9/(1 + 3) 4 + 5; representada no formato da

AST gerada pelo frontend.
O compilador foi construdo com a opo do JJTree M U LT I = true. Dessa
forma, so geradas uma classe para cada n da AST deixando a estrutura
do compilador bem organizada, fcil de manter e evita redundncias no backend. Toda vez que ele invocado, caso tenha alguma instruo ainda no
implementada, uma mensagem de erro mostrada no console para o usurio,
indicando inclusive qual o respectivo n da AST que se trata, facilitando a sua
localizao.
Embora a instruo while faa parte da gramtica em uso pelo C2BSV, ela
50

ainda no foi implementada. Durante o parser, caso o compilador encontre a

instruo while, ser emitido um erro no console e todo o processo abortado.
Por exemplo, a sada do compilador para o seguinte cdigo
while(x == 1){...};
pode ser vista na listagem 4.9. Na linha 10 encontra-se a mensagem de erro
[While] not implemented yet!.
Listagem 4.9: Sada da AST indicando que uma instruo ainda no foi implementada.
1
2
3
4
5
6
7
8

-root
- While
- Condition
Equal [==]
Identifier [x]
Int [1]
- Do
Statement

9
10

[While] not implemented yet!

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

Instrues de deciso e laos podem ser representadas na prpria mquina

de estados em UML de forma visual. Por exemplo, as estruturas de decises
como if e case podero ser representadas atravs das transies entre os estados com sua respectiva condio, como pode ser visualizado na figura 4.11(a).
51

Tambm possvel expressar estruturas de laos como f or e while atravs de

estados aninhados, conforme mostrado na figura 4.11(b).

(a) Estrutura case utilizando

mquina de estado.

(b) Estrutura de laos aninhados

utilizando mquina de estado.

Figura 4.11: Representaes de estruturas de decises e laos como mquina

de estados.

52

CAPTULO

5
Aplicaes da Ferramenta Proposta

Como forma de validar a ferramenta, foram desenvolvidos dois testes com

finalidades bem distintas entre si: um processador de uso geral e um elemento
de processamento de imagem Sobel para deteco de bordas. A inteno com
estes dois casos a de explorar todos os recursos desenvolvidos neste trabalho
como declarao de tipos de dados, utilizao de vetores e memria, uso de
laos aninhados de forma grfica, entre outros.
Para validar o comportamento destes dois exemplos, foram realizadas simulaes com a ferramenta Bluesim e os respectivos resultados analisados.
Estes dois exemplos tambm foram sintetizados utilizando a ferramenta Quartus II da Altera, tendo como alvo o kit de desenvolvimento da Terasic DE2-701 .
Dentre as caractersticas desde kit, ele possui um FPGA da famlia Cyclone
II modelo EP2C70F896C6. Os resultados das simulaes e o relatrio das
snteses realizada, partir do Verilog gerado pelo compilador Bluespec, so
apresentados no final de cada seo.

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

dos. Foram implementadas onze instrues desde processador, divididas em

trs grupos, onde foram mantidos os mesmos opcodes utilizados nas aulas de
laboratrio.

5.1.1

Modelagem do processador

Antes de comear a modelagem do processador com o diagrama de estados,

necessrio definir, no diagrama de classes, os tipos de dados que sero
utilizados. Conforme ilustrado na figura 5.1, foram definidos cinco tipos de
dados:
trs tipos Bit com tamanhos 3, 6 e 16 bits;
um vetor para armazenar 8 elementos de 16 bits;
e uma memria com a seguinte configurao:
largura de endereo de 6 bits, possibilitando enderear 64 posies
de memria, ficando 32 posies para as instrues e o restante para
os dados;
largura de dados de 16 bits para comportar o tamanho das instrues do processador;
tipo single port;
dados, que sero carregados na memria no incio da simulao, em
codificao binria;
arquivo com o contedo inicial da memria nomeado como memory.bin.

Figura 5.1: Definio dos tipos de dados utilizados na modelagem do processador.

O prximo passo fazer a modelagem da mquina de estados que ir representar o processador.
54

Como possvel observar na figura 5.2, o primeiro estado a ser executado

o Fetch. Nele feita uma requisio de leitura memria no endereo
armazenado no registrador PC (program counter), que no incio tem o valor
0; o valor do PC incrementado; e a execuo direcionada para o estado
Decode. importante lembrar que todas as operaes dentro do estado so
executadas em paralelo em um nico ciclo de relgio.
No estado Decode, a instruo j est disponvel na porta da memria para
ser lida. Este valor ento armazenado no registrador IR (instruction register)
para ento seguir ao estado PostDecode.
O estado PostDecode um estado auxiliar do Decode que no executa instruo. Ele necessrio apenas para que o valor do registrador IR, modificado
no estado anterior, fique com seu valor atualizado. a partir deste estado que
saem as diversas transies para os estados que iro executar suas respectivas instrues. Cada transio tem como condio os 6 primeiros bits do
registrador IR para identificar qual instruo dever ser executada.
As instrues implementadas podem ser divididas em trs grupos. As tabelas 5.1, 5.2 e 5.3 listam os conjuntos de instrues relacionadas manipulaes de dados, operaes aritmticas e de controle, respectivamente.
Tabela 5.1: Instrues de manipulao de dados.
Instruo
MOV RX RY
LOADINDEX RX RY
STOREINDEX RX RY
LOADIMED RX

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

Tabela 5.2: Instrues aritmticas.

Instruo
ADD RX RY RZ
SUB RX RY RZ
MUL RX RY RZ
DIV RX RY RZ

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

Algumas instrues necessitam de apenas um ciclo de relgio para serem

executadas, j outras necessitam de 2 ciclos. No caso das instrues que
necessitam de mais de um ciclo para completar sua execuo, isto feito
colocando um estado a mais para a instruo em questo, como pode ser visto,
55

Tabela 5.3: Instrues de controle.

Instruo
Significado
NOP
Sem operao
HALT
Parar a execuo

Opcode
000000|x|xxxxxxxxx
001111|x|xxxxxxxxx

por exemplo, com a instruo LOADIMED onde foram necessrios utilizar os

estados LoadImed1 e LoadImed2.
No final da execuo de cada instruo, as transies fazem o fluxo de
execuo retornar ao estado Fetch, fechando assim o ciclo de operao. A
nica exceo da instruo HALT, cujo o objetivo justamente encerrar o
ciclo de execuo.

Figura 5.2: Diagrama de estados do processador.

Para finalizar a modelagem do processador necessrio criar uma ao no
diagrama de atividades, apresentado na figura 5.3. Nesta ao atribudo
que seu comportamento representado pelo diagrama de estados, cujo o mo56

delo o da mquina de estados em UML da figura 5.2. Adicionalmente, so

criados os sinais de entrada/sada e as variveis locais. No caso deste processador foram definidas apenas variveis locais utilizando os tipos definidos no
diagrama de classes, conforme segue:
pc Bit#6
ir Bit#16
(rx, ry, rz) Bit#3
registers VecRegisters (8 elementos do tipo Bit#16)

Figura 5.3: Ao que representa o processador com as variveis utilizadas

localmente na regio inferior.

5.1.2

Resultados

Foi criado um programa com algumas instrues para testar o funcionamento

do processador. Estas instrues j esto em codificao binria no arquivo
texto que ser carregado na memria. Na listagem 5.1 encontra-se um trecho
deste arquivo. Junto com as instrues, esto alguns dados que fazem parte
dos testes.
Listagem 5.1: Instrues utilizadas para testar o processador.
1
2
3
4
5
6
7
8

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

// *** INICIO DO SEGMENTO DE DADOS ***

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

Fitter Resource Usage Summary

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

Slow Model Fmax Summary

-----------------------------------------------------------------------Fmax
Restricted Fmax
Clock Name
Note
-----------------------------------------------------------------------21.73 MHz
21.73 MHz
CLK

No apndice A encontra-se o cdigo fonte BSV completo gerado pela ferramenta UML2BSV deste processador.

5.2

Elemento de Processamento de Imagem Sobel

Para explorar outras funcionalidades da ferramenta UML2BSV, modelou-se

um elemento de processamento para deteco de borda em imagens digitais
por meio do algoritmo Sobel (Marques Filho e Neto, 1999). Este mtodo trabalha com duas mscaras 3 3 que so aplicadas a cada pixel da imagem
original. Uma mscara responsvel por detectar as variaes horizontais e
outra para as verticais.
As mscaras utilizadas no filtro Sobel so:



 1 2 1 
 1






H=
0
0
0  , V =  2




 1
1
2
1 

0
0
0

1
2
1

A cada janela formada pela mscara na imagem original resulta em um

pixel na nova imagem. No incio da operao a mscara localizada no canto
superior esquerdo da imagem, com deslocamento da esquerda para a direita,
pixel por pixel, at que a janela alcance a lateral direita da imagem. Aps isso,
ela recolocada totalmente esquerda da imagem novamente, mas uma linha
a baixo, e segue deslocando-se novamente para a direita por todas as colunas.
Todo o procedimento termina quando a janela ficar localizada no canto inferior
direito da imagem.
59

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   
    
    
    
    
..
..
.. .. .. . .
.
.
.
. . .
     


















 

 







Os pixels que formam a borda da imagem no so calculados. Existem

alguns mtodos para tratar este problema, mas no caso deste trabalho, optouse por ignorar esta regio. Com isso, a imagem MN resultante fica com as
dimenses M-2N-2.

5.2.1

Modelagem do filtro Sobel

Para a implementao do filtro Sobel foram necessrios definir no diagrama

de classes quatro tipos de dados, conforme mostra a figura 5.4.
dois tipos Bit com tamanhos 1 e 14 bits;
um tipo Int com tamanho de 32 bits;
e uma memria com a seguinte configurao:
largura de endereo de 14 bits, possibilitando enderear 16.384 posies de memria, o suficiente, por exemplo, para armazenar uma
imagem com dimenses 128128.
largura de dados de um Inteiro, para armazenar as informaes dos
pixels;
tipo single port;
60

 dados, que sero carregados na memria no incio da simulao, em

codificao hexadecimal;
arquivo com o contedo inicial da memria nomeado como mOriginal.hex.

Figura 5.4: Definio dos tipos de dados utilizados na modelagem do filtro

Sobel.
Com os tipos de dados definidos passa-se para a modelagem da mquina
de estados do filtro Sobel, representado na figura 5.5.
Da forma que o filtro Sobel foi implementado neste trabalho, ele capaz de
processar imagens de diversas dimenses. O limitador est na quantidade de
bits alocados para o endereamento na memria, que, neste caso, a multiplicao do nmero de linhas vezes o de colunas (MN) no pode ser maior do
que 16.384.

Figura 5.5: Diagrama de estados do filtro Sobel.

O primeiro estado, BeginSobel, faz inicializao de uma varivel e fica
aguardando um sinal externo para comear. Essa espera necessria para
que o mdulo receba os valores com a dimenso da imagem que ser processada.
61

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.6: Captura de tela da ferramenta UML onde o comportamento do

estado CalcHV definido utilizando a linguagem C.
comportamento do estado, que neste caso foi o C;
Body, onde encontra-se o comportamento do estado CalcHV escrito em
C e que ser traduzido para Bluespec pelo compilador C2BSV.
O cdigo do estado CalcHV faz parte do clculo do filtro Sobel e, como j foi
explicado neste trabalho, estas duas instrues sero executadas num mesmo
ciclo de relgio. Para finalizar a modelagem do filtro Sobel, necessrio criar
uma ao no diagrama de atividades, apresentado na figura 5.7.
Assim como no exemplo anterior, o comportamento desta ao ser a mquina de estados da figura 5.5. Para o filtro Sobel foram declarados sinais de
entrada e sada alm de variveis locais, listadas a seguir com seus respectivos
tipos:
Sinais de entrada:
start Bit#1
rows, cols Int#32
Sinal de sada:
ready Bit#1
Variveis locais:
i00 ao i22 Int#32
63

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).

(a) Imagem original

(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

Total memory bits

524,288 / 1,152,000 ( 46 % )
Embedded Multiplier 9-bit elements 2 / 300 ( < 1 % )
Total PLLs
0 / 4 ( 0 % )

19
20
21
22
23
24
25
26
27
28
29

Fitter Resource Usage Summary

-----------------------------------------------------------------------Resource
Usage
-----------------------------------------------------------------------M4Ks
128 / 250 ( 51 % )
Total block memory bits
524,288 / 1,152,000 ( 46 % )
Total block memory implementation bits
589,824 / 1,152,000 ( 51 % )
Embedded Multiplier 9-bit elements
2 / 300 ( < 1 % )
PLLs
0 / 4 ( 0 % )

30
31
32
33
34
35
36

Slow Model Fmax Summary

-----------------------------------------------------------------------Fmax
Restricted Fmax
Clock Name
Note
-----------------------------------------------------------------------68.19 MHz
68.19 MHz
CLK

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

um diagrama de estados, seria possvel modelar um diagrama de atividades

com diversas aes. Utilizando elementos do tipo Fork, seria possvel dividir o
fluxo de execuo em n aes, cada uma executando uma mquina de estado
de forma concorrente.
Outra melhoria poderia incluir o uso das aes Entry e Exit dentro dos estados. Com isso seria possvel reduzir o nmero de estados de uma modelagem.
Atualmente apenas a ao Do permitida.
Outra limitao desta ferramenta que atualmente no possvel fazer uso
de outros mdulos durante a modelagem de um hardware. Caso esta situao
seja necessria preciso fazer modificaes manualmente no cdigo fonte BSV
gerado.
Por fim, outras instrues poderiam ser implementadas ao subconjunto da
linguagem C, como por exemplo operaes com nmeros em ponto flutuante.
Parte dos trabalhos relacionados limitam-se a apenas gerar a parte de controle da mquina de estados, deixando o programador responsvel por escrever o comportamento de cada estado num momento posterior gerao do
cdigo. Outros trabalhos limitam-se apenas a copiar o cdigo do comportamento descrito pelo programador para regies correspondentes do controle da
mquina. J esta ferramenta se diferencia destes trabalhos dando opo ao
desenvolvedor de codificar o comportamento na prpria modelagem com a opo de utilizar o C, uma linguagem diferente da linguagem alvo, de alto nvel
e muito popular.
Parte deste trabalho resultou na publicao do artigo por Durand e Bonato
(2012) e um novo artigo est em fase final de escrita, abrangendo o trabalho
como um todo e ser submetido para uma revista especializada da rea.

68

Referncias Bibliogrficas

IEEE Standard for IP-XACT, Standard Structure for Packaging, Integrating,

and Reusing IP within Tools Flows. IEEE Std 1685-2009, p. C1 360, 18,
2010.
A BDEL -H AMID , A.; Z AKI , M.; T AHAR , S. A tool converting finite state machine
to VHDL. In: Electrical and Computer Engineering, 2004. Canadian
Conference on, 2004, p. 1907 1910 Vol.4.
A CCELLERA O RGANIZATION I NC .
IP-XACT Technical Committee.
http:
//www.accellera.org/activities/ip-xact, [Online; acessado em 02Fevereiro-2011], 2011.
A GARWAL , A. Comparison of high level design methodologies for algorithmic IPs: Bluespec and C-based synthesis. 2009. Dissertao (Mestrado),
Massachusetts Institute of Technology, 2009.
A HO , A. V.; S ETHI , R.; U LLMAN , J. D.
and tools. Addison Wesley, 1986.

Compilers: Principles, techniques,

A LDEC Active-HDL. http://www.aldec.com/activehdl/, [Online; acessado em 20-Novembro-2010], 2010.

A LTERA C ORPORATION Stratix IV GX FPGA Development Board, 530 Edition - Reference Manual. http://www.altera.com/products/devkits/
altera/kit-siv-gx.html, [Online; acessado em 21-Fevereiro-2011],
2010.
A PACHE S OFTWARE F OUNDATION The Apache Velocity Project. [On-line], [Online; acessado em 04-Outubro-2011].
Disponvel em: <http://velocity.apache.org/>.
B ERGER , A. S. Embedded systems design: An introduction to processes,
tools and techniques. CMP Books, 2001.
69

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.

Introduction to reconfigurable computing.

Berlin: Springer,

B ONATO , V.; M ARQUES , E. Roboarch: A component-based tool proposal for

developing hardware architecture for mobile robots. In: Industrial Embedded Systems, 2009. SIES 09. IEEE International Symposium on, 2009,
p. 249 252.
B ROWN , S. D. Fundamentals of Digital Logic with VHDL Design (McGrawHill Series in Electrical and Computer Engineering). McGraw-Hill Companies, 2005.
C ARBOU , M. xmltool - XML tool to manage XML documents through a Fluent
Interface. [On-line], [Online; acessado em 10-Agosto-2011].
Disponvel em: <http://code.google.com/p/xmltool/>.
D EDA S YS LLC Programming Language Popularity. http://langpop.com/,
[Online; acessado em 29-Novembro-2010], 2010.
D ELAMARO , M. E. Como Construir um Compilador: Utilizando Ferramentas Java. 1 ed.. Novatec, 2004.
D ENSMORE , D.; P ASSERONE , R. A Platform-Based Taxonomy for ESL Design.
Design Test of Computers, IEEE, v. 23, n. 5, p. 359 374, maio, 2006.
D UFFNER , S.; S TROBEL , R. Qfsm - A graphical tool for designing finite state
machines. http://qfsm.sourceforge.net/, [Online; acessado em 20Novembro-2010], 2010.
D URAND , S.; B ONATO , V. A tool to support Bluespec SystemVerilog coding
based on UML diagrams. In: 38th Annual Conference of the IEEE Industrial Electronics Society. IECON 12, IEEE, 2012, p. 4652 4657.
E DWARDS , S. The Challenges of Synthesizing Hardware from C-Like Languages. Design Test of Computers, IEEE, v. 23, n. 5, p. 375 386, maio,
2006.
F OWLER , M. UML distilled: a brief guide to the standard object modeling
language (3rd Edition). Boston: Addison-Wesley, 2003.
70

F ULLER , S.; M ILLETT, L. Computing performance: Game over or next level?

Computer, v. 44, n. 1, p. 31 38, janeiro, 2011.
G HOSH , K. L. IP-XACT Solutions. [On-line], [Online; acessado em 15-Abril2012].
Disponvel em: <http://www.edautils.com/ip-xact.html>.
G ILL , A. Introduction to the theory of finite-state machines.
Hill, 1962.
G RSSLE , P. UML 2.0 in action a project based tutorial.
U.K: Packt Pub, 2005.

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.

Processamento digital de imagens. Bras-

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

M OORE , E. F. Gedanken Experiments on Sequential Machines.

mata Studies. Princeton U., 1956. p. 129153.

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

N IKHIL , R.; C ZECK , K. BSV by Example. City: CreateSpace, 2010.

N ORVELL , T. S.
The JavaCC FAQ.
http://www.engr.mun.ca/~theo/
JavaCC-FAQ/, [Online; acessado em 17-Outubro-2010], 2007.
OSCI Open SystemC Initiative. http://www.systemc.org/, [Online; acessado em 27-Novembro-2010], 2010.
P ABLO , S.; C ACERES , S.; C EBRIAN , J.; B ERROCAL , M. A proposal for
ASM++ diagrams. In: Design and Diagnostics of Electronic Circuits and
Systems, 2007. DDECS 07. IEEE, 2007, p. 1 4.

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.

San Diego: Morgan Kaufmann,

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

Listagem do cdigo fonte BSV do processador de uso geral, apresentado na

seo 5.1, gerado automaticamente pela ferramenta UML2BSV.
Listagem A.1: Cdigo gerado do Processador.
1

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

typedef enum {START, FETCH, DECODE, POSTDECODE, LOADIMED1, LOADIMED2,

STOREIMED1, STOREIMED2, LOADINDEX1, LOADINDEX2, STOREINDEX, MOV, ADD,
SUB, MUL, DIV, NOP, HALT} State deriving(Bits, Eq);

10
11
12

(* synthesize *)
module mkProcessor(Empty);

13
14
15
16

BRAM_Configure cfg = defaultValue;

cfg.loadFormat = tagged Binary "memory.bin";
BRAM1Port#(Bit#(6), Bit#(16)) memory <- mkBRAM1Server(cfg);

17

75

18
19
20
21
22
23
24

Reg#(State) state <- mkReg(START);

Reg#(Bit#(6)) pc <- mkReg(0);
Reg#(Bit#(16)) ir <- mkReg(0);
Vector#(8, Reg#(Bit#(16))) registers <- replicateM(mkReg(0));
Reg#(Bit#(3)) rx <- mkReg(0);
Reg#(Bit#(3)) ry <- mkReg(0);
Reg#(Bit#(3)) rz <- mkReg(0);

25
26
27
28

rule start (state == START);

state <= FETCH;
endrule

29
30
31
32
33
34

rule fetch (state == FETCH);

memory.portA.request.put(makeRequest(False, pc, ?));
pc <= pc + 1;
state <= DECODE;
endrule

35
36
37
38
39
40
41
42
43

rule decode (state == DECODE);

let tmp <- memory.portA.response.get();
ir <= tmp;
rx <= tmp[9:7];
ry <= tmp[6:4];
rz <= tmp[3:1];
state <= POSTDECODE;
endrule

44
45
46
47
48
49
50
51
52
53
54
55
56
57

rule postDecode (state == POSTDECODE);

if (ir[15:10] == b111000) state <=
if (ir[15:10] == b111001) state <=
if (ir[15:10] == b111100) state <=
if (ir[15:10] == b111101) state <=
if (ir[15:10] == b110011) state <=
if (ir[15:10] == b100000) state <=
if (ir[15:10] == b100001) state <=
if (ir[15:10] == b100010) state <=
if (ir[15:10] == b100011) state <=
if (ir[15:10] == b000000) state <=
if (ir[15:10] == b001111) state <=
endrule

LOADIMED1;
STOREIMED1;
LOADINDEX1;
STOREINDEX;
MOV;
ADD;
SUB;
MUL;
DIV;
NOP;
HALT;

58
59
60
61
62
63

rule loadImed1 (state == LOADIMED1);

memory.portA.request.put(makeRequest(False, pc, ?));
pc <= pc + 1;
state <= LOADIMED2;
endrule

64
65
66

rule loadImed2 (state == LOADIMED2);

let tmp <- memory.portA.response.get();

76

67
68
69

registers[rx] <= tmp;

state <= FETCH;
endrule

70
71
72
73
74
75

rule storeImed1 (state == STOREIMED1);

memory.portA.request.put(makeRequest(False, pc, ?));
pc <= pc + 1;
state <= STOREIMED2;
endrule

76
77
78
79

80
81

rule storeImed2 (state == STOREIMED2);

let tmp <- memory.portA.response.get();
memory.portA.request.put(makeRequest(True, truncate(registers[rx
]), tmp));
state <= FETCH;
endrule

82
83
84

85
86

rule loadIndex1 (state == LOADINDEX1);

memory.portA.request.put(makeRequest(False, truncate(registers[ry
]), ?));
state <= LOADINDEX2;
endrule

87
88
89
90
91
92

rule loadIndex2 (state == LOADINDEX2);

let tmp <- memory.portA.response.get();
registers[rx] <= tmp;
state <= FETCH;
endrule

93
94
95

96
97

rule storeIndex (state == STOREINDEX);

memory.portA.request.put(makeRequest(True, truncate(registers[ry
]), registers[rx]));
state <= FETCH;
endrule

98
99
100
101
102

rule mov (state == MOV);

registers[rx] <= registers[ry];
state <= FETCH;
endrule

103
104
105
106
107

rule add (state == ADD);

registers[rx] <= registers[ry] + registers[rz];
state <= FETCH;
endrule

108
109
110
111
112

rule sub (state == SUB);

registers[rx] <= registers[ry] - registers[rz];
state <= FETCH;
endrule

77

113
114
115
116
117

rule mul (state == MUL);

registers[rx] <= registers[ry] * registers[rz];
state <= FETCH;
endrule

118
119
120
121
122

rule div (state == DIV);

registers[rx] <= registers[ry] / registers[rz];
state <= FETCH;
endrule

123
124
125
126

rule nop (state == NOP);

state <= FETCH;
endrule

127
128
129
130

rule halt (state == HALT);

$finish(0);
endrule

131
132

endmodule

133
134

endpackage

78

A PNDICE

B
Cdigo fonte BSV do filtro Sobel
gerado automaticamente pela
ferramenta UML2BSV

Listagem do cdigo fonte BSV do elemento de processamento do filtro Sobel,

apresentado na seo 5.2, gerado automaticamente pela ferramenta UML2BSV.
Listagem B.1: Cdigo gerado do Sobel.
1

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

typedef enum { BEGINSOBEL, FOR_J, STEP4, STEP3, CALCHV, ENDSOBEL, STEP2,

FOR_I, STEP1, STEP6, STEP5, STEP7, STEP8, ABS, STEP9, SUM, UPPERBOUND
, RESULT } State deriving(Bits,Eq);

16
17

(* synthesize *)

79

18

module mkSobelFSM(I_SobelFSM);

19
20
21
22

BRAM_Configure cfg = defaultValue;

cfg.loadFormat = tagged Hex "mOriginal.hex";
BRAM1Port#(Bit#(14), Int#(32)) mOriginal <- mkBRAM1Server(cfg);

23
24

Reg#(State) state <- mkReg(BEGINSOBEL);

25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42

Reg#(Bit#(1)) start <- mkReg(0);

Reg#(Int#(32)) i00 <- mkReg(0);
Reg#(Int#(32)) i01 <- mkReg(0);
Reg#(Int#(32)) i02 <- mkReg(0);
Reg#(Int#(32)) i10 <- mkReg(0);
Reg#(Int#(32)) i12 <- mkReg(0);
Reg#(Int#(32)) i20 <- mkReg(0);
Reg#(Int#(32)) i21 <- mkReg(0);
Reg#(Int#(32)) i22 <- mkReg(0);
Reg#(Int#(32)) i <- mkReg(0);
Reg#(Int#(32)) j <- mkReg(0);
Reg#(Int#(32)) cols <- mkReg(0);
Reg#(Int#(32)) rows <- mkReg(0);
Reg#(Int#(32)) kernelH <- mkReg(0);
Reg#(Int#(32)) kernelV <- mkReg(0);
Reg#(Int#(32)) pixelOut <- mkReg(0);
Reg#(Bit#(1)) ready <- mkReg(0);

43
44
45
46
47

rule beginSobel (state == BEGINSOBEL);

if (start == 1) state <= FOR_J;
j <= -1;
endrule

48
49
50
51
52
53
54

rule for_j (state == FOR_J);

if (j >= (rows-3)) state <= ENDSOBEL;
if (j < (rows-3)) state <= FOR_I;
j <= (j + 1);
i <= -1;
endrule

55
56
57
58
59
60

61

rule step4 (state == STEP4);

state <= STEP5;
let tmp <- mOriginal.portA.response.get;
i02 <= tmp;
mOriginal.portA.request.put(makeRequest(False, truncate(pack((i+(
j*cols)+cols))), ?));
endrule

62
63
64
65

rule step3 (state == STEP3);

let tmp <- mOriginal.portA.response.get;
i01 <= tmp;

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

rule calcHV (state == CALCHV);

state <= ABS;
kernelH <= ((-1 * i00) + ((-2 * i01) + ((-1 * i02) + (i20 + ((2 *
i21) + i22)))));
kernelV <= ((-1 * i00) + (i02 + ((-2 * i10) + ((2 * i12) + ((-1 *
i20) + i22)))));
endrule

75
76
77
78

rule endSobel (state == ENDSOBEL);

ready <= 1;
endrule

79
80
81
82
83

84
85

rule step2 (state == STEP2);

let tmp <- mOriginal.portA.response.get;
i00 <= tmp;
mOriginal.portA.request.put(makeRequest(False, truncate(pack((i+(
j*cols)+1))), ?));
state <= STEP3;
endrule

86
87
88
89
90
91

rule for_i (state == FOR_I);

if (i >= (cols-3)) state <= FOR_J;
if (i < (cols-3)) state <= STEP1;
i <= (i + 1);
endrule

92
93
94

95
96

rule step1 (state == STEP1);

mOriginal.portA.request.put(makeRequest(False, truncate(pack((i+(
j*cols)))), ?));
state <= STEP2;
endrule

97
98
99
100
101

102
103

rule step6 (state == STEP6);

let tmp <- mOriginal.portA.response.get;
i12 <= tmp;
mOriginal.portA.request.put(makeRequest(False, truncate(pack((i+(
j*cols)+(cols*2)))), ?));
state <= STEP7;
endrule

104
105
106
107

rule step5 (state == STEP5);

let tmp <- mOriginal.portA.response.get;
i10 <= tmp;

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

rule step7 (state == STEP7);

let tmp <- mOriginal.portA.response.get;
i20 <= tmp;
mOriginal.portA.request.put(makeRequest(False, truncate(pack((i+(
j*cols)+(cols*2)+1))), ?));
state <= STEP8;
endrule

118
119
120
121
122

123
124

rule step8 (state == STEP8);

let tmp <- mOriginal.portA.response.get;
i21 <= tmp;
mOriginal.portA.request.put(makeRequest(False, truncate(pack((i+(
j*cols)+(cols*2)+2))), ?));
state <= STEP9;
endrule

125
126
127
128
129
130

rule abs (state == ABS);

state <= SUM;
kernelH <= abs(kernelH);
kernelV <= abs(kernelV);
endrule

131
132
133
134
135
136

rule step9 (state == STEP9);

let tmp <- mOriginal.portA.response.get;
i22 <= tmp;
state <= CALCHV;
endrule

137
138
139
140
141
142

rule sum (state == SUM);

if ((kernelV + kernelH) <= 255) state <= RESULT;
if ((kernelV + kernelH) > 255) state <= UPPERBOUND;
pixelOut <= (kernelV + kernelH);
endrule

143
144
145
146
147

rule upperBound (state == UPPERBOUND);

state <= RESULT;
pixelOut <= 255;
endrule

148
149
150
151
152

rule result (state == RESULT);

state <= FOR_I;
$display("%3d", pixelOut);
endrule

153

82

154
155
156
157

method Action in_start(Bit#(1) p_start);

start <= p_start;
endmethod

158
159
160
161

method Action in_cols(Int#(32) p_cols);

cols <= p_cols;
endmethod

162
163
164
165

method Action in_rows(Int#(32) p_rows);

rows <= p_rows;
endmethod

166
167
168
169

method Bit#(1) out_ready();

return ready;
endmethod

170
171
172

endmodule: mkSobelFSM

173
174

endpackage: SobelFSM

83

A PNDICE

C
Gramtica do compilador C2BSV

Listagem da gramtica utilizada para construir o compilador C2BSV, gerada

pelo programa JJDoc, parte do pacote do JavaCC.
Listagem C.1: Gramtica do compilador C2BSV.
1
2
3
4
5
6
7
8
9
10
11
12

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

|
|
|
|

<#DECIMAL_LITERAL: ["1"-"9"] (["0"-"9"])*>

<#HEX_LITERAL: "0" ["x","X"] (["0"-"9","a"-"f","A"-"F"])+>
<#OCTAL_LITERAL: "0" (["0"-"7"])*>
<FLOATING_POINT_LITERAL: (["0"-"9"])+ "." (["0"-"9"])* (<EXPONENT>)?
(["f","F","d","D"])? | "." (["0"-"9"])+ (<EXPONENT>)? (["f","F","d","
D"])? | (["0"-"9"])+ <EXPONENT> (["f","F","d","D"])? | (["0"-"9"])+
(<EXPONENT>)? ["f","F","d","D"]>
| <#EXPONENT: ["e","E"] (["+","-"])? (["0"-"9"])+>
| <STRING_LITERAL: "\"" (~["\"","\\","\n","\r"] | "\\" (["n","t","b","r
","f","\\","\","\""] | ["0"-"7"] (["0"-"7"])? | ["0"-"3"] ["0"-"7"]
["0"-"7"] | ["\n","\r"] | "\r\n"))* "\"">
}

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

StructDeclarator := ( Declarator | ( Declarator )? ":"

ConstantExpression )
Declarator := DirectDeclarator
DirectDeclarator := ( <IDENTIFIER> | "(" Declarator ")" ) ( ( ( "["
ConstantExpression "]" ) | ( "[" "]" ) )? ) ( "(" ParameterTypeList
")" | "(" ( IdentifierList )? ")" )*
ParameterTypeList := ParameterList ( "," "..." )?
ParameterList := ParameterDeclaration ( "," ParameterDeclaration )*
ParameterDeclaration := DeclarationSpecifiers ( Declarator | (
AbstractDeclarator )? )
IdentifierList := ( <IDENTIFIER> ) ( "," ( <IDENTIFIER> ) )*
Initializer := ( AssignmentExpression | "{" InitializerList ( "," )?
"}" )
InitializerList := Initializer ( "," Initializer )*
TypeName := SpecifierQualifierList ( AbstractDeclarator )?
AbstractDeclarator := ( DirectAbstractDeclarator )
DirectAbstractDeclarator := ( "(" AbstractDeclarator ")" | "[" (
ConstantExpression )? "]" | "(" ( ParameterTypeList )? ")" ) ( "["
( ConstantExpression )? "]" | "(" ( ParameterTypeList )? ")" )*
Statement := ( ExpressionStatement | CompoundStatement |
SelectionStatement | IterationStatement | JumpStatement )
ExpressionStatement := ( Expression )? ";"
CompoundStatement := "{" ( DeclarationList )? ( StatementList )? "}"
StatementList := ( ExpressionStatement | CompoundStatement |
SelectionStatement | IterationStatement | JumpStatement )+
SelectionStatement := ( <IF> "(" Expression ")" Statement ( <ELSE>
Statement )? )
IterationStatement := ( <WHILE> "(" Expression ")" Statement )
JumpStatement := ( <RETURN> ( Expression )? ";" )
Expression := AssignmentExpression ( "," AssignmentExpression )*
AssignmentExpression := AssignmentOperator
| ConditionalExpression
AssignmentOperator := UnaryExpression ( "=" AssignmentExpression |
"*=" AssignmentExpression | "/=" AssignmentExpression | "%="
AssignmentExpression | "+=" AssignmentExpression | "-="
AssignmentExpression | "<<=" AssignmentExpression | ">>="
AssignmentExpression | "&=" AssignmentExpression | "^="
AssignmentExpression | "|=" AssignmentExpression )
ConditionalExpression := LogicalORExpression ( ( ( "?" Expression ) (
":" ConditionalExpression ) ) )?
ConstantExpression := ConditionalExpression
LogicalORExpression := LogicalANDExpression ( ( "||"
LogicalORExpression ) )?
LogicalANDExpression := InclusiveORExpression ( ( "&&"
LogicalANDExpression ) )?
InclusiveORExpression := ExclusiveORExpression ( ( "|"
InclusiveORExpression ) )?
ExclusiveORExpression := ANDExpression ( ( "^" ExclusiveORExpression
) )?

87

96
97

98

99

100

101

102

103

104

105

106
107
108

109
110
111

ANDExpression := EqualityExpression ( ( "&" ANDExpression ) )?

EqualityExpression := RelationalExpression ( ( "=="
EqualityExpression | "!=" EqualityExpression ) )?
RelationalExpression := ShiftExpression ( ( "<" RelationalExpression
| ">" RelationalExpression | "<=" RelationalExpression | ">="
RelationalExpression ) )?
ShiftExpression := AdditiveExpression ( ( "<<" ShiftExpression | ">>"
ShiftExpression ) )?
AdditiveExpression := MultiplicativeExpression ( ( "+"
AdditiveExpression | "-" AdditiveExpression ) )?
MultiplicativeExpression := CastExpression ( ( "*"
MultiplicativeExpression | "/" MultiplicativeExpression | "%"
MultiplicativeExpression ) )?
CastExpression := ( "(" TypeName ")" CastExpression | UnaryExpression
)
UnaryExpression := ( PostfixExpression | "++" UnaryExpression | "--"
UnaryExpression | UnaryOperator )
UnaryOperator := ( "+" CastExpression | "-" CastExpression | "~"
CastExpression | "!" CastExpression )
PostfixExpression := PrimaryExpression ( "[" Expression "]" | "(" (
ArgumentExpressionList )? ")" | "." StructAttribute | "++" | "--"
)*
StructAttribute := <IDENTIFIER>
PrimaryExpression := ( <IDENTIFIER> | Constant | "(" Expression ")" )
ArgumentExpressionList := ( AssignmentExpression ( ","
AssignmentExpression )* )
Constant := <INTEGER_LITERAL>
| <FLOATING_POINT_LITERAL>
| <STRING_LITERAL>

112
113

DOCUMENT END

88