Pós -Gr aduação em Ciênci a da Computação

“U ma Metodol ogia para E s t i mativa de Área B as eados em R edes de Petr i T empor i zadas

par a Ambientes de S i s temas de H ardwar e/S oftwar e Co-Des i gn”

Por

Albano P or tela Machado

Di s s er tação de Mes tr ado

Universidade Federal de Pernambuco posgraduacao@cin.ufpe.br

www.cin.ufpe.br/~posgraduacao

RECIFE, AGOSTO/2004

ALBANO PORTELA MACHADO

UMA METODOLOGIA PARA ESTIMATIVA DE ÁREA BASEADOS EM REDES DE PETRI TEMPORIZADAS PARA AMBIENTES DE

SISTEMAS DE HARDWARE/SOFTWARE CO-DESIGN.

Dissertação apresentada ao Curso de Mestrado em Ciência da Computação como requisito parcial à obtenção do grau de Mestre em Ciência da Computação. Centro de Informática da Universidade Federal de Pernambuco. Orientador: Prof. Dr. Paulo Romero Martins Maciel

RECIFE, AGOSTO /2004

iii

DEDICATÓRIAS

Esta dissertação é dedicada aos meus pais Avelino (in memorian) e Avelina, que sempre acreditaram que a educação é o maior recurso que o ser humano deve buscar; aos meus irmãos Fátima, Juvino e Avelino e à professora Edna Barros, uma pessoa com uma capacidade profissional e valor humano inquestionáveis, que me incentivou a vir para esta instituição.

iv

AGRADECIMENTOS

Obrigado meu Deus por mais esta conquista! Gostaria de registrar meus agradecimentos como reconhecimento sincero da dedicação de muitas pessoas que direta ou indiretamente, contribuíram para a realização deste trabalho. Ao meu orientador professor Paulo Romero Martins Maciel na sua luta incessante sempre à busca de melhores meios e caminhos, guiando e monitorando o progresso desta pesquisa de forma objetiva e consistente. Aos professores Manoel Eusébio de Lima, PhD, e Ricardo Massa Ferreira de Lima, Doutor, pela brilhante participação da banca examinadora, contribuindo substancialmente para a melhoria da qualidade deste trabalho. Aos colegas e professores do GRECO (Grupo de Engenharia da Computação), em especial a Fábio Prudente, Pablo Viana, Edson Barbosa, Abel Silva, Cristiano Araújo, companheiros de mestrado que tanto deram apoio nos momentos em que parecia não haver luz no fim do túnel. Aos colegas Adnan Sherif (MSc UFPE) e Sérgio(UESB) pela ajuda na formalização dos conceitos matemáticos. À minha grande amiga Vanessa Bittencourt (UESB) que com seu apoio e carinho não mediu esforços para a concretização desta dissertação. Ao meu cunhado e grande amigo Eduardo Shimizu pela solidariedade e incentivo. Aos demais professores e funcionários da UFPE. Ao CNPQ pelo apoio financeiro.

v

UMA METODOLOGIA PARA ESTIMATIVA DE ÁREA BASEADOS EM REDES DE PETRI TEMPORIZADAS PARA AMBIENTES DE

SISTEMAS DE HARDWARE/SOFTWARE CO-DESIGN 1 Autor: Albano Portela Machado Orientador: Prof. Dr. Paulo Romero Martins Maciel

RESUMO

A maioria dos sistemas electrônicos modernos consiste em hardware dedicado e componentes programáveis (chamados componentes de software). Ao longo dos últimos anos, o número de metodologias que aplicaram simultaneamente técnicas de diferentes áreas para desenvolver sistemas mistos de hardware e software tem crescido consideravelmente.

Projetos concorrentes de sistemas mistos de hardware/software têm mostrado ser vantajoso quando considerado como um todo ao invés de se considerar entidades independentes. Hoje em dia, o mercado eletrônico demanda sistemas de alto desempenho e de baixo custo. Estes requisitos são essenciais para a competitividade de mercado. Além disso, um curto time-to-market é um fator importante. A demora no lançamento do produto causa sérias reduções no lucro, desde que é mais simples vender um produto quando se tem pouca ou nenhuma competição. Isto significa que facilitando o re-uso de projetos anteriores, uma rápida exploração de projeto, análise/verificação qualitativa em fases iniciais do projeto, prototipação e a redução do tempo requerido para testes, reduzem o tempo global exigido de uma especificação até o produto final. Ao projetar tais sistemas mistos de hardware/software, a análise de alternativas de projeto e a decisão de onde implementar cada parte de sistema, isto é, em hardware ou em software, são tarefas muito importantes. A estimativa de métricas de qualidade permite a exploração do espaço de projeto e pode guiar a decisão de implementação de partes do sistema. Tais métricas são calculadas no nível de sistema, ou seja, sem implementação real. Conseqüentemente, tais estimativas também aceleraram o projeto

1 Dissertação de Mestrado em Ciência da Computação, Centro de Informática, Universidade Federal de

Pernambuco, Recife, PE, (187p.). Agosto de 2004.

vi

do sistema e permitem a análise de restrições de projeto, fornecendo uma retroalimetação para decisões de projeto.

As redes de Petri são técnicas de especificação formal que permitem uma representação gráfica e matemática. Têm métodos poderosos que permitem aos projetistas realizar análises qualitativa e quantitativa. Redes de Petri Timed, são extensões de redes de Petri nas quais as informações de tempo são expressas por duração (rede com tempo determinístico, política de disparo em três fases) e são associadas às transições.

Para uma descrição comportamental de alto nível, o projeto de hardware é dividido em classes de blocos funcionais: caminho de dados e controladores.

O caminho de dados consiste em três tipos de componentes RT: unidades de armazenamento (registradores e latches), unidades funcionais (ALUS e comparadores), e unidades de interconexão (multiplexadores e barramentos).

As unidades de armazenamento são requeridas para armazenar valores de dados como constantes, variáveis e vetores no comportamento. As unidades funcionais são necessárias para implementar as operações no comportamento. Após todas as variáveis e operações no comportamento terem sido mapeadas às unidades de armazenamento e funcionais, respectivamente, podemos estimar o número de unidades de interconexão, como os barramentos e multiplexadores, os quais são requeridos para interligar as unidades de armazenamento e funcionais.

Este trabalho propõe uma abordagem para estimar a área de hardware a partir do número de unidades de armazenamento, funcionais e de interconexão, levando-se em consideração restrições de tempo e dependência de dados, e estende alguns trabalhos anteriores com o objetivo de melhorar a precisão dos métodos de estimativa de área. Isto é, o método proposto considera uma rede de fluxo de dados que captura dependência de dados e calcula a área do caminho de dados a partir do número e tipo dos seus componentes, considerando a relação de dependência temporal.

Palavras-chaves: Redes de Petri, Redes de Petri Temporizadas, Estimativas, Hardware/Software Co-Design, Dependência de Dados, Caminho de Dados, Unidades de Armazenamento, Unidades Funcionais, Unidades de Interconexão, Modelos Intermediários.

vii

A TIMED PETRI NET METHODOLOGY BASED ON AREA ESTIMATOR FOR HARDWARE/SOFTWARE CO-DESIGN

SYSTEMS ENVIRONMENTS 2 Autor: Albano Portela Machado Orientador: Prof. Dr. Paulo Romero Martins Maciel

ABSTRACT

Most modern electronic systems consist of dedicated hardware and programmable components (called software components). Over the last few years, the number of methodologies that concurrently apply design techniques from different areas to develop mixed hardware/software system has been growing considerably.

The concurrent design of mixed hardware/software systems has shown to be advantageous when considered as a whole instead of considering as independent entities. Nowadays, the electronic market demands high-performance and low cost systems. These requirements are essential for the market competitiveness. Furthermore, a short time-to-market is an important factor. The delay in product launching causes serious profit reductions, since it is much simpler to sell a product if you have little or no competition. It means that facilitating the re-use of previous designs, faster design exploration, qualitative analysis/verification in an early phase of the design, prototyping, and the reduction of the required time-to-test, reduce the overall time required from a specification to the final product.

When designing such mixed hardware/software system, the analysis of design alternatives and the decision of where to implement each part of system, that is, in hardware or in software, are very important tasks. The estimation of quality metrics permits design space exploration and may guide the decision of the implementation media of a system’s parts. Such metrics are calculated at system level, or rather, without real implementation. Hence, such estimations also speed up a system’s design and

2 Master of Science dissertation in Computer Science, Informatics Center, Federal University of

Pernambuco, Recife, PE, (176p.). Agosto, 2004.

viii

permit the analysis of design constraints, providing a quick feed-back for design decisions.

Petri nets are a formal specification technique that allow for a graphical, mathematical representation and have powerful methods which allow designers to perform qualitative and quantitative analysis. Timed Petri nets, are Petri nets extensions in which the time information is expressed by duration (determinist timed net with three phase policy firing semantics) and is associated to the transitions.

For a given high-level behavioral description, the hardware design is divided into classes of functional blocks: data-paths and controllers.

The datapath consists of three kinds of RT components: storage units (such as registers and latches), functional units (such as ALUS and comparators), and interconnect units (such as multiplexers and buses).

Storage units are required for holding data values by the constants, variables and arrays in the behavior. Functional units are needed to implement the operations in the behavior. After all the variables and operations in the behavior have been mapped to storage and functional units, we can estimate the number of interconnect units, such as buses and multiplexers, which are required for interconnecting the storage and functional units.

This work proposes an approach to estimate the hardware area based on the number of storage, functional and interconnect units, taking into account timing constraints and the data-dependency, and extends some previous works aiming improving the accuracy area estimation methods. That is, the proposed method considers an data-flow net that captures data-dependency for calculating the area of the data-path based on the number and type of its components, considering temporal dependence relation.

Keywords: Petri nets, Timed Petri Nets, Estimates, Hardware/Software Co-Design, Data-Dependency, Data-Path, Storage Units, Functional Units, Interconnect Units, Intermediate Model.

ix

SUMÁRIO

1 ................................................................................................................................... 1

Introdução ................................................................................................................... 1

1.1 Projeto de Sistemas Digitais.............................................................................. 1

1.2 Hw/Sw Co-Design: Uma visão Geral............................................................... 2

1.3 Estimativas ........................................................................................................ 6 1.3.1 Precisão versus Custo Computacional .......................................................... 7 1.3.2 Fidelidade .................................................................................................... 7

1.4 Estilos de Projetos ............................................................................................. 8

1.5 Métricas de Qualidade ...................................................................................... 9 1.5.1 Métricas de Custo de Hardware .................................................................... 9 1.5.2 Métricas de Custo de Software ................................................................... 10 1.5.3 Outras Métricas .......................................................................................... 11

1.6 Contribuições .................................................................................................. 12

1.7 Organização .................................................................................................... 13

2 ................................................................................................................................. 14

Trabalhos Relacionados ............................................................................................ 14

2.1 Modelos Intermediários .................................................................................. 14 2.1.1 Máquinas de Estados Finitos ...................................................................... 15 2.1.2 Grafos de Fuxo de Controle/Dados............................................................. 16 2.1.3 Redes de Petri ............................................................................................ 17

2.2 Algoritmos Usados em Estimativas de Área .................................................. 18 2.2.1 Unidades de Armazenamento ..................................................................... 18 2.2.2 Unidades Funcionais .................................................................................. 20 2.2.3 Unidades de Interconexão........................................................................... 21

2.3 Ferramentas de Co-Design.............................................................................. 22

x

2.3.1 Vulcan II .................................................................................................... 23 2.3.2 LYCOS ...................................................................................................... 24 2.3.3 Co-Design Studio ....................................................................................... 25 2.3.4 SpecSyn ..................................................................................................... 26

2.4 Conclusões ....................................................................................................... 28

3 ................................................................................................................................. 29

Redes de Petri ............................................................................................................ 29

3.1 Redes de Perti Marcadas ................................................................................ 30

3.2 Propriedades Comportamentais..................................................................... 33 3.2.1 Alcançabilidade (reachability).................................................................... 34 3.2.2 Limitação (boundedness)............................................................................ 34 3.2.3 Liveness ..................................................................................................... 36 3.2.4 Reversibilidade (reversibility) .................................................................... 37

3.3 Métodos de Análise ......................................................................................... 38

3.4 Subclasses de Redes de Petri........................................................................... 41 3.4.1 State Machine............................................................................................. 42 3.4.2 Marked Graph ............................................................................................ 42 3.4.3 Redes Free-Choice ..................................................................................... 42 3.4.4 Redes Extended Free-Choice...................................................................... 43 3.4.5 Redes Asymmetric Choice ......................................................................... 43

3.5 Redes de Petri Temporizadas ......................................................................... 44 3.5.1 Modelo de Zuberek .................................................................................... 44 3.5.2 Outros Modelos.......................................................................................... 50

3.6 Conclusões ....................................................................................................... 51

4 ................................................................................................................................. 52

Modelo Intermediário ................................................................................................ 52

4.1 Introdução ....................................................................................................... 52

4.2 Linguagem de Programação Occam............................................................... 53

4.3 Modelo de Fluxo de Controle.......................................................................... 54

4.4 Modelo de Fluxo de Dados.............................................................................. 56 4.4.1 Componentes da Rede ................................................................................ 57 4.4.2 Método de Tradução................................................................................... 58

4.5 Conclusões ....................................................................................................... 69

5 ................................................................................................................................. 70

Estimativa de Área..................................................................................................... 70

5.1 Modelo da Estimativa de Hardware............................................................... 70

xi

5.2 Sistema de Estimativa de Área de Hardware................................................. 71

5.3 Definição do Modelo Intermediário ............................................................... 72

5.4 Estimativa de Área do Caminho de Dados..................................................... 75 5.4.1 Número de Unidades de Armazenamento: Método Baseado nas Variáveis Simultaneamente “Vivas” ................................................................................... 76 5.4.2 Número de Unidades de Armazenamento: Método Baseado nos Tempos de Vida das Variáveis. ............................................................................................. 84 5.4.3 Número e Tipo de Unidades Funcionais ..................................................... 88 5.4.4 Número de Unidades de Interconexão (multiplexadores 2×1) ..................... 95 5.4.5 Área do Caminho de Dados ...................................................................... 106

5.5 Conclusões ..................................................................................................... 108

6 ............................................................................................................................... 110

Estudos de casos ...................................................................................................... 110

6.1 Um Pequeno Exemplo................................................................................... 110 6.1.1 Descrição ................................................................................................. 110 6.1.2 Unidades de Armazenamento ................................................................... 111 6.1.3 Unidades Funcionais ................................................................................ 114 6.1.4 Unidades de Interconexão (multiplexadores 2×1) ..................................... 116 6.1.5 Comparações............................................................................................ 117

6.2 Equação Diferencial de 2a Ordem. ............................................................... 117 6.2.1 Descrição ................................................................................................. 118 6.2.2 Unidades de Armazenamento ................................................................... 118 6.2.3 Unidades Funcionais ................................................................................ 120 6.2.4 Unidades de Interconexão (multiplexadores 2×1) ..................................... 121 6.2.5 Comparações............................................................................................ 122

6.3 Filtro de Ondas Elíptico de 5a Ordem. ......................................................... 123 6.3.1 Descrição ................................................................................................. 123 6.3.2 Unidades de Armazenamento ................................................................... 124 6.3.3 Unidades Funcionais ................................................................................ 125 6.3.4 Unidades de Interconexão (multiplexadores 2×1) ..................................... 126 6.3.5 Comparações............................................................................................ 127

6.4 Máquina de Refrigerantes ............................................................................ 128 6.4.1 Descrição ................................................................................................. 128 6.4.2 Unidades de Armazenamento ................................................................... 129 6.4.3 Unidades Funcionais ................................................................................ 130 6.4.4 Unidades de Interconexão (multiplexadores 2×1) ..................................... 131 6.4.5 Comparações............................................................................................ 133

6.5 Conclusões ..................................................................................................... 133

7 ............................................................................................................................... 135

Conclusões e Trabalhos Futuros ............................................................................. 135

xii

7.1 Objetivos do trabalho ................................................................................... 135

7.2 Trabalhos Futuros......................................................................................... 137

Apêndice A............................................................................................................... 141

Pequeno Exemplo .................................................................................................... 141

A.1 Modelo Intermediário – INA (.pnt ) ............................................................ 141

A.2 Tempo das Transições – INA (.tmd)............................................................ 144

A.3 Grafo de Estados .......................................................................................... 145

Apêndice B............................................................................................................... 152

Equação Diferencial de 2a Ordem ........................................................................... 152

B.1 Descrição em VHDL..................................................................................... 152

B.2 Descrição em Occam .................................................................................... 153

B.3 Modelo Intermediário – INA (.pnt ) ............................................................ 154

B.4 Esquemático do Modelo Intermediário ....................................................... 158

Apêndice C............................................................................................................... 159

Filtro de Ondas Elíptico de 5a Ordem. ..................................................................... 159

C.1 Descrição em VHDL..................................................................................... 159

C.2 Descrição em Occam .................................................................................... 160

C.3 Modelo Intermediário – INA (.pnt ) ............................................................ 161

C.4 Esquemático do Modelo Intermediário ....................................................... 171

Apêndice D............................................................................................................... 172

Máquina de Refrigerantes ....................................................................................... 172

D.1 Descrição em Occam .................................................................................... 172

D.2 Modelo Intermediário – INA (.pnt ) ............................................................ 173

D.3 Esquemático do Modelo Intermediário ....................................................... 181

Referências .............................................................................................................. 182

xiii

Lista de figuras

Figura 1.1: Metodologia de Hardware/software co-design. ......................................... 3 Figura 1.2: Modelos típicos de estimadores associados à precisão, fidelidade e velocidade das estimativas. .......................................................................................... 6 Figura 1.3: Estilos de projeto ....................................................................................... 9 Figura 2.1: O sistema VULCAN II.............................................................................. 23 Figura 2.2: Fluxo de tarefas em LYCOS ..................................................................... 25 Figura 2.3: A ferrameta Co-Desing Studio ................................................................. 26 Figura 2.4: Ambiente de projeto SpecSyn ................................................................... 27 Figura 3.1: Redes de Petri representando: (a) atividades paralelas determinísticas (uma rede de Petri marked graph); (b) computação dataflow. ................................... 31 Figura 3.2: Disparo da transição t e evolução da marcação....................................... 32 Figura 3.3: Dois tipos de confusão. (a) confusão simétrica. (b) confusão assimétrica. 33 Figura 3.4: Comportamento patológico qualitativo:(a) Uma rede de Petri não limitada, apresenta deadlock (não-viva), não-reversível; (b) Aumentando a marcação inicial (e.g. m0 (p5) = 1) a rede que é viva, entra em deadlock. ..................................................... 35 Figura 3.5: Exemplos de Redes de Petri contendo todas as possíveis combinações de propriedades: B (bounded ), L (live), R (reversible). (a) t1 dead, p1 ilimitado. (b) t1 dead, p1 ilimitado. (c) p2 ilimitado. (d) t1, t2, t3, t4 não vivas. (e) p1 ilimitado. (f) t1 dead. (g) marcação inicial não será mais alcançável. (h) apresenta todas as propriedades desejáveis. .................................................................................................................. 38 Figura 3.6: (a) Uma rede de Petri marcada. (b) A árvore de cobertura da rede. (c) O grafo de cobertura da rede. ........................................................................................ 41 Figura 3.7: Estruturas principais caracterizando redes de Petri e seu diagrama Venn.................................................................................................................................... 44 Figura 3.8: Rede de Petri temporizada Γ1................................................................... 48

xiv

Figura 4.1: Exemplo de especificação em occam........................................................ 54 Figura 4.2: Modelo do fluxo de controle para a especificação da Figura 4.1.............. 55 Figura 4.3: Tradução de um processo ........................................................................ 61 Figura 4.4: Tradução de literais ................................................................................. 61 Figura 4.5: Declaração de variáveis........................................................................... 62 Figura 4.6: Leitura de variável................................................................................... 63 Figura 4.7: Escrita de variável ................................................................................... 63 Figura 4.8: Tradução de expressões ........................................................................... 64 Figura 4.9: Tradução da atribuição (:= ) .................................................................... 65 Figura 4.10: Tradução de entrada (?) ........................................................................ 65 Figura 4.11: Tradução da saída(!) ............................................................................. 66 Figura 4.12: Tradução do condicional(IF/ALT).......................................................... 67 Figura 4.13: Tradução do laço (WHILE).................................................................... 67 Figura 4.14: Modelo do fluxo de dados para a especificação da Figura 4.1 ............... 68 Figura 5.1: Modelo para estimativas com unidade de controle e caminho de dados ... 71 Figura 5.2: Sistema de Estimativa de Área de Hardware............................................ 71 Figura 5.3: Especificação em occam de um comportamento bem simples ................... 72 Figura 5.4: Modelo de Fluxo de dados gerado pelo ferramenta depend...................... 73 Figura 5.5: Rede de Petri temporizada Γ1 – Modelo de fluxo de dados. ..................... 74 Figura 5.6: Grafo de estados para Γ1 ......................................................................... 78 Figura 5.7: Grafo de estados simplificado para ΓΓ1 ..................................................... 81 Figura 5.8: Transições escalonadas por estados para ΓΓ1. ........................................... 90

xv

Figura 5.9: Conexões para as entradas das unidades funcionais: UF1, UF2 e UF3 em

Γ3. .............................................................................................................................. 99 Figura 5.10: Implementação para Γ3 com multiplexadores 2 ×1. ................................ 99 Figura 5.11: Conexões fatoradas para as entradas das unidades funcionais: UF1, UF2 e UF3 em Γ3. .............................................................................................................. 99 Figura 5.12: Redução do número de multiplexadores 2 x 1 por fatoração para Γ3.... 100 Figura 5.13: (a) Conexões para as duas entrada da unidade funcional (b) Implementação do projeto final para Γ1.................................................................... 106 Figura 6.1: Comportamento escalonado e tempo de vida das variáveis .................... 111 Figura 6.2: Descrição em occam do pequeno exemplo ............................................. 111 Figura 6. 3: Pequeno Exemplo: Modelo Intermediário do Fluxo de Dados............... 112 Figura 6.4: Pequeno Exemplo: Tempos de disparos das transições ordenados no tempo.................................................................................................................................. 115 Figura 6.5: Pequeno Exemplo: Resultado do mapeamento das transições lógicas/aritméticas nas unidades funcionais. ............................................................ 116 Figura 6.6: Pequeno Exemplo – Caminho de dados com multiplexadores 2×1.......... 117 Figura 6.7: Máquina de Refrigerantes: Visão estrutural........................................... 129 Figura 7.1: Comportamento de um projeto: a) Especificação em occam, b) rede de fluxo de controle, c) rede de fluxo de dados (d) e grafo de alcançabilidade do fluxo de dados........................................................................................................................ 138 Figura 7.2: Comportamento de um projeto: a) Rede de fluxo de dados extendida e b) grafo de alcançabilidade gerado............................................................................... 139

xvi

Lista de tabelas

Tabela 3.1: O conjunto de estados alcançáveis em Γ1. ................................................ 49 Tabela 5.1: Xilinx 5000 Library (obtida em [38]) ....................................................... 75 Tabela 5.2: O conjunto de estados alcançáveis para Γ1 .............................................. 79 Tabela 5.3: Variáveis vivas por estados (tempo de vida das variáveis) para Γ1........... 85 Tabela 5.4: Resultado final do mapeamento das variáveis para os registradores para ΓΓ1

................................................................................................................................... 86 Tabela 5.5: Mapeamento das transições às unidades funcionais para ΓΓ1 .................... 91 Tabela 5.6: Mapeamento das variáveis para unidades de armazenamento para ΓΓ3. .... 96 Tabela 5.7: Mapeamento das transições (com suas respectivas variáveis de leitura e escrita) e definição das instruções às unidades funcionais em ΓΓ3. .............................. 96 Tabela 5.8: Conexões das unidades de armazenamento à unidade funcional UF1 em ΓΓ3.................................................................................................................................... 98 Tabela 5.9: Conexões das unidades de armazenamento à unidade funcional UF2 em ΓΓ3.................................................................................................................................... 98 Tabela 5.10: Conexões das unidades de armazenamento à unidade funcional UF3 em ΓΓ3. .............................................................................................................................. 98 Tabela 5.11: Mapeamento das transições à unidade funcional UF1 e suas respectivas instruções aritméticas para ΓΓ1. ................................................................................. 105 Tabela 5.12: Conexões unidades armazenamento com a unidade funcional UF1 para ΓΓ1.................................................................................................................................. 105

Tabela 6.1: Pequeno Exemplo: variáveis simultaneamente vivas por estados .......... 113 Tabela 6.2: Pequeno Exemplo: Tempo de vida das variáveis. ................................... 114

xvii

Tabela 6.3: Pequeno Exemplo: Resultado final do mapeamento das variáveis para os registradores ............................................................................................................ 114 Tabela 6.4: Pequeno Exemplo:Tempos de disparos iniciais e finais das transições... 115 Tabela 6.5: Pequeno Exemplo – Mapeamento das transições (com suas instruções) para as unidades funcionais utilizando somente componentes isolados..................... 116 Tabela 6.6: Pequeno Exemplo – Conexões das unidades de armazenamento às unidade funcionais. ................................................................................................................ 116 Tabela 6.7: Equação Diferencial de 2a Ordem: variáveis simultaneamente vivas..... 119 Tabela 6.8: Equação Diferencial de 2a Ordem: Tempo de vida das variáveis........... 119 Tabela 6.9:Equação Diferencial de 2a Ordem: Resultado final do mapeamento das variáveis para os registradores................................................................................. 120 Tabela 6.10: Equação Diferencial de 2a Ordem:Tempos de disparos iniciais e finais das transições ................................................................................................................. 120 Tabela 6.11: Equação Diferencial de 2a Ordem: Resultado do mapeamento das transições (operações lógicas aritméticas) nas unidades funcionais. ........................ 121 Tabela 6.12: Equação Diferencial de 2a Ordem: Mapeamento das transições (e suas respectivas instruções) para as unidades funcionais. ................................................ 121 Tabela 6.13:Equação Diferencial de 2a Ordem: Conexões das unidades de armazenamento às unidade funcionais...................................................................... 122 Tabela 6.14: Equação Diferencial de 2a Ordem: Resultados..................................... 122 Tabela 6.15: Filtro de Ondas Elíptico de 5a Ordem: variáveis simultaneamente vivas................................................................................................................................. 124 Tabela 6.16: Filtro de Ondas Elíptico de 5a Ordem: mapeamento variáveis para os registradores ............................................................................................................ 124 Tabela 6.17: Filtro de Ondas Elíptico de 5a Ordem – Tempos de disparos iniciais e finais das transições ................................................................................................. 125 Tabela 6.18: Filtro de Ondas Elíptico de 5a Ordem – Resultado do mapeamento das transições lógica/aritméticas às unidades funcionais. ............................................... 126

xviii

Tabela 6.19: Filtro de Ondas Elíptico de 5a Ordem – Mapeamento das transições (com suas instruções) às unidades funcionais. .................................................................. 126 Tabela 6.20: Filtro de Ondas Elíptico de 5a Ordem – Conexões das unidades de armazenamento às unidade funcionais...................................................................... 127 Tabela 6.21: Filtro de Ondas Elíptico de 5a Ordem – Resultados.............................. 128 Tabela 6.22 – Máquina de Refrigerantes: variáveis simultaneamente vivas por estados.................................................................................................................................. 130 Tabela 6.23: Máquina de Refrigerantes – Resultado final do mapeamento das variáveis aos registradores. ..................................................................................................... 130 Tabela 6.24: Máquina de Refrigerantes – Tempos de disparos iniciais e finais das transições. ................................................................................................................ 131 Tabela 6.25: Máquina de Refrigerantes – Resultado do mapeamento das transições lógica/aritméticas às unidades funcionais. ................................................................ 131 Tabela 6.26: Máquina de Refrigerantes – Mapeamento das transições (e suas instruções) às unidades funcionais............................................................................ 132 Tabela 6.27: Máquina de Refrigerantes – Conexões das unidades de armazenamento às unidade funcionais.................................................................................................... 132 Tabela 6.28: Máquina de Refrigerantes – Resultados. .............................................. 133

1 Introdução

Este capítulo introduz o problema de hardware/software co-design, seus objetivos e dá uma visão geral de suas principais atividades, dando ênfase aos métodos de estimativas de área. É também propósito deste capítulo mostrar a importância de se ter um modelo formal para análise qualitativa e quantitativa de sistemas concorrentes, e, finalmente descrever as contribuições deste trabalho.

1.1 Projeto de Sistemas Digitais

Projeto integrado de hardware e software (Hardware/Software Co-Design)

compreende o projeto de sistemas com dois tipos de componentes: os de aplicação

específica (hardware) e os programáveis de propósito geral (software), aos quais se

encontram acoplados [38]. Esta técnica de projeto é diferente das abordagens

convencionais (somente por hardware ou por software), porque relaciona o ciclo de

desenvolvimento do hardware ao do software. Desta forma, decisões tomadas no âmbito

do projeto de hardware afetam substancialmente o projeto de software. Este paradigma

de projeto tem sido aplicado a uma grande variedade de projetos de sistemas eletrônicos

especializados: equipamentos de comunicação, controladores e instrumentação bem

como em automação industrial.

Apesar de tais sistemas não serem novos, o apoio de ferramentas de CAD

(Computer Aided Design), tem sido bastante restrito, impedindo a implementação de

sistemas complexos devido ao elevado custo de desenvolvimento [6]. Esta área de

pesquisa tem despertado muito interesse nos últimos anos. Algumas das motivações

para a pesquisa recente nesta área são:

___________________________________________________________________

2

• a diminuição do custo de produção de dispositivos eletrônicos, tornando-se possível

incorporá-los a eletrodomésticos, veículos, aparelhos médicos, etc.

• a crescente diversidade e complexidade das aplicações que utilizam sistemas

integrados, as quais requerem métodos avançados para o projeto de hardware, de

software e da integração de ambos.

• as aplicações passaram a depender destes dispositivos eletrônicos para funcionar

levando a avanços em ambientes de simulação, técnicas de prototipação, métodos

formais para projeto e verificação, síntese de alto-nível e ferramentas CAD;

• a necessidade de se reduzir os custos de projeto;

• validação de sistema;

• redução do time-to-market.

1.2 Hw/Sw Co-Design: Uma visão Geral

O problema considerado no hardware/software co-design [7][17][28][62]

consiste na implementação de uma funcionalidade de um determinado sistema em um

conjunto interconectado de componentes de hardware e software, levando em

consideração as restrições do projeto e procurando balancear aspectos como custo,

desempenho, consumo de energia, etc. Por exemplo, considerando-se que uma

determinada funcionalidade venha a ser implementada apenas em software e que a

arquitetura tenha apenas um processador, é possível que restrições de desempenho não

venham a ser atendidas. Neste caso o uso de dispositivos de hardware de propósitos

específicos podem ser utilizados, de maneira que as restrições de desempenho sejam

satisfeitas. Por outro lado, é importante ressaltar que a implementação de

funcionalidades em software reduz o custo do produto.

O projeto de sistemas embarcados, segundo o paradigma de hardware-software

co-design, pode ser visualizado na Figura 1.1, a qual reúne as principais etapas de

projeto segundo as publicações mais recentes na área.

___________________________________________________________________

3

Na etapa de análise de requisitos [38] são definidas as características do

sistema com base nas especificações do cliente e restrições inerentes ao problema a ser

tratado. As principais características a serem capturadas incluem, além de uma primeira

visão da funcionalidade, requisitos de tempo real, tecnologia de implementação,

consumo de potência, tamanho do produto, custo de desenvolvimento, custo de

produção, ambiente de utilização do produto, confiabilidade, manutenção e evolução do

projeto.

Figura 1.1: Metodologia de Hardware/software co-design.

A especificação do sistema [23][38] é o resultado da etapa de análise,

representado por um modelo. A modelagem de sistemas embarcados não é uma tarefa

simples, face à heterogeneidade de seus componentes e à diversidade de aplicações.

Assim, atualmente, vários estilos de modelagem são utilizados, dependendo da

aplicação em questão, tais como: modelos orientado a estados, modelos orientados a

atividades, modelos orientados a estruturas e modelos heterogêneos.

___________________________________________________________________

4

Uma etapa essencial num sistema de co-design é a etapa de particionamento

[2][23][38] em hardware e software, onde se decide qual parte do sistema será

implementada em hardware e em software, de forma a resultar numa implementação

que satisfaça às restrições de projeto tais como: custo, desempenho, área e consumo de

potência, etc. O particionamento é um problema NP-completo, e portanto, algoritmos

que realizam particionamento automático são baseados em heurísticas que procuram

reduzir a complexidade do problema.

Uma vez obtida a especificação do sistema, esta é, normalmente, traduzida para

um modelo intermediário [2][38] (interno) capaz de representar as características desta

especificação. Um aspecto importante a ser considerado na escolha deste modelo

interno é o seu poder de representatividade de abstração e o formalismo associado, pois,

sobre este modelo serão realizadas análises qualitativas/quantitativas, verificação e

simulações. A adoção de um formalismo intermediário capaz de expressar diversos

modelos de comunicação e concorrência possibilita ao sistema de hardware/software co-

design ser independente da linguagem de especificação.

A etapa de validação/verificação e análise qualitativa [2][38] visa garantir que

o sistema resultante e a especificação são semanticamente equivalentes. Em geral, este

tipo de validação é realizado considerado-se um modelo simulável do sistema final em

vez de um protótipo real do mesmo. A validação pode se dar através de simulação ou

verificação formal de algumas propriedades do sistema. Validações podem ser

realizadas em algumas fases de projeto. Quando se valida o modelo ou um protótipo

temos a validação virtual e quando já se tem o produto a validação é dita validação

final.

A verificação por outro lado, é o passo onde se verifica se o modelo tem ou não

determinadas propriedades que o projetista julga importantes para o sistema a ser

desenvolvido. Técnicas de verificação formal podem garantir que duas descrições

distintas do sistema têm a mesma semântica.

A análise qualitativa não se procura por nenhuma propriedade específica, mas

por um conjunto de propriedades genéricas. Nesta etapa métodos formais são aplicados

___________________________________________________________________

5

para analisar se o modelo possui propriedades, tais quais liveness, fairness,

reversibilidade [50], etc.

Na etapa de estimativas [2][38] um conjunto de métricas são calculadas. Para o

cálculo destas métricas, é necessária a formalização de um conjunto de métodos e a

elaboração de ferramentas que implementem estes métodos. Os referidos algoritmos

devem considerar o modelo intermediário que representa a especificação do sistema,

restrições de projeto e a arquitetura de implementação. O conjunto de métricas obtido

nesta fase é de essencial importância, pois estas métricas orientam o particionamento

hardware/software; possibilitam uma exploração rápida do espaço de projeto pela

avaliação de diferentes alternativas de implementação; e a verificação de violações de

restrições sem a necessidade da implementação dos sistemas, tornando mais ágil todo o

processo de hardware/software co-design.

A etapa de co-síntese [2][38] visa a implementação do hardware, do software e

da interface entre ambos. Síntese de hardware envolve o mapeamento da descrição do

hardware em unidades físicas da arquitetura. Este processo é realizado em várias etapas

e por diferentes ferramentas de síntese, incluindo ferramentas de síntese de alto nível, de

síntese lógica e de layout. A síntese do software inclui a compilação dos módulos de

software para a arquitetura alvo. A síntese de interface visa a geração de hardware e

software necessários para a sincronização dos módulos de hardware e de software.

A fase de prototipação consiste na última tarefa de validação antes da

implementação final do sistema digital. Nesta fase, um protótipo é um sistema tão

similar ao sistema real o quanto possível naqueles aspectos que importam para a

avaliação do sistema, sem requerer uma implementação final. A criação de um protótipo

é baseada em geral em uma implementação com FPGAs (hardware) conectado a

processadores que executam o software, ou ainda pode-se usar tecnologias como

system-on-a-chip (SoC). SOC é a maior revolução no desenvolvimento de projeto de

circuitos e sistemas integrados, devido ao nível sem precedentes de integrações

possíveis. O sistema prototipado imita o comportamento do respectivo sistema real com

componentes de hardware e software juntos sem a necessária implementação real, de

forma a permitir a validação final do sistema em um único componente. Após os testes

___________________________________________________________________

6

de avaliação do protótipo o sistema pode ser implementado em uma arquitetura mais

definitiva, se necessário, com ajustes.

1.3 Estimativas

Estimativas de métricas no projeto de sistemas é essencial por duas razões;

primeiro, por permitir ao projetista avaliar a qualidade do projeto, comparando as

estimativas de qualquer métrica do projeto com as restrições especificadas por aquela

métrica. Por exemplo, se a área estimada do projeto for maior que o tamanho permitido,

pode ser necessário implementar em hardware vetores de variáveis (especificados

originalmente para serem implementados em memória do microcontrolador) para

satisfazer a restrição de tamanho. Segundo, estimativas permitem ao projetista de

sistemas explorar alternativas de projeto, provendo um rápida retro-alimentação para

qualquer decisão de projeto. Deste modo, o projetista pode explorar um grande número

de alternativas antes de fazer a síntese de sua implementação final [21].

Figura 1.2: Modelos típicos de estimadores associados à precisão, fidelidade e velocidade das

estimativas.

Pode ser necessário definir um modelo para estimar cada métrica do sistema. A

utilidade da estimativa depende da precisão e/ou fidelidade que o modelo representa o

sistema. Para mostrar o impacto dos modelos de projetos na estimativa, listamos na

Figura 1.2 modelos típicos que podem ser usados para estimar área de sistema a partir

de sua especificação funcional. Os vários tipos de modelos na figura representam uma

progressão de detalhes [21] que precisa ser definida a fim de melhorar a precisão da

___________________________________________________________________

7

estimativa de área. Para cada modelo na figura, também listamos tarefas adicionais que

um estimador deve apresentar para realizar estimativas precisas em comparação com os

modelos anteriores.

1.3.1 Precisão versus Custo Computacional

A Figura 1.2 deixa claro que uma importante questão na seleção de um modelo

de projeto é o tradeoff entre a precisão e o custo computacional para se calcular uma

métrica. A precisão [21] de uma estimativa é uma medida da proximidade entre a

estimativa e o valor real da métrica mensurada após a implantação do projeto. A

precisão depende do grau de detalhes do modelo do projeto. Por exemplo, o modelo da

Figura 1.2(a), aproxima a área de projeto como a soma das áreas de memória.

Estimadores baseados em tais modelos simples executam rapidamente e são fáceis de

serem desenvolvidos, dado que somente algumas características são computadas no

cálculo das métricas. Todavia, modelos simples não têm a precisão que possa ser

requerida para guiar o projetista na seleção da alternativa de projeto apropriada. Por

outro lado, um modelo de projeto pode incorporar diversos aspectos do sistema.

Estimadores baseados em modelos detalhados requerem maior tempo de computação,

contudo produzem estimativas mais precisas, e, portanto, possibilitam uma melhor

seleção das alternativas de projeto.

1.3.2 Fidelidade

A fidelidade [34] de um método de estimativa é definida como o percentual de

comparações de previsões corretas entre implementações de projeto. Se os valores

estimados de uma métrica de projeto para duas diferentes implementações comparadas

com seus respectivos valores medidos suportam o mesmo relacionamento comparativo,

então a estimativa compara corretamente as duas implementações. Em outras palavras,

a métrica estimada pode ser usada para selecionar a melhor implementação dentre um

conjunto de possíveis implementações diversas. Quanto mais alta a fidelidade de um

___________________________________________________________________

8

estimador, mais provável que decisões corretas de projeto sejam tomadas baseadas na

comparação das estimativas das duas implementações.

Durante a seleção de uma dentre diversas implementações de projeto, previsões

de qualidade de projeto baseadas em estimativas com alto grau de fidelidade resultarão,

em média, em melhores projetos. Fidelidade depende diretamente do modelo usado para

estimar o parâmetro do projeto (como por exemplo: custo e performance de

implementações de hardware e software). Em geral, quanto mais preciso o modelo,

maior a fidelidade do estimador.

1.4 Estilos de Projetos

Estilo de Projeto diz respeito à classe de estrutura física de circuitos usada na

confecção final de um determinado circuito integrado (chip ou CI) [2]. As aplicações

em geral podem ser implementadas usando circuitos integrados ASICs (Aplication

Specific Integrated Circuits) full-custom ou dispositivos semi-custom programáveis e

reconfiguráveis. A Figura 1.3 mostra possíveis estilos para implementação de projetos

[12][63][67][69].

Na implementação de lógica tradicional, a escolha da tecnologia ou estilo de

projeto, é usualmente conseqüência da capacidade, desempenho e preço desta

tecnologia. Projetos Full-custom proporcionam maior capacidade e melhor desempenho,

porém a um alto custo de projeto. Outros estilos tendem a ser mais baratos, para baixo

volume de produção, apresentando, em geral, menor desempenho e capacidade. Full-

custom, Standard-cell e MPGA são mais caros que FPGA e PLD em baixo volume de

produção, já que a confecção de máscaras e a necessidade de uma silicon foundry para

produzir os chips em muito os oneram. Por outro lado, FPGAs e PLDs são tecnologias

para baixo volume de produção, já que não precisam de gastos adicionais em confecção

de máscaras e outros custos de fabricação.

Embora tecnologias customizadas apresentem um custo mais alto de produção

que outros estilos, devido à complexidade de desenvolvimento e fabricação, quando se

___________________________________________________________________

9

deseja um grande volume de produção (alta escala de produção), o custo fixo é

amortizado, o que permite torná-lo competitivo e mais barato que os FPGAs. Assim, o

usuário deve escolher o estilo que melhor lhe convier, satisfazendo suas necessidades de

desempenho e preço.

Figura 1.3: Estilos de projeto

1.5 Métricas de Qualidade

Nesta seção, são descritas algumas das métricas de qualidade comumente usadas

para caracterizar um projeto. As duas mais importantes métricas são o custo e o

desempenho (tempo de execução) das implementações do hardware e software. Embora

outras métricas tenham importância significativa, muitas decisões de alto nível são

baseadas completamente nestas duas métricas.

1.5.1 Métricas de Custo de Hardware

Métricas de custo de hardware incluem o custo de manufatura dos chips, custos

de embalagens, custos de testes, custos de engenharia e de projeto .

O custo de manufatura depende do tamanho da implementação do projeto. A

métrica de tamanho mais comum é da área de projeto, a qual é uma medida da área de

silício requerida por uma implementação. Para um dado projeto, uma estimativa de área

deve incluir a área requerida para os elementos de armazenamento (registradores e

memórias), unidades funcionais (ULAs), unidades de interconexão (multiplexadores e

___________________________________________________________________

10

barramentos), lógica de controle e área de conexões requerida para conectar estes

elementos. Quando se projeta um sistema, estimativas de área são úteis quando se

deseja analisar se partes do projeto caberão em uma determinada área de chip. Por

exemplo, se a área de sistema é estimada em 80.000 mícrons quadrados, este sistema

não poderá ser implementado em um chip com uma área máxima de 50.000 mícrons

quadrados. O projeto deve ser então particionado e implementado como dois ou mais

chips.

O custo de embalagem é geralmente calculado levando-se em consideração o

número de pinos do projeto. O projetista deve ficar atento para minimizar o número de

pinos em um chip, já que o mesmo afeta não somente o custo de embalagem, como

também a área resultante da superfície da placa, para possibilitar a interconexão dos

pinos.

Atualmente ferramentas CAD são utilizadas para realizar testes e assim verificar

a validade do projeto bem antes da sua implementação. Estes mecanismos podem ajudar

a descobrir vários erros de especificação, evitando sua propagação ao longo do processo

de síntese. Após a implementação final do projeto são realizados testes para verificar o

funcionamento do projeto.

O custo de engenharia e projeto é medido pelas implicações financeiras

associadas com a realização da implementação de um projeto. Isto inclui custos de

manufatura, embalagens, testes, vendas e manutenção, etc.

1.5.2 Métricas de Custo de Software

Enquanto implementações em hardware têm como vantagem aumentar o

desempenho dos sistemas, partes do projeto são freqüentemente implementadas em

software, executando em um microprocessador específico. Diversas vantagens estão

associadas com a implementação em software. Primeiro, o custo de tal implementação é

bem baixo, dado que componentes programáveis como processadores e micro-

controladores são usualmente manufaturados em larga escala. Segundo, o tempo de

desenvolvimento requerido para a implementação em software pode ser

___________________________________________________________________

11

significantemente menor. Dada uma especificação executável, uma implementação em

software requer principalmente compilação, enquanto uma implementação em hardware

requer diversas atividades de projeto, incluindo testes e fabricação. Finalmente, com

implementações em software é possível realizar mudanças nas especificações no último

estágio do ciclo de projeto. Tais mudanças para uma implementação em hardware

freqüentemente acarretarão em um grande esforço de re-projeto.

Uma especificação implementada em software deverá ser compilada dentro de

um conjunto de instruções de um processador selecionado. As duas métricas de custo

associadas com a implementação em software são o tamanho da memória de programa e

dados.

1.5.3 Outras Métricas

Agora discutiremos brevemente algumas outras métricas aplicáveis ao projeto

de sistemas: métricas de desempenho, dissipação de potência, tempo de projeto e time-

to-market entre outras.

Métricas de desempenho podem ser divididas em métricas de computação e

comunicação. Métricas de computação medem o tempo requerido para se realizar a

computação de um determinado comportamento. Métricas de comunicação são relativas

ao tempo gasto por um componente na interação com outros componentes no sistema.

Dissipação de potência em componentes de sistemas refere-se ao consumo de

energia nos circuitos no tempo. A dissipação de potência é dependente da freqüência do

clock e do número de portas as quais estão realmente ativas (i.e, sofre uma mudança em

seu valor) em cada ciclo de clock. Quanto mais alta a freqüência do clock e o número de

portas ativas no componente, maior a potência dissipada pelo componente.

Tempo de projeto é definido como o tempo requerido para se obter uma

implementação a partir da especificação funcional. O tempo de projeto é dependente

diretamente da metodologia de projeto adotada.

Time-to-market direciona o projeto com relação ao potencial de lucro, dado que

o lucro está relacionado à brevidade com que um produto é lançado no mercado e o

___________________________________________________________________

12

período de ausência de concorrência. Time-to-market pode ser definido como o total de

tempo gasto desde a concepção do projeto até a entrega do produto ao consumidor final.

Além do tempo de projeto, deve ser considerado também o tempo requerido para

realizar-se um estudo de marketing, definição da especificação a partir dos requisitos

dos usuários, fabricação, testes, distribuição e desenvolvimento de suporte de hardware

e software para fazer com que o produto seja usável.

1.6 Contribuições

Como visto anteriormente, a etapa de estimativas é de fundamental importância

na solução do problema de hardware/software co-design. A estimativa de métricas

possibilita explorar o espaço de projetos mais precisamente, e pode fornecer

informações relevantes que auxiliem a decidir onde implementar os subsistemas, isto é,

em hardware ou em software. Estimativas precisas são ainda mais importantes em

sistemas que executam automaticamente o particionamento de hardware e software.

Algumas destas métricas consideram os aspectos inerentes às implementações em

hardware e em software. Para este propósito, modelos de implementação de hardware e

de software devem ser desenvolvidos. Tais modelos não devem ser ambíguos. Portanto

o uso de modelos formais, que têm semântica bem definida, possibilita representar as

características dos sistemas. Métodos bem estabelecidos para análise qualitativa (e

verificação) e para análise quantitativa são muito importantes no projeto de sistemas

mistos de hardware e software.

Redes de Petri [50][59][60][65][72] é uma família de formalismos consolidada

adequada à modelagem e validação de sistemas concorrentes, dado que concorrência,

sincronização e conflito são naturalmente expressos por estes modelos.

Um modelo em redes de Petri foi proposto por Maciel [38] para representar o

fluxo de controle, bem como várias métricas e ferramentas de análise associadas. O

desenvolvimento de um modelo de fluxo de dados foi proposto por Monteiro[47].

Também utilizando redes de Petri, tal modelo permitiu uma integração com o modelo

___________________________________________________________________

13

de fluxo de controle, trazendo a possibilidade de análise conjunta, simulação, assim

como melhoria nos resultados das estimativas.

Os resultados obtidos até então para estimativas de área de hardware [38]

levaram em consideração a fidelidade. Este trabalho de dissertação, dentro do contexto

de um sistema de hardware/software co-design, tem como objetivo específico

desenvolver uma metodologia para realizar estimativas de área de hardware:

multiplexadores, unidades funcionais e unidades de armazenamento. Desta forma, foi

proposta a implementação de uma ferramenta para cálculo da estimativa da área de

implementação de hardware – um estimador que leve em consideração precisão e

fidelidade a um custo computacional aceitável, para possibilitar boas soluções de

projeto. Para tal fim, esta ferramenta utiliza uma especificação comportamental

traduzida para o modelo de fluxo de dados [47], utilizando redes de Petri temporizadas

[72].

1.7 Organização

Este trabalho está organizado como segue: o Capítulo 2 apresenta os trabalhos

relacionados e o estado da arte em estimativas em hardware/software co-design. O

Capítulo 3 introduz os conceitos de redes de Petri que serão utilizados no decorrer do

trabalho. Um modelo para a representação de fluxo de dados utilizando redes de Petri é

apresentado no Capítulo 4. No Capítulo 5 é apresentada a metodologia para a

estimativa de área de hardware utilizando o modelo de fluxo de dados em redes de Petri.

Quatro estudos de casos foram realizados para validar a metodologia proposta. Estes são

apresentados no Capítulo 6. Finalmente, o Capítulo 7 conclui o trabalho e sugere

possíveis caminhos a serem tratados em trabalhos futuros.

2 Trabalhos Relacionados

Este capítulo apresenta um conjunto de trabalhos relacionados à estimativa de área. Primeiro, são apresentados alguns formalismos utilizados para a representação da funcionalidade da especificação que são utilizados pelas ferramentas. Em seguida, são descritos diferentes algoritmos para realização de estimativa de área. Posteriormente, são apresentadas algumas ferramentas de co-design, considerando seu fluxo de tarefas, formatos internos e estimadores de área. Finalmente, é feita uma comparação entre estas ferramentas.

2.1 Modelos Intermediários

Projetistas de sistemas usam diferentes modelos em suas diversas metodologias

de projeto de hardware ou software [20]. Estes modelos podem ser classificados em

cinco categorias distintas: (1) orientada a estados; (2) orientada a atividades; (3)

orientada a estruturas; (4) orientada a dados; e (5) heterogêneos. Um modelo orientado

a estados, tal como máquinas de estados finitos, representa o sistema como um

conjunto de estados e um conjunto de transições entre eles, as quais são ativadas por

eventos externos ou internos. Um modelo orientado a estados é apropriado para

sistemas de controle, reativos, onde as interações do sistema é o aspecto mais

importante do mesmo. As máquinas de estados finitos concorrentes hierárquicos e a

maioria das lógicas são exemplos de modelos orientados a estados. Um modelo

orientado a atividades – grafo de fluxo de dados, grafo de fluxo de controle –

descrevem o sistema como o conjunto de atividades relacionadas por dados ou

dependências de execução. Este modelo é mais aplicado a sistemas transformacionais,

tais como sistemas de processamento de sinais digitais, onde dados sofrem um conjunto

de transformações. As álgebras de processo são membros desta classe. Usando um

___________________________________________________________________

15

modelo orientado a estrutura, tal como um diagrama de bloco, pode-se descrever os

módulos físicos do sistema e as interconexões entre eles. Diferentemente dos modelos

orientados a estados e atividades os quais refletem a funcionalidade do sistema, o

modelo orientado a estrutura dá enfoque principalmente na composição física do

sistema. Alternativamente, pode-se usar o modelo orientado a dados, tal como um

diagrama de entidade-relacionamento, quando é preciso representar o sistema como

uma coleção de dados relacionados por seus atributos. Este modelo seria mais adequado

para sistemas de informação, tais como banco de dados, onde a função do sistema é

menos importante que a organização dos dados. Finalmente, o projetista poderia usar

um modelo heterogêneo – que integraria muitas das características dos quatro modelos

prévios – sempre que ele precisasse representar uma variedade de diferentes visões em

um sistema complexo. Grafo de fluxo de dados e controle, program-state machine e as

redes de Petri são exemplos de modelos heterogêneos.

Atualmente várias ferramentas de co-design adotam uma linguagem de alto-

nível como formato de entrada [3][26][45][55]. Entretanto, tais ferramentas também

utilizam um formato interno para representar a funcionalidade do sistema [45][55].

Alguns dos formatos mais utilizados para a representação da funcionalidade dos

sistemas são máquinas de estados finitos, grafo de fluxo de dados e controle, álgebras

de processo e as redes de Petri.

2.1.1 Máquinas de Estados Finitos

Máquinas de estados finitos (FSMs1) são um mecanismo de modelagem bastante

difundido, principalmente pela diversidade de técnicas de análise e de síntese

disponíveis. FSMs são indicadas para representar o comportamento seqüencial de um

sistema. Contudo, por falta de suporte a hierarquia e paralelismo, a especificação de

sistemas complexos via FSMs ordinárias acarreta uma explosão do número de estados.

FSMs também não provêm suporte para sistemas que envolvem processamento de

1 Finite State Machines

___________________________________________________________________

16

dados. Uma máquina de estados finitos [21] pode ser definida por uma quíntupla FSM =

⟨ S, I, O, f : S × I→ S, h : S × I→ O ⟩, onde:

• S = {s1, s2, . . . , sj} é um conjunto finito de estados;

• I = {i1, i2, . . . , im} é um conjunto finito de entradas;

• O = {o1, o2, . . . , on} é um conjunto finito de saídas;

• f é a função do próximo estado, a qual determina o próximo estado em

função da entrada e do estado corrente.

• h é uma função de saída, a qual determina as saídas, também em função da

entrada e do estado corrente.

Note que cada FSM tem um estado que é distinguido como o estado inicial e um

conjunto de estados distinguidos como estados finais.

Diversas extensões foram propostas a FSMs, desde o suporte a dados até

hierarquias. FSMs extendidas (EFSMs2) [22] acrescentam uma via de dados, permitindo

que computações sejam realizadas nos estados e nas transições de estados, bem como a

associação de condições de disparo dependentes dos dados. FSMs concorrentes

hierárquicas (HCFSMs3) [16] suportam a decomposição de estados em sub-estados

concorrentes, formando uma hierarquia de máquinas. Um sistema com n processos,

cada qual com k estados, gera uma FSM com kn estados. A hierarquia facilita o

entendimento do modelo.

2.1.2 Grafos de Fuxo de Controle/Dados

O modelo de grafos de fluxo de controle e dados (CDFGs4) é um modelo

heterogêneo elaborado para combinar os conceitos de grafo de fluxo de controle

(CFGs5) [11] e grafo de fluxo de dados (DFGs6) [13].

2 Extended FSMs 3 Hierarchical Concurrent FSMs 4 Control/Data Flow Graphs 5 Control Flow Graphs

___________________________________________________________________

17

Um CFG representa as seqüências de processamento (tal como as FSMs),

estruturas de repetição e decisão. Através do CFG é possível analisar propriedades

comportamentais do sistema. Já o DFG representa os processamentos de dados que

ocorrem no sistema. Com isso é possível avaliar dependências de dados, por exemplo.

Uma outra vantagem de tal modelo é o fato de tanto a estrutura de controle do

sistema como suas vias de dados estarem representadas em um único modelo. Desta

forma, além das análises individuais sobre cada modelo, é possível avaliar propriedades

combinadas do modelo através de simulação.

2.1.3 Redes de Petri

O modelo em redes de Petri [50] é outro tipo de modelo heterogêneo,

especialmente definido para modelar especificação de sistemas concorrentes. O modelo

de redes de Petri consiste de um conjunto de lugares, um conjunto de transições e um

conjunto de fichas. Fichas residem nos lugares e circulam através da rede sendo

consumidas e produzidas quando uma transição dispara, determinando assim seu

comportamento. A adoção de modelo em redes de Petri traz diversas vantagens, entre

elas:

• podem modelar uma grande variedade de características de sistemas:

seqüência de ações, escolhas não-determinísticas, sincronização, exclusão

mútua e concorrência;

• às atividades do sistema podem ser atribuídas informações como duração,

prioridades, condições, etc;

• podem ser usadas para analisar propriedades úteis como segurança, liveness,

ausência de dead-lock, etc;

• ferramentas disponíveis permitem analisar e verificar propriedades

funcionais e não funcionais do sistema;

6 Data Flow Graphs

___________________________________________________________________

18

• técnicas de redução podem ser aplicadas para diminuir o custo

computacional das análises e verificações.

As redes de Petri são o formalismo adotado neste trabalho e serão descritas em

mais detalhes no Capítulo 3.

2.2 Algoritmos Usados em Estimativas de Área

A especificação de um sistema pode ser decomposta em vários módulos

funcionais, os quais podem ser implementados em hardware ou software. Neste trabalho

nos referiremos a uma determinada funcionalidade de um projeto como comportamento.

Assim para implementar determinado comportamento de uma especificação, três

componentes estruturais do caminho de dados serão necessários: unidades de

armazenamento, unidades funcionais e unidades de interconexão.

Diversos métodos para síntese de via de dados têm sido extensivamente

discutidos em [20]. Nesta seção discutiremos três heurísticas utilizadas na estimativa de

área: clique partitioning, left-edge e o force-directed. Descreveremos estas técnicas para

estimar o número e tipo destes componentes que implementam o comportamento de um

sistema. Assim, partimos de uma representação comportamental e chegamos a uma

representação estrutural.

2.2.1 Unidades de Armazenamento

As unidades de armazenamento são estruturas requeridas para armazenar valores

de dados representados por constantes, variáveis e vetores (i.e registradores e laches). A

estratégia mais simples assume que cada variável no comportamento deverá ser

implementada em um registrador separado ou memória. Todavia, tal implementação

pode ter um excessivo número de unidades de armazenamento, já que valores de

variáveis não são necessários durante toda execução do comportamento. É possível

minimizar o número de unidades de armazenamento fazendo o mapeamento de diversas

___________________________________________________________________

19

variáveis que não são usadas concorrentemente para o mesmo registrador ou memória.

Para determinar se duas variáveis são usadas concorrentemente, devemos considerar

seus correspondentes tempos de vida. O tempo de vida de uma variável é definido como

o intervalo de tempo entre sua definição (i.e., escrita na variável) e seu último uso (i.e.,

leitura do valor da variável) antes da próxima definição. O número de unidades de

armazenamento que será requerido em um projeto é igual ao número máximo de tempos

de vida das variáveis que se sobrepõem.

Uma vez que o tempo de vida das variáveis tenham sido computados, diversas

abordagens podem ser usadas para determinar o número de unidades de armazenamento

requeridas para implementar as variáveis.

2.2.1.1 Algoritmo Clique Partitioning

A abordagem clique partitioning pode ser usada para determinar o conjunto de

variáveis que poderiam ser mapeadas na mesma unidade de armazenamento. Um grafo,

G = (V, E), é derivado de um dado comportamento, no qual cada vértice vi ∈ V

representa unicamente uma variável vi e existe um arco ei,j ∈ E se e somente se vi e vj

podem ser armazenados na mesma unidade de armazenamento, isto é, o intervalo de

tempo de vida das mesmas não se sobrepõem. Um sub-grafo completo (um conjunto de

vértices em um grafo não dirigido em que existe uma aresta entre todos os pares de

vértices) ou clique de G representa a unidade de armazenamento para todas as variáveis

no sub-grafo. Para encontrar o número mínimo de unidades de armazenamento,

devemos particionar o grafo G em um número mínimo de cliques de tal forma que cada

vértice pertença a exatamente a um clique. Este problema é chamado clique-partitioning

[10].

Descreveremos brevemente a heurística proposta em [68] para resolver o

problema do clique-partitioning. A abordagem consiste de diversas interações, em cada

uma o par de nós com o maior número de vizinhos comuns é fundido em um único nó.

Arcos de outros nós no grafo para os dois nós fundidos são substituídos por outros arcos

para o nó fundido criado recentemente. Repetindo o processo de fusão de nós até não

restarem arcos no grafo resultará na criação de um conjunto de cliques. Cada clique

___________________________________________________________________

20

corresponde a uma unidade de armazenamento, que implementará as variáveis

pertencentes ao clique.

2.2.1.2 Algoritmo Left-Edge

Outra heurística para solução do problema clique partitioning baseia-se no

algoritmo left-edge [30] que foi proposto para minimizar o número de registradores em

REAL [35]. Dada uma lista de variáveis no comportamento e seus intervalos de tempos

de vida associados, o algoritmo primeiro ordena a lista de variáveis em ordem

ascendente dos tempos iniciais de seus tempos de vida. O algoritmo realiza diversos

passos sobre a lista ordenada, examinando os tempos de vida das variáveis na ordem em

que elas ocorrem na lista. Em cada passo, o algoritmo aloca um novo registrador e

atribui uma nova variável ao mesmo se o tempo de vida desta variável não se

sobrepõem com os tempos de vidas das variáveis já atribuídas naquele registrador. Estas

variáveis atribuídas são então eliminadas da lista ordenada de variáveis. O processo é

repetido até que todas as variáveis tenham sido atribuídas aos registradores.

Os métodos citados possibilitam maior estimativa de precisão em relação ao

número de unidades de armazenamento necessários ao comportamento do que

simplesmente assumindo uma unidade de armazenamento por variável. Todavia, esta

estimativa mais precisa é obtida ao custo de computação extra, necessária para ambos os

métodos apresentados acima.

2.2.2 Unidades Funcionais

As unidades funcionais são necessárias para implementar as operações (i.e

ALUs e comparadores). Para se estimar o número requerido de unidades funcionais, no

caso em que o comportamento já tenha sido escalonado em passos de controle, diversas

abordagens podem ser usadas.

2.2.2.1 Algoritmo Clique Partitioning

A abordagem do clique partitioning [68] envolve a construção de um grafo

similar ao apresentado para determinar o número de unidades de armazenamento. Cada

___________________________________________________________________

21

nó no grafo representa uma operação no comportamento. Um arco existe entre dois nós

no grafo se e somente se as operações correspondentes tem sido atribuídas a diferentes

passos de controle e existem unidades funcionais que podem realizar ambas as

operações. Os cliques em tal grafo representa o conjunto de operações que podem ser

executadas pela mesma unidade funcional. A heurística já descrita na Seção 2.2.1.1

determinará o número necessário de unidades funcionais.

2.2.2.2 Algoritmo Force-Directed

Se uma restrição de desempenho (como o número máximo de passos de

controle) é especificada para o comportamento, o número mínimo de unidades

funcionais requerida para implementar este comportamento pode ser determinado

usando o algoritmo force-directed [56]. O algoritmo realiza tentativas de distribuir

operações do mesmo tipo uniformemente em todos os passos de controle disponíveis.

Esta distribuição uniforme garante que unidades funcionais alocadas para realizar

operações em um passo de controle são usadas eficientemente em todos os outros

passos de controle, levando a uma alta utilização das unidades funcionais. Em cada

iteração, o algoritmo atribui exatamente uma operação não escalonada no passo de

controle, assim minimizando o número esperado de unidades funcionais necessárias ao

projeto. Depois do término do algoritmo, o número máximo de operações de um tipo

específico atribuído a qualquer passo de controle é o número de unidades funcionais

daquele tipo. Diferentemente do clique partitioning, a abordagem requer a amarração

das unidades funcionais, i.e., a atribuição de operações no comportamento às unidades

funcionais específicas. Tal mapeamento de operações a unidades funcionais é essencial,

pois nos possibilita determinar o número de interconexões necessárias entre as unidades

de armazenamento e unidades funcionais.

2.2.3 Unidades de Interconexão

As unidades de interconexão são requeridas para interconectar unidades de

armazenamento às unidades funcionais (i.e multiplexadores e barramentos). Esta seção

___________________________________________________________________

22

mostra como o algortimo clique partitioning pode ser utilizado para determinar o

número de interconexões de um dado comportamento.

2.2.3.1 Algoritmo Clique Partitioning

Depois que todas as variáveis e operações no comportamento tenham sido

mapeadas para unidades de armazenamento e funcionais, podemos estimar o número de

unidades de interconexão, tais como barramentos e multiplexadores.

Primeiro, o conjunto de conexões entre as unidades de armazenamento e

funcionais no projeto é determinado. Por exemplo, se o comportamento tem a atribuição

A := B + C, então existe a conexão da unidade de armazenamento na qual B e C foram

atribuídas à unidade funcional que implementa a operação de adição, e outra conexão da

unidade funcional para a unidade de armazenamento na qual A está confinada.

Uma vez que as conexões tenham sido determinadas, um modelo de grafo

similar ao apresentado para determinar o número unidades de armazenamento e

funcionais é construído. Cada vértice no grafo representa a conexão entre duas

unidades. Um arco existe entre dois vértices se e somente se as conexões

correspondentes não são usadas concorrentemente para transferência de dados no

mesmo passo de controle. Cada clique no grafo representa uma unidade de

interconexão. Todas as conexões cujos vértices representativos estão no clique são

atribuídos ao mesmo multiplexador ou barramento.

2.3 Ferramentas de Co-Design

Esta seção apresenta alguns ambientes importantes de projeto de sistemas de

hardware/software. Nosso objetivo é fornecer uma visão geral de diferentes

metodologias de hardware/software co-design do ponto de vista de estimativa de área.

___________________________________________________________________

23

2.3.1 Vulcan II

O método de projeto de co-síntese de hardware/software desenvolvido por De

Micheli et al. [27] na Universidade de Stanford é descrito na Figura 2.1. A

funcionalidade ao nível de sistema é especificada com HardwareC como um conjunto

de processos interativos.

A descrição em HardwareC é compilada e gera um modelo baseado em um

grafo de fluxo de dados, o qual é particionado em uma arquitetura composta de um

microprocessador, um componente de hardware (que pode ser posteriormente dividida

em vários componentes) e uma memória local.

Descrição em Hardware C

ModeloSistema(grafo)

Programa(grafo-fluxo)

Interface(grafo)

ASIC(grafo)

Programa C

Implementação - sistema misto Simulação

Particionamento

Figura 2.1: O sistema VULCAN II

O algoritmo de particionamento utilizado no sistema VULCAN II se baseia na

versão mais simplificada do algoritmo Min cut, a qual foi adaptada para o contexto de

hardware/software co-design [25][27]. O algoritmo inicia com uma implementação em

hardware e tenta mover para software objetos elegíveis (operações determinísticas ou

blocos de atribuições com operações determinísticas), cuja movimentação minimize a

função objetivo e que satisfaça às restrições de desempenho. Uma vez que a

movimentação é realizada, os próximos objetos a serem considerados serão aqueles

mais relacionados ao objeto movido anteriormente, isto é blocos ou operações

sucessoras.

___________________________________________________________________

24

A função objetivo utilizada em VULCAN II incorpora as métricas de área de

hardware, área de memória para armazenamento de programa e dados, largura de

barramento, taxa de transferência de dados, custo de sincronização e tempo entre

algumas operações. A abordagem de Stanford não provê suporte para análise qualitativa

nem permite verificação formal.

O cálculo aproximado dos componentes de hardware é determinado através da

abordagem bottom up, estimando os recursos necessários para implementar operações

individuais. O tamanho do hardware é computado através do tamanho do atributo de

uma operação, todavia não inclui o custo do hardware para circuitos de controle.

2.3.2 LYCOS

O sistema LYCOS (LYngby CO-Synthesis) é um ambiente de co-design que

permite a implementação de sistemas digitais em uma arquitetura constituindo de um

microprocessador e ASIC com comunicação via memória mapeada em E/S [45][46].

Uma visão geral de co-design pode ser vista na Figura 2.2. O sistema aceita descrições

em C e VHDL, as quais são mapeadas para um formato interno baseado em CDFG7 –

grafos comunicantes de fluxo de controle e dados. Com base neste formato interno, a

funcionalidade da especificação inicial é representada através de uma rede hierárquica

de unidades funcionais com semântica bem definida, as quais se comunicam via

variáveis compartilhadas segundo protocolo assíncrono.

O particionamento em hardware/software é realizado considerando-se BSB’s

(Basic Scheduling Blocks) [46], os quais podem ser representados por um DFG (Data

Flow Graph), um loop, um condicional ou uma chamada de procedimento. Para cada

BSB é estimado um conjunto de métricas, incluindo as métricas de área de hardware,

quantidade de memória para dados e programas, tempo de execução em hardware e

software, bem como área e tempo das funções de comunicação, tanto do lado do

hardware como do lado do software. Esta estimativa é feita por ferramentas de análise e

de escalonamento integradas ao ambiente.

7 Control /Data Flow Graphs

___________________________________________________________________

25

CDFG´s

C VHDL

Tradutor Tradutor

Assembly VHDL

Geração de código

Interfaces

Bibl. Interfaces

Particionamento

Análise Est. Pot.

Escalon./Aloc.

Atribuição

Bibl. Funções

Síntese

Figura 2.2: Fluxo de tarefas em LYCOS

A estimativa de área de hardware considera a área do caminho de dados e a área

do controlador para cada BSB. Com o objetivo de computar o hardware para

implementação da descrição, primeiro um chip deve ser escolhido de uma biblioteca de

dispositivos. Segundo, recursos devem ser pré-alocados. Uma alocação extensa (grande

número de unidades funcionais) permite explorar eventuais paralelismos, mas, como a

área do controle é ac = achip – adp8, isto estabelece limites de quanta funcionalidade pode

ser implementada no hardware. De outra forma, uma pequena alocação (baixo número

de unidades funcionais) aumenta o número de BSB os quais podem ser movidos para

hardware, mas isto limita a exploração de paralelismo.

Embora o uso de alocação prévia permite considerar a possibilidade de recursos

compartilhados, ele não provê um método formal para computar a área de controle nem

para estimar possíveis compartilhamentos de recursos e área de registradores.

2.3.3 Co-Design Studio

O ambiente de hardware/software Co-Design Studio foi proposto por Cavalcante

[8] e estava voltado ao projeto de sistemas embarcados de tempo real crítico. Esta

abordagem considerava uma arquitetura multi-processada e consistia de uma ferramenta

de especificação que usa rede de Petri temporizada hierárquica, um algoritmo de

8 ac – controler área, achip – total chip area, adp – data-path area

___________________________________________________________________

26

escalonamento que leva em consideração deadlines e relações de exclusão, e um

algoritmo de particionamento (ver Figura 2.3).

As razões para uso de redes de Petri como formalismo de especificação é a sua

capacidade para análise de sistemas, especificação e síntese de hardware. Algumas

estruturas adicionais de gráficos foram incorporadas dentro da notação de redes de Petri

para facilitar o processo de modelagem. Todavia, estas estruturas são especificadas

usando elementos de redes de Petri padrões.

O método de particionamento é dividido em pré-particionamento e

particionamento do sistema. A fase de pré-particionamento analisa as restrições de

tarefas e relações entre tarefas com o objetivo de reduzir o tempo de execução movendo

estas tarefas para hardware. O sistema de particionamento move tarefas para hardware

considerando a exploração do paralelismo. Todavia, este framework não provê métodos

de estimativas formais para computar tempo de execução, área, custo de comunicação,

possibilidade de compartilhamento de recursos e grau de exclusão mútua.

Choice of Architecture

Process Scheduling

Pre- Partitioning

System Specification Architecture Selection

refinement

Time Wizard

Constraint Analysis Consistency / Profiling

System Partitioning

Success Hardware Synthesis Software Compilation

Change Analyses

Partitioning Loop

Failure

Figura 2.3: A ferrameta Co-Desing Studio

2.3.4 SpecSyn

O sistema SpecSyn consiste num ambiente composto por várias ferramentas que

permitem o projeto de sistemas digitais conforme o paradigma SER (Specify-Explore-

Refine) no qual o projetista especifica o sistema a ser projetado, explora as várias

alternativas de projeto e refina a solução mais adequada para um nível suportado pelas

___________________________________________________________________

27

ferramentas de síntese convencionais (hardware e software) [21]. Uma visão geral do

ambiente SpecSyn pode ser vista na Figura 2.4. O ambiente aceita descrições

comportamantais em VHDL ou specCharts, a qual é baseada em StateChart [6] e resulta

VHDL comportamental a nível de sistema, a partir da qual pode ser gerado código C e

código VHDL (níveis mais baixos de abstração) pela utilização de ferramentas de

síntese de software e de síntese de alto nível (hardware), respectivamente.

A especificação é traduzida para um modelo intermediário chamado SLIF no

qual as ferramentas operam. A abordagem do SpecSyn consiste de três tarefas:

alocação, particionamento e transformação.

Durante a fase de alocação são definidos os componentes da arquitetura de

implementação. Processadores e ASICs são alocados para o comportamento (partes

computacionais), memórias para variáveis que devem ser armazenadas e canais de

comunicação para barramentos. O passo de particionamento mapeia agora estes objetos

para os componentes da arquitetura fonte alocada. Diferentes algoritmos de

particionamento estão integrados no SpecSyn, entre os quais clustering, group

migration, simulated annealing e clique partitioning. Estimadores rápidos produzem

uma variedade de métricas de sistema para cada partição, incluindo desempenho de

hardware e software, taxa de bits, tamanho de hardware, pinos, tamanhos de programa

de software e dados. Para estimativa de parâmetros de hardware tais como tempo de

execução, ciclo de clock e área, uma biblioteca de projeto é fornecida. Tal biblioteca

contém informação sobre o número, tipo, delay e área dos componentes. Depois do

particionamento, a especificação inicial é refinada automaticamente incluindo alocação

de memória de variáveis compartilhadas e inseridas interface de protocolos.

Pré-Estimador

Refinamento

SLIF

Especificação funcional VHDL ou SpecChart

Descrição funcional system-level VHDLSíntese SW

Síntese HW

Síntese SW

Síntese HW

Estimador on-line

Transformação

Particionamento

Alocação

Estimador on-line

Transformação

Particionamento

Alocação

Estimador on-line

Transformação

Particionamento

Alocação

Figura 2.4: Ambiente de projeto SpecSyn

___________________________________________________________________

28

2.4 Conclusões

Neste capítulo foi apresentado alguns dos modelos intermediários utilizados em

metodologias de hardware/software co-design, com destaque a máquinas de estados

finitos, grafo de fluxo de controle/dados e redes de Petri. Em seguida abordamos alguns

algoritmos usados em estimativas de área, geralmente atuando em modelos de grafo de

fluxo de controle/dados: clique partitioning, left-edge e force-directed. Finalmente

citamos algumas ferramentas de co-design.

A metodologia proposta de estimativa de área de hardware atua sobre o

formalismo das redes de Petri. O uso do método formal (com semântica bem definida)

além da facilidade de modelagem permitem realizar análises quantitativas e qualitativas.

O modelo intermediário (grafo marcado) utilizado nesta abordagem é independente de

linguagem de descrição, possibilitando análises a um baixo custo computacional, o que

simplifica as análises de diversas alternativas de projetos.

Observamos que poucas ferramentas de Hardware/Software Co-Design utilizam

estimativas de área para o particionamento em hardware e software (Vulcan II, Lycos,

SpecSyn) e que poucos ambientes de Hardware/Software Co-Design apresentam

modelos intermediários baseados em métodos formais. As estimativas de área obtidas

por estes ambientes de Hardware/Software Co-Design são pouco precisas.

3 Redes de Petri

Este capítulo apresenta os principais conceitos de redes de Petri relevantes para este trabalho. Primeiro, são apresentados os componentes do modelo e sua notação gráfica. Em seguida, são mostrados as propriedades que podem ser capturadas a partir do modelo, os métodos de análise e as subclasses de redes de Petri. Finalmente, são apresentadas as redes de Petri temporizadas, o formalismo utilizado no desenvolvimento deste trabalho.

Atualmente os sistemas modernos estão cada vez mais paralelos (objetivando

melhoria do desempenho – maior utilização de tempo de CPU) e distribuídos

(otimizando o custo, o sistema é distribuído em computadores com menor poder de

processamento). Eles precisam ser analisados sob os pontos de vista qualitativos e

quantitativos [38]. Análise qualitativa busca propriedades como ausência de deadlocks,

a ausência de overflows (lugares não-limitados), ou a presença de exclusão mútua no

uso de recursos compartilhados. Seu objetivo principal é avaliar as características do

sistema modelado. Análise quantitativa busca informações sobre desempenho (e.g.

throughput, tempo de conclusão médios) ou nível de utilização (e.g. comprimento

médios de filas, taxas de utilização). Em outras palavras, a análise quantitativa procura

quantificar informações sobre desempenho, confiabilidade, disponibilidade, etc, do

sistema a ser modelado.

Redes de Petri (RdPs) são uma técnica de especificação formal, bem

estabelecida, que leva em conta uma representação gráfica e matemática, e têm métodos

poderosos que permitem aos projetistas realizarem análises qualitativas e quantitativas

[50][60]. São capazes de representar naturalmente concorrência, não-determinismo,

sincronização, restrições de tempo, dependência de controle e dados, etc. Redes de Petri

são o formalismo mais tradicional para tratar estas propriedades de sistemas, pois elas

não podem ser descritas facilmente em formalismos tradicionais, desenvolvidos para

___________________________________________________________________

30

análises de sistemas “clássicos” com comportamento seqüencial. Mais precisamente,

redes de Petri podem ser consideradas como um formalismo gráfico, especialmente

apropriado para modelagem e análise de sistemas dinâmicos de eventos discretos

(SDED), os quais apresentam paralelismo e o comportamento é caracterizado por

fenômenos de sincronização e compartilhamento de recursos. Sistemas

multiprocessados e distribuídos; redes de comunicação e arquiteturas de fluxo de dados;

sistemas de manufatura; são apenas poucos exemplos de SDED, para os quais

abordagens tradicionais se apresentam inconvenientes e inadequadas.

Redes de Petri-Básicas, todavia, não são completas para o estudo de

desempenho de sistemas desde que nenhuma suposição é feita sobre a duração das

atividades do sistema [72]. Diversas extensões ao conceito de tempo têm sido feitas às

redes de Petri. O tempo tem sido considerado associado ao disparo das transições e/ou

lugares de redes de Petri. Na abordagem utilizada neste trabalho, os tempos de disparos

estão associados às transições da rede. No começo dos disparos, fichas são removidas e

armazenadas nas transições, provenientes de seus respectivos lugares de entrada. Uma

descrição de “estado” deve levar em consideração a distribuição de fichas nos lugares,

bem como (disparos) transições da rede, e o “comportamento” da rede temporizada

(representada pelo seu espaço de estados) pode ser bem diferente que o conjunto de

marcações alcançáveis de uma rede marcada [72]. Em particular, redes marcadas não-

limitadas podem corresponder a redes temporizadas limitadas, bem como redes

temporizadas não-limitadas podem corresponder à redes marcadas limitadas (exemplos

são dados em [71])

3.1 Redes de Perti Marcadas

Uma rede de Petri ( veja Figura 3.1) é um tipo particular de grafo direcionado,

ponderado, bipartido, com um estado inicial chamado de marcação inicial, m0.

Consistindo de dois tipos de nós, chamados de lugares e transições, onde arcos provêm

dos lugares para as transições e das transições para os lugares. Na representação gráfica,

___________________________________________________________________

31

lugares são desenhados como círculos e transições como barras ou retângulos. Arcos

são rotulados com seus pesos (inteiros positivos), onde um arco k-ponderado pode ser

interpretado como um conjunto de k arcos paralelos. Rótulos para pesos unitários são

usualmente omitidos. Uma marcação (estado) atribui a cada lugar um inteiro não

negativo. Se uma marcação atribui a um lugar p um inteiro não negativo k, dizemos que

p é marcado com k fichas. Uma marcação é ilustrada por meio de k pontos pretos

(fichas) em um lugar p.

(a ) (b ) Figura 3.1: Redes de Petri representando: (a) atividades paralelas determinísticas (uma rede de Petri marked graph); (b) computação dataflow.

Em modelagem usamos o conceito de condições e eventos. Lugares representam

condições e transições representam eventos. Uma transição (um evento) tem um certo

número de lugares de entrada e saída representando as pré-condições e as pós-

condições de um evento, respectivamente. A presença de uma ficha em um lugar é

interpretada como uma condição verdadeira associada aquele lugar. Em outra

interpretação, k fichas são colocadas ao lugar para indicar que k itens de dados ou

recursos estão disponíveis.

Formalmente, uma rede de Petri Place/Transition N é uma quádrupla N =

(P, T, A, ω) onde:

P é um conjunto finito, não vazio, de lugares,

T é um conjunto finito, não vazio, de transições,

P ∩ T = {}; i.e. lugares e transições são conjuntos disjuntos,

A é um conjunto de arcos direcionados com conexões entre lugares com

transições e transições com lugares, A ⊆ (P × T) ∪ (T × P),

___________________________________________________________________

32

ω é uma função ponderada a qual associa um inteiro positivo “peso” para cada

arco da rede,

ω: A→ {1,2, ...}.

Usualmente, Inp(p), Out(p), Inp(t) e Out(t) denotam o multi conjuntos de

transições de entrada e saída de um lugar p, o multi conjuntos de lugares de entrada e

saída de uma transição t, respectivamente.

Uma rede de Petri Place/Transition marcada é um par M = (N, mo) onde:

N é uma rede de Petri generalizada, N = (P, T, A, ω),

mo é uma função de marcação inicial, mo : P→ {0,1, ...} que associa um número

não-negativo, chamado de fichas à cada lugar da rede.

Seja m: P→ {0,1, ...} uma função chamada de marcação de uma rede N = (P, T,

A, ω). Uma transição t está habilitada pela marcação m sse (se somente se) para cada

lugar de entrada de t (p ∈ Inp(t)), contém ao menos ω(p,t) fichas, ou seja m(p) ≥ ω(p,t).

O conjunto de todas as transições habilitadas por m é denominada por En(m). Cada

transição habilitada por uma marcação m pode disparar. Quando uma transição t

habilitada dispara, fichas são removidas dos lugares de entrada de t em números

correspondentes ao peso dos arcos de entrada, e semelhantemente, os pesos dos arcos de

saída de t determina o número de fichas adicionados aos lugares de saída (veja Figura

3.2). Um disparo de uma transição habilitada altera a avaliação da função de marcação.

(a)

d isparando t]t2

2

32

2

3

(b )

t

Figura 3.2: Disparo da transição t e evolução da marcação

Uma transição sem nenhum lugar de entrada é chamada transição source, e

aquela sem nenhum lugar de saída é chamada transição sink. Observe que uma transição

source está incondicionalmente habilitada, e que o disparo de uma transição sink

consome, mas não produz fichas.

___________________________________________________________________

33

Em algumas situações de modelagem, uma mistura de concorrência (atividades

paralelas) e conflito (um lugar tem duas (ou mais) transições de saída) pode ocorrer.

Esta situação é chamada de confusão. Dois tipos de confusão são mostrados Figura 3.3.

Figura 3.3(a) mostra uma confusão simétrica, onde dois eventos t1 e t2 são concorrentes

e ao mesmo tempo estão em conflito com o evento t3. Figura 3.3(b) mostra uma

confusão assimétrica, onde t1 é concorrente com t2 mas estará em conflito com t3 se t2

disparar primeiro.

Figura 3.3: Dois tipos de confusão. (a) confusão simétrica. (b) confusão assimétrica.

3.2 Propriedades Comportamentais

Sistemas distribuídos e concorrentes são difíceis de gerenciar e entender. Muitos

enganos e erros são freqüentes durante o ciclo de projeto.

Uma forma de se adquirir maior confiabilidade nestes sistemas pode ser pela

análise/verificação formal de propriedades. Erros podem ser detectados próximo do

momento em que são introduzidos, reduzindo a sua propagação para estágios

subseqüentes do projeto.

Este trabalho apresenta apenas algumas propriedades qualitativas – aquelas

relevantes para a metodologia desenvolvida. Dois tipos de propriedades são

consideradas: aquelas que dependem e as que são independentes da marcação inicial. As

primeiras são referidas como propriedades comportamentais e as últimas propriedades

estruturais. Nesta seção estudaremos as propriedades comportamentais básicas e as

respectivas técnicas de análise.

___________________________________________________________________

34

3.2.1 Alcançabilidade (reachability)

Alcançabilidade – indica a possibilidade de atingirmos uma determinada

marcação pelo disparo de um número finito de transições, a partir de uma marcação

inicial [51][58]. Em uma rede de Petri marcada M = (N, mo), o disparo de uma transição

ti pode alterar a marcação da rede, conforme as regras anteriormente descritas. Uma

marcação mj é diretamente alcançável (ou tk-alcançável) de uma marcação mi sse existir

uma transição tk ∈ Em(mi), tal que

m (p ) (p ,t ) , se p In p ( ) - O u t ω ∈i k k k− t ( t ) ,

∀ ∈(p P ) m (p ) =j m (p ) ( t ,p ) , se p O u t(t ) - In p (t ) , i k k k+ ω ∈m (p ) (p ,t ) ( t ,p ), se p In p (t ) O u t(t ) ,i k k k k− ω + ω ∈ ∩m (p ), q u a lq u er o u tra a ltern a tiv a .i

Além do mais, uma marcação mj é alcançavel de uma marcação mi (mi• mj) sse

existir uma seqüência de marcações (mi0 mi1 ... mik) tal que mi = mi0, mj = mik, e mij é

diretamente alcançável de mij-1 para 1 ≤ j ≤ k.

O conjunto de todas as marcações alcançáveis na rede M = (N, m0) com a

marcação inicial m0 é denotado por M(M). O conjunto de todas as seqüências de

disparos possíveis de mo em uma rede M é denotado por L(M).

3.2.2 Limitação (boundedness)

Uma rede marcada M é k-limitada ou simplesmente limitada (bounded) se

existir um inteiro positivo k, tal que cada marcação no conjunto M(M) atribua no

máximo k fichas para cada lugar da rede

∃ (k > 0) ∀ (m ∈ M(M)) ∀ (p ∈ P) m(p) ≤ k.

Uma conseqüência óbvia desta definição é que uma rede marcada M é limitada

sse seu conjunto de alcançabilidade M(M) é finito. Uma rede de Petri M é dita segura

(safe) se ela for 1-limitada.

___________________________________________________________________

35

Uma marcação mj cobre uma marcação mi (mj • mi) sse mj ≠ mi, mj(p) ≥ mi(p)

para todo p ∈ P, e mj(p) > mi(p) implica que mi(p) > 0. Segue imediatamente a partir

desta definição que se mj • mi, então En(mj) = En (mi). Além do mais, se σ é a

seqüência de transições disparáveis que transformam mi em mj, então σ pode também

ser disparado em mj criando ainda outra marcação mk tal que mk • mj e (usando a

notação de vetor) mk – mj = mj – mi. Então, σ pode ser disparada em mk etc. Concluindo,

se duas marcações mi e mj são alcançáveis a partir da marcação inicial m0 na rede M =

(N, m0) e se mj • mi, então a rede M é ilimitada.

Considerando a rede na Figura 3.4(a) com a marcação m0 = (1, 0, 0, 0) (i.e. uma

ficha em p1 e nenhuma ficha em p2, p3 e p4). O disparo de t2 permite-nos alcançar a

marcação m1 = (0, 0, 1, 1). Disparando t4, m2 = (1, 0, 1, 0) é alcançado. Repetindo η

vezes a seqüência t2t4 a marcação mη = (1, 0, η, 0) é alcançada. Então a marcação de p3

pode ser arbitrariamente alta. Na prática, a capacidade do elemento físico representado

por p3 deve ser finita, então um overflow deveria aparecer. O lugar p3 é dito ilimitado

(unbounded). Atenção deve ser dada à situação acima porque, não-limitação pode ser

uma situação patológica (sistema gerando recursos de forma infinita). Sistema limitado

(i.e. todos os lugares limitados) é uma boa propriedade comportamental.

Figura 3.4: Comportamento patológico qualitativo:(a) Uma rede de Petri não limitada, apresenta deadlock (não-viva), não-reversível; (b) Aumentando a marcação inicial (e.g. m

0 (p5) = 1) a rede que

é viva, entra em deadlock.

___________________________________________________________________

36

3.2.3 Liveness

O conceito de liveness está proximamente relacionado à ausência de deadlocks

em sistemas operacionais. Nesta seção discutiremos o conceito de liveness em função

das possibilidades de disparo de transições.

Deadlock em uma rede de Petri é a impossibilidade do disparo de qualquer

transição da rede. Para analisarmos este conceito observemos a rede de Petri da Figura

3.4(a). Disparando-se a transição t1 a partir da marcação m0 , atinge-se uma marcação

onde nenhuma transição pode ser disparada: um deadlock total foi alcançado. Uma rede

marcada M é dita ser livre de deadlock (deadlock-free) (i.e. para qualquer marcação

alcançável) se ao menos uma transição pode sempre ser disparada. Uma condição

suficiente de ausência de deadlock é vivacidade (liveness). Uma transição t é

potencialmente disparável, dada uma marcação m, se existir uma seqüência de disparos

de transições σ, levando a marcação m’ na qual t é habilitada. Uma transição é live

(viva) se ela for potencialmente disparável em todas as marcações acessíveis. Em outras

palavras, uma transição é live se ela nunca perder a possibilidade de disparo (i.e. de

realizar alguma atividade). Uma rede de Petri M é viva se todas as transições forem

vivas.

Um comportamento paradoxo em sistemas concorrentes é o seguinte: à primeira

vista pode ser intuitivamente aceito que aumentando a marcação inicial (e.g.

aumentando o número de recursos) de uma rede marcada “ajuda” a torná -la viva. Uma

rede viva, visto na Figura 3.4(b) mostra que acrescentando o número de recursos pode

levar a situações de deadlock: adicionando uma ficha a p5, t2 pode ser disparada e um

deadlock é alcançado.

Liveness é uma propriedade fundamental para sistemas encontrados no mundo

real, no entanto muitas vezes é muito “caro” observar esta propriedade em alguns

sistemas de grande porte. Assim sendo, há uma tendência de relaxarmos esta condição e

adotarmos níveis de liveness para as transições e, conseqüentemente, para as redes [50].

Uma transição ti de uma rede M é denominada:

___________________________________________________________________

37

1. morta (dead) ou nível n0, se esta transição nunca for disparada em qualquer

seqüência de L(M), ou seja, se não existir alguma marcação M’ ∈ M(M) tal

que M’ habilita ti;

2. N1 – live, se ti pode ser disparada pelo menos uma vez em alguma seqüência de

L(M);

3. N2 – live, se ti pode ser disparada pelo menos k vezes em alguma seqüência de

disparo de L(M);

4. N3 – live, se ti aparece um número infinito de vezes em alguma seqüência de

paro de L(M);

5. N4 – live ou simplesmente live, se ti é N1 – live para todas as marcações de

M(M) .

Uma rede de Petri M é classificada como Ni – live se todas as transições na rede

são Ni – live. Ressaltamos ainda que se uma rede é N4 – live então esta rede também é

N3 – live que implica ser N2 – live e N1 – live. Obviamente, este princípio não se aplica

para o nível N0.

3.2.4 Reversibilidade (reversibility)

Outra propriedade interessante é a reversibilidade. Uma rede de Petri M = (N,

m0) é reversível se for sempre possível retornar à marcação inicial (i.e. m0 é alcançável

de qualquer outra marcação acessível). A rede mostrada na Figura 3.4(a) não é

reversível. De fato se existir um deadlock total proveniente de alguma marcação

alcançável, a rede não pode ser reversível. A recíproca não é verdadeira, como é visto

na Figura 3.5(g), onde a rede não é reversível, no entanto é viva, então livre de

deadlock.

Vivacidade, limitação e reversibilidade são apenas três diferentes “boas”

propriedades comportamentais independentes entre si que podem ser interessantes em

___________________________________________________________________

38

um sistema dinâmico. Figura 3.5 mostra exemplos de oito possíveis combinações destas

três propriedades.

Figura 3.5: Exemplos de Redes de Petri contendo todas as possíveis combinações de propriedades: B (bounded ), L (live), R (reversible). (a) t1 dead, p1 ilimitado. (b) t1 dead, p1 ilimitado. (c) p2 ilimitado. (d) t1, t2, t3, t4 não vivas. (e) p1 ilimitado. (f) t1 dead. (g) marcação inicial não será mais alcançável. (h) apresenta todas as propriedades desejáveis1.

3.3 Métodos de Análise

Na seção anterior apresentamos algumas propriedades comportamentais

relacionadas às redes de Petri. Dedicamos esta seção aos métodos de análise [50][51]

[58] das redes de Petri. Estes métodos serão utilizados para a análise das propriedades

apresentadas anteriormente. Os métodos de análise das redes de Petri podem ser

classificados dentro dos seguintes três grupos: análise baseada na árvore de cobertura,

1 Fonte obtida em [50]

___________________________________________________________________

39

os métodos baseados na equação fundamental, os métodos baseados na análise da

estrutura e as técnicas de redução [50].

O primeiro método envolve a enumeração das marcações alcançáveis ou

marcações cobertas. Este método sofre do problema da explosão do espaço de estados.

A análise pela avaliação da equação fundamental e das técnicas de reduções são

poderosas, mas em muitos casos são aplicadas somente em subclasses de redes ou

situações especiais.

Nesta seção descreveremos detalhadamente um método baseado na exploração

do espaço de estados que se aplica aos sistemas com um número infinito de estados (o

método da árvore de cobertura [50]), no qual se baseia este trabalho de dissertação.

Dada uma rede de Petri marcada M = (N, m0), a partir da marcação inicial m0,

podemos obter tantas marcações “novas” quanto o número de transições habilitadas.

Para cada marcação nova, podemos novamente chegar a mais marcações. Este processo

resulta em uma árvore de marcações. “Nós” representam marcações geradas a partir de

mo (a raiz) e seus sucessores, e cada arco representa um disparo de transição, o qual

transforma uma marcação em outra.

A árvore da Figura 3.6(b), crescerá infinitamente se a rede for ilimitada. Para

manter a árvore finita, será introduzido um símbolo especial ù , que pode ser pensado

como “infinito”.

A árvore de cobertura de uma rede de Petri marcada M = (N, mo) é construída

seguindo o seguinte algoritmo:

1. rotule a marcação mo como raiz e marque como “novo”;

2. enquanto existirem marcações “novas” , faça o seguinte:

a. selecione uma nova marcação m;

b. se m é idêntica a uma marcação no caminho da raiz até m, então marque m

como “velha” e vá para uma nova marcação;

c. se nenhuma transição estiver habilitada por m, marque como “ dead-end”;

___________________________________________________________________

40

d. enquanto existirem transições habilitadas por m, faça o seguinte para cada

transição habilitada t por m:

I. obtenha a marcação m’ que resulta ao dispararmos a transição t a

partir de m;

II. no caminho da raiz até m, se existir uma marcação m” tal que m’(p) ≥

m”(p) para cada lugar p e m’ ≠ m”, i. e., m’ cobre m”, então

sobrescreva m’(p) com ω para cada p tal que m’(p) > m”(p);

III. introduza m’ como um nó, desenhe um arco com rótulo t de m para

m’ e marque m’ como “novo”.

Como exemplo considere a rede da Figura 3.6(a). Para a marcação inicial mo =

(1, 0, 0), as duas transições t1 e t3 estão habilitadas. Disparando t1 transforma-se mo em

m1 = (0, 0, 1), o qual é um nó dead-end, desde que nenhuma transição está habilitada

por m1. Agora, disparando t3 de mo resulta em m’3 = (1, 1, 0), a qual cobre mo = (1, 0, 0).

Portanto, a nova marcação é m3 = (1, ù , 0), onde duas transições t1 e t3 estão novamente

habilitadas. Disparando t1 atinge-se m4 = (0, ù , 1), a partir do qual t2 pode ser disparada,

resultando no nó “velho” m5 = m4. Disparando t3 de m3 resulta em no nó “velho” m6 =

m3. Assim, temos a árvore de cobertura mostrada na Figura 3.6(b).

Algumas das propriedades que podem ser analisadas usando-se a árvore de

cobertura C são [50]:

I. uma rede M = (N, mo) é limitada, ou seja, o conjunto de todas as possíveis

marcações alcançáveis é finita sse ù não aparece em nenhum nó rotulado em C;

II. uma rede M = (N, mo) é segura sse somente 0’s e 1’s aparece nos nós rotulados

em C;

III. uma transição t é dead sse ela não aparece como um arco rotulado em C.

Para uma rede de Petri limitada, a árvore de cobertura é chamada de árvore de

alcançabilidade, pois ela contém todas as marcações possíveis. Neste caso, todos os

problemas de análise discutidos na Seção 3.2, podem ser resolvidos pela árvore de

alcançabilidade.

___________________________________________________________________

41

O grafo de cobertura, visto na Figura 3.6(c), de uma rede M = (N, mo) é um

grafo direcionado G = (V, E). Seu conjunto de nós V é o conjunto de todos os nós

distintos (rotulados) na árvore de cobertura e o conjunto de arcos E é o conjunto de

arcos rotulados com uma transição tk representando todos os possíveis disparos de cada

transição. Para uma rede de Petri limitada, o grafo de cobertura é referido como grafo

de alcançabilidade, porque o conjunto de vértices V se torna o mesmo do conjunto de

todas as possíveis marcações acessíveis.

(a ) (b ) (c ) Figura 3.6: (a) Uma rede de Petri marcada. (b) A árvore de cobertura da rede. (c) O grafo de cobertura da rede.

3.4 Subclasses de Redes de Petri

Uma rede de Petri M = (N, mo), onde N = (P, T, A, ω), é dita ordinária quando

todos os pesos dos arcos são iguais a 1. Todas as redes consideradas nesta seção são

ordinárias. Note que redes de Petri ordinárias e não-ordinárias têm o mesmo poder de

modelagem. A única diferença é a conveniência da modelagem.

Subclasses de redes são definidas pela introdução de restrições às redes de Petri.

Restringir o modelo pode tornar mais fácil estudar seu comportamento [15]. Esta seção

apresenta um conjunto de restrições estruturais em redes ordinárias que aumentam o

poder de decisão pela restrição do poder de modelagem. Redes Place/Transition podem

ser divididas em diversas classes. Cada classe tem um certo poder de modelagem e suas

próprias propriedades. A Figura 3.7 mostra o poder de modelagem e o inter-

relacionamento das subclasses [14][50][58].

___________________________________________________________________

42

3.4.1 State Machine

State machine (SM) é uma rede de Petri que cada transição t tem exatamente um

lugar de entrada e exatamente um lugar de saída, i.e.,

|Inp(t)| = |Out(t)| = 1 ∀ t ∈ T.

States machines podem representar conflito (um lugar que é entrada de mais de

uma transição), mas, como as transições não podem ter mais que um lugar de entrada

e/ou saída, elas não podem representar sincronização e concorrência.

3.4.2 Marked Graph

Marked graph (MG) é uma rede de Petri que cada lugar p tem exatamente uma

transição de entrada e exatamente uma transição de saída, i.e.,

|Inp(p)| = |Out(p)| = 1 ∀ p ∈ P.

Marked graphs podem representar sincronização e concorrência, mas, como os

lugares não podem ter mais que uma transição de entrada e/ou saída, eles não podem

modelar conflito [9][50][52]. Marked graphs têm sido profundamente estudado porque

modelam um grande número de sistemas práticos e pela simplicidade de análise de

propriedades.

3.4.3 Redes Free-Choice

Free-choice (FC) é uma rede de Petri que cada arco proveniente de um lugar é

um único arco de saída ou é um único arco de entrada para uma transição, i.e.,

∀ p ∈ P, |Out(p)| ≤ 1 ou Inp(Out(p)) = {p}; equivalentemente,

∀ p1, p2 ∈ P, Out(p1) ∩ Out(p2) ≠ ∅ ⇒ |Out(p1)| = |Out(p2)| = 1.

Esta classe permite a modelagem de concorrência, sincronização e conflitos. Em

redes free-choice, existe um único lugar de entrada para as transições em conflito,

___________________________________________________________________

43

conseqüentemente o conflito é controlado [29] pela escolha livre de qual transição

disparar.

3.4.4 Redes Extended Free-Choice

Extended free-choice (EFC) é uma rede tal que

Out(p1) ∩ Out(p2) ≠ ∅ ⇒ Out(p1) = Out(p2) ∀ p1, p2 ∈ P.

Esta definição estende a definição prévia de redes extended free-choice, é

evidente que cada rede free-choice é também uma extended free-choice.

3.4.5 Redes Asymmetric Choice

Redes asymmetric choice (AC) – também conhecida como redes simples – é

uma rede de Petri que

Out(p1) ∩ Out(p2) ≠ ∅ ⇒ Out(p1) ⊆ Out(p2) ou Out(p1) ⊇ Out(p2) ∀ p1, p2 ∈ P.

As estruturas de redes de Petri mostrada na Figura 3.7 são as estruturas chaves

que caracteriza estas subclasses. É fácil reconhecer as principais estruturas de SMs e

MGs mostrada na Figura 3.7(a) e (b) respectivamente. FCs são generalizações das

estruturas comuns a ambas SMs e MGs. Elas permitem a estrutura de conflito de SM e a

estrutura de sincronização de MG, mas exclui a estrutura mostrada na Figura 3.7(c),

onde Out(p1) = Out(p2) = {t1, t2}. Extend free-choice (EFCs) permite a estrutura

mostrada na Figura 3.7(c), mas não aquela mostrada na Figura 3.7(d), onde Out(p1) =

{t1} ⊆ Out(p2) = { t1, t2}. Redes assymetric choice (AC) permite a estrutura mostrada

na Figura 3.7(d), mas não a estrutura mostrada na Figura 3.7(e), onde Out(p1) = {t1, t2}

e Out(p2) = {t2, t3}.

Em suma, SMs não admite sincronização, MGs não admite conflitos, FCs não

admite confusão, e ACs permite confusão assimétrica (Figura 3.7 (b)) mas não permite

confusão simétrica (Figura 3.7 (a)). Suas relações no diagrama de Venn é mostrado na

Figura 3.7 (f).

___________________________________________________________________

44

Figura 3.7: Estruturas principais caracterizando redes de Petri e seu diagrama Venn2.

3.5 Redes de Petri Temporizadas

Diversos conceitos de redes de Petri temporizadas têm sido propostos atribuindo

tempo às transições ou aos lugares da rede. Nesta seção definiremos o modelo de

Zuberek (Timed Petri Net) onde tempo (duration) é atribuído às transições. A seguir

veremos brevemente outros modelos de rede: Place Timed Petri Nets (com tempo

atribuído aos lugares) e Time Petri Net (intervalo de tempo associado às transições).

3.5.1 Modelo de Zuberek

Seguindo o modelo de Zuberek [72], vamos estender a rede de Petri N como

sendo uma quíntupla N= (P, T, A, ω, B) onde:

P, T, A e ω foram definidos na secção 3.1,

B é um conjunto (possivelmente vazio) de arcos inibidores, B ⊆ P × T , e A e B

são conjunto disjuntos.

Usualmente Inh(t) denota o multi conjuntos dos lugares inibidores de t. Um arco

inibidor conecta um lugar a uma transição e é representado por uma linha tracejada

terminando com um pequeno círculo (ao invés de uma ponta de flecha) na transição. O 2 Fonte obtida em [50].

___________________________________________________________________

45

arco inibidor desabilita a transição quando no lugar de entrada tem uma ficha e habilita

a transição quando no lugar de entrada não tem ficha e a marcação do outro lugar de

entrada habilita a transição.

A relação de “lugar compartilhado free-choice” é de fato uma relação de

equivalência no conjunto de transições T, portanto ele determina uma partição de T

dentro do conjunto de classes equivalentes free-choice denotado por Free(T) = {T1, T2,

..., Tk}.

Uma função de seleção de uma marcação m em uma rede de Petri N é uma

função g: T→ {0, 1, ...} tal que:

• existe uma seqüência de marcações intermediárias (mi1, mi2 ... mik) e uma

correspondente seqüência de transições σ=(ti1, ti2 ... tik) tal que m = mi0, e tij

∈ En (mij-1) para todo 1 ≤ j ≤ k, onde

• o conjunto de transições habilitadas por mik é vazio, e

• para todo t ∈ T, g(t) é igual ao número de ocorrências de t na seqüência σ.

O conjunto de todas as funções de seleção da marcação m é denominado por Sel(m).

Em redes de Petri temporizadas, cada transição t leva um tempo positivo para

disparar. Quando a transição t está habilitada, um disparado pode ser iniciado pela

remoção das fichas dos lugares de entrada de t. Durante o tempo de disparo, as fichas

permanecem “dentro” da transição t, e então os disparos terminam pela adição de fichas

em cada lugar de saída de t. Se uma transição é habilitada enquanto ela dispara, um

novo, disparo independente pode ser iniciado.

Em redes temporizadas, cada disparo é iniciado no mesmo instante de tempo no

qual ela está habilitada, embora alguma transição habilitada não dispare (como, por

exemplo, as transições em classes equivalentes free-choice).

___________________________________________________________________

46

Semântica de passos (step semantics) [66] é uma estratégia de disparo que leva

em consideração o disparo de um conjunto máximo de transições paralelas habilitadas.

Desta forma, o conjunto de alcançabilidade é reduzido.

Em redes de Petri temporizadas [70] o tempo de disparo das transições são

determinísticos (ou constantes), isto é, existe um número não-negativo atribuído a cada

transição da rede que determina a duração dos disparos das transições. Dado que a

ausência de memória (memoryless) não se aplica para tais redes, a descrição do estado

deve explicitamente incluir a “história” dos disparos.

Uma rede de Petri temporizada ΓΓ é uma tupla ΓΓ = (M, c, f) onde:

M é uma rede de Petri free-choice marcada, M = (N, m0), N = (P, T, A, ω, B),

c é uma função de escolha que atribui uma probabilidade “ free-choice” a cada

transição da rede de tal maneira que

f é uma função de tempo de disparo que atribui um valor real não negativo f(t)

para cada transição t da rede (f: T → R⊕ , onde R⊕ denota o conjunto dos números reais

não negativos).

O estado de uma rede de Petri temporizada é definido por uma tupla de funções:

uma delas descreve a distribuição de fichas nos lugares; a segunda, a distribuição de

fichas nas transições (disparadas) – indicando o número de vezes que a transição é

disparada em um passo; e a terceira é a função de “tempo de disparo remanescente” a

qual provê uma “história” das transições disparadas.

O estado s de uma Rede de Petri temporizada ΓΓ é uma tupla s = (m, n, r) onde:

m é uma função de marcação, m : P → {0, 1, ...},

n é uma função de grau de disparo, n : T → {0, 1, ...},

r é uma função de tempo de disparo remanescente que atribui o tempo de

disparo restante para cada disparo independente (se algum) de uma transição. Se o grau

de disparo de uma transição t for igual a k, n(t) = k, a função de tempo de disparo

___________________________________________________________________

47

restante r(t) é um vetor de índice k denominado por r(t)[1], r(t)[2], ..., r(t)[k]; r é uma

função parcial e é não-definida para aquelas transições t que n(t) = 0.

Um estado inicial si de uma rede ΓΓ é uma tupla si = (mi, ni, ri) onde ni é a função

de seleção do conjunto Sel(m0), ni ∈ Sel(m0). A função de tempo de disparo

remanescente, ri, é igual ao tempo de disparo f(t) para todas aquelas transições t nas

quais ni > 0

e a marcação mi é definida como

Uma rede de Petri free-choice pode ter diferentes estados iniciais (a depender da

probabilidade de distribuição das fichas entre as transições free-choice)

Um estado sj = (mj, nj, rj) é diretamente alcançável (ou gk- alcançável) do estado

si = (mi, ni, ri), sse as seguintes condições são satisfeitas:

onde

O Estado sj o qual é gk-alcançável de si é então obtido pela terminação dos

“próximos” disparos – isto é, aqueles disparos nos quais o tempo de disparo

remanescente é o menor deles; este tempo é denominado por hi e é chamado do tempo

___________________________________________________________________

48

de armazenamento ou tempo de residência curta do estado si – (6,7), atualizando a

marcação da rede (5), e então iniciando novos disparos (se possível) o qual corresponde

à função de seleção gk do conjunto Sel(m’ i) (1, 2, 3 e 4).

Um estado sj é (geralmente) alcançável de um estado si se existir uma seqüência

de estados diretamente alcançáveis do estado si para o estado sj. Também, um conjunto

S(ΓΓ) de estados acessíveis é definido como o conjunto de todos os estados de uma rede

ΓΓ os quais são alcançáveis dos estados iniciais da rede ΓΓ.

Um grafo de estado G de uma rede de Petri free-choice temporizada limitada ΓΓé

um grafo direcionado rotulado G(ΓΓ) = (V, D, h, q) onde:

V é um conjunto de vértices os quais é igual ao conjunto de estados alcançáveis

da rede ΓΓ, V = S(ΓΓ),

D é o conjunto de arcos direcionados, D ⊂ V × V, tal que (si, sj) está em D sse sj

é diretamente alcançável a partir de si,

h é uma função rotuladora de vértices que associa o tempo de armazenamento

do estado si = (mi, ni, ri) para cada si ∈ S(T), h :V→ R⊕ ,

q é uma função rotuladora de arcos que atribui a probabilidade das transições do

estado si para sj a cada arco (si, sj) no conjunto D.

Figura 3.8: Rede de Petri temporizada ΓΓ1

Para fixarmos os conceitos definidos nesta seção, tomaremos como base a rede

temporizada Γ1 (Figura 3.8) onde a função f (função de tempo de disparo) atribui os

seguintes valores às transições: f(t1) = 10, f(t2) = 5, f(t3) = 1, f(t4) = 2. A atribuição dos

___________________________________________________________________

49

valores pela função de escolha c é a seguinte: c(t1) = 0.6, c(t2) = 0.4. A derivação do

conjunto S(ΓΓ1) é dada na Tabela 3.1.

A seguir descrevemos o conjunto de estados alcançáveis para a rede da Figura

3.8 de acordo com a Tabela 3.1. Inicialmente a marcação inicial m0 é dada por 5p1 (lugar

5 com cinco fichas). Esta marcação habilita as transições t1 e t2, estas são disparadas em

paralelo, estratégia conhecida como semântica de passos. O estado s1 = (m1, n1, r1) é o

estado inicial (si) e é definido a seguir. A função do grau de disparo n1 é dada por n1(t1)

= 3 e n1(t2) = 2 (assumimos que a transição t1 foi disparada três vezes e t2 duas vezes,

poderíamos ter outra distribuição das fichas, i.e, estados iniciais distintos). Pela

marcação m1 não temos fichas nos lugares (todas as fichas em p1 foram consumidas de

acordo com a regra definida para mi vista anteriormente); A função de tempo de disparo

remanescente para o estado s1 é definido por: r1(t1)[1] = 10, r1(t1)[2] = 10, r1(t1)[3] = 10,

r1(t2)[1] = 5, r1(t2)[2] = 5 (no estado inicial a duração da transição é definida por f(t)).

Tabela 3.1: O conjunto de estados alcançáveis em ΓΓ1.

m i n i m'i g k

1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4

t 1 [1] = 10; t 1 [2] = 10; t 1 [3] = 10; t 2 [1] = 5; t 2 [2] = 5;

t 1 [1] = 5; t 1 [2] = 5; t 1 [3] = 5; 1 0 0 0 3 0.60t 4 [1] = 2; 0 1 0 0 4 0.40

t 1 [1] = 3; t 1 [2] = 3; t 1 [3] = 3; t 1 [4] = 10;

t 1 [1] = 3; t 1 [2] = 3; t 1 [3] = 3; t 2 [1] = 5;

5 0 0 0 0 1 0 3 0 t 1 [1] = 7; t 3 [1] = 1; 1 0 0 0 1 0 0 0 0 66 0 0 0 1 1 0 0 0 t 1 [1] = 6; 6 0 1 0 1 0 0 0 0 77 0 1 0 1 0 0 0 0 não definido, n i (t i ) = 08 0 0 0 0 0 1 1 0 t 2 [1] = 2; t 3 [1] = 1; 1 0 0 0 1 0 0 0 0 99 0 0 0 1 0 1 0 0 t 2 [1] = 1; 1 0 0 1 1 0 0 0 0 10

10 0 0 1 1 0 0 0 0 não definido, n i (t i ) = 0

g k = Ø

0 0 1 0 5

4 0 0 0 0 3 0 0 1 3 0 3 0 0 0 0 1 0 8

3 0 0 0 0 4 0 0 0 3

2 0 0 0 0 3 0 0 1 2

r i

3 2 0 0 0 0 0 1

s i h(s i )

5 0 0 2 01 0 0 0 0

deadlock

deadlock

q (s i , s j )

1.00

1.00

1.00

s j

2

1 0 0 0

0 3 0 0

Agora definiremos os próximos estados da rede. Vimos que o estado sj = (mj, nj,

rj) é diretamente alcançável (ou gk- alcançável) do estado si = (mi, ni, ri) se as

condições (1), (2), (3), (4), (5) e (6) forem atendidas. De acordo com a condição (7) hi é

definido como o tempo mínimo entre os tempos de disparos remanescentes das

transições t1 e t2, que neste caso é igual a 5. Pela condição (6) di(t2) = 2 (t2 apresenta

___________________________________________________________________

50

dois elementos do vetor com tempo de disparo remanescente iguais a hi) e di(t1) = 0 (os

elementos do vetor de t1 apresentam tempo de disparo remanescente superiores a hi).

Assim a transição t2 finaliza o disparo e o estado intermediário m’ 1 igual a 2p3 é

alcançado (5). Por (1) a transição t4 (gk(t4)=1) é disparada uma vez alcançando o estado

s2 = (m2, n2, r2). A função do grau de disparo (ni) é dada por (3), sendo que n2(t1)

continua igual a 3 (esta transição ainda não conclui nenhum de seus disparos nem foram

gerados novos disparos para esta transição), n2(t2) = 0 (transição concluiu todos os seus

disparos) e n2(t4) = 1 (foi gerado um novo disparo). A marcação m2 é igual a 0 para

todos os lugares, condição (2); A função de tempo de disparo remanescente é definido

por (4): r2(t1)[1] = 5, r2(t1)[2] = 5, r2(t1)[3] = 5 (aqui decrementamos h(s1) em r1) e

r2(t4)[1] = 2 (como é um novo disparo é igual a f(t)). Agora definimos novamente o

valor para hi, e assim sucessivamente.

3.5.2 Outros Modelos

Em uma rede PTPN (Place Timed Petri Nets) [38] uma ficha pode estar

disponível ou indisponível. Na marcação inicial todos as fichas estão na condição

disponível. Uma transição t estará habilitada para ser disparada, se e somente se, cada

lugar de entrada da mesma contiver fichas suficientes e disponíveis considerando o peso

dos arcos. A transição dispara tão logo ela esteja habilitada. O disparo consiste na

remoção das fichas dos lugares de entrada da transição e na colocação de um número de

fichas nos lugares de saída de acordo com o peso dos arcos. Após o disparo, uma ficha

permanece indisponível no lugar durante um intervalo de tempo, logo após este

intervalo ela se torna disponível.

Time Petri Nets [38] são extensões de redes de Petri nas quais a informação de

tempo é expressa por intervalos (dmin, dmax) e é associado às transições. Uma transição tj

é disparável no tempo x, se e somente se, ela estiver continuamente habilitada durante o

intervalo (x, dmin) em x. Uma transição disparável pode disparar a qualquer tempo entre

dmin ≤ x ≤ dmax. Uma transição disparável deve disparar no tempo x se ela estiver

continuamente habilitada durante o intervalo (x, dmax) em x.

___________________________________________________________________

51

3.6 Conclusões

Redes de Petri são uma família de técnicas de especificação formal bem

estabelecida, largamente difundida e adequada à modelagem de sistemas contendo

atividades concorrentes. RdPs fornecem uma representação matemática do sistema

modelado, permitindo que sejam realizadas verificações e análises de suas propriedades.

Além disso, uma notação gráfica permite a visualização dos componentes do modelo,

contribuindo para o entendimento do mesmo.

Neste capítulo apresentamos uma introdução a redes de Petri com o objetivo de

facilitar o entendimento dos modelos utilizados para a realização de estimativas de área

de hardware. Mostramos algumas das principais propriedades que um bom modelo

baseado neste formalismo deve apresentar como: alcançabilidade, limitação, liveness e

reversibilidade. Em seguida expomos os métodos de análise e algumas subclasses de

redes de Petri e finalmente discutimos as redes de Petri temporizadas, onde foi

formalizado o modelo de Zuberek (Timed Petri Nets), mais adequado (modela

naturalmente) à metodologia da estimativa de área quando comparados com outros

modelos temporizados (Time Petri Nets e Place Timed Petri Nets).

4 Modelo Intermediário

Neste capítulo faz-se uma apresentação dos modelos intermediários: modelo de fluxo de dados e modelo de fluxo de controle. Ambos os modelos são apoiados em redes de Petri (RdP) temporizadas. Aqui é feita uma apresentação da linguagem de programação occam, seguida de uma descrição breve do modelo de fluxo de controle, o qual representa a ordem real das ações de uma especificação. Finalmente é feita uma descrição detalhada do modelo de fluxo de dados, o qual permite a análise de dependência de dados entre processos paralelos, seguida do método de tradução de uma especificação em occam para o mesmo.

4.1 Introdução

Dois modelos distintos em Redes de Petri foram desenvolvidos para representar

o comportamento de uma aplicação a ser modelada: os modelos de fluxo de controle e

dados. O modelo de fluxo de controle permite uma representação do fluxo de controle

de uma especificação, isto é, a representação de uma combinação de processos

paralelos, seqüências, condicionais e repetitivos. O modelo de fluxo de dados foi

desenvolvido com o objetivo de capturar dependência de dados desta especificação.

Estes modelos podem ser usados independentemente ou de forma conjunta para

a computação de métricas como: tempo de execução, dependência de dados, estimativa

de recursos, etc. Além disso, eles podem ser utilizados para a realização de simulações.

Ambos os modelos foram originalmente concebidos para traduzir uma entrada

especificada em occam, mas outras linguagens, como C/C++, também podem ser

consideradas. Estes modelos possibilitam a computação de métricas e propriedades

qualitativas com o uso cooperativo de ferramentas de análise estrutural e

comportamental de redes de Petri.

___________________________________________________________________

53

4.2 Linguagem de Programação Occam

A linguagem de programação occam [32] é derivada de CSP [31], projetada para

expressar algoritmos concorrentes, possibilitando a descrição de aplicações através de

coleções de processos. Cada processo de uma aplicação descreve o comportamento de

um aspecto particular da implementação. Como esta linguagem foi concebida de CSP,

uma técnica de descrição algébrica, ela tem uma semântica precisa e bem definida e

permite transformações de programas.

O conjunto de occam (processos primitivos e combinadores) considerado neste

trabalho é descrito em formato BNF:

P:: = SKIP — STOP — x:=e

— ch?x — ch!e

— IF(c1p1, ...,cnpn) | ALT(g1p1, ...,gnpn)

— SEQ(p1, ..., pn) | PAR(p1, ..., pn)

— WHILE(cP)

VAR x:P — CHAN ch:P

BOX (p1, ..., pn) | CON(p1, ..., pn)

Os processos mais simples de occam são: a atribuição, a ação de entrada

(input), a ação de saída (output), processos SKIP e STOP. SKIP, STOP e x:=e

representam um nop (no operation), deadlock e uma atribuição, respectivamente. ch?x e

ch!e descrevem ações de comunicação de entrada e saída. IF(c1p1, ...,cnpn) e ALT(g1p1,

...,gnpn) são combinadores condicionais determinísticos e não-determinísticos. SEQ(p1,

..., pn) e PAR(p1, ..., pn) representam combinadores seqüenciais e paralelos,

respectivamente. WHILE(cP) repesenta uma iteração (while loop). VAR x:P e CHAN

ch:P são declarações de variáveis e canais. Este subconjunto de occam foi estendido

para considerar dois novos construtores: BOX e CON [38], os quais não têm nenhum

semântico, são apenas anotações úteis para as fases de classificação e clustering do

sistema PISH[4] de hardware/software co-design, desenvolvido pelo grupo de

___________________________________________________________________

54

engenharia de computação da UFPE. Um processo dentro de um construtor BOX não é

dividido e seu custo é analisado como um todo. O construtor CON é uma anotação para

processos de controle.

Occam obedece um conjunto de leis algébricas[32] as quais definem a sua

semântica. Por exemplo, as leis PAR(p1, p2)= PAR(p2, p1) e SEQ(p1, p2, ..., pn) =

SEQ(p1 SEQ( p2, ..., pn)) definem a simetria do combinador PAR e a associatividade do

combinador SEQ, respectivamente. A Figura 4.1 mostra um exemplo de uma

especificação em occam.

4.3 Modelo de Fluxo de Controle

Esta seção apresenta o modelo em redes de Petri desenvolvido para representar

o fluxo de controle de uma especificação em occam. Este modelo foi proposto em [38] e

sua descrição detalhada pode ser encontrada neste trabalho.

CHAN OF INT ch1, ch2:PAR INT x, y, z: SEQ x := 0 Z := 0 WHILE x < 10 SEQ ch1 ! x ch2 ? y x := x + 1 z := y + 2 INT x, y: SEQ x := 0 WHILE x < 10 SEQ ch1 ? x IF x > 0 y := x + 1 TRUE y := 0 ch2 ! y

Figura 4.1: Exemplo de especificação em occam

___________________________________________________________________

55

Aqui daremos uma visão sintética deste modelo, já que o foco principal deste

trabalho está baseado no modelo de fluxo de dados. Informações detalhadas sobre o

modelo e suas métricas podem ser encontradas em [39][40][41][42][43][44].

Este modelo utiliza uma RdP temporizada [72] para representar uma

especificação em occam. Transições representam ações da especificação original.

Lugares são usados para conectar ações na ordem em que elas foram originalmente

descritas. Construtores condicionais têm uma função de probabilidade associada a cada

execução do desvio.

x 0:=

x x+1:= y x+ 1:= y 0:=

z y+2:=

y 0:=

(x<10)

(x<10)

(x<10)

ch1 !x

ch2?y

ch1?x

d loop

d loop

epar

d ifd if

ch2!y

x 0:=

Figura 4.2: Modelo do fluxo de controle para a especificação da Figura 4.1

Nesta classe de rede, uma duração é associada a cada transição. O consumo das

marcas (fichas) dos lugares de entrada da transição ocorre instantaneamente, assim que

todas as pré-condições são atendidas. Em seguida, o disparo da transição ocorre e, ao

___________________________________________________________________

56

final do tempo preconizado, são geradas as pós-condições. A associação entre os

componentes da linguagem e os componentes da rede é mostrada a seguir:

Lugares: Os lugares são responsáveis pela conexão entre as ações, representadas

nas transições, fixando a ordem da execução das mesmas. O modelo prevê conflitos e

fusões, ou seja, um lugar pode pertencer ao conjunto de pré-condições ou pós-condições

de mais de uma transição ao mesmo tempo. Desta forma, permite-se modelar o

comportamento da escolha determinística (IF), não determinística (ALT) e do laço

(WHILE).

Transições: A cada transição são associadas informações sobre o número e o

tipo das operações realizadas, variáveis e constantes utilizadas, duração da operação e

prioridade.

A Figura 4.2 apresenta o modelo de fluxo de controle (modelo intermediário em

redes de Petri) a partir da tradução de uma especificação em occam (Figura 4.1).

4.4 Modelo de Fluxo de Dados

Esta seção apresenta o modelo intermediário em redes de Petri [47]

desenvolvido para representar o fluxo de dados de um sistema, com a finalidade de

capturar dependências de dados [44][48]. Este modelo representa as várias seqüências

de operações que produzem, modificam ou consomem dados. A tradução é realizada de

maneira a refletir o maior grau de paralelismo interno possível aos processos, já que a

ordem real das operações está representada no modelo de fluxo de controle.

É importante deixar claro que o modelo permite a representação do fluxo de

dados de processos de maneira independente da linguagem de especificação original. A

linguagem occam é sempre citada nos exemplos apenas pelo fato de a mesma ser

utilizada dentro do contexto do sistema PISH [4]. Este modelo permite uma integração

com o modelo de fluxo de controle, trazendo a possibilidade de análise conjunta do

sistema, simulação, assim como uma melhoria nos resultados das estimativas.

___________________________________________________________________

57

Além disso, RdPs são uma técnica de especificação formal bem estabelecida,

com diversas ferramentas de análise disponíveis. Um modelo apoiado nesta técnica

possibilita outros tipos de análise, além da dependência de dados, como tempo de

execução, custo de comunicação, balanceamento de carga, exclusão mútua etc. Este

trabalho de dissertação foi baseado neste modelo para o desenvolvimento de técnicas de

estimativas do número de registradores, unidades funcionais e multiplexadores.

4.4.1 Componentes da Rede

Do ponto de vista estrutural, o modelo faz um mapeamento entre os objetos da

descrição e os componentes de uma RdP.

Lugares: Cada lugar da rede representa um valor, seja ele uma constante, uma

variável ou resultado de uma expressão. Nos casos dos literais, cada vez que um deles

ocorre numa descrição, um lugar é acrescentado à rede para representá-lo. Em relação

às variáveis, é adotada uma estratégia de renomeamento. Sempre que ocorre uma

atribuição a uma variável, é criado um lugar para representar o seu novo valor. Todas as

referências futuras (para leitura) a essa variável são realizadas sobre esse novo lugar.

Finalmente, o valor retornado por uma expressão também é expresso por um lugar.

Transições: As transições podem modelar dois grupos distintos de objetos. O

primeiro grupo é composto por expressões (aritméticas, lógicas, relacionais, binárias e

booleanas). O segundo grupo é formado por operadores e construtores presentes na

linguagem de especificação occam. São considerados os operadores de atribuição e

comunicação, além dos construtores SEQ, PAR, IF, ALT e WHILE.

Arcos: O sentido do fluxo dos dados através da rede é dado pelos arcos. Eles

representam tanto a utilização (de um lugar para uma transição) como a geração (de

uma transição para um lugar) de novos valores pelas operações representada nas

transições do modelo.

Fichas: As fichas modelam a presença de um valor em um dado momento. Se

um lugar tem uma ficha, significa que o valor representado por aquele lugar está

___________________________________________________________________

58

disponível para ser utilizado pela operação que o segue. Quando é disparada, a transição

consome aquela ficha e o efeito semântico é da indisponibilidade do valor.

Deve-se frisar que, apesar de modelar a existência e a presença de valores, o par

lugar/ficha não se prende a valores específicos. Ele se refere apenas ao fato de que um

valor qualquer associado àquele lugar está disponível para ser utilizado no sistema.

Além de representar valores, os lugares ainda têm uma outra função dentro do

modelo. Existem lugares que fazem parte dos modelos dos construtores, como os

lugares que marcam o início e o fim de um processo, por exemplo:

Lugar inicial: O lugar inicial sempre precede uma transição de início de

processo. A função deste lugar é alimentar todos os demais lugares que representam

literais e variáveis recém-declaradas, que têm um valor inicial determinado. A presença

de uma ficha nesse lugar habilita o funcionamento do processo.

Lugar final: O lugar final sucede uma transição de fim de processo. Durante a

execução de um processo, todos os valores gerados no processo vão sendo transportados

através da rede, até chegarem a um ponto onde não serão mais necessários. A transição

de fim consome todas as fichas desses lugares e gera uma ficha no lugar final. A

presença de uma ficha nesse lugar indica que o processo foi executado completamente.

4.4.2 Método de Tradução

Esta seção descreve o processo de tradução do fluxo de dados de uma

especificação em occam para o modelo de redes de Petri. Para cada tipo de construção

diferente, é exibida uma definição informal das convenções adotadas no processo de

tradução. Adiante é exibido o resultado completo da tradução de uma especificação.

Antes, porém, torna-se necessário introduzir os conceitos que foram adotados na

caracterização do tipo de rede adotado no modelo. Foram feitas restrições em algumas

das construções do formalismo, simplificando o modelo de fluxo de dados. Conforme já

foi visto no Capítulo 3, Seção 3.4, quanto mais restrito for o modelo de RdP adotado,

mais simples são os resultados das análises.

___________________________________________________________________

59

O primeiro destes conceitos é o de rede livre de conflitos9. Uma rede é dita livre

de conflitos se não existir nenhum lugar que seja pré-condição de mais de uma

transição:

Definição 4.1 – Rede livre de conflitos: Seja N = (P, T, I, O) uma RdP. N é

uma rede livre de conflitos sse (I(ti) ∩ I(tj)) = {}, ∀ ti, tj ∈ T, ti ≠ tj, denotado CF(N).

Uma rede é dita livre de fusões10 se não existe nenhum lugar que seja pós-

condição de mais de uma transição:

Definição 4.2 – Rede livre de fusões: Seja N = (P, T, I, O) uma RdP. N é uma

rede livre de fusões sse (O(ti) ∩ O(tj)) = {}, ∀ ti, tj ∈ T, ti ≠ tj, denotado MF(N).

Em seguida, temos a definição da rede livre de laços11. Entretanto, antes da

caracterização de uma rede livre de laços, torna-se necessário definir uma relação de

precedência entre transições:

Definição 4.3 – Relação de precedência: Seja N = (P, T, I, O) uma RdP, e

uma relação • ⊆ T × T. Sejam ainda ti, tj ∈ T. • é definida como uma relação de

precedência sobre N da seguinte forma: ti • tj ⇔ (O(ti) ∩ I(tj)) ≠{} ∨ ∃ tk ∈ T | ti • tk

∧ tk • tj.

Definição 4.4 – Rede livre de laços: Seja N = (P, T, I, O) uma RdP. N é uma

rede livre de laços sse t • t, ∀ t ∈ T, denotado LF(N).

A seguir define-se o modelo adotado. A rede do fluxo de dados é uma rede

limitada, livre de conflitos, fusões e laços.

Definição 4.5 – RdP de fluxo de dados: Uma RdP do modelo de fluxo de

dados (RdPd) é uma rede N = (P, T, I, O), onde temos CF(N), MF(N) e LF(N).

Um outro conceito utilizado no contexto do modelo do fluxo de dados é o de

sub-rede.

9 Conflict-free 10 Merging-free 11 Loop-free

___________________________________________________________________

60

Definição 4.6 – Sub-rede: Sejam N = (P, T, I, O) e N’ = (P’, T’, I’, O’ ) RdPs.

N é dita uma sub-rede de N ‘ sse P ⊆ P’, T ⊆ T’, I ⊆ I’, O ⊆ O’, onde N ⊆ N’.

O código occam mostrado na Figura 4.1 é utilizado como exemplo único para a

definição de todos os construtores. Para cada construtor apresentado, uma parte do

código é traduzida para seu equivalente no modelo do fluxo de dados.

Neste exemplo, existem dois processos que se comunicam através de canais. A

finalidade principal não é mostrar a análise da dependência de dados em si, mas o

método de tradução, uma vez que o exemplo contém praticamente todos os construtores

suportados pelo modelo (a menos do combinador ALT). Além disso, ele não contém

variáveis do tipo vetor, nem processos replicados que poderiam sobrecarregar

visualmente o modelo.

As regras de tradução serão apresentadas a seguir, levando em consideração

uma descrição em occam de um processo Pi. Todos os lugares da rede do processo têm

um prefixo pi conectado ao seu nome. Da mesma forma, todas as transições têm um

prefixo ti.

O processo de tradução gera uma rede de Petri limitada marked graph (ver

Capítulo 3). Assim, o número de arcos de entrada de cada lugar é igual ao numero de

arcos de saída daquele lugar, que é igual a um, ou seja, #I(p) = #O(p) = 1, para cada

lugar p, contudo os lugares start e end de cada processo têm #I(p) = #O(p) = 0,

respectivamente.

4.4.2.1 Processo

Todos os combinadores de occam (SEQ, PAR, IF, ALT, WHILE) são

representados no modelo do fluxo de dados com a denominação de processo. Embora

cada um dos combinadores seja tratado separadamente na tradução, todos eles têm um

formato básico, ao qual são acrescentados outros componentes.

No processo de tradução, sempre que um combinador é encontrado, são

acrescentados dois pares de lugares/transições à rede: o par inicial (pi.start e ti.start) e o

par final (ti.end e pi.end). Em seguida, é realizada recursivamente uma tradução de todos

os processos dentro do combinador. Por fim, todos os lugares iniciais e finais dos seus

___________________________________________________________________

61

processos internos são conectados às transições de início e fim, respectivamente. A

denominação de processo-pai e processo-filho é aplicada no contexto desse

aninhamento de combinadores.

Um lugar especial pi.dummy é também acrescentado ao processo. Este lugar é

inserido entre as transições ti.start e ti.end. Esta operação tem por finalidade garantir que

as transições inicial e final do processo fiquem conectadas por pelo menos um caminho.

A Figura 4.3 mostra a tradução de um combinador seqüencial (SEQ) em uma

RdP equivalente no modelo de fluxo de dados.

...INT ...:SEQ ...

p .sta rti

p .endi

p .du m m yi

t .sta rti

t .e ndi

Figura 4.3: Tradução de um processo

4.4.2.2 Literais

Literais em occam são valores expressos diretamente na especificação. Durante

a tradução, sempre que um literal l é encontrado na especificação, um novo lugar

pi.val[l] é conectado à transição ti.start do processo.

Na Figura 4.4, é exibida a tradução de duas ocorrências do literal 0 (zero) dentro

da especificação. Um lugar pi.val[0] é acrescentado para cada ocorrência como saída da

transição ti.start.

...INT ...:SEQ x := 0 y := 0 ...

p .sta rti

p .va l[0 ]i p .va l[0 ]i

t .sta rti

Figura 4.4: Tradução de literais

4.4.2.3 Variáveis

A estratégia escolhida para modelar as variáveis baseia-se no renomeamento.

Cada novo valor atribuído a uma variável gera-se uma nova instância da mesma

___________________________________________________________________

62

(representada por um novo lugar na rede). Todas as referências feitas à variável são

executadas sobre a nova instância.

Na declaração de uma variável v, um lugar de nome pi.v.0 é acrescentado para

representar sua primeira instância. As instâncias subseqüentes são nomeadas com pi.v.1,

pi.v.2, sucessivamente. Num último passo, ao final da tradução do processo, a última

instância de uma variável é conectada à transição ti.end do processo. A Figura 4.5

mostra a declaração de três variáveis inteiras (x, y e z). Após o término do processo, os

valores de suas instâncias são consumidos pela transição ti.end.

...INT x,y,z:SEQ ...

p .sta rti

p .en di

p .x.0i

p .z.ti

p .z.0i

p .x.ri

p .y.0i

p .y.si

t .s ta rti

t .e n di

Figura 4.5: Declaração de variáveis

A leitura da instância n de uma variável v compreende a duplicação de seu valor

dentro do modelo. Uma transição ti.clone é acrescentada após o lugar pi.v.n. Seguindo

essa transição são acrescentados dois lugares pi.v.n+1 e pi.v.n+2. O lugar pi.v.n+1 é

conectado à transição da operação que utiliza a variável (v). O lugar pi.v.n+2 é deixado

livre para que possa ser usado posteriormente por outra operação, por uma atribuição ou

simplesmente pela transição de fim-de-processo (ti.end).

Na Figura 4.6 é exibida a parte da rede que modela a leitura da instância n da

variável x. Uma transição duplica o valor de x (ti.clone) e o distribui aos lugares

pi.x.n+1 e pi.x.n+2. A transição t.op representa a operação de adição em x+1,

consumindo o valor representado por pi.x.n+1. O lugar pi.x.n+2 permanece disponível

para uma nova operação de leitura, atribuição ou mesmo fim de processo.

___________________________________________________________________

63

...x := x + 1...

p .x.ni

p .x.n + 2i p .x.n + 1i

t .c lo n ei

t .o pi Figura 4.6: Leitura de variável

Uma escrita na instância n de uma variável v compreende a criação de uma nova

instância e no descarte da anterior. Porém, a eliminação do valor anterior é realizado de

duas maneiras diferentes, dependendo do escopo da escrita.

Caso a escrita seja feita fora de um combinador de execução condicional (IF,

ALT e WHILE), o valor anterior da variável é descartado através de uma transição

ti.sink. Esta transição é acrescentada ao modelo e o lugar pi.v.n é conectado a ela.

Pertencendo ao escopo de um condicional (i.e. variável pertence ao corpo do

combinador condicional), pi.v.n é conectado à própria transição que escreve o novo

valor em v (ti.op). Dessa forma, pode-se representar o fato de que – tendo uma execução

condicional – o processo pode ou não modificar o valor anterior da variável.

A Figura 4.7 exibe as duas situações possíveis em uma operação de atribuição.

Primeiro, o valor zero é atribuído à instância n da variável z fora de um processo

condicional. O valor em pi.z.n é descartado através da transição ti.sink e o valor da

constante zero (pi.val[0]) é atribuído (ti. :=) à nova instância de z (pi.z.n+1). Em seguida,

ocorre uma outra atribuição a z dentro de um processo condicional. O valor em pi.z.n+1

é descartado novamente, porém não mais através de uma transição sink. A transição ti.:=

modela a operação que escreve a nova instância de z. Portanto, o novo valor de z

(pi.val[f]) é direcionado a esta transição em conjunto com o valor anterior de z

(pi.z.n+1), gerando a nova instância representada por pi.z.n+2.

...z := 0... WHILE ... SEQ ... z := y + 2 ...

p .z.n+ 1i

p .z.n+ 2i

p .va l[f]i

p .z.ni p .va l[0 ]i

t .:=i

t .:=i

t .sin ki

Figura 4.7: Escrita de variável

___________________________________________________________________

64

4.4.2.4 Expressões

As expressões aritméticas, relacionais e lógicas são representadas no modelo

através da combinação de lugares (operandos) e transições (operadores). Três passos são

necessários para concluir a tradução de uma expressão:

I. incluir os lugares que representam os operandos;

II. incluir a transição que representa a operação (ti.f);

III. incluir o lugar que representa o resultado da operação (pi.val[f]);

Os dois últimos passos são diretos, pois só dependem da existência dos

operandos. O primeiro, entretanto, tem um tratamento diferente para as duas situações

que podem ocorrer:

• caso o operando seja um literal, o mesmo deve ser representado no modelo

através da introdução de um lugar correspondente (pi.val[l]), conforme a

tradução de literais visto anteriormente;

• se o operando for uma variável, o tratamento é da forma como descrito

anteriormente em leitura de variável.

Na Figura 4.8 temos a rede equivalente à expressão y+2. Primeiro, são aplicados

o método de tradução para instância y lida e o método de tradução para o literal 2. Em

seguida, a transição ti.+ é acrescentada para representar o cálculo da expressão e um

lugar pi.val[+] representa o resultado dessa expressão.

...Z := y + 2...

p .y.ni

p .va l[ ]i f

p .va l[2 ]i

t .+i

Figura 4.8: Tradução de expressões

4.4.2.5 Atribuição

A tradução da atribuição está diretamente relacionada com a tradução de

expressões e a escrita em variáveis. Primeiramente, a expressão f é traduzida e o lugar

que representa o resultado da expressão é então conectado a uma nova transição ti. :=,

esta transição representa a operação que faz a escrita na n-ésima instância da variável v,

___________________________________________________________________

65

cuja tradução se dá conforme a escrita de variável já vista. A rede exibida na Figura 4.9

modela a operação de atribuição z := y + 2. A tradução da expressão y+2 é realizada

como já mostrado na seção anterior. Em seguida, aplica-se a escrita de variável sobre a

transição ti.:=, gerando uma nova instância da variável z (pi.z.n+1).

...Z := y + 2...

p .z.n + 1i

t .i :=

p .va l[f]i

Figura 4.9: Tradução da atribuição (::== )

4.4.2.6 Comunicação

A tradução das operações de comunicação se divide em duas etapas distintas: a

declaração de canais e a comunicação propriamente dita. A declaração de um canal ch é

refletida no modelo simplesmente com a inclusão de um lugar pi.ch.

A comunicação definida em occam é realizada através de operações de leitura e

escrita no canal, que são semelhantes à operação de atribuição. É importante destacar

que o modelo só permite uma operação de escrita e uma operação de leitura para cada

canal. A leitura de um canal se comporta como uma operação de escrita de variável,

onde o valor atribuído à variável é o conteúdo do próprio canal e não o resultado de uma

expressão. Porém na leitura a operação de duplicação não se aplica ao canal, que

funciona como um literal. Uma transição ti.? é acrescentada à rede e conectada adiante

do lugar que representa o canal. A saída desta transição é então dirigida ao lugar que

representa a nova instância da variável contendo o valor lido através do canal. Em

seguida, é aplicada a operação de escrita da variável. Na rede da Figura 4.10 encontra-se

a tradução do processo ch2?y. A escrita de variável é aplicada sobre a variável y e sobre

a transição ti.?. A entrada de ti.? é dada pelo lugar que representa o canal (pj.ch2).

p .y.ni

t .sin ki

...ch2 ? y...

p .y.n+ 1i

t .?i

p .ch 2j

Figura 4.10: Tradução de entrada (?)

Já a escrita pode ser vista como uma atribuição onde a variável é o canal. A

diferença dessa vez se dá por conta de que o valor do canal não é descartado, como

___________________________________________________________________

66

ocorre com a variável. Uma transição ti.! é acrescentada à rede e todos os lugares

representando o resultado das expressões enviadas pelo canal são conectados à

transição.

Além disso, dois lugares especiais são acrescentados na operação de escrita. Um

lugar pi.’! é acrescentado entre as transições ti.start e ti.! para garantir que o processo só

consiga enviar informações se ele estiver ativo. Um outro lugar pi.!’ é acrescentado

entre ti.! e ti.end para garantir que o processo só termine se conseguir enviar as

informações. Na rede da Figura 4.11 é exibida a tradução de ch1!x. A operação de

comunicação é dada pela transição ti.!. Sua entrada é a instância de x que está sendo

enviada (pi.x.n+1) e sua saída é o lugar que representa o canal ch1 (pj.ch1). Nota-se

também a inclusão dos lugares pi.’! . e pi.!’ antes e depois da transição de comunicação,

respectivamente.

p .x .n + 1i

p .ch 1j

p .x .n + 2i

p .s ta rti p .x .ni

t .!i

t .sta rtit .c lo n ei

t .en di

...ch1 ! x...

p .’!i

p .en di Figura 4.11: Tradução da saída(!)

4.4.2.7 Condicionais

A tradução dos condicionais IF e ALT é realizada da mesma forma. Primeiro,

todas as condições e guardas são avaliadas como expressões. Em seguida, uma rede de

processos é acrescentada ao modelo para representar o construtor condicional. Os

lugares representando o valor final das expressões de guarda são conectados como pré-

condições da transição ti.start. Finalmente, todos os processos dentro de cada ramo do

condicional são também traduzidos. Na Figura 4.12 encontra-se parte da rede que

representa o condicional IF ( x>0 . . . , TRUE . . . ). As expressões condicionais x>0 e

TRUE são traduzidas e seus lugares equivalentes pi.val[>], e pi.val[TRUE] são

___________________________________________________________________

67

acrescentados como pré-condições da transição inicial de cada processo guardado pelos

respectivos condicionais.

...

...

...

IF x > 0 ... TRUE

p .x.ni

t .>i

p .va l[0 ]i

p .sta rti

p .en di

p .du m m yi

t .sta rti

t .en di

p .va l[T R U E ]i

p .va l[> ]i

Figura 4.12: Tradução do condicional(IF/ALT)

4.4.2.8 Laços

O construtor de laços (WHILE) é traduzido com uma regra semelhante à dos

condicionais. Porém, além da expressão condicional b ser traduzida uma vez no início

do processo, gerando um lugar pi.val[bB] como pré-condição de ti.start, também é

traduzida ao final, gerando um lugar pi.val[bA] o qual é conectado como pré-condição de

ti.end. Esta tradução extra deve-se ao fato de que variáveis utilizadas na expressão

condicional podem vir a ser modificadas dentro do laço. Dessa forma evita-se também a

necessidade de realimentação das variáveis do laço. No exemplo mostrado na Figura

4.13, o laço WHILE x<10 . . . tem seu modelo composto por: o resultado da expressão

x<10 (pi.val[<B]), o qual é acrescentado como pré-condição de ti.start; pela tradução do

processo dentro do laço e, finalmente, por outro lugar que representa a mesma

expressão após o laço (pi.val[<A]), acrescentado como pré-condição de ti.end.

...WHILE x < 10 ......

p .x .ni

p .x .n + ki

t .<i

t .<i

p .va l[1 0 ]i

p .va l[1 0 ]ip .s ta r ti

p .en di

p .du m m yi

t .s ta rti

t .e n di

p .va l[< ]iB

p .va l[< ]iA

Figura 4.13: Tradução do laço (WHILE)

A Figura 4.14 mostra como fica o modelo de fluxo de dados para a

especificação em occam mostrado pela Figura 4.1 acima.

___________________________________________________________________

68

0 :p 0.ch1

3 4: t2.?

1 :p 0.ch2

1 2: t1.?

1 :t1 .end

4 :p 1.end

2 5:p1 .y.1

1 8: t1.clone

3 1:p1 .y.2

1 9: t1.+

3 2:p1 .y.3

3 4:p1 .val

2 0: t1. :=

3 5:p1 .z.1

3 7:p1 .x.10

4 0:p2 .sta rt

2 4: t2. s ta rt

4 1:p2 .dum m y

2 5:t2.end

4 2:p2 .end

4 3:p2 .x.0

2 7: t2. s ink

4 4:p2 .y.0

4 2: t2. :=

4 5:p2 .val[0 ]

2 6: t2. :=

4 6:p2 .x.1

3 0: t2.clone

4 7:p2 .sta rt

2 8: t2. s ta rt

4 8:p2 .dum m y

2 9:t2.end

4 9:p2 .end

5 0:p2 .x.2

3 1: t2.<

5 1:p2 .x.3

3 5: t2. s ink

5 2:p2 .val[1 0]

5 3:p2 .val

5 4:p2 .sta rt

3 2: t2. s ta rt

5 5:p2 .dum m y

3 3:t2.end

5 6:p2 .end

5 7:p2 .x.4

3 8: t2.clone

5 8:p2 .sta rt

3 6: t2. s ta rt

5 9:p2 .dum m y

3 7:t2.end

6 0:p2 .end

6 1:p2 .x.5

3 9: t2.>

6 2:p2 .x.6

4 0: t2.clone

6 3:p2 .val[0 ]

6 4:p2 .val

6 5:p2 .x.7

4 1: t2.+

6 6:p2 .x.8

4 6: t2.clone

6 7:p2 .val[1 ]

6 8:p2 .val

6 9:p2 .y.1

4 3: t2. :=

7 0:p2 .val[TRUE]

7 1:p2 .val[0 ]

7 2:p2 .y.2

4 5: t2.clone

7 3:p2 .'!

4 4: t2. !

7 4:p2 .! '

7 5:p2 .y.3

7 6:p2 .y.4

7 7:p2 .x.9

4 7: t2.<

7 8:p2 .x.10

7 9:p2 .val[1 0]

8 0:p2 .val

3 3:p1 .val[2 ]

1 3:p1 .end

5 :t1 .end

2 0:p1 .end3 0:p1 .x.8

2 2: t1.clone

3 6:p1 .x.9

2 3: t1.<

3 9:p1 .val

1 2:p1 .dum m y

9 :t1 .end

1 4:t1.clone

2 6:p1 .x.6

1 5: t1.+

2 7:p1 .x.7

1 7: t1. s ink

2 9:p1 .val

1 6: t1. :=

4 :t1 .sta rt 1 1: t1.clone

1 8:p1 .sta rt

8 :t1 .sta rt

1 9:p1 .dum m y

2 1:p1 .'!

1 0: t1. !

2 2:p1 .! '

2 3:p1 .x.4

2 4:p1 .x.5

2 8:p1 .val[1 ]

3 :p 1.dum m y

8 :p 1.val[0 ]

2 :t1 .:=

9 :p 1.x.1

6 :t1 .clone

1 1:p1 .sta rt

1 4:p1 .x.2

7 :t1 .<

1 5:p1 .x.3

1 6:p1 .val[1 0]

1 7:p1 .val

1 0:p1 .val[0 ]

3 8:p1 .val[1 0]

5 :p 1.x.0

3 :t1 .s ink

6 :p 1.y.0

1 3: t1. s ink

7 :p 1.z.0

2 1: t1. s ink

2 :p 1.start

0 :t1 .sta rt

Figura 4.14: Modelo do fluxo de dados para a especificação da Figura 4.1

___________________________________________________________________

69

4.5 Conclusões

Neste capítulo apresentamos os modelos em redes de Petri desenvolvidos para

representar o fluxo de controle e dados, bem como introduzimos o conjunto da

linguagem de programação occam (processos primitivos e combinadores).

A partir de uma especificação occam (Figura 4.1) foi mostrado o modelo de

fluxo de controle (Figura 4.2) e dados (Figura 4.14) resultante. Para o modelo de fluxo

de dados foi definido os componentes da rede: lugares (representando valores),

transições (expressões, operadores e construtores de occam), arcos (utilização ou

geração de novos valores) e fichas (modelam a presença de um valor em um dado

momento). Em seguida foi apresentado o método de tradução para os processos

(combinadores de occam), literais, variáveis, expressões, atribuição, comunicação,

condicionais e laços.

Observamos que o modelo de fluxo de dados resultante, visto na (Figura 4.14) é

uma rede de Petri da subclasse grafo marcado. Este tipo de rede não modela conflito,

mas é ideal para modelar sincronização e concorrência. A vantagem deste modelo é que

as análise qualitativas e quantitativas, possíveis de serem realizadas através do mesmo,

apresentam um baixo custo computacional.

5 Estimativa de Área

Neste capítulo é apresentada a abordagem para o cálculo da estimativa de área dos componentes do caminho de dados: unidades funcionais, de armazenamento e de interconexão (multiplexadores), a partir de uma especificação de alto nível mapeada para um modelo intermediário de dados – Rede de Petri temporizada (timed Petri net). Inicialmente são apresentados conceitos de estilos de projetos, métricas de qualidades e finalmente é demonstrada a abordagem da estimativa de área para os componentes do caminho de dados.

5.1 Modelo da Estimativa de Hardware

Dada uma especificação de um sistema para o qual estimativas devem ser

computadas, o projeto correspondente poderá ser implementado como uma máquina de

estados finitos com caminho de dados (FSMD – finite-state machine with datapath). A

arquitetura de uma FSMD consiste de uma unidade de controle e de um caminho de

dados (datapath), como mostrado na Figura 5.1.

O caminho de dados consiste de registradores, unidades funcionais,

multiplexadores e/ou barramentos. Em uma operação típica no caminho de dados os

operandos são lidos dos registradores, as operações são computadas nas unidades

funcionais, e finalmente o resultado é escrito no registrador destino. Todo acesso à

memória é roteado através de registradores pelas operações de leitura e escrita que

carregam valores de dados nos registradores antes de seu uso no caminho de dados, e

armazena os resultados da computação em registradores antes de serem escritos na

memória.

A unidade de controle consiste do registrador de estado, da lógica de controle

para direcionar as linhas de controle para os componentes do caminho de dados, e a

___________________________________________________________________

71

lógica do próximo estado para computar o próximo estado a ser armazenado no

registrador de estado. Linhas de status do caminho de dados levam os resultados das

operações de comparação para a lógica do próximo estado.

Lógica de Controle

Lógica Próximo Estado

Registrador de Estado

mux mux mux mux mux mux

mux mux

R1 R2 R3

mux mux

R4 R5 R6

ALU1 *Bits de Status

Sinais de Controle

UC

RC

RS

UE

Lógica de Controle

Lógica Próximo Estado

Registrador de Estado

mux mux mux mux mux mux

mux mux

R1 R2 R3

mux mux

R4 R5 R6

ALU1 *Bits de Status

Sinais de Controle

UC

RC

RS

UE

Figura 5.1: Modelo para estimativas com unidade de controle e caminho de dados

5.2 Sistema de Estimativa de Área de Hardware

Esta seção tem como objetivo dar uma visão geral do sistema de estimativa de

área de hardware implementado neste trabalho. Um sistema [33] é definido como um

conjunto de componentes inter-relacionados que coleta (ou recupera), processa,

armazena e distribui informações para seus usuários. Os sistemas possuem três funções

básicas: entrada, processamento e saída.

Program Convolution

SEQ i=0 FOR 2PAR

IF (x[i]>= 0 c:= x[i],x[i]<0 c:= x[i]/2)

IF (x[i+1]>= 0 d:= x[i+1],x[i+1]<0 d:= x[i+1]/2)

PAR j=0 FOR 4e[j]:= x[f(i,j)]

PARw := k*e[i]PAR j= 0 FOR 4

y[j] := y[j] + e[j]*(c+d)

Program Convolution

SEQ i=0 FOR 2PAR

IF (x[i]>= 0 c:= x[i],x[i]<0 c:= x[i]/2)

IF (x[i+1]>= 0 d:= x[i+1],x[i+1]<0 d:= x[i+1]/2)

PAR j=0 FOR 4e[j]:= x[f(i,j)]

PARw := k*e[i]PAR j= 0 FOR 4

y[j] := y[j] + e[j]*(c+d)

Program Convolution

SEQ i=0 FOR 2PAR

IF (x[i]>= 0 c:= x[i],x[i]<0 c:= x[i]/2)

IF (x[i+1]>= 0 d:= x[i+1],x[i+1]<0 d:= x[i+1]/2)

PAR j=0 FOR 4e[j]:= x[f(i,j)]

PARw := k*e[i]PAR j= 0 FOR 4

y[j] := y[j] + e[j]*(c+d)

Program Convolution

SEQ i=0 FOR 2PAR

IF (x[i]>= 0 c:= x[i],x[i]<0 c:= x[i]/2)

IF (x[i+1]>= 0 d:= x[i+1],x[i+1]<0 d:= x[i+1]/2)

PAR j=0 FOR 4e[j]:= x[f(i,j)]

PARw := k*e[i]PAR j= 0 FOR 4

y[j] := y[j] + e[j]*(c+d)

Especificaçãoem Occam

Modelo Intermediário

em RdP

ferramenta

depend

Sistema deEstimativa de

Área de Hardware

Entrada ProcessamentoSaída

Figura 5.2: Sistema de Estimativa de Área de Hardware

No sistema de estimativa de hardware, visto na Figura 5.2, a entrada é um

modelo intermediário. Este modelo é obtido pela ação de um tradutor (ferramenta

___________________________________________________________________

72

depend desenvolvida por Monteiro[47]) que traduz o código de uma especificação em

occam em um modelo fluxo de dados apoiado em redes de Petri temporizadas. O

processamento é baseado no cálculo de estimativas de área de hardware do caminho de

dados: unidades de armazenamento [37], funcionais e de interconexão. A saída do

sistema é a estimativa de área, bem como o tipo e quantidades destes componentes.

5.3 Definição do Modelo Intermediário

A partir da especificação da Figura 5.3 e utilizando-se um tradutor, ferramenta

depend, chegamos a uma rede de Petri marked-graph marcada limitada que representa o

modelo de fluxo de dados – modelo intermediário mostrado na Figura 5.4.

Figura 5.3: Especificação em occam de um comportamento bem simples

No modelo de fluxo de dados, conforme visto no Capítulo 4, lugares

representam valores e transições representam expressões aritméticas, operadores e

construtores da linguagem de especificação. Cada valor produzido por um processo

(incluindo variáveis, constantes e valores intermediários) tem um lugar equivalente, cuja

marcação modela a presença deste valor. Existem dois pares especiais de lugares e

transições para cada processo (start e end), os quais alimentam todos os valores iniciais

e consomem todos os valores finais.

Com as informações temporais (retardo) associadas aos componentes de uma

determinada tecnologia, determinam-se os tempos das transições que modelam

operações lógico-aritméticas do modelo de fluxo de dados gerado. Às demais transições

são associadas a tempos de retardo com valor zero, já que as mesmas não consomem

tempo. O resultado é uma rede de Petri marked graph temporizada ΓΓ1= (M, f),

conforme visto na Figura 5.5, onde:

___________________________________________________________________

73

M é uma rede de Petri marked graph marcada, M = (N, m0), N = (P, T, A, ω),

f é uma função de tempo de disparo a qual atribui um valor real não negativo f(t)

para cada transição t da rede, f: T → R⊕ e R⊕ denota o conjunto de números reais não

negativos.

Figura 5.4: Modelo de Fluxo de dados gerado pelo ferramenta depend

___________________________________________________________________

74

Figura 5.5: Rede de Petri temporizada ΓΓ1 – Modelo de fluxo de dados.

O estado s de uma Rede de Petri temporizada ΓΓ1 é uma tupla s = (m, n, r). Um

estado inicial si de uma rede ΓΓ1 é uma tupla si = (mi, ni, ri). Vemos que este modelo é

uma simplificação da rede temporizada proposta por Zuberek (rede free-choice, ver

Seção 3.5), pois aqui não temos a possibilidade de escolhas. Assim um grafo de estado

G de uma rede de Petri marked graph temporizada limitada ΓΓ1 é um grafo direcionado

rotulado G(ΓΓ1) = (V, D, h) onde:

___________________________________________________________________

75

V é um conjunto de vértices iguais ao conjunto de estados alcançáveis da rede ΓΓ,

V = S(ΓΓ1),

D é o conjunto de arcos direcionados, D ⊂ V × V, tal que (si, sj) está em D sse sj

é diretamente acessível a partir de si,

h é uma função rotuladora de vértices a qual associa o tempo de armazenamento

do estado si = (mi, ni, ri) para cada si ∈ S(ΓΓ1), h :V→ R⊕.

A Tabela 5.1 resume algumas métricas de desempenho de uma biblioteca de

componentes implementada na família em Xilinx’s XC4000E (FPGA) com a

ferramenta CAD Xilinx Foundation Series 3.1. A área é expressa em termos do número

de portas (gates) e os tempos de retardos em nanosegundos. Alguns destes componentes

são multifuncionais.

Tabela 5.1: Xilinx 5000 Library (obtida em [38])

Componentes Function Gate Count Delay (ns)AND 5 9.5OR 5 9.5DFF 7 9.0

MUX21(1) 5 10.0MUX21(8) 40 19.9

ADD(8) 107 17.7SUB(8) 107 19.7

COMP(8) <, =, > 116 19.2MUL(8) 433 36.3DIV(8) 431 44.0

INV - Inversor, AND - AND GateOR - OR gate, DFF - D Flip-Flop

5.4 Estimativa de Área do Caminho de Dados

A primeira tarefa na estimativa do tamanho de qualquer projeto é determinar o

número e tipos de componentes que implementarão o comportamento dado. Uma vez

que os componentes requeridos sejam determinados, podemos obter estimativas de

tamanho para uma variedade de tecnologias. Para uma implementação em FPGA, por

exemplo, uma estimativa do número total de blocos lógicos combinacionais (CLB)

usados no projeto, pode ser obtida pelo somatório do número de CLBs usados por cada

___________________________________________________________________

76

componente no projeto. Para uma implementação gate array, a complexidade do projeto

pode ser medida pelo somatório do número de gates equivalentes necessários para os

componentes. Para uma implementação full custom, o tamanho do projeto pode ser

estimado levando-se em consideração o número de transistores em todos os

componentes ou pela área obtida após a realização do layout e placement dos

componentes.

Como descrito na Seção 5.1, o comportamento dado é assumido para ser

implementado como uma FSMD com uma unidade de controle e um caminho de dados.

O caminho de dados consiste de três tipos de componentes: unidades de armazenamento

(registradores e latches), unidades funcionais (ALUs e comparadores), e unidades de

interconexão (multiplexadores e barramentos). Diversos métodos para síntese do

caminho de dados têm sido discutidos extensivamente em [20]. Nesta seção,

descreveremos técnicas para estimativa do número e área destes componentes, que são

requeridos para implementar uma especificação funcional.

5.4.1 Número de Unidades de Armazenamento: Método Baseado nas Variáveis Simultaneamente “Vivas”

Unidades de armazenamento [21] são requeridas para guardar valores de dados

representados por constantes, variáveis e vetores de um determinado comportamento.

Entendemos aqui por comportamento como uma “parte” de uma funcionalidade do

sistema, mais complexa que uma operação aritmética, o qual pode ser representado de

diversas maneiras, por exemplo: como processo, procedimento, máquina de estados, etc.

Para uma descrição de um comportamento em alto nível, o projeto de hardware é

dividido em classes de blocos funcionais: caminho de dados e controladores [40]. Um

aspecto que deve ser considerado é o número necessário de registradores para

implementar uma determinada descrição comportamental.

A estratégia mais simples assume que cada variável do comportamento deverá

ser implementada em um registrador ou localização de memória [38]. Todavia, tal

implementação pode ter um número excessivo de unidades de armazenamento, pois

valores de variáveis podem não ser necessários durante a execução do comportamento.

___________________________________________________________________

77

Pode-se minimizar o número de unidades de armazenamento fazendo o mapeamento de

diversas variáveis que não estão sendo concorrentemente utilizadas para um mesmo

registrador. A abordagem proposta consiste na estimativa do número de registradores

considerando dependência causal capturadas no modelo de fluxo de dados (redes de

Petri temporizada – timed Petri nets). Este modelo considera dependência de dados

entre operadores de uma descrição comportamental, bem como precedência de tempo

entre tais operações.

Duas variáveis a e b podem ser alocadas em um mesmo registrador se a e b

nunca estiverem “em uso” ao mesmo tempo. O algoritmo proposto analisa a

representação intermediária do programa (modelo de fluxo de dados) para determinar

quais variáveis estão em uso ao mesmo tempo. Dizemos que a variável é viva se ela

armazenar um valor que será utilizado no futuro.

Para ilustrarmos esta abordagem começaremos com um exemplo bem pequeno,

mas que possibilita o entendimento da abordagem proposta, a descrição em occam

mostrada na Figura 5.3. Verificamos nesta especificação que as três operações foram

projetadas para serem executadas em paralelo. No modelo de fluxo de dados gerado

(Figura 5.5) elas são executadas seqüencialmente devido à dependência de dados entre

as variáveis.

O grafo de estados gerado para a rede da Figura 5.5, através da ferramenta INA

(Integrated Net Analyzer) [66], é mostrado na Figura 5.6. No começo do processo,

estado s1, o lugar p1.start tem apenas uma ficha, habilitando a transição t0. Esta

transição dispara e logo no início do disparo uma ficha é removida do lugar de entrada

desta transição (p1.start) e fica “armazenada” na transição t0 durante o tempo de disparo

(duration). No final do disparo, uma ficha é depositada nos lugares de saída da transição

disparada (t0), aqui representado pelos lugares p1.dummy, p1.a.0, p1.b.0, p1.c.0 e p1.c.0.

Estes novos lugares, somando-se aqueles lugares vivos do estado anterior, cujas

transições não foram disparadas, constituem o estado atual. Neste caso específico, o

estado anterior (s1), tínhamos apenas uma transição a ser disparada (t0),

conseqüentemente o estado s2 é constituído dos novos lugares vivos: p1.dummy, p1.a.0,

p1.b.0, p1.c.0 e p1.c.0, conforme mostrado pela Figura 5.6. Os lugares marcados no estado

___________________________________________________________________

78

s2 habilitam as transições t2, t3, t6 e t11. Estas transições habilitadas disparam em paralelo

(semântica de passo), novamente fichas são retiradas dos lugares de entrada (p1.a.0,

p1.b.0, p1.c.0 e p1.c.0) e novas fichas são armazenadas nas transições disparadas,

permanecendo nelas até o término do tempo remanescente de disparo. À medida que é

alcançado o final do tempo dos disparos de cada transição em particular, novas fichas

chegam aos lugares de saída das respectivas transições gerando novos estados. Para

cada transição é computado seu tempo remanescente de disparo o qual estabelece uma

política de liberação de fichas, isto é, aquelas transições com menor tempo

remanescente (coluna h(si) da Tabela 5.2) concluirão seus disparos. Como as transições

t2, t3, t6 e t11 apresentam a mesma duração, isto é, tempos de disparo remanescentes

iguais a zero, todas estas transições concluem seus disparos gerando fichas para os

novos lugares: p1.a.1, p1.a.2, p1.b.1 e p1.b. O lugar p1.dummy continua vivo (ie. marcado),

pois é entrada da transição t1.end que só será disparada no final do processo. Assim

chegamos ao estado s3, constituído dos seguintes lugares vivos: p1.a.1, p1.a.2, p1.b.1, p1.b

e p1.dummy. Desta maneira, procede-se até que todas as transições sejam disparadas.

Figura 5.6: Grafo de estados para ΓΓ1

É importante salientar que na Figura 5.6, o estado final s13 está rotulado como

dead state, isto é, a rede não é reversível como mostrado na Figura 5.5 (não retorna ao

___________________________________________________________________

79

estado s1). Isto é devido a não inclusão da transição closure pela ferramenta depend

quando da geração da rede. Aqui não incluímos esta transição manualmente, o que é

feito com o propósito de ganharmos tempo na análise, já que a não inclusão desta

transição não altera os resultados obtidos pela aplicação da ferramenta INA.

A Tabela 5.2 mostra todos os estados alcançáveis da rede, acrescentando

detalhes ao grafo de estados mostrado na Figura 5.6. A marcação intermediária m’ i

representa os lugares marcados antes do disparo das transições; gk ∈ Sel(m’ i) é o

conjunto das transições habilitadas pela marcação m’ i; a coluna mi define os lugares

vivos, cujas fichas não foram consumidas, pois não são lugares de entrada das

transições habilitadas; ni define o conjunto de transições disparadas (com fichas

armazenadas) com tempo remanescente, isto é, que ainda não completaram o seu tempo

de execução; h(si) representa o menor tempo remanescente das transições do conjunto ni

(tempo de permanência no estado si). h(si) define o conjunto de transições que

finalizarão seus disparos, gerando novos estados a serem alcançados. O somatório de

h(si) determina o tempo de execução do comportamento. Detalhes formais da definição

dos campos desta tabela encontram-se no Capítulo 3.

m'i g k m i n i

Lugares Transições Lugares Transições

1 p1.start t0 null n i (t0 ) = 1 0 2

2 p1.dummy, p1.a.0, p1.b.0, p1.c.0, p1.d.0 t2, t3, t6, t11 p1.dummy n i (t2, t3, t6, t11 ) = 1 0 3

3 p1.dummy, p1.a.1, p1.a.2, p1.b.1, p1.b.2 t4, t8, t12 p1.dummy n i (t4, t8, t12 ) = 1 0 4

4 p1.dummy, p1.a.3, p1.a.4, p1.b.3, p1.b.4 t16 p1.dummy, p1.a.3, p1.a.4, p1.b.3 n i (t4, t16 ) = 1 0 4n i (t4 ) = 1 15 5

5 p1.dummy, p1.val, p1.a.3, p1.a.4, p1.b.3 t5 p1.dummy, p1.a.3, p1.a.4, p1.b.3 n i (t5 ) = 1 0 66 p1.dummy, p1.a.3, p1.a.4, p1.b.3, p1.c.1 t7 p1.dummy, p1.a.3, p1.a.4, p1.b.3 n i (t7 ) = 1 0 7

7 p1.dummy, p1.a.3, p1.a.4, p1.b.3, p1.c.2, p1.c.3 t9 p1.dummy, p1.a.3, p1.a.4, p1.c.3 n i (t9 ) = 1 15 88 p1.dummy, p1.a.3, p1.a.4, p1.c.3, p1.val t10 p1.dummy, p1.a.3, p1.a.4, p1.c.3 n i (t10 ) = 1 0 9

9 p1.dummy, p1.a.3, p1.a.4, p1.c.3, p1.d.1 t13 p1.dummy, p1.a.3, p1.a.4, p1.c.3 n i (t13 ) = 1 0 10

10 p1.dummy, p1.a.3, p1.a.4, p1.c.3, p1.d.2, p1.d.3 t14 p1.dummy, p1.a.4, p1.c.3, p1.d.3 n i (t14 ) = 1 15 11

11 p1.dummy, p1.a.4, p1.c.3, p1.d.3, p1.val t15 p1.dummy, p1.a.4, p1.c.3, p1.d.3 n i (t15 ) = 1 0 1212 p1.dummy, p1.a.4, p1.c.3, p1.d.3, p1.b.5 t1 null n i (t1 ) = 1 0 13

13 p1.end dead-lock

s i h(s i ) s j

Tabela 5.2: O conjunto de estados alcançáveis para ΓΓ1

Observando atentamente a Figura 5.5 juntamente com a Figura 5.6 vemos a

existência de lugares especiais como dummy, val, start, end utilizados na definição dos

___________________________________________________________________

80

modelos. Para o cálculo de unidade s de armazenamento os lugares que nos interessa

são os lugares representando variáveis e literais. Um ponto importante a ser considerado

são os lugares (variáveis e literais) de entrada das transições sink e end, nestes casos

estes lugares marcados devem ser descartados no cômputo das variáveis

simultaneamente vivas. Quando um lugar é entrada de uma transição sink (que modela

uma atribuição de variável) este lugar não estará vivo em outros estados. Na passagem

do estado s2 para s3, vemos que os lugares p5 (p1.c.0) e p6 (p1.d.0), que são componentes

de s2, não mais aparecem no estado s3, pois suas fichas são consumidas pela transição

sink. Com relação aos lugares de entrada da transição end, significa que chegamos ao

final do processo e não serão utilizadas no futuro. Outro aspecto importante é o índice

das variáveis, que está relacionado com seu uso em determinado estado. Observando o

estado s3, vemos os lugares p7 (p1.a.1) e p8 (p1.a.2), cujas fichas são provenientes do

término do disparo da transição t2 (t1.clone). A transição clone possibilita a duplicação

do valor da variável a e a distribui em lugares diferentes para uso futuro. Logo estes

lugares representam a mesma variável a.

No estado s3 temos os seguintes lugares marcados (vivos) representando

variáveis: p1.a.1, p1.a.2, p1.b1 e p1.b.2. Os lugares p1.a.1 e p1.b1 são entradas para a

transição t4 (t1.+), que executa uma operação de soma visto na especificação da Figura

5.3 ( c := a + b), enquanto os lugares p1.a.2 e p1.b2 são entradas para transições clone.

Considerando a variável a no estado s3, ao disparar-se a transição t12 (t1.clone), a ficha

do lugar p1.a.2, que é entrada desta transição, é duplicada nos lugares p1.a.3 e p1.a.4.

Observando o lugar p1.a.3 (entrada da transição t14 (t1.+) que modela a instrução b := a

+ d) vemos que o mesmo permanece vivo durantes os estados s4, s5, s6, s7, s8, s9 e s10,

quando a transição t14 é disparada. Considerando agora a variável b, quando a transição

t8 (t1.clone) é disparada em s3 as fichas do lugar p1.b.2 são duplicadas nos lugares p1.b.3

e p1.b.4. O lugar p1.b.3 (entrada da t9 (t1.+) que executa a instrução d := c + b),

permanece vivo até o estado s7. Assim, na passagem do estado s3 para s4 pelo disparo da

transição t4 (t1.+) – operação soma (instrução c := a + b) – precisamos inicialmente de

dois registradores para armazenar os valores das variáveis a (p1.a.1) e b (p1.b.1). Vimos

que a variável c não pode compartilhar o mesmo registrador com variável a, pois esta

permanece viva até o estado s10, nem tampouco a variável c pode compartilhar o mesmo

___________________________________________________________________

81

registrador com a variável b, pois esta continua viva até o estado s7. Logo, os tempos de

vida destas variáveis se sobrepõem. Conseqüentemente, neste estado precisamos de três

registradores.

A solução da abordagem proposta é especificar um algoritmo cuja solução é

encontrar os estados com o maior número de lugares marcados representando variáveis

simultaneamente vivas. Figura 5.7 mostra um grafo de estados simplificado, onde

foram removidos os lugares start, end, val e dummy e lugares que são entradas de

transições sink e end. Também retiramos os índices dos lugares representando variáveis.

O número máximo de variáveis simultaneamente vivas é obtido no estados s6 (a, b, c) e

s7 (a, b, c). Portanto, são necessárias três unidades de armazenamento para implementar

esta especificação.

Figura 5.7: Grafo de estados simplificado para Γ1

Após esta apresentação informal, vamos abordar o método proposto de maneira

mais formal.

Definição 5.1 – Função de nomeação l : Seja N = (P, T, A, ω, m0, f), uma rede

de Petri marked graph temporizada. l é uma função de nomeação que nomeia elementos

___________________________________________________________________

82

dos conjuntos de lugares e transições com nomes significativos, l : P ∪ T → L onde

L = {string1, string2,...}.

Assim, na geração da rede de Petri temporizada são nomeados os lugares e

transições. Desta forma são definidos os lugares que modelam variáveis e/ou literais, e

transições que realizam operações lógicas aritméticas, bem como lugares e transições

especiais, conforme descrito no Capítulo 4. Por exemplo, um lugar representando uma

variável tem a seguinte forma: pi.string.k (onde p representa o lugar, i é o índice do

processo, string é o nome da variável e k é o índice da variável). Um literal tem a forma

pi.val[m], onde m é o valor do literal.

Definição 5.2 – Conjunto de Variáveis e Literais: Seja N = (P, T, A, ω, m0, f),

uma rede de Petri marked graph temporizada e l uma função de nomeação. VAR = {ph,

..., pl, ..., pn} é definido como o conjunto de lugares rotulados como variáveis. LIT =

{pk, ..., pj ..., pz} é o conjunto de lugares rotulados como literais, onde as seguintes

condições devem ser satisfeitas,

1. l(VAR) ∩ {pi.start, pj.end, pk.dummy, pq.val[r], ps.cht, pu.val } = φ |

i,j,k,q,r,s,t,u ∈ + ,

2. VAR ⊂ P ∧ LIT ⊂ P,

3. l (ph) ≠ l (pl), ∀ ph, pl ∈ VAR,

4. l(LIT) ={ pi.val[m] | i, m ∈ + },

5. l (pk) ≠ l (pj), ∀ pk, pj ∈ LIT,

6. VAR ∩ LIT = Ø.

Após definirmos o conjunto de variáveis e literais, precisamos saber quais as

variáveis que estão vivas (marcadas) por estados no grafo de estados.

Definição 5.3 – Conjunto de Variáveis Marcadas por Estado: Seja N = (P, T,

A, ω, m0, f), uma rede de Petri marked graph temporizada. Seja G(N) = (V, D, h) um

grafo de estado, onde V é um conjunto de vértices os quais é igual ao conjunto de

estados alcançáveis da rede N, V = S(N). Seja s = (m, n, r) um estado s da Rede N,

___________________________________________________________________

83

s ∈ S. VARMi(N, si) = {pi, ..., pq..., pw} é definido como o conjunto de variáveis

marcadas no estado si, onde (VARMi(N, si) ⊆ VAR) ∧ (m(p) = 1 ∀ p ∈ VARMi(N, si))

∧ (l(Out(p)) ∉ {tr.sink, ts.end}| r, s ∈ +).

Conforme visto no Capítulo 3 Out(p) é a transição de saída do lugar p. Agora

que definimos as variáveis vivas por estado, excluídas aquelas cujas transições de saída

são do tipo sink e end, o cálculo das unidades de armazenamento é obtida pela

cardinalidade do maior conjunto de VARMi(N, si).

Definição 5.4 – Número de Unidades de Armazenamento: Seja N = (P, T, A,

ω, m0, f), uma rede de Petri marked graph temporizada. Seja G(N) = (V, D, h) um grafo

de estado, onde V é um conjunto de vértices os quais é igual ao conjunto de estados

alcançáveis da rede N, V = S(N). Seja s = (m, n, r) o estado s da Rede de Petri

temporizada N, s ∈ S. Seja VARMi(N, si) = {pi, ..., pq..., pw} o conjunto de variáveis

marcadas no estado si. NREG = MAX(VARMi(N, si), ∀ si ∈ S(N)) + # LIT, nos dá o

número de Unidades de Armazenamento necessários para implementar a funcionalidade

(comportamento) de determinada especificação, onde a função MAX determina a

cardinalidade do maior conjunto.

O algoritmo proposto é:

• Entrada: ΓΓ( M, f) uma rede marked-graph temporizada marcada onde M =

(N, m0) é a rede marcada e N = (P, T, A, ω) a estrutura da rede.

• Saída: O número de unidades de armazenamento necessário para realizar a

especificação (NREG).

Passos:

I. Computar o grafo de estados

II. Para cada estado, conte o número de lugares representando variáveis, desprezando

os lugares que são entrada de transições do tipo sink e end.

___________________________________________________________________

84

III. Considere os estados com o maior número de lugares marcados representando

variáveis simultaneamente vivas. Este número de lugares representa o número de

unidades de armazenamento necessário para reter os valores das variáveis.

IV. Para computar os literais, a partir do conjunto de literais da especificação, gere um

subconjunto eliminando os valores repetidos. A cardinalidade deste subconjunto

determina a quantidades de registradores.

V. A quantidade de registradores é a soma dos registradores usados para armazenar as

variáveis e os literais.

A complexidade para a geração do grafo de estados da rede (marked graph,

semântica de passos) é O(K) onde K = { x | x ∈ • + ∧ 1 ≤ x ≤ T}, isto é, o grafo gerado

é composto de um único estado (todas as transições da rede são disparadas

paralelamente) ou T estados (apenas uma transição é disparada em cada estado). A

complexidade do algoritmo para estimativa do número de registradores para

armazenamento das variáveis é O (K * P), para cada estado é verificado a marcação de

todos os lugares. Para o cálculo dos registradores que armazenam literais a

complexidade é O(P), é feita a verificação dos lugares apenas no estado s2. Onde T

representa o conjunto de transições, P é o conjunto de lugares, K é o conjunto de

estados gerados. Logo, a complexidade da abordagem proposta para o cálculo dos

registradores pelo método das variáveis simultaneamente vivas é O(K + K * P + P).

5.4.2 Número de Unidades de Armazenamento: Método Baseado nos Tempos de Vida das Variáveis.

O algoritmo da seção anterior é uma maneira rápida para se calcular a

quantidade de registradores de um comportamento sem precisar computar o tempo de

vida das variáveis, diminuindo assim o custo do processamento. No entanto, como o

objetivo desta abordagem também é o calculo dos multiplexadores no caminho de

dados, é necessário realizarmos o mapeamento das variáveis para as unidades de

armazenamento. Para isto implementamos o algoritmo left-edge, descrito no Capítulo

2, para realizar este mapeamento.

___________________________________________________________________

85

A Tabela 5.3 mostra os tempos de vida das variáveis, bem como os tempos

iniciais de cada estado para o comportamento mapeado na Figura 5.5. A partir da Tabela

5.2 obtemos a coluna h(si), menor tempo de permanência no estado si. Acumulando

h(si) obtemos os tempos finais de cada estado, por exemplo, os estados s1 a s3 têm

tempos finais igual a zero (∑h(si) = 0), enquanto o estado s4 (∑(h(si) = 15)), assim nos

estados s1 a s3 o tempo de permanência acumulado foi zero, no estado s4 foi consumido

15 unidades de tempo até o seu término, logo o tempo final de s4 é o tempo final até o

estado s3 mais o tempo de permanência em s4, que é igual a 15. A coluna tempo inicial

acumulado é obtida pela subtração das colunas h(si) acumulado e h(si) para cada

estado si.

Tabela 5.3: Variáveis vivas por estados (tempo de vida das variáveis) para ΓΓ1

h(s i ) acumulado a b c d

s1 0 0 0s2 0 0 0 x xs3 0 0 0 x xs4 15 15 0 x xs5 0 15 15 x xs6 0 15 15 x x xs7 15 30 15 x x xs8 0 30 30 xs9 0 30 30 x x

s10 15 45 30 x xs11 0 45 45s12 0 45 45s13 0 45 45

EstadosTempo inicial

acumuladoh(s i ) Variáveis

O tempo de vida de uma variável é determinado pela seqüência de estados

(coluna variáveis na tabela) onde a mesma é marcada (viva). Dada a lista de variáveis

de uma descrição comportamental e seus tempos de vida associados, o algoritmo left-

edge primeiro ordena a lista de variáveis em ordem ascendente, considerando o tempo

passado desde o início da execução do comportamento até o instante em que a variável

se torna viva (coluna tempo inicial acumulado). O algoritmo realiza diversos passos

sobre a lista ordenada obtida, examinando os tempos de vida das variáveis na ordem em

que elas ocorrem na lista. Em cada passo o algoritmo aloca um novo registrador e

atribui uma nova variável ao mesmo se o tempo de vida desta variável não se

___________________________________________________________________

86

sobrepõem aos tempos de vidas das variáveis já atribuídas àquele registrador. Estas

variáveis atribuídas são eliminadas da lista ordenada de variáveis. O processo é repetido

até que todas as variáveis tenham sido atribuídas aos registradores.

Aqui vamos ilustrar o algoritmo left-edge, através do comportamento da Figura

5.5, onde os tempos de vida são vistos na Tabela 5.3. O conjunto de variáveis é

inicialmente ordenado de acordo com os tempos de vida resultando na lista L = {a, b, c,

d}. No primeiro passo, uma unidade de armazenamento R1 é alocada e a variável a é

atribuída a esta unidade. Percorrendo a lista L, observamos que todos os tempos de vida

das demais variáveis se sobrepõem ao da variável a. Portanto, a unidade de

armazenamento R1 consiste apenas da variável a e esta variável é retirada da lista L. No

segundo passo, a unidade de armazenamento R2 é alocada e b é atribuída à mesma.

Percorrendo a lista L, observamos que a variável d é a próxima variável que pode ser

atribuída à unidade de armazenamento R2, já que seu intervalo de tempo de vida não se

sobrepõe ao da variável b, já atribuída a R2. Nenhuma outra variável tem um tempo de

vida que não se sobrepõe àqueles das variáveis b e d. Então, a unidade de

armazenamento R2 consiste das variáveis b e d, e estas variáveis são retiradas da lista L.

No terceiro e último passo, a unidade de armazenamento R3 é alocada e a variável c é

atribuída à mesma.

Tabela 5.4: Resultado final do mapeamento das variáveis para os registradores para Γ1

a b c d

R1 xR2 x xR3 x

Unidades de armazenamento

Variáveis atribuídas

A Tabela 5.4 mostra o resultado final do mapeamento das variáveis para os

registradores para o comportamento da Figura 5.5, após a aplicação do algoritmo left-

edge. Verificamos que foi encontrado o mesmo resultado da abordagem anterior, isto é,

três unidades de armazenamento. Agora com maior custo computacional, já que foi

necessária a computação do tempo de vida das variáveis.

A complexidade para a geração do grafo de estados da rede é O(K), K = { x | x

∈ • + ∧ 1 ≤ x ≤ T}. Para a definição dos tempos de vida das variáveis a complexidade

___________________________________________________________________

87

é O(K*P). Para a construção da lista ordenada de variáveis é O(V*logV) e finalmente

para mapear as variáveis aos registradores é O(V*R), R = { y | y ∈ • + ∧ 1 ≤ y ≤ V}.

Onde T representa o conjunto de transições, P é o conjunto de lugares, K é o conjunto

de estados gerados, V ⊂ P é o conjunto de variáveis e R é o conjunto de registradores.

Logo, a complexidade da abordagem proposta para o cálculo dos registradores pelo

método baseado nos tempos de vida das variáveis é O(K + K * P + V*logV + V*R).

A seguir definiremos uma abordagem formal para o método descrito.

Inicialmente definiremos variável. Uma mesma variável pode ser modelado em vários

lugares, logo necessitamos de uma função que obtenha a variável desses lugares.

Definição 5.5 – Função Var e Conjunto de Variáveis: Seja VAR = {ph, ..., pl,

..., pn} o conjunto de lugares rotulados como variáveis e uma função de nomeação l.

l (VAR) → VI, onde VI = {pi.substringj.m | i, j, n ∈ +}. var : VI → VARIAVEL é uma

função que extrai uma sub-string um elemento do conjunto VI, onde var(pi.substringj.m)

= substringj e VARIAVEL = {substringj | j ∈ +} é o conjunto de variáveis.

Após obtermos as variáveis (conjunto VARIAVEL) do comportamento dado,

precisamos definir uma matriz que contenha os tempos de vida das variáveis. Se um

elemento da matriz contiver o valor 1 significa que a variável é viva (marcada) neste

estado. A seqüência de marcas com valor 1 na coluna (entre os estados) determina o

tempo de vida da variável.

Definição 5.6 – Matriz de Tempo de Vida de Variáveis: Seja N = (P, T, A, ω,

m0, f), uma rede de Petri marked graph temporizada marcada. Seja G(N) = (V, D, h) um

grafo de estados, onde V = S(N). Seja s = (m, n, r) o estado s da Rede de Petri

temporizada N, s ∈ S(N). Seja VARIAVEL = {substringj | j ∈ +} o conjunto de

variáveis do comportamento. MTVD: S × VARIAVEL → {0,1} é definida como uma

matriz de tempo de vida de variáveis representando a marcação das variáveis em seus

respectivos estados.

Sabemos que em uma unidade de armazenamento só poderá conter variáveis nas

quais não há sobreposição de seus tempos de vida. Assim será necessário definir o que é

não-sobreposição.

___________________________________________________________________

88

Definição 5.7 – Não-Sobreposição: Seja MTVD uma matriz de tempo de vida

de variáveis. Dizemos que o tempo de vida de uma variável vi não se sobrepõe ao tempo

de vida de uma variável vj sse não estiverem marcadas no mesmo estado, ou seja, se

MTVD[sk, vi] = 1 ⇒ MTVD[sk, vj] = 0 ∨ se MTVD[sk, vi] = 0 ⇒ MTVD[sk, vj] = 1, ∀ sk ∈

S(N) ∧ ∀ vi, vj ∈ VARIAVEL.

A partir da MTVD (matriz de tempo de vida das variáveis) será feita a atribuição

das variáveis às unidades de armazenamento quando satisfeita a condição de não-

sobreposição dos tempos de vida das variáveis.

Definição 5.8 – Unidade de Armazenamento: Seja VARIAVEL = {substringj |

j ∈ +} o conjunto de variáveis do comportamento. Seja MTVD uma matriz de tempo

de vida de variáveis. REG = {substringm | m ∈ +} é definido como uma unidade de

armazenamento obtida a partir de MTVD, na qual seus elementos são variáveis que não

apresentam sobreposição dos seus tempos de vida, onde REG ⊆ VARIAVEL.

O número de unidades de armazenamento é obtido pela cardinalidade do

conjunto das unidades de armazenamento somado à cardinalidade do conjunto de

literais.

Definição 5.9 – Número de Unidades de Armazenamento: Seja REG =

{substringm | m ∈ } uma unidade de armazenamento. REGISTRADORES = {REGi | i

∈ +} é definido como o conjunto das unidades de armazenamento.

NREGISTRADORES = # REGISTRADORES + # LIT nos dá o número de Unidades de

Armazenamento necessário para implementar o comportamento de uma determinada

especificação.

5.4.3 Número e Tipo de Unidades Funcionais

O número requerido de unidades funcionais pode ser estimado de diversas

maneiras. Primeiro, o projetista do sistema pode especificar a alocação das unidades

funcionais explicitamente. Segundo, no caso em que o comportamento já tenha sido

escalonado em passos de controle, uma abordagem baseada em clique partitioning [68]

___________________________________________________________________

89

pode ser usada para determinar o número de unidades funcionais requeridas.

Finalmente, se uma restrição de desempenho (como o número máximo de passos de

controle) é especificada para o comportamento, o número mínimo de unidades

funcionais requerida para implementar o comportamento pode ser determinado usando o

algoritmo force-directed [56]. Nestas e em outras abordagens encontradas são utilizados

modelos de grafos de controle/dados, veja maiores detalhes no Capítulos 2 e 3.

Na abordagem proposta, como o modelo de fluxo dados é uma rede de Petri

marked-graph temporizada, o comportamento é escalonado em estados (ciclos de clock,

passos de controle em outros modelos) quando da geração do grafo de estados para a

rede. Neste caso, precisamos saber em qual estado acontece o disparo das transições que

modelam operações lógicas aritméticas. Diferentemente do clique partitioning, a

abordagem proposta requer a amarração das unidades funcionais, i.e., a atribuição de

operações às unidades funcionais específicas. Tal mapeamento é essencial, dado que

nos possibilita determinar o número de interconexões necessário entre as unidades de

armazenamento e unidades funcionais.

O estado s de uma rede de Petri temporizada é uma tupla s = (m, n, r), detalhes

no Capítulo 3. A Tabela 5.2 apresenta o conjunto de estados alcançáveis para ΓΓ1. A

coluna h(si), como já vimos, é o menor tempo remanescente no estado si. No início do

estado s3 foram disparadas as transições t4, t8 e t12 (coluna gk em s3) com tempos de

disparo f iguais a 15, 0 e 0 respectivamente (ver Figura 5.5). Logo que t8 e t12 terminam

seus disparos, pois apresentam o menor tempo remanescente entre as transições (r(t8) =

r(t12) = h(s3) = 0) , fichas são colocadas nos lugares de saída destas transições (p15, p16,

p19 e p20), que juntamente com o lugar p1 (coluna mi do estado s3) representam a

mudança para o estado s4. Neste estado, a transição t16 torna-se habilitada. Com o

disparo de t16, a coluna ni mostra que o estado s4 acumula dois disparos, um disparo de

t16 e outro disparo de t4. O tempo remanescente de t4 continua sendo 15 (tempo total de

execução da mesma), já que os tempos decorridos dos disparos das transições anteriores

foram zero. A transição t16 (com menor tempo remanescente, r(t16) = 0) conclui seu

disparo e como é uma transição do tipo sink (não possui lugares de saída, só consome as

fichas) não houve mudança na marcação dos lugares. Finalmente, a transição t4 (neste

___________________________________________________________________

90

momento a única transição que não conclui seu disparo, r(t4) = 15 e ni (t4) = 1, logo

h(s4) = r(t4) que é igual a 15) finaliza seu disparo. Neste caso em particular o tempo

remanescente coincide com o tempo de execução, pois não houve tempo efetivo de

consumo nas transições anteriores. Após o término do disparo da transição t4 o estado s5

é atingido, decorrido 15 unidades de tempo.

Para definirmos o tempo inicial acumulado de disparo de cada transição lógica

aritmética procedemos da mesma forma utilizada para as variáveis simultaneamente

vivas (Seção 5.3.1). No caso das variáveis verificamos o estado onde a mesma está

marcada (viva), aqui precisamos definir o estado onde a transição foi disparada. Por

exemplo, pela coluna gk da Tabela 5.2, as transições t4, t9 e t14 (que modelam a operação

aritmética soma) foram disparadas a partir dos estados s3, s7 e s10, respectivamente. Pela

Tabela 5.3 (construída para o cálculo de unidades de armazenamento) estes estados têm

tempos iniciais de 0, 15 e 30, nesta ordem. Desta forma, as transições t4, t9 e t14

apresentam tempo iniciais de disparo de 0, 15 e 30. Somando-se o tempo inicial de

disparo com o tempo de duração do disparo da transição obtemos o tempo final de

disparo, assim os tempos finais de disparo destas transições são 15, 30 e 45 unidades de

tempo, respectivamente. A Figura 5.8 mostra estas transições escalonadas por estados,

onde ocorreram os respectivos disparos.

Figura 5.8: Transições escalonadas por estados para Γ1.

Pela Figura 5.8, observamos que não há sobreposição dos intervalos de tempos

dos disparos das transições, logo, para executar este comportamento será necessário um

único somador.

___________________________________________________________________

91

A Tabela 5.5 mostra o mapeamento das transições t4, t9 e t14 à unidade funcional

UF1 que realiza a operação soma.

Tabela 5.5: Mapeamento das transições às unidades funcionais para Γ1

t4 t9 t14

UF 1 x x x

Unidades Funcionais

Transições atribuídas

A seguir descrevemos uma abordagem formal para o método descrito.

Definição 5.10 – Conjunto de Transições e Operações Lógicas/Aritméticas:

Seja N = (P, T, A, ω, m0, f), uma rede de Petri marked graph temporizada. Seja l uma

função injetora de nomeação. TLA = {th, ..., tl, ..., tn} é definido como o conjunto de

transições lógicas/aritméticas, onde l: TLA = OPLA, onde TLA ⊂ T. OPLA = {+ , −, ∗,

/, >, >=, =, <=, <} é definido como o conjunto de operações lógicas/aritméticas.

Após definirmos as transições lógicas/aritméticas é preciso mapear os disparos

iniciais de cada transição no grafo de estados.

Definição 5.11 – Matriz de Disparo de Transições: Seja N = (P, T, A, ω, m0,

f), uma rede de Petri marked graph temporizada. Seja G(N) = (V, D, h) um grafo de

estados, onde V = S(N). Seja s = (m, n, r) um estado de N (s ∈ S(N)). Seja TLA o

conjunto de transições lógicas aritméticas. MDT: TLA × S → {0,1} é uma matriz de

disparo de transições representando o estado onde ocorreu o disparo de cada transição,

onde MDT [tj, sk] = 1 sse tj é disparada no estado sk, ∀ sk ∈ S(N) ∧ ∀ tj ∈ TLA.

Para sabermos se o intervalo de duração do disparo de determinada transição

não se sobrepõe ao de outra transição é necessário definirmos os tempos iniciais e finais

acumulados de cada transição que modela uma operação lógica/aritmética.

Definição 5.12 – Função de Tempo: Seja TLA o conjunto de transições lógicas

aritméticas. τ é uma função de tempo que atribui a cada transição lógica aritmética o par

tempo de disparo inicial e final, τ: TLA = + ∪ {0}× + ∪ {0}, portanto τ(tj) = (tincio,

tfinal) onde τ(tj).tincio é igual ao tempo acumulado do estado onde ocorreu o disparo da

transição tj e τ(tj).tfinal = τ(tj).tincio + f (tj), ∀ tj ∈ TLA.

___________________________________________________________________

92

Definição 5.13 – Não-Sobreposição do Disparo Seja TLA o conjunto de

transições lógicas aritméticas. Dizemos que a duração de disparo de uma transição ti não

se sobrepõe à duração de disparo de uma transição tj sse τ(ti).τfinal ≤ τ(tj).τincio ∨ τ(tj).τfinal

≤ τ( ti).τincio, onde ti e tj ∈ TLA.

Agora definimos um conjunto que agrupa as transições cuja duração dos seus

disparos não se sobrepõem.

Definição 5.14 – Conjunto de Transições Funcionais: Seja TLA o conjunto de

transições lógicas aritméticas. Seja MDT a matriz de disparo das transições. CTFi = {th,

..., tl, ..., tn} é definido como um conjunto de transições funcionais, obtido a partir de

MDT, representando o conjunto das transições lógicas/aritméticas cuja duração dos

respectivos disparos não se sobrepõem, onde CTF ⊆ TLA.

Definido o conjunto de transições funcionais, precisamos definir conjuntos que

modelam operações específicas.

Definição 5.15 – Tipos de Conjuntos de Transições Funcionais: Seja CTFi

{th, ..., tl, ..., tn} um conjunto de transições funcionais. Seja l uma função de marcação,

onde l(t) ∈ OPLA, ∀ t ∈ CTFi. Um CTF_SOMADORj = {x | x ∈ CTFi ∧ l(x) = +} é o

conjunto de transições que modelam a operação soma. Um CTF_SUBTRATORm = {x | x

∈ CTFi ∧ l(x) = −} é o conjunto de transições que modelam a operação subtração. Um

CTF_MULTIPLICADORn = {x | x ∈ CTFi ∧ l(x) = ∗} é o conjunto de transições que

modelam a operação multiplicação. Um CTF_DIVISORr = {x | x ∈ CTFi ∧ l(x) = /} é o

conjunto de transições que modelam a operação divisão. Uma CTF_ULAs = {x | x ∈

CTFi ∧ l(x) ∈ {+, −}} é o conjunto de transições que modelam as operações soma e

divisão. Um CTF_COMPARADORt = {x | x ∈ CTFi ∧ l(x) ∈ {>, >=, =, <=, <}} é o

conjunto de transições que modelam as operações maior, maior ou igual, igual, menor

ou igual e menor. CTF_SOMADORj, CTF_SUBTRATORm, CTF_MULTIPLICADORn,

CTF_DIVISORr, CTF_ULAs e CTF_COMPARADORt são definidos como tipos de

conjuntos de transições funcionais, onde i, j, m, n, r, s, t ∈ +.

Definido os conjuntos cujas transições modelam operações específicas,

precisamos agrupar estes conjuntos, definindo conjuntos de conjuntos, e determinar a

___________________________________________________________________

93

cardinalidade dos mesmos. Cada agrupamento de conjuntos definirá um tipo de unidade

funcional (somador, ULA, etc.) e a cardinalidade deste conjunto nos dá o número de

unidades funcionais de determinado tipo no projeto.

Definição 5.16 – Conjunto dos Conjuntos de Transições Funcionais: Sejam

CTF_SOMADORj, CTF_SUBTRATORm, CTF_MULTIPLICADORn, CTF_DIVISORr,

CTF_ULAs e CTF_COMPARADORt tipos de conjuntos de transições funcionais.

CTF_SOMADORES = Uj CTF_SOMADORj é o conjunto dos conjuntos de transições

que modelam a operação soma. CTF_SUBTRATORES = Um CTF_SUBTRATORm é o

conjunto dos conjuntos de transições que modelam a operação soma.

CTF_MULTIPLICADORES = Un CTF_MULTIPLICADORn é o conjunto dos conjuntos

de transições que modelam a operação multiplicação. CTF_DIVISORES = Ur

CTF_DIVISORr é o conjunto dos conjuntos de transições que modelam a operação

divisão. CTF_ULAS = Us CTF_ULAs é o conjunto dos conjuntos de transições que

modelam as operações soma e subtração. CTF_COMPARADORES = Ut

CTF_COMPARADORt é o conjunto dos conjuntos de transições que modelam as

operações maior, maior ou igual, igual, menor ou igual e menor, onde o símbolo U (big

cup) resulta na união do conjunto de conjuntos tal que i, j, m, n, r, s, t ∈ +.

Definição 5.17 – Número e Tipos de Unidades Funcionais: Sejam

CTF_SOMADORES, CTF_SUBTRATORES, CTF_MULTIPLICADORES,

CTF_DIVISORES, CTF_ULAS, CTF_COMPARADORES os conjuntos dos conjuntos de

transições funcionais. NCTF_SOMADORES = # CTF_SOMADORES,

NCTF_SUBTRATORES = # CTF_SUBTRATORES, NCTF_MULTIPLICADORES = #

CTF_MULTIPLICADORES, NCTF_DIVISORES = # CTF_DIVISORES, NCTF_ULAS

= # CTF_ULAS, NCTF_COMPARADORES = # CTF_COMPARADORES, nos dá o

número e tipos das Unidades Funcionais necessários para implementar o

comportamento de determinada especificação.

A abordagem proposta tem como objetivo minimizar o número de unidades

funcionais a serem utilizadas em determinado comportamento. O algoritmo proposto é:

___________________________________________________________________

94

• Entrada: ΓΓ( M, f) uma rede marked-graph temporizada marcada onde M =

(N, m0) é a rede marcada e N = (P, T, A, ω) a estrutura da rede.

• Saída: O número de unidades funcionais para cada operação lógica

aritmética necessária para realizar a especificação (NCTF_SOMADORES,

NCTF_SUBTRATORES, NCTF_MULTIPLICADORES, NCTF_DIVISORES,

NCTF_ULAS, NCTF_COMPARADORES ).

Passos:

I. Compute o grafo de estados

II. Para cada estado obtenha o tempo inicial acumulado dos mesmos de acordo com a

coluna h(si) na Tabela 5.2.

III. Para cada transição o tempo de disparo inicial será igual ao do respectivo estado

onde se iniciou o disparo. Obtenha o tempo final de disparo, que será a soma do

tempo inicial do disparo com a duração do disparo (f(ti)) da respectiva transição.

IV. Ordene, em uma lista L, o conjunto de transições lógicas/aritméticas de acordo com

o tempo de disparo inicial de cada transição.

V. Para cada subconjunto definido de operações representando unidades funcionais

(somadores, ULA’s, etc.), aloque uma unidade funcional UFk e tente atribuir à

mesma transições da lista L que pertençam ao subconjunto definido. No primeiro

passo atribua a UFk uma primeira transição e busque na lista L novas transições que

não apresentem sobreposição dos intervalos de tempo de execução. Elimine da lista

L as transições do conjunto UFk.

VI. Nos demais passos são feitas novas alocações de unidades funcionais e atribuídas às

mesmas transições onde os intervalos de tempo de execução não se sobrepõem. O

algoritmo termina quando a lista L fica vazia.

VII. Calcule o número de unidades funcionais necessárias de acordo com os

subconjuntos definidos inicialmente e obtidos da lista L.

___________________________________________________________________

95

A complexidade para a geração do grafo de estados da rede é O(K), K = { x | x ∈

• + ∧ 1 ≤ x ≤ T}. Para a definição dos intervalos de disparos das transições a

complexidade é O(K*T). Para a construção da lista ordenada de transições é

O(TLA*logTLA) e finalmente para mapear as transições às unidades funcionais é

O(TLA*UF), UF = { y | y ∈ • + ∧ 1 ≤ y ≤ TLA}. Onde T representa o conjunto de

transições, K o é conjunto de estados gerados, TLA ⊂ T é o conjunto de transições

lógica/aritméticas e UF é o conjunto de unidades funcionais. Logo, a complexidade da

abordagem proposta para o cálculo das unidades funcionais é O(K + K * T +

TLA*logTLA + TLA*UF).

5.4.4 Número de Unidades de Interconexão (multiplexadores 2××1)

Depois que todas as variáveis e operações tenham sido mapeadas para unidades

de armazenamento e funcionais, podemos estimar o número de unidades de

interconexão (barramentos e/ou multiplexadores), os quais são requeridos para

interconectar as unidades de armazenamento às unidades funcionais.

Na abordagem proposta, estimamos uma implementação com multiplexadores.

Estas unidades de interconexão são estimadas diretamente a partir do modelo de fluxo

de dados temporizados (Figura 5.5) e do mapeamento de variáveis e operações para

unidades de armazenamento e funcionais, respectivamente.

Primeiro, o conjunto de conexões entre as unidades de armazenamento e

funcionais no projeto é determinado. Examinando o comportamento, visto na Figura

5.3, encontramos a instrução C := A + B. Então existe uma conexão das unidades de

armazenamento nas quais as variáveis A e B foram atribuídas com a unidade funcional

que implementa a operação de adição, e outra conexão da unidade funcional à unidade

de armazenamento na qual a variável C foi confinada. No modelo intermediário (Figura

5.5.) a instrução C := A + B é modelada pela transição t4 (t1.+) e pelos lugares p7

(p1.a.1), p9 (p1.b.1) e p12 (p1.c.1).

___________________________________________________________________

96

Como visto no Capítulo 3, Inp(p) e Out(p), denotam os conjuntos das transições

de entrada e saída de um lugar p. Enquanto Inp(t) e Out(t) representam os conjuntos dos

lugares de entrada e saída de uma transição t, respectivamente. Para exemplificar a

abordagem proposta com maiores detalhes, aplicaremos a mesma a um comportamento

fictício (timed Petri net) o qual denominaremos ΓΓ3. A Tabela 5.6 mostra um banco de

registradores com cinco unidades de armazenamento e suas respectivas variáveis

alocadas, obtidos de ΓΓ3.

Tabela 5.6: Mapeamento das variáveis para unidades de armazenamento para Γ3.

R1 a, e, h, jR2 c, g, kR3 b, iR4 d, lR5 f

Unidades de Armazenamento

Variáveis

Na Tabela 5.7, temos o mapeamento das transições às unidades funcionais. As

colunas Inp(t) e Out(Out(Out(t))) mostram os lugares representando variáveis de leitura

e escrita, respectivamente, para cada transição lógica/aritmética. Os dados desta tabela

são obtidos a partir do modelo de fluxo de dados temporizados. Na coluna instruções

são vistos as operações aritméticas executadas por cada unidade funcional. As variáveis,

nestas instruções, foram substituídas pelas suas respectivas unidades de armazenamento,

de acordo com o mapeamento da Tabela 5.6.

Tabela 5.7: Mapeamento das transições (com suas respectivas variáveis de leitura e escrita) e definição das instruções às unidades funcionais em Γ3.

t7 a, f b R3 := R1 + R5t11 e, k l R4 := R1 + R2t9 g, d f R5 := R2 + R4t3 l, b a R1 := R4 + R3

t15 c, i k R2 := R2 + R3t5 e, d f R5 := R1 + R4t1 f, k d R4:= R5 + R2

t23 i, f k R2 := R3 + R5t19 f, a c R2 := R5 + R1

t27 a, i g R2 := R1 * R3t31 c, b i R3 := R2 * R3

UF 1

UF 2

UF 3

+

+

*

Unidades Funcionais

Tipo operação Transições Inp(t) Out(Out(Out(t))) Instruções

___________________________________________________________________

97

A partir destas tabelas podemos determinar o conjunto de conexões entre as

unidades de armazenamento e funcionais no projeto. Cada unidade funcional é

composta de uma lista de conexões. Uma conexão é definida através de três atributos:

unidade de armazenamento (do tipo string, determina a unidade de armazenamento de

entrada de dados), ligação para o lado esquerdo e ligação para o lado direito (ambos

atributos booleanos que indicam a existência de ligações entre a unidade de

armazenamento de entrada e os lados esquerdo e direito da unidade funcional).

A unidade funcional UF1 (ver coluna instruções da Tabela 5.7) apresenta a

seguinte lista de instruções L1 = (R3 := R1 + R5, R4 := R1 + R2, R5 := R2 + R4, R1 := R4 + R3,

R2 := R2 + R3, R5 := R1 + R4 , R4 := R5 + R2). No primeiro passo, criamos para UF1 uma

lista de conexões C1 e duas conexões c1 e c2, logo em seguida anexamos estas duas

conexões à lista C1. Sempre que uma conexão é criada, ambos os atributos booleanos

são inicializados com o valor falso. De posse do primeiro elemento da lista L1 (R3 := R1

+ R5), para a conexão c1, atribuímos ao atributo unidade de armazenamento o valor R1 e

ao atributo ligação para lado esquerdo o valor verdadeiro. Para a conexão c2,

atribuímos ao atributo unidade de armazenamento o valor R5 e ao atributo ligação para

lado direito o valor verdadeiro. Assim, conectando as unidades de armazenamento R1 e

R5 à esquerda e à direita de UF1, respectivamente, é possível realizar a operação

aritmética desta instrução. Para o segundo elemento da lista L1 (R4 := R1 + R2), buscamos

em C1 as conexões que contêm nos atributos unidade de armazenamento os valores R1 e

R2. Verificamos que a condição é verdadeira para a conexão c1 (existe conexão para R1),

portanto cria-se a conexão c3 onde atribuímos o valor de R2 ao atributo unidade de

armazenamento. Com relação aos atributos booleanos, vemos que na conexão c1 o

atributo ligação para lado esquerdo possui valor verdadeiro e c3 os valores das ligações

para os lados esquerdo e direito são falsos. Portanto, é necessário fazer uma ligação da

conexão c3 para o lado direito da unidade funcional para que a operação possa ser

executada. Fazemos isto atribuindo o valor verdadeiro ao atributo ligação para lado

direito da conexão c3. Segue-se similarmente para os demais elementos da lista L1,

levando-se em consideração a existência de conexões para as unidades de

armazenamento e direcionando os atributos booleanos para que as operações possam ser

___________________________________________________________________

98

realizadas. A Tabela 5.8 mostra as conexões que fazem a amarração das unidades de

armazenamento à unidade funcional UF1.

Nos passos seguintes, criamos similarmente as listas de conexões para as outras

unidades funcionais. A Tabela 5.9 e a Tabela 5.10 mostram as conexões das unidades de

armazenamento às unidades funcionais UF2 e UF3, respectivamente.

Tabela 5.8: Conexões das unidades de armazenamento à unidade funcional UF1 em Γ3.

C1 R1 verdadeiro falso

C2 R5 falso verdadeiroC3 R2 verdadeiro verdadeiroC4 R4 verdadeiro verdadeiroC5 R3 verdadeiro verdadeiro

Conexões de entrada UF1 (+)

Unidades armazenamento

ligação p/ lado esquerdo UF1

ligação p/ lado direito UF1

Tabela 5.9: Conexões das unidades de armazenamento à unidade funcional UF2 em Γ3.

C1 R3 verdadeiro falsoC2 R5 falso verdadeiroC3 R1 verdadeiro falso

Conexões de entrada UF2 (+)

Unidades armazenamento

ligação p/ lado esquerdo UF2

ligação p/ lado direito UF2

Tabela 5.10: Conexões das unidades de armazenamento à unidade funcional UF3 em Γ3.

C1 R1 verdadeiro falsoC2 R3 falso verdadeiroC3 R2 verdadeiro falso

Conexões de entrada UF3 (*)

Unidades armazenamento

ligação p/ lado esquerdo UF3

ligação p/ lado direito UF3

A Figura 5.9 mostra o resultado esquemático das linhas de conexões para as

duas entradas (lados esquerdo e direito) das unidades funcionais UF1, UF2 e UF3 do

comportamento da rede de Petri timed fictícia ΓΓ3.

Uma vez que as conexões tenham sido determinadas, elas precisam ser

mapeadas em um multiplexador ou barramento. Uma estratégia simples seria

implementar o conjunto de conexões que são entradas comuns (mesmo lado da unidade

funcional) com o mesmo multiplexador ou barramento.

___________________________________________________________________

99

Figura 5.9: Conexões para as entradas das unidades funcionais: UF1, UF2 e UF3 em ΓΓ3.

Figura 5.10: Implementação para ΓΓ3 com multiplexadores 2 ××1.

A Figura 5.9 mostra que existem quatro conexões para cada entrada da unidade

funcional UF1, logo são necessários dois multiplexadores 4 × 1 ou seis multiplexadores

2 ×1 para implementar estas conexões. Para as unidades funcionais UF2 e UF3, com

duas entradas do lado esquerdo e uma entrada do lado direito é necessário apenas um

multiplexador no lado esquerdo para cada unidade funcional. Figura 5.10 mostra o

resultado da implementação utilizando-se apenas multiplexadores 2 × 1.

Figura 5.11: Conexões fatoradas para as entradas das unidades funcionais: UF1, UF2 e UF3 em ΓΓ3.

___________________________________________________________________

100

A redução no custo dos multiplexadores pode ser obtida pela fatoração das

conexões que apresentam entradas comuns para os diferentes multiplexadores. Insere-se

um multiplexador em separado, o qual servirá como entrada para cada conjunto de

conexões que apresentam entradas comuns. Por exemplo, as conexões c3, c4 e c5 são

entradas comuns para os dois lados da unidade funcional UF1. Estas conexões podem

ser “fatoradas” e implementadas no multiplexador M, como mostrado na Figura 5.11.

Figura 5.12: Redução do número de multiplexadores 2 x 1 por fatoração para ΓΓ3.

Fatorando-se as entradas do multiplexador reduz-se o número total de

multiplexadores do projeto e desta forma o custo dos multiplexadores. A Figura 5.12

mostra o resultado da implementação utilizando a abordagem proposta, foram utilizados

seis multiplexadores 2 × 1. Para realizar a implementação mostrada pela Figura 5.10

foram necessários oito multiplexadores 2 × 1, logo a implementação através da

fatoração apresentou uma redução de 25% na implementação.

Abaixo apresentamos a definição formal do método proposto para estimar o

número de Unidades de Interconexão.

Definição 5.18 – Conjunto de Lugares de Entrada de uma Transição

Lógica/Aritmética: Seja N = (P, T, A, ω, m0, f), uma rede de Petri marked graph

temporizada. Seja TLA = {th, ..., tl, ..., tn} o conjunto de transições lógicas aritméticas.

Seja VAR = {ph, ..., pl, ..., pn} o conjunto de lugares representando variáveis. Seja LIT =

{pk, ..., pj ..., pz} o conjunto de lugares representando literais. LETi (N, ti) = (pn, pm) é

___________________________________________________________________

101

uma tupla composta dos lugares de entrada da transição lógica aritmética ti, onde ti ∈

TLA ⊂ T ∧ ∀p ∈ LETi (N, ti), p ∈ VAR ∨ p ∈ LIT.

Definição 5.19 – Conjunto de constantes: Seja N = (P, T, A, ω, m0, f) uma

rede de Petri marked graph temporizada. Seja LIT = {pk, ..., pj ..., pz} o conjunto de

lugares representando literais. Seja l uma função de nomeação dos conjuntos de lugares

e transições com nomes significativos, l : P ∪ T → L , onde L = {string1, string2,...} ∧

l(p) = pr.val[k] ∀ p ∈ LIT. l : LIT→ LITC , onde LITC = {pr.val[k] | r,k ∈ +} é o

conjunto de constantes de um determinado comportamento.

Obtido os lugares de entrada das transições lógicas/aritméticas precisamos

identificar as variáveis ou constantes modeladas por estes lugares.

Definição 5.20 – Variáveis e/ou Constantes de Entrada de uma Transição

Lógica/Aritmética: Seja N = (P, T, A, ω, m0, f) uma rede de Petri marked graph

temporizada. Seja VAR = {ph, ..., pl, ..., pn} o conjunto de lugares representando

variáveis. Seja LIT = {pk, ..., pj ..., pz} o conjunto de lugares representando literais. Seja

LETi (N, ti) = (pn, pm) uma tupla dos lugares de entrada da transição lógica aritmética ti,

onde, pn, pm ∈ VAR ∨ pn, pm ∈ LIT. Seja l uma função de nomeação dos conjuntos de

lugares e transições com nomes significativos, l : P ∪ T → L , onde L = {string1,

string2,...} ∧ l (p) = pr.substrings.t ∀ pn ∈ VAR ∧ l (p) = pr.val[k] ∀ p ∈ LIT. Seja LITC

= {pr.val[k] | r,k ∈ +} o conjunto de constantes de um determinado comportamento.

VCETi(N, ti) = (x, y) é uma dupla de variáveis e/ou constantes de entrada de uma

transição lógica/aritmética, onde (x = pr.substrings.t ∨ x = pr.val[k]) ∧ (y = pr.substrings.t

∨ y = pr.val[k]) ∧ l(pn) = x ∧ l(pm) = y ∧ pn ∈ LETi (N, ti) ∧ pm = LETi(N, ti).

Identificadas as variáveis e/ou constantes modeladas pelos lugares de entrada

das transições lógicas/aritméticas precisamos saber em quais unidades de

armazenamento estes lugares formam mapeados.

Definição 5.21 – Unidades de Armazenamento de Entrada de uma

Transição Lógica/Aritmética: Seja N = (P, T, A, ω, m0, f) uma rede de Petri marked

graph temporizada. Seja VCETi(N, ti) = (x, y) uma dupla de variáveis e/ou constantes de

___________________________________________________________________

102

entrada de uma transição lógica/aritmética. Seja REGISTRADORES = {REGi | i ∈ +}

o conjunto das unidades de armazenamento, onde REGk = {substringm | m, k ∈ +}.

Seja LITC = {pr.val[k] | r,k ∈ +} o conjunto de constantes. UAETi(N, ti) = (m, n) é

uma tupla composta de unidades de armazenamento de entrada de uma transição

lógica/aritmética, onde (m ∈ REGISTRADORES ∨ m = LITC) ∧ (n ∈

REGISTRADORES ∨ n = LITC) ∧ x ∈ m ∧ y ∈ n.

A partir desta definição obtemos os registradores de entrada (armazenam

variáveis ou constantes) para cada transição lógica aritmética da rede.

Definição 5.22 – Conjunto de Pares de Registradores das Transições

Funcionais: Seja N = (P, T, A, ω, m0, f), uma rede de Petri marked graph temporizada.

Seja CTFi = {th, ..., tl, ..., tn} o conjunto de transições funcionais. Seja UAETi(N, ti) =

(m, n) uma tupla composta de unidades de armazenamento de entrada de uma transição

ti lógica/aritmética. CPRTFi(N, CTFi) = {x | x = UAETi(N, ti) ∧ ti ∈ CTFi} é o conjunto

de pares de registradores das transições funcionais.

Desta forma obtemos todos os pares de registradores (de variáveis ou

constantes) para cada conjunto de transições funcionais. O passo seguinte é a obtenção

do conjunto de conexões das unidades de armazenamento ao conjunto de transições

funcionais, antes definiremos uma função que retorne os elementos de uma tupla.

Definição 5.23 – Função Primeiro, Segundo e Terceiro: Seja K = (x, y, z) uma

tupla de elementos quaisquer, primeiro(K) = x, segundo(K) = y e terceiro(K) = z

retornam o primeiro, o segundo e o terceiro elemento de uma tupla, respectivamente.

Definição 5.24 – Conjunto de Conexões de um Conjunto de Transições

Funcionais: Seja N = (P, T, A, ω, m0, f), uma rede de Petri marked graph temporizada.

Sejam primeiro, segundo e terceiro funções que retornam o primeiro, o segundo e o

terceiro elemento de uma tupla, respectivamente. Seja CPRTFi(N, CTFi) = {r | r =

UAETi(N, ti) ∧ ti ∈ CTFi} o conjunto de pares de registradores de CTFi. Uma conexão

ck = (x, y, z) é uma tupla, onde x é uma unidade de armazenamento, y e z são atributos

booleanos que indicam se x tem ligações com os lados esquerdo e direito de CTFi,

___________________________________________________________________

103

respectivamente. CONEXÕES(N, CTFi) = {ck | k ∈ +} é o conjunto de conexões de um

conjunto de transições funcionais, onde primeiro(ck) = primeiro(r) ∨ primeiro(ck) =

segundo(r) ∧ r ∈ CPRTFi(N, CTFi) ∧ primeiro(ck) ≠ primeiro(cj) ∀ c ∈

CONEXÕES(N, CTFi).

A partir desta definição obtemos o conjunto das conexões entre as unidades de

armazenamento (de variáveis e/ou constantes) aos lados direito e/ou esquerdo do

conjunto de unidades funcionais.

Definição 5.25 – Função de Ligação: Seja ck = (x, y, z) uma conexão. link é

uma função de ligação que atribui a ck uma tupla de valor booleano, link(ck) = (a,b),

onde (a = verdadeiro ∨ a = falso) ∧ (b = verdadeiro ∨ b = falso) ∧ y = a ∧ z = b.

Através da função link é possível modelar as instruções lógica/aritméticas no

conjunto de transições funcionais. Por exemplo, se em uma conexão a e b forem

verdadeiros, significa que a unidade de armazenamento x possui ligações à direita e à

esquerda do conjunto de transições funcionais.

Definição 5.26 – Número de Unidades de Interconexão: Seja N = (P, T, A, ω,

m0, f), uma rede de Petri timed marked graph. Seja CTFi = {th, ..., tl, ..., tn} o conjunto

de transições funcionais. Sejam primeiro, segundo e terceiro funções que retornam o

primeiro, o segundo e o terceiro elemento de uma tupla, respectivamente. Seja CTF = Ui

CTFi o conjunto que contém todas os conjuntos de transições funcionais CTFi. Seja ck =

(x, y, z) uma conexão. Seja CONEXÕES (N, CTFi) = {ck | k ∈ +} o conjunto de

conexões de CTFi. CETFi = { r | r ∈ CONEXÕES (N, CTFi) ∧ segundo(r) =

verdadeiro} é o conjunto de conexões com ligações ao lado esquerdo de CTFi. CDTFi

= { s | s ∈ CONEXÕES (N, CTFi) ∧ terceiro(s) = verdadeiro} é o conjunto de conexões

com ligações ao lado direito de CTFi. NMULT2×1i(N, CTFi) = # CETFi + # CDTFi

– 2 determina o número de multiplexadores 2×1 de CTFi. TOTALMULT = 3 i∈{1,2,3 ...

#CTF} NMULT2×1i(N, CTFi) é o número de Unidades de Interconexão (multiplexadores

2×1) necessário para implementar o comportamento de determinada especificação.

___________________________________________________________________

104

A abordagem proposta objetiva minimizar o número de unidades de

interconexão de determinado comportamento. O algoritmo proposto é:

• Entrada: ΓΓ( M, f) uma rede marked-graph temporizada marcada onde M =

(N, m0) é a rede marcada e N = (P, T, A, ω) a estrutura da rede; mapeamento

das variáveis para as unidades de armazenamento e o mapeamento das

transições às unidades funcionais.

• Saída: o número de unidades de interconexão necessárias para realizar a

especificação (TOTALMULT).

Passos:

I. Para cada conjunto de transições funcionais CTFi obter a lista de transições Li.

II. Para cada transição t da lista Li obter os lugares que modelam as variáveis e/ou

constantes de leitura (inp(t)) e variáveis de escrita (Out(Out(Out(t)))) no modelo

intermediário – modelo de fluxo de dados temporizados.

III. Para cada variável e/ou constante de leitura (vi e vj) e variável de escrita (vk) obter

suas respectivas unidades de armazenamento Ri, Rj e Rk.

IV. Montar a lista de operações Lopi = { Rk := Ri op Rj, . . . } para cada conjunto de

transições funcionais, com base na operação lógica aritmética modelada pela

transição t e suas respectivas unidades de armazenamento de leitura e escrita.

V. A cada passo, para cada elemento da lista Lop, verificar a necessidade de criação de

novas conexões. Para cada conexão ci existente mapear os atributos unidade de

armazenamento, ligação para lado esquerdo e ligação para lado direito para que a

operação lógica aritmética possa ser executada. Desta forma obtemos o conjunto de

conexões para cada conjunto de transições funcionais.

VI. Para as conexões que são entradas comuns para os dois lados do conjunto de

transições funcionais, proceder com o processo de fatoração. Desta forma

diminuímos a quantidade de multiplexadores no projeto.

VII. A quantidade de multiplexadores 2×1 para cada unidade funcional é obtida pelo

número de conexões – 2 e o total de multiplexadores 2×1 pelo somatório.

___________________________________________________________________

105

A complexidade para a obtenção das variáveis e/ou constantes de entrada de

cada transição lógica/aritmética é O(TLA*P). Para a determinação do conjunto de pares

de registradores de cada unidade funcional – lista de operações LOPi é O(V*R), R = { y

| y ∈ • + ∧ 1 ≤ y ≤ V}. Para determinar o conjunto de conexões Ci de cada unidade

funcional a complexidade é O(LOP* C). Onde P é o conjunto de lugares, TLA ⊂ T é o

conjunto de transições lógica/aritméticas, V ⊂ P é o conjunto de variáveis e R é o

conjunto de registradores, LOP é o conjunto de pares de registradores e C é o conjunto

de conexões. Logo, a complexidade da abordagem proposta para o cálculo das unidades

de interconexão é O(TLA*P + V*R + LOP* C).

Agora vamos aplicar o algoritmo proposto acima à Rede de Petri temporizada

ΓΓ1 (modelo utilizado para demonstrar nossa abordagem), mostrada pela Figura 5.5. As

duas entradas restantes: mapeamento das variáveis para as unidades de armazenamento

e das transições para as unidades funcionais é dada pela Tabela 5.4 e pela Tabela 5.5,

respectivamente. De acordo com a Tabela 5.5, a lista de transições para a única unidade

funcional do projeto UF1 é L1 = {t4, t9, t14}. A Tabela 5.11 mostra os lugares que

modelam as variáveis de leitura (coluna Inp(t)) e escrita (coluna Out(Out(Out(t))))

obtidos a partir do modelo intermediário de fluxo de dados temporizados (Figura 5.5),

bem como a lista de operações Lop1 = {R3:= R1 + R2, R2:= R2 + R3, R2:= R1 + R2} com

suas respectivas unidades de armazenamento de entrada e escrita, já mapeadas com base

na Tabela 5.4.

Tabela 5.11: Mapeamento das transições à unidade funcional UF1 e suas respectivas instruções aritméticas para Γ1.

t4 a, b c R3 := R1 + R2t9 b, c d R2 := R2 + R3

t14 a, d b R2 := R1 + R2UF 1 +

Unidades Funcionais

Tipo operação

Out(Out(Out(t))) InstruçõesTransições Inp(t)

Tabela 5.12: Conexões unidades armazenamento com a unidade funcional UF1 para Γ1.

C1 R1 sim nãoC2 R2 não simC3 R3 sim não

Conexões de entrada UF1 (+)

Unidades armazenamento

link p/ lado esquerdo UF1

link p/ lado direito UF1

___________________________________________________________________

106

Após a execução dos passos sobre a lista Lop1 obtemos o conjunto de conexões

mostrado na Tabela 5.12. Estas linhas de conexões para as duas entradas da unidade

funcional UF1 é melhor visualizada pelo esquemático da Figura 5.13(a). O projeto final

do caminho de dados (unidades de armazenamento, funcionais e de armazenamento –

multiplexadores 2×1) é visto na Figura 5.13(b). Finalizando, para a o comportamento

mostrado na Figura 5.3, o qual foi traduzido para um modelo intermediário em redes de

Petri temporizada (timed) ΓΓ1 mostrado pela Figura 5.5, foi gerada uma estimativa para

uma implementação do caminho de dados de três unidades de armazenamento, um

multiplexador 2×1 e uma unidade funcional (somador). O próximo passo é obter a

estimativa de área de acordo com tecnologia a ser utilizada, FPGAs, full custom entre

outras.

Figura 5.13: (a) Conexões para as duas entrada da unidade funcional (b) Implementação do projeto final para ΓΓ1.

5.4.5 Área do Caminho de Dados

Depois da descrição dos métodos para estimar as unidades de armazenamento,

funcionais e de interconexão no caminho de dados, veremos agora como calcular a área

total do mesmo. Para determinar a área do caminho de dados é necessário calcular as

áreas das unidades que o constitui e depois realizar somatório das mesmas. A seguir

definiremos formalmente a área de cada unidade.

A área das unidades funcionais é calculada levando-se em consideração o

número de unidades funcionais de determinado tipo vezes a área associada ao operador

que implementa esta operação. Realiza-se o somatório para cada processo dentro do

___________________________________________________________________

107

conjunto de processos NS (Net Set – conjunto de sub-redes modelando processos) da

especificação.

Definição 5.27 – Área das unidades funcionais: Seja FUN(NS, opl) o número

unidades funcionais do tipo opl relativo a um conjunto de processos NS. Seja OPS(NS) o

conjunto de tipos de operações distintas no conjunto de processos NS. Seja opj uma

operação dentro de uma expressão lógica aritmética e. AHUF(NS) = 3 ∀opl∈OPS(NS)

FUN(NS, opl) × AHopl nos dá a área das unidade funcionais que executam um conjunto

de processos, onde AHopl é a área associada ao operador que implementa uma operação

do tipo opl, considerando o tipo de dado fornecido (número de bits).

A área total de leitura/escrita necessária para implementar as unidades de

armazenamento é estimada levando em consideração o produto do número de bits de

cada unidade de armazenamento (usada para mapear um subconjunto ou todas as

variáveis do conjunto de processos NS) pela área de hardware necessária para

implementar uma unidade de armazenamento de um bit. Realiza-se o somatório para

cada elemento do conjunto de unidades de armazenamento que implementa NS.

Definição 5.28 – Área das unidades de armazenamento: Seja VS(NS) o

conjunto de todas as variáveis utilizadas no conjunto de processos NS = {pro, ..., pri, ...,

prn}. Seja RS(NS) o conjunto de todas as unidades de armazenamento necessárias para

implementar este conjunto de variáveis. Seja NOB(Ri) o número de bits de uma unidade

de armazenamento Ri ∈ RS(NS) e AHb a área de hardware necessária para implementar

uma unidade de armazenamento de um bit. AHrw(NS) = 3 ∀Ri∈RS(NS) NOB(Ri) × AHb

estima a área de armazenamento de hardware de um conjunto de processos NS.

A área total de multiplexadores de um conjunto de processos simples NS é

estimada através do somatório da área do multiplexador de cada processo membro do

conjunto NS. A área de um multiplexador é calculada multiplicando a área de um

multiplexador 2 x 1 de um bit pela largura da palavra.

Definição 5.29 – Área das unidades de interconexão (multiplexadores): Seja

NS = {pro, ..., pri, ..., prn} um conjunto de processo simples. Seja MS(NS) o conjunto de

todas os multiplexadores 2×1 utilizadas no conjunto de processos NS. Seja NOB(Mi) o

___________________________________________________________________

108

número de bits de um multiplexador 2×1. Mi ∈ MS(NS) e AM1 a área de hardware

necessária para implementar um multiplexador 2×1 de um bit. AHM2×1(NS) = 3 ∀Mi∈MS(NS)

NOB(Mi) × AM1 estima a área de multiplexadores 2×1 de um dado conjunto de

processos simples NS.

Definição 5.30 – Área do data-path: Seja AHop(NS), AHrw(NS) e AHm(NS) as

áreas das unidades funcionais, de armazenamento e de interconexão (multiplexadores),

respectivamente. AHdp = AHop(NS) + AHrw(NS) + AHM2×1(NS) estima a área do caminho

de dados de um conjunto de processos simples NS.

5.5 Conclusões

Neste capítulo foi apresentada a abordagem para o cálculo da estimativa de área

do caminho de dados: unidades de armazenamento, funcionais e de interconexão.

Vimos que o modelo intermediário baseado em redes de Petri temporizadas é obtido

pela tradução de uma especificação em occam. O sistema de estimativa de área de

hardware implementado neste trabalho é baseado em diversos métodos para o cálculo da

área de cada componente do caminho de dados. Para as unidades de armazenamento foi

utilizado dois métodos: o método baseado nas variáveis simultaneamente “vivas” e o

método baseado nos tempos de vida das variáveis. O primeiro método é mais simples e

é baseado na contagem das variáveis simultaneamente vivas em cada estado do grafo de

alcançabilidade, gerado a partir do modelo intermediário pela ferramenta INA. O(os)

estado(s) com o maior número de variáveis simultaneamente vivas são selecionados. O

número destas variáveis nestes estados determina o limite inferior das unidades de

armazenamento do projeto. O segundo método é baseado na sobreposição do tempo de

vida das variáveis, isto é, se os tempos de vida de duas variáveis não se sobrepõem, as

mesmas podem ocupar a mesma unidade de armazenamento. O segundo método foi

escolhido pois para o cálculo dos multiplexadores é necessário definir em quais

unidades de armazenamento as variáveis foram alocadas.

___________________________________________________________________

109

Para as unidades funcionais a metodologia proposta é baseada na sobreposição

dos intervalos dos tempos de execução das transições que modelam operações lógicas e

aritméticas, isto é, se os intervalos de tempo de execução de duas transições

lógicas/aritméticas não se sobrepõem, as mesmas podem ocupar a mesma unidade

funcional daquela operação específica. Desta forma obtemos as unidades funcionais

necessárias ao projeto.

Definido o mapeamento das variáveis às unidades de armazenamento e das

transições lógicas e aritméticas às unidades funcionais é possível determinar o número

de unidades de interconexão. A metodologia proposta é definir as conexões com base

nestes dois mapeamentos e no modelo intermediário (onde é modelada a ligação das

variáveis às transições lógicas aritméticas/aritméticas). Substituindo-se as variáveis por

unidades de armazenamento e as transições por unidades funcionais estabelecemos as

conexões entre as unidades de armazenamento e funcionais. Com base no número de

conexões calculamos o número de multiplexadores 2×1.

Com posse do número e tipo de cada componente do caminho dados calcula-se a

área, em função do o estilo de projeto definido, para cada componente. A área total é

obtida pelo somatório da área de cada componente.

6 Estudos de casos

Neste capítulo, objetivando a validação da metodologia proposta, são apresentados os resultados de estimativas de área de hardware (caminho de dados) com base em quatro aplicações: um pequeno exemplo, Equação Diferencial de 2a Ordem, Filtro de Ondas Elíptico de 5a Ordem e finalmente a uma máquina de refrigerantes. Inicialmente, será feita uma breve descrição de cada sistema. A seguir, são apresentados os resultados da estimativa de área do caminho de dados. Finalmente os dados são comparados com implementações reais e/ou estimativas realizadas por outras abordagens.

6.1 Um Pequeno Exemplo

Nesta seção, tomamos o comportamento escalonado e tempo de vida das

variáveis (ver Figura 6.1) o qual chamamos de pequeno exemplo e aplicamos a

metodologia proposta para estimarmos o caminho de dados – unidades funcionais, de

armazenamento e de interconexão (multiplexadores 2×1).

6.1.1 Descrição

O pequeno exemplo é utilizado de forma didática, para demonstrar a abordagem

da metodologia clique partitioning em [21]. O comportamento do pequeno exemplo

apresenta onze variáveis escalonadas em expressões entre cinco estados. A partir deste

escalonamento foi gerado o código em occam de forma a representar este

comportamento, conforme visto na Figura 6.2. Finalmente, geramos o caminho de

dados utilizando-se unidades lógica/aritméticas (ALU’s) combinadas com componentes

específicos (executam uma única operação – somador, multiplicador, etc.).

___________________________________________________________________

111

+

++

Figura 6.1: Comportamento escalonado e tempo de vida das variáveis

PAR INT v1,v2,v3,v4,v5,v6,v7,v8,v9,v10,v11: SEQ v3:=v1+v2 PAR v5:=v6*v3 v7:=v3-v4 PAR v11:=v10*v5 v8:=v5+v3 v9:=v7+v1 PAR v1:=v11-v8 v2:=v8*v9 Figura 6.2: Descrição em occam do pequeno exemplo

6.1.2 Unidades de Armazenamento

Nesta seção utilizaremos dois métodos: o método baseado na análise das

variáveis simultaneamente vivas por estados e o método baseado nos tempos de vidas

das variáveis. O segundo método é uma continuação do primeiro, onde é feito o

mapeamento das variáveis nas unidades de armazenamento.

6.1.2.1 Método Baseado na Análise das Variáveis Simultaneamente Vivas.

O primeiro passo é traduzir a especificação em occam em um modelo

intermediário em redes de Petri. Fazemos isto através do uso da ferramenta depend

desenvolvido por [47] . Desta forma obtemos o modelo visto na Figura 6. 3.

___________________________________________________________________

112

0 :p1 .start

0 : t1 . start

1 :p1 .dum m y

1 :t1 .end

2 :p1 .end

3 :p1 .v1 .0

2 : t1 .c lone

4 :p1 .v2 .0

3 : t1 .c lone

5 :p1 .v3 .0

6 : t1 . s ink

6 :p1 .v4 .0

1 5 : t1 .c lone

7 :p1 .v5 .0

1 3 : t1 . sink

8 :p1 .v6 .0

9 : t1 .c lone

9 :p1 .v7 .0

1 8 : t1 . sink

1 0 :p1 .v8 .0

3 0 : t1 . sink

1 1 :p1 .v9 .0

3 5 : t1 . sink

1 2 :p1 .v1 0 .0

2 1 : t1 .c lone

1 3 :p1 .v1 1 .0

2 5 : t1 . sink

1 4 :p1 .v1 .1

4 : t1 .+

1 5 :p1 .v1 .2

3 2 : t1 .c lone

1 6 :p1 .v2 .1 1 7 :p1 .v2 .2

4 7 : t1 . sink

1 8 :p1 .va l

5 : t1 . :=

1 9 :p1 .v3 .1

1 0 : t1 .c lone

2 0 :p1 .start

7 : t1 . start

2 1 :p1 .dum m y

8 :t1 .end

2 2 :p1 .end

2 3 :p1 .v6 .1

1 1 : t1 .*

2 4 :p1 .v6 .2

2 5 :p1 .v3 .22 6 :p1 .v3 .3

1 4 : t1 .c lone

2 7 :p1 .va l

1 2 : t1 . :=

2 8 :p1 .v5 .1

2 2 : t1 .c lone

2 9 :p1 .v3 .4

1 6 : t1 . - 3 0 :p1 .v3 .5

2 7 : t1 .c lone

3 1 :p1 .v4 .1

3 2 :p1 .v4 .2

3 3 :p1 .va l

1 7 : t1 . :=

3 4 :p1 .v7 .1

3 1 : t1 .c lone

3 5 :p1 .start

1 9 : t1 . start

3 6 :p1 .dum m y

2 0 :t1 .end

3 7 :p1 .end

3 8 :p1 .v1 0 .1

2 3 : t1 .*

3 9 :p1 .v1 0 .2

4 0 :p1 .v5 .24 1 :p1 .v5 .3

2 6 : t1 .c lone

4 2 :p1 .va l

2 4 : t1 . :=

4 3 :p1 .v1 1 .1

3 8 : t1 .c lone

4 4 :p1 .v5 .4

2 8 : t1 .+

4 5 :p1 .v5 .5

4 6 :p1 .v3 .6

4 7 :p1 .v3 .7

4 8 :p1 .va l

2 9 : t1 . :=

4 9 :p1 .v8 .1

3 9 : t1 .c lone

5 0 :p1 .v7 .2

3 3 : t1 .+

5 1 :p1 .v7 .3

5 2 :p1 .v1 .3

5 3 :p1 .v1 .4

4 2 : t1 . sink

5 4 :p1 .va l

3 4 : t1 . :=

5 5 :p1 .v9 .1

4 4 : t1 .c lone

5 6 :p1 .start

3 6 : t1 . start

5 7 :p1 .dum m y

3 7 :t1 .end

5 8 :p1 .end

5 9 :p1 .v1 1 .2

4 0 : t1 . - 6 0 :p1 .v1 1 .3

6 1 :p1 .v8 .26 2 :p1 .v8 .3

4 3 : t1 .c lone

6 3 :p1 .va l

4 1 : t1 . :=

6 4 :p1 .v1 .5

6 5 :p1 .v8 .4

4 5 : t1 .* 6 6 :p1 .v8 .5

6 7 :p1 .v9 .2

6 8 :p1 .v9 .3

6 9 :p1 .va l

4 6 : t1 . :=

7 0 :p1 .v2 .3

Figura 6. 3: Pequeno Exemplo: Modelo Intermediário do Fluxo de Dados

___________________________________________________________________

113

Definido o estilo de projeto adotado para a implementação desta especificação,

associamos tempo (delay) às transições que modelam as operações lógicas/ aritméticas,

obtendo o modelo intermediário (rede de Petri marked-graph temporizada marcada)

utilizado para a geração do grafo de estados da rede. Este grafo apresenta 27 estados.

No Apêndice A disponibilizamos uma versão textual deste grafo (gerada pela

ferramenta INA) para que o leitor possa analisá-lo.

A Tabela 6.1 mostra os estados com o maior número de variáveis

simultaneamente vivas: s2, s3, s6 e s7 com cinco variáveis. Desta forma são estimadas

cinco unidades de armazenamento para a implementação do pequeno exemplo.

Tabela 6.1: Pequeno Exemplo: variáveis simultaneamente vivas por estados

Estadoss 2

s 3

s 6

s 7 v 1 , v 3 , v 4 , v 6 , v 10

v 1 , v 3 , v 4 , v 6 , v 10

Variáveis simutaneamente vivasv 1 , v 2 , v 4 , v 6 , v 10

v 1 , v 2 , v 4 , v 6 , v 10

6.1.2.2 Método Baseado nos Tempos de Vida das Variáveis.

A partir do grafo de estados gerado do modelo de dados, construímos uma

matriz (ver Tabela 6.2) onde identificamos em quais estados as variáveis estão vivas

(marcadas). A seqüência de estados onde a variável é marcada (coluna da matriz)

constitui o tempo de vida da mesma. A coluna Total nos dá a quantidade de variáveis

vivas por estados, total este obtido pelo método da seção anterior. As variáveis que não

apresentam sobreposição dos seus tempos de vida podem ocupar a mesma unidade de

armazenamento, como acontece, por exemplo, com as variáveis v1 e v11. Ocorrendo

sobreposição, as variáveis não podem compartilhar a mesma unidade de

armazenamento, como acontece com a variável v1 e v2. As colunas que apresentam as

mesmas hachuras são as variáveis que não apresentam sobreposição em seus tempos de

vida e que compartilham a mesma unidade de armazenamento.

Após a análise dos tempos de vida das variáveis, obtivemos o resultado final do

mapeamento das variáveis para as unidades de armazenamento (visto na Tabela 6.3).

___________________________________________________________________

114

Nesta tabela observamos que foram necessárias cinco unidades de armazenamento para

mapear todas as variáveis, resultado este que vem corroborar o método anterior.

Tabela 6.2: Pequeno Exemplo: Tempo de vida das variáveis.

v1 v2 v3 v4 v5 v6 v7 v8 v9 v10 v11S1 0S2 • • • • • 5S3 • • • • • 5S4 • • • • 4S5 • • • • 4S6 • • • • • 5S7 • • • • • 5S8 • • • • 4S9 • • • 3S10 • • • • 4S11 • • • • 4S12 • • 2S13 • • • 3S14 • • • 3S15 • • 2S16 0S17 • 1S18 • 1S19 • • 2S20 • • 2S21 • • 2S22 • 1S23 • • 2S24 • • 2S25 0S26 0S27 0

TotalVariáveisEstados

Tabela 6.3: Pequeno Exemplo: Resultado final do mapeamento das variáveis para os registradores

v1 v2 v3 v4 v5 v6 v7 v8 v9 v10 v11R1 • • • •R2 • • •R3 • •R4 •R5 •

Unidades de armazenamento

Variáveis atribuídas

6.1.3 Unidades Funcionais

A Tabela 6.4 mostra os tempos iniciais e finais de disparo das transições do

pequeno exemplo. Vimos que o tempo inicial de disparo da transição é dado pelo tempo

___________________________________________________________________

115

inicial do estado onde a transição foi disparada. O tempo de disparo final é a soma do

tempo de disparo inicial com a duração do disparo da transição.

Tabela 6.4: Pequeno Exemplo:Tempos de disparos iniciais e finais das transições

s3 0 t4 + 15 15s7 15 t11 * 24 39s8 15 t16 - 15 30s11 30 t33 + 15 45s14 39 t23 * 24 63s15 39 t28 + 15 54s21 54 t45 * 24 78s24 63 t40 - 15 78

Duração disparo

Tempo de disparo final

Tempo de disparo inicialEstados Transições Operação

lógica/arit.

A Figura 6.4 mostra a lista de transições ordenadas de forma ascendente

levando-se em consideração o tempo inicial de disparo. A partir desta lista mapeamos as

transições em unidades funcionais levando-se em consideração a não-sobreposição dos

seus intervalos de tempos de disparos, isto é, se não houver sobreposição dos tempos de

disparos, as transições podem ser atribuídas à mesma unidade funcional. A Figura 6.5

mostra o resultado final do mapeamento das transições nas unidades funcionais após a

aplicação da metodologia proposta. Neste caso foram necessárias duas ULA’s (ULA 1

que executa as operações modeladas pelas transições t4, t16, t33, t45 e ULA2 pelas

transições t11, t28 e t40 ) e um multiplicador responsável pela realização da operação

representada pela transição t23.

Figura 6.4: Pequeno Exemplo: Tempos de disparos das transições ordenados no tempo.

___________________________________________________________________

116

Figura 6.5: Pequeno Exemplo: Resultado do mapeamento das transições lógicas/aritméticas nas unidades funcionais.

6.1.4 Unidades de Interconexão (multiplexadores 2××1)

A lista de transições para cada unidade funcional é mostrada na Tabela 6.5. As

variáveis de leitura e escrita estão definidas nas colunas inp(t) e Out(Out(Out(t))).A

coluna Tipo Operação mostra as operações executadas pela unidade funcional no

comportamento. A coluna instruções é obtida a partir do mapeamento destas variáveis

(nas expressões lógicas/aritméticas) para as unidades de armazenamento de acordo com

a Tabela 6.3.

Tabela 6.5: Pequeno Exemplo – Mapeamento das transições (com suas instruções) para as unidades funcionais utilizando somente componentes isolados.

t4 v1, v2 v3 R2 := R1 + R2t16 v3, v4 v7 R3 := R2 - R3t33 v1, v7 v9 R1 := R1 + R3t45 v9, v8 v2 R2 := R1 * R2t11 v3, v6 v5 R1 := R2 * R4t28 v3, v5 v8 R2 := R2 + R1t40 v8, v11 v1 R1 := R2 - R1

UF 3 * t23 v5, v10 v11 R1 := R1 * R5

ULA1

ULA2

-, +, *

-, +, *

Out(Out(Out(t))) InstruçõesUnidades

FuncionaisTipo

operaçãoTransições Inp(t)

Tabela 6.6: Pequeno Exemplo – Conexões das unidades de armazenamento às unidade funcionais.

C1 R3 sim simC2 R2 não simC3 R1 sim nãoC1 R4 não simC2 R1 não simC3 R2 sim nãoC1 R5 não simC2 R1 sim não

UF3

ULA1

ULA2

link p/ lado direito

Unidades funcionais

Conexões de entrada

Unidades armazenamento

link p/ lado esquerdo

___________________________________________________________________

117

A Tabela 6.6 mostra o conjunto de conexões das unidades de armazenamento à

cada unidade funcional. Por exemplo, a conexão c1 nos diz que existe uma ligação do

registrador R3 aos lados direito e esquerdo da unidade funcional ULA1. Baseado neste

conjunto de conexões o algoritmo proposto chega à estimativa final do caminho de

dados utilizando-se multiplexadores 2×1 (ver Figura 6.6). Foram estimados três

multiplexadores 2×1 para realizar o comportamento.

Figura 6.6: Pequeno Exemplo – Caminho de dados com multiplexadores 2××1.

6.1.5 Comparações

O resultado obtido pela aplicação da abordagem do clique partitioning em [21]

para o pequeno exemplo foi de cinco registradores para mapear onze variáveis

existentes. Infelizmente, este método é um problema NP-hard. Na prática heurísticas

gulosas (greedy) são empregadas [1]. Vemos que nosso algoritmo encontra os mesmos

resultados do clique partitioning, isto é, cinco unidades de armazenamento, a uma

complexidade menor. Em [21] não foram fornecidos dados relativos às unidades de

armazenamento e de interconexão.

6.2 Equação Diferencial de 2a Ordem.

Nesta seção nos aplicamos a abordagem proposta à equação diferencial de 2a

ordem, onde obtivemos a estimativa do caminho de dados.

___________________________________________________________________

118

6.2.1 Descrição

Este benchmark, proveniente do 1992 High Level Synthesis Workshop, prover a

descrição de hardware para um pequeno laço de ponto-fixo. O algoritmo tenta resolver

numericamente a equação

y" + 3xy’ + 3y = 0

Aqui, assumindo-se que u representa dy/dx ou y’ . dx é aproximado como x1 – x.

Similarmente, dy = y1 – y e du = u1 – u. O valor ‘a’ fornece o número de vezes que o

laço numérico é executado. u1, x1 e y1 representa os novos valores de u, x e y. Deste

modo, x1 = x + dx, y1 = udx + y, u1 = u – 3xudx – 3ydx. O comportamento carrega os

valores iniciais de x, y, u, dx e a. Este benchmark foi derivado de [5].

Para este benchmark foi escrita uma especificação em occam, a partir da

especificação original em VHDL. A partir da especificação em occam, foi gerado com a

ferramenta depend [47] o modelo intermediário em redes de Petri. As especificações em

VHDL e em occam, bem como o modelo textual e um esquemático gráfico da rede de

Petri encontram-se no Apêndice B.

6.2.2 Unidades de Armazenamento

Aplicamos, nesta seção, duas metodologias à equação diferencial de 2a ordem

para a estimativa das unidades de armazenamento: método baseado nas variáveis

simultaneamente vivas e o método baseado nos tempos de vida das variáveis.

6.2.2.1 Método Baseado nas Variáveis Simultaneamente Vivas.

De posse do modelo intermediário gerado e depois de associados os tempos

(delay em ns) às transições lógicas/aritméticas, obtivemos o modelo temporizado

(marked timed Petri net) em redes de Petri. O grafo de estados gerado para este modelo

apresentou 34 estados. A Tabela 6.7 mostra os estados com o maior número de

variáveis simultaneamente vivas: s18 e s19 com seis variáveis. Logo foram estimados seis

registradores, necessários para a implementação da equação diferencial de 2a ordem.

___________________________________________________________________

119

Tabela 6.7: Equação Diferencial de 2a Ordem: variáveis simultaneamente vivas

Estadoss 18

s 19

y_var, u_var, dx_var, t1, t3, t2y_var, u_var, t3, dx_var, t2, t1

Variáveis simutaneamente vivas

6.2.2.2 Método Baseado nos Tempos de Vida das Variáveis.

Tabela 6.8: Equação Diferencial de 2a Ordem: Tempo de vida das variáveis.

x_var y_var u_var a_var dx_var x1 y1 t1 t2 t3 t4 t5 t6S1 0S2 0S3 • • • • • 5S4 • • • • • 5S5 • • • • • 5S6 • • • • • 5S7 • • • • • 5S8 • • • • • 5S9 • • • • • 5S10 • • • • • 5S11 • • • • 4S12 • • • • 4S13 • • • • 4S14 • • • 3S15 • • • • 4S16 • • • • 4S17 • • • • 4S18 • • • • • • 6S19 • • • • • • 6S20 • • • 3S21 • • • • • 5S22 • • • • • 5S23 • • • 3S24 • • • • 4S25 • • • • 4S26 • • 2S27 • • • 3S28 • • • 3S29 • 1S30 • • 2S31 • • 2S32 0S33 0S34 0

TotalEstados Variáveis

A partir do grafo de estados gerado através da ferramenta INA, construímos uma

matriz onde identificamos em quais estados as variáveis estão vivas (marcadas). O

resultado é visto na Tabela 6.8. A coluna Total nos dá a quantidade de variáveis vivas

por estados, total este obtido pelo método da seção anterior. As áreas que apresentam as

mesmas hachuras, representam a mesma unidade de armazenamento. Nestas, os tempos

___________________________________________________________________

120

de vida das variáveis não se sobrepõem. O resultado final do mapeamento das variáveis

para as unidades de armazenamento, após a análise dos tempos de vida das variáveis é

mostrada na Tabela 6.9. Nesta tabela observamos que foram necessárias seis unidades

de armazenamento para mapear todas as variáveis, resultado este que vem corroborar o

método anterior (estados s18 e s19 com o maior número de variáveis simultaneamente

vivas).

Tabela 6.9:Equação Diferencial de 2a Ordem: Resultado final do mapeamento das variáveis para os registradores

x_var y_var u_var a_var dx_var x1 y1 t1 t2 t3 t4 t5 t6R1 • • • • •R2 • • •R3 •R4 •R5 •R6 •

VariáveisUnidades de armazenamento

6.2.3 Unidades Funcionais

Tabela 6.10: Equação Diferencial de 2a Ordem:Tempos de disparos iniciais e finais das transições

s4 0 t16 < 15 15s4 0 t21 * 25 25s7 0 t64 + 15 15

s10 15 t69 < 15 30s13 15 t29 * 25 40s13 15 t25 * 25 40s19 40 t39 * 25 65s19 40 t34 * 25 65s22 65 t44 - 15 80s25 80 t49 - 15 95s28 95 t54 * 25 120s31 120 t59 + 15 135

Estados Tempo de disparo final

Tempo de disparo inicial Transições Operação

lógica/arit.Duração disparo

A Tabela 6.10 mostra os tempos iniciais e finais de disparo das transições da

Equação Diferencial de 2a Ordem. Tendo como base os dados desta tabela, o algoritmo

proposto mapeia as transições para as unidades funcionais tendo em vista a política de

sobreposição (ou não) dos intervalos do tempo de disparo. A Tabela 6.11 mostra o

resultado do mapeamento das transições (operações lógicas/aritméticas) nas unidades

funcionais. Foram estimadas cinco unidades funcionais: ULA1 (responsável pelas

___________________________________________________________________

121

operações soma, subtração e comparação), Comparador1 (operação de comparação) e

três multiplicadores. A utilização de ULAs combinadas com componentes específicos

resulta em uma economia de projeto.

Tabela 6.11: Equação Diferencial de 2a Ordem: Resultado do mapeamento das transições (operações lógicas aritméticas) nas unidades funcionais.

t16 t21 t25 t29 t34 t39 t44 t49 t54 t59 t64 t69ULA 1 +, -, < x x x x x

Comparador1 < xMultiplicador1 * x x xMultiplicador2 * x xMultiplicador3 * x

Unidades funcionais

Operações realizadas

Transições atribuidas

6.2.4 Unidades de Interconexão (multiplexadores 2××1)

A lista de transições (modelam operações lógicas/aritméticas), com seus

respectivos lugares de entrada e saída, para cada unidade funcional é mostrada na

Tabela 6.12. A coluna instruções é obtida a partir do mapeamento das variáveis (nas

expressões lógicas aritméticas) para as unidades de armazenamento de acordo com a

Tabela 6.9.

Tabela 6.12: Equação Diferencial de 2a Ordem: Mapeamento das transições (e suas respectivas instruções) para as unidades funcionais.

t44 t4, u_var t6 R1 := R1 - R5t49 t5, t6 u_var R5 := R2 - R1t59 y1, y_var y_var R4 := R1 + R4t64 dx_var, x_var x_var R1 := R3 + R1t69 a_var, x_var ........................ R2 < R1

Somador 1 < t16 a_var, x_var ........................ R2 < R1t21 dx_var, u_var t1 R1 := R3 * R5t39 t3, dx_var t5 R2 := R6 * R3t54 dx_var, u_var y1 R1 := R3 * R5t29 y_var, val[3] t3 R6 := R4 * L[3]t34 t2, t1 t4 R1 := R2 * R1

Multiplicador3 * t25 x_var, val[3] t2 R2 := R1 * L[3]

Unidades Funcionais

Tipo operação Transições Inp(t) Out(Out(Out(t))) Instruções

ULA 1 +, -, <

*

Multiplicador2*

Multiplicador1

A Tabela 6.13 mostra o conjunto de conexões das unidades de armazenamento

às unidades funcionais após a execução do algoritmo. Vemos que na ULA1 existe uma

conexão do lado esquerdo e quatro conexões do lado direito, logo são necessários três

___________________________________________________________________

122

multiplexadorores 2×1 no lado direito desta unidade (o número de multiplexadores 2×1

em cada lado da unidade funcional é dado pelo numero de ligações em cada lado menos

um). Logo, um total de seis multiplexadores 2×1 é estimado para realizar a Equação

Diferencial de 2a Ordem.

Tabela 6.13:Equação Diferencial de 2a Ordem: Conexões das unidades de armazenamento às unidade funcionais.

Esquerdo Direito Esquerdo DireitoC1 R3 não simC2 R5 não simC3 R2 não simC4 R4 não simC5 R1 sim nãoC1 R1 não simC2 R2 sim nãoC1 R6 não simC2 R5 não simC3 R3 sim nãoC1 L[3] não simC2 R4 sim nãoC3 R1 não simC4 R2 sim nãoC1 L[3] não simC2 R1 sim não

0

1

2 2 1 1

N° de multiplexadores

1 4 0 3

N° de links Conexões de entrada

Unidades armazenamento

link p/ lado esquerdo

link p/ lado direito

Unidades Funcionais

Multiplicador2

ULA 1

1 0

1 0

2 0

ULA 2 1

Multiplicador1 1

Multiplicador3 1 0

6.2.5 Comparações

Resultados experimentais deste benchmark são dados na Tabela 6.14.

Basicamente, comparamos nossos resultados com LBE[53], ILP[61] e Maciel[38].

Tabela 6.14: Equação Diferencial de 2a Ordem: Resultados

Variáveis LiteraisLBE [53] 2(ULA's), 3(*) 6 1 • •ILP [61] 2(ULA's), 2(*) 4 2 • •

Maciel [38] • 12 5 122(+), 3(*), 1(c) 52(ULA's) e 3(*) 6

Multiplexadores

2. As variáveis de entrada NÃO são armazenadas em registradores*:multiplicador (delay = 24.4 ns), +: somador (delay = 15.0 ns)

Nossa estimativa 6 1

Fonte Unidades funcionais Registradores

5

1. As variáveis de entrada e saída são armazenadas em registradores

•: Dado não fornecidoULA's(+, -):Unidade lógica aritmética (delay = 15 ns), c:comparador (delay = 15 ns)

___________________________________________________________________

123

Como podemos observar, obtemos o mesmo limite inferior encontrado em

LBE[53] para a estimativa de unidades funcionais (2 ULA’s e 3 * ) e registradores (6).

As abordagens LBE[53] e ILP[61] não forneceram o número de registradores.

Comparados os resultados com Maciel[38] obtivemos 50% de redução nas estimativas

de registradores e multiplexadores 2×1. Vemos que nossa abordagem encontra

alternativas de projeto iguais ou menores que estes trabalhos, estimando todos os

componentes do caminho de dados.

6.3 Filtro de Ondas Elíptico de 5a Ordem.

Nesta seção, aplicamos nossa abordagem ao filtro de ondas elíptico de 5a ordem

com o propósito de obtermos a estimativa do seu caminho de dados – unidades

funcionais, de armazenamento e de interconexão (multiplexadores 2×1).

6.3.1 Descrição

O filtro elíptico pertence a classe dos filtros de respostas a impulsos infinitos –

Infinite Impulse Response (IIR) – onde a resposta do filtro a um impulso de entrada

permanece diferente de zero até o tempo infinito num sentido teórico. O filtro em

particular que testamos neste trabalho é um filtro passa-baixa. A descrição do projeto

do filtro é composta de um bloco básico com diversas operações aritméticas. Tem sido

um benchmark popular para comparar resultados de escalonamentos. Este benchmark é

derivado de descrições em [36] e [54].

Geramos o comportamento em occam a partir da especificação original em

VHDL deste benchmark. Em seguida, obtemos o modelo intermediário em redes de

Petri, através da tradução do código em occam pela ferramenta translate [47]. As

especificações em VHDL e em occam, bem como os modelos textual e gráfico

(esquemático) da rede de Petri encontram-se no Apêndice C.

___________________________________________________________________

124

6.3.2 Unidades de Armazenamento

Nesta seção, aplicamos ao filtro de ondas elíptico de 5a ordem duas

metodologias proposta para o cálculo das unidades de armazenamento. A primeira é

baseada nas variáveis simultaneamente vivas e a segunda baseia-se nos tempos de vida

das variáveis.

6.3.2.1 Método Baseado nas Variáveis Simultaneamente Vivas.

O modelo temporizado (marked timed Petri net) em redes de Petri foi obtido a

partir do modelo intermediário gerado, depois de associados os tempos (delay em ns) às

transições lógicas aritméticas. O grafo de estados gerado para este modelo apresentou

52 estados (ver Tabela 6.15). Nesta tabela, os estados com o maior número de variáveis

simultaneamente vivas são os estados s20, s23, s24, s27 e s28, com dez variáveis. Desta

forma são necessárias dez unidades de armazenamento para a implementação do filtro

de ondas elíptico de 5a ordem.

Tabela 6.15: Filtro de Ondas Elíptico de 5a Ordem: variáveis simultaneamente vivas

Estadoss 20

s 23

s 24

s 27

s 28

Variáveis simutaneamente vivasINP, SV38, SV18, SV39, n1, n5, n2, n6, n3, n7INP, SV38, SV18, SV39, n1, n2, n5, n3, n9, n8 INP, SV38, SV18, SV39, n1, n9, n2, n5, n8, n3

INP, SV38, SV18, n9, n8, SV39, n1, n12, n11, n10 n11, INP, SV38, SV18, n9, n8, SV39, n1, n12, n10

6.3.2.2 Método Baseado nos Tempos de Vida das Variáveis.

A Tabela 6.16 nos mostra o resultado final do mapeamento das variáveis para as

unidades de armazenamento.

Tabela 6.16: Filtro de Ondas Elíptico de 5a Ordem: mapeamento variáveis para os registradores

R1 n28, n26, n22, INPR2 n17, n1, SV2R3 n29, p1, n15, n13, n10, n3, SV13R4 SV18R5 n23, n16, n14, n11, n5, n4, SV26R6 n25, n21, n18, n12, n2, SV33R7 SV38R8 n19, SV39R9 n24, n20, n8, n7, n6R10 n9

VariáveisUnidades de armazenamento

___________________________________________________________________

125

Esta tabela foi construída a partir do grafo de estados gerado através da

ferramenta INA, onde identificamos as variáveis vivas (marcadas) em seus respectivos

estados. É construída uma matriz onde as colunas representam as variáveis e as linhas

os estados. Uma seqüência onde a variável é marcada (coluna) representa o tempo de

vida desta variável. A partir da análise da sobreposição (ou não) dos tempos de vida das

variáveis chegamos à estimativa de dez unidades de armazenamento para mapear todas

as variáveis. O resultado é idêntico ao do método anterior.

6.3.3 Unidades Funcionais

Na Tabela 6.17 são vistos os tempos de disparos iniciais e finais das transições

lógicas/aritméticas do Filtro de Ondas Elíptico de 5a Ordem.

t4 + 15 15t9 + 15 15

s7 15 t14 + 15 30s11 30 t19 + 15 45s15 45 t24 + 15 60s20 60 t35 + 15 75s21 60 t40 + 15 75

t45 + 15 90t55 + 15 90

s25 75 t50 + 15 90s28 90 t146 + 15 105

t66 + 15 105t71 + 15 105t76 + 15 120t86 + 15 120t81 + 15 120t91 + 15 120t99 + 15 135

t104 + 15 135s39 120 t112 + 15 135s43 135 t133 + 15 150

t123 + 15 150t128 + 15 150

s48 150 t138 + 15 165s39 120 t159 + 15 135s49 150 t154 + 15 165

s37 120

s45 135

s33 105

s34 105

s24 75

s30 90

Operação lógica/arit.

Duração disparo

Tempo de disparo final

s3 0

Estados Tempo de disparo inicial Transições

Tabela 6.17: Filtro de Ondas Elíptico de 5a Ordem – Tempos de disparos iniciais e finais das transições

Os tempos de disparos iniciais das transições coincidem com os tempos dos

estados onde foram iniciados os disparos. O tempo de disparo final é o tempo de disparo

___________________________________________________________________

126

inicial acrescentado da duração do disparo da transição. A partir dos dados desta tabela,

o algoritmo proposto mapeia as transições às unidades funcionais tendo em vista a

política de sobreposição (ou não) dos intervalos do tempo de disparo. O resultado do

mapeamento das transições lógicas/aritméticas às unidades funcionais é visto na Tabela

6.18. Para a implementação desta especificação foram estimados quatro somadores.

Tabela 6.18: Filtro de Ondas Elíptico de 5a Ordem – Resultado do mapeamento das transições lógica/aritméticas às unidades funcionais.

Somador1 t154 t133 t159 t91 t146 t55 t40 t24 t19 t14 t9Somador2 t138 t128 t112 t86 t71 t50 t35 t4Somador3 t123 t104 t81 t66 t45Somador4 t99 t76

Unidades funcionais Transições atribuidas

6.3.4 Unidades de Interconexão (multiplexadores 2××1)

Tabela 6.19: Filtro de Ondas Elíptico de 5a Ordem – Mapeamento das transições (com suas instruções) às unidades funcionais.

t154 n29, n19 SV33o canal=R3+R8t133 n15, n25 SV2o canal=R3+R6t159 n24, n16 SV39o canal=R9+R5t91 SV39, n16 n20 R9=R8+R5

t146 n11, n9 SV26o canal=R5+R10t55 n9, n2 n12 R6=R10+R6t40 n2, n7 n9 R10=R6+R9t24 n2, n4 n5 R5=R6+R5t19 SV26, n3 n4 R5=R5+R3t14 SV13, n1 n3 R3=R3+R2t9 SV39, SV33 n2 R6=R8+R6

t138 n28, n17 SV13o canal=R1+R2t128 SV38, n27 n29 R3=R7+R3t112 n21, INP n25 R6=R6+R1t86 n16, n9 n19 R8=R5+R10t71 SV39, n14 n16 R5=R8+R5t50 n5, n8 n11 R5=R5+R9t35 n6, n3 n8 R9=R9+R3t4 SV2, INP n1 R2=R2+R1

t123 SV18, n26 n28 R1=R4+R1t104 n19, SV38 n23 R5=R8+R7t81 n8, n15 n18 R6=R9+R3t66 n13, n1 n15 R3=R3+R2t45 n8, n3 n10 R3=R9+R3t99 SV18, n18 n22 R1=R4+R6t76 n15, n1 n17 R2=R3+R2

Somador2

Somador3

Somador4

Somador1

Unidades Funcionais Transições Inp(t) Out(Out(Out(t))) Instruções

___________________________________________________________________

127

A Tabela 6.19 mostra as unidades funcionais com suas respectivas listas de

transições. Nas colunas inp(t) e Out(Out(Out(t))) estão as variáveis de leitura e escrita

para cada transição, definidas em função das expressões lógicas/aritméticas da

especificação. A coluna instruções é obtida a partir do mapeamento destas variáveis nas

unidades de armazenamento de acordo com a Tabela 6.16

A Tabela 6.20 mostra as conexões das unidades de armazenamento às unidades

funcionais e o n0 de multiplexadores em cada lado das unidades funcionais após a

execução do algoritmo. Logo, são estimados vinte e dois multiplexadores 2×1 para

implementar o Filtro de Ondas Elíptico de 5a Ordem.

Tabela 6.20: Filtro de Ondas Elíptico de 5a Ordem – Conexões das unidades de armazenamento às unidade funcionais.

Esquerdo Direito Esquerdo DireitoC1 R2 não simC2 R10 sim nãoC3 R5 não simC4 R9 sim nãoC5 R6 sim simC6 R8 sim simC7 R3 sim nãoC1 R9 sim simC2 R8 não simC3 R10 não simC4 R5 sim nãoC5 R6 não simC6 R3 não simC7 R7 sim nãoC8 R2 não simC9 R1 sim nãoC1 R2 sim nãoC2 R3 não simC3 R9 sim nãoC4 R7 não simC5 R8 sim nãoC6 R1 não simC7 R4 sim nãoC1 R2 não simC2 R3 sim nãoC3 R6 não simC4 R4 sim não

Unidades Funcionais

Conexões de entrada

Unidades armazenamento

link p/ lado esquerdo

link p/ lado

N° de links

Somador2

N° de multiplexadores

Somador1 5 4 4

4 6 3 5

3

Somador3 4 3 3

Somador4 2 2 1 1

2

6.3.5 Comparações

A Tabela 6.21 apresenta os resultados experimentais deste benchmark.

Comparamos nossos resultados com os dados obtidos em HAL[57], LBE[53],

___________________________________________________________________

128

OASIC[24], InSyn[64] e Maciel[38]. Como podemos ver, obtemos o mesmo limite

inferior para a estimativa de unidades funcionais (quatro) que HAL[57] e LBE[53].

Quanto ao número de registradores, obtemos uma variável a mais (sete) quando

comparado com HAL[57] (seis ) – nesta abordagem as variáveis de entrada NÃO são

armazenadas em registradores. Quando as variáveis de entrada e saída são armazenadas

em registradores obtemos o mesmo índice (dez registradores) que LBE[53] e

OASIC[24]. Com relação a Maciel[38], obtivemos uma redução de 77.3% nos

registradores e 15.3% nos multiplexadores 2×1.

Tabela 6.21: Filtro de Ondas Elíptico de 5a Ordem – Resultados.

Variáveis Literais2(+), 2(*) 6 2 0 •

3(+), 2(*p ) 12 1 0 •3(+), 3(*) 11 1 0 •2(+), 2(*) 10 1 0 •

3(+), 2(*p ) 10 1 0 •3(+), 2(*p ) 8 2 0 •

OASIC [24] 3(+), 2(*p ) 10 1 0 •InSyn [64] 3(+), 2(*p ) 8 2 0 •Maciel [38] • 44 1 0 26

7 2 0 1710 1 0 22

1. As variáveis de entrada e saída são armazenadas em registradores2. As variáveis de entrada NÃO são armazenadas em registradores+: somador (15.0 ns), *p : 2-stage pipelined multiplier(25.0 ns)•: Dado não fornecido

Nossa estimativa 4(+)

HAL [57]

LBE [53]

Fonte Unidades funcionaisRegistradores

Multiplexadores

6.4 Máquina de Refrigerantes

Nesta seção aplicamos a abordagem proposta à máquina de refrigerantes, onde

obtivemos a estimativa do caminho de dados – unidades funcionais, de armazenamento

e de interconexão (multiplexadores 2×1).

6.4.1 Descrição

A Figura 6.7 mostra uma visão estrutural do bloco de controle e outros módulos

da especificação da máquina de refrigerantes. Ela foi implementada em hardware e

___________________________________________________________________

129

mapeada com sucesso em uma FPGA Xilinx série XC4000E, da família 4013EHQ240

com a ferramenta CAD Xilinx Foundation Series 3.1. O comportamento desta máquina

é descrito logo abaixo.

U ser In te rface

pr

em

rese t c lo ck

changevalue

vm

na crevlr

ld

ac

CoinI nput

C hange R $

S oft D rinkD elivery

Figura 6.7: Máquina de Refrigerantes: Visão estrutural.

Após o reset, a máquina espera por uma moeda. Quando o cliente insere a

primeira moeda, a máquina fica em estado de espera até que o refrigerante seja

solicitado. Quando um refrigerante é selecionado, a máquina verifica o estoque para o

refrigerante em particular. Se o dinheiro depositado for insuficiente para realizar a

compra do refrigerante a máquina devolve o valor pago pelo cliente. Sendo o valor

depositado for suficiente, a máquina calcula o troco e verifica se tem saldo no estoque

para devolver ao cliente. Em caso afirmativo, a máquina entrega o refrigerante e o troco

ao cliente. Se negativo, o cliente é notificado e decide se paga mais pelo refrigerante ou

recebe o valor depositado de volta. Na devolução do troco, a máquina calcula o valor do

mesmo em número de moedas, 50 e 10 centavos.

A partir da especificação em occam da máquina de refrigerantes foi gerado com

a ferramenta depend [47] o modelo intermediário em redes de Petri. As especificações

em VHDL e em occam, bem como os modelos textual e gráfico (esquemático) da rede

de Petri encontram-se no Apêndice D.

6.4.2 Unidades de Armazenamento

Aplicamos, nesta seção, duas metodologias para a estimativa das unidades de

armazenamento da Máquina de Refrigerantes. O primeiro método é baseado nas

variáveis simultaneamente vivas e o segundo é baseado nos tempos de vida das

variáveis.

___________________________________________________________________

130

6.4.2.1 Método Baseado nas Variáveis Simultaneamente Vivas.

A partir do modelo intermediário gerado e depois de associados os tempos

(delay em ns) às transições lógicas/aritméticas, obtivemos o modelo temporizado

(marked timed Petri net) em redes de Petri. O grafo de estados gerado para este modelo

apresentou 64 estados. A Tabela 6.22 mostra os estados com a maior quantidade de

variáveis simultaneamente vivas: s4 e s5 com oito variáveis. Desta forma, são estimadas

oito unidades de armazenamento para a implementação da Máquina de Refrigerantes.

Tabela 6.22 – Máquina de Refrigerantes: variáveis simultaneamente vivas por estados.

Estadoss 4

s 5

Variáveis simutaneamente vivasca50, nac, ac, rev, emv, prv, totalPaid, price ca50, nac, ac, price, rev, totalPaid, emv, prv

6.4.2.2 Método Baseado nos Tempos de Vida das Variáveis.

A partir do grafo de estados gerado através da ferramenta INA, construímos uma

matriz onde identificamos as variáveis vivas (marcadas) e seus respectivos estados,

onde computamos os tempos de vida das variáveis. O resultado final do mapeamento

das variáveis para as unidades de armazenamento é visto na Tabela 6.23, isto é, oito

unidades de armazenamento para mapear todas as variáveis, resultado este que vem

corroborar o método anterior.

Tabela 6.23: Máquina de Refrigerantes – Resultado final do mapeamento das variáveis aos registradores.

R1 ca10, change, emvR2 nmd10, nmd50, acR3 nacR4 priceR5 totalPaidR6 coinValue, prvR7 revR8 ca50

Unidades de armazenamento Variáveis

6.4.3 Unidades Funcionais

A Tabela 6.24 mostra a lista de transições ordenadas de forma ascendente

levando-se em consideração o tempo inicial de disparo. Com base nesta lista buscamos

___________________________________________________________________

131

mapear as transições em unidades funcionais levando-se em consideração a

sobreposição dos intervalos dos tempos de disparos, isto é, se não houver sobreposição

destes tempos, as transições podem ser atribuídas à mesma unidade funcional.

A Tabela 6.25 mostra o resultado do mapeamento das transições

lógica/aritméticas às unidades funcionais. Foram estimadas duas unidades lógicas

aritméticas (ULA’s), dois comparadores e um divisor para esta implementação.

Tabela 6.24: Máquina de Refrigerantes – Tempos de disparos iniciais e finais das transições.

t15 = 15 15t44 = 15 15

s6 0 t46 = 15 15s9 15 t21 = 15 30

s11 15 t38 = 15 30t30 + 15 45t34 = 25 45

s19 45 t51 - 15 60s23 60 t57 < 15 75s24 60 t59 = 15 75s25 60 t61 > 15 75s26 60 t79 / 24 84

t67 = 15 90t69 = 15 90

s33 84 t87 <= 15 99s34 84 t90 <= 15 99s44 99 t94 - 15 114s47 114 t100 = 15 129s50 129 t106 / 24 153s54 153 t115 <= 15 168

s5 0

s16 30

s30 75

Estados Tempo de disparo inicial

Transições Operação lógica/arit.

Duração disparo

Tempo de disparo final

Tabela 6.25: Máquina de Refrigerantes – Resultado do mapeamento das transições lógica/aritméticas às unidades funcionais.

ULA 1 <=, =, -, > t115, t100, t94, t69, t61, t51, t34, t38, t46ULA 2 =, + t67, t59, t30, t21, t44

Comparador1 <=, <, = t90, t57, t15Comparador2 <= t87

Divisor ÷ t106, t79

Unidades funcionais Transições atribuidasOperações

realizadas

6.4.4 Unidades de Interconexão (multiplexadores 2××1)

A lista de transições para cada unidade funcional é mostrada na Tabela 6.26. As

variáveis de leitura e escrita estão definidas nas colunas inp(t) e Out(Out(Out(t))). A

___________________________________________________________________

132

coluna instruções é obtida a partir do mapeamento destas variáveis para as unidades de

armazenamento de acordo com a Tabela 6.23.

Tabela 6.26: Máquina de Refrigerantes – Mapeamento das transições (e suas instruções) às unidades funcionais.

t34 val[0], emv ........................ LO=R1t38 val[0], prv ........................ LO=R6t46 val[1], rev ........................ L1=R7t51 price, totalPaid ........................ R1=R4-R5t61 val[0], change ........................ L0>R1t69 val[NAC], nac ........................ LAC=R3t94 val[50], change change R1=L50-R1

t100 val[0], change ........................ L0=R1t115 ca10, nmd10 ........................ R1<=R2t21 val[0], emv ........................ L0=R1t30 coinValue, totalPaid totalPaid R5=R6+R5t44 val[0], rev ........................ L0=R7t59 val[0], change ........................ L0=R1t67 val[AC], ac ........................ LNAC=R2t15 val[0], prv ........................ L0=R6t57 val[0], change ........................ L0<R1t90 ca50, nmd50 ........................ R8<=R2

Comparador2 t87 val[0], nmd50 ........................ L0<=R2t79 val[50], change nmd50 R2=L50/R1

t106 val[10], change nmd10 R2=L10/R1

Unidades Funcionais Transições Inp(t)

ULA 1

ULA 2

Comparador1

Divisor

Out(Out(Out(t))) Instruções

Tabela 6.27: Máquina de Refrigerantes – Conexões das unidades de armazenamento às unidade funcionais.

Esquerdo Direito Esquerdo DireitoC1 R7 não simC2 L1 sim nãoC3 R6 sim nãoC4 R5 não simC5 R4 sim nãoC6 R3 não simC7 LAC sim nãoC8 L50 não simC9 L0 não simC10 R2 não simC11 R1 sim nãoC1 R7 não simC2 R5 não simC3 R6 sim nãoC4 R1 não simC5 L0 sim nãoC6 R2 não simC7 LNAC sim nãoC1 R6 não simC2 R1 não simC3 L0 sim nãoC4 R2 não simC5 R8 sim nãoC1 R2 não simC2 L0 sim nãoC1 L50 sim nãoC2 R1 não simC3 L10 sim não

Unidades Funcionais

Conexões de entrada

Unidades armazenament

link p/ lado esquerdo

link p/ lado direito

N° de links N° de multiplexadores

6 4 5

Comparador1 2

Comparador2

2

1

Divisor

3

ULA 1 5

3 1 2

ULA 1 3 4 2

1 0 0

1 1 0

___________________________________________________________________

133

A Tabela 6.27 mostra as conexões das unidades de armazenamento às unidades

funcionais após a execução do algoritmo. Por exemplo, na ULA1 existe cinco conexões

no lado esquerdo e seis conexões no direito. Logo são necessários quatro e cinco

multiplexadorores 2×1 nos lados esquerdo e direito desta unidade, respectivamente. No

total, são estimados dezoito multiplexadores 2×1 para implementar a Máquina de

Refrigerantes.

6.4.5 Comparações

Tabela 6.28 mostra a implementação estrutural da Máquina de Refrigerantes em

uma FPGA Xilinx série XC4000E, da família 4013EHQ240. Os dados são mostrados

em números de gates equivalentes e em número de unidades. Como podemos observar

nos resultados obtidos por esta abordagem, houve uma redução da ordem de 38.4% e

10% nos registradores para as variáveis e multiplexadores, respectivamente. Com

relação à área total houve uma redução de 41.4 %.

Tabela 6.28: Máquina de Refrigerantes – Resultados.

Variaveis ConstantesMaciel [38] • 13 6 20 4755

Nossa estimativa 2(ALU's), 2(c) e 1(÷) 8 1 6 18 27871. As variáveis de entrada e saída são armazenadas em registradores÷: divisor (delay = 24.4 ns), ULA's(+, -, c):Unidade lógica aritmética (delay = 15 ns), c:comparador (delay = 15 ns)•: Valores não fornecidos

Área Total (gates)Fonte Unidades Funcionais Registradores Multiplexadores

6.5 Conclusões

Com o objetivo de validar a metodologia proposta nós a aplicamos a quatro

especificações. Primeiro, a um pequeno exemplo onde fizemos comparações com a

abordagem do clique partitioning. Encontramos os mesmos resultados no cômputo das

unidades de armazenamento a um custo computacional menor, já que a abordagem do

clique partitioning é NP-hard. Posteriormente consideramos a Equação Diferencial de

___________________________________________________________________

134

2a. Ordem e o Filtro de Ondas Elíptico de 5a Ordem. Estes benchmarks são provenientes

do 1992 High Level Synthesis Workshop. Comparamos os resultados obtidos com outros

trabalhos relacionados: LBE[53], ILP[61], HAL[57], OASIC[24], InSyn[64] e

Maciel[38]. Vimos que os resultados em termos de precisão são similares ou menores a

estes trabalhos. Finalmente submetemos a abordagem proposta à descrição de uma

Máquina de Refrigerantes e obtivemos uma redução de área da ordem de 41.4%.

Uma outra vantagem é que estamos alcançando melhoria dos resultados em

relação a trabalhos prévios. A abordagem foi aplicada sobre métodos formais com

semântica bem definida, o que tem proporcionado também estimativas a um baixo custo

computacional devido ao modelo intermediário (redes de Petri temporizadas da

subclasse grafo marcado) adotado.

7 Conclusões e Trabalhos Futuros

Este capítulo resume as contribuições deste trabalho e apontada possibilidades de melhoria e novas linhas de investigação para trabalhos futuros dentro do tema.

7.1 Objetivos do trabalho

A crescente diversidade e complexidade dos sistemas digitais, a necessidade de

diminuição dos custos e a redução do time-to-market, fazem das técnicas de suporte a

hardware/software codesign um importante tópico de pesquisa. Além do mais, o re-uso

de projetos anteriores, análise/verificação qualitativa, rápida exploração de projetos,

algoritmos rápidos de particionamento, e prototipação são importantes tarefas em

hardware/software codesign. Estimativas são essenciais na exploração rápida de

projetos, na validação rápida de restrições de projeto e no rápido particionamento em

hardware e software. Por esta razão, o estudo de métodos formais, o uso de métricas de

qualidade e métodos de análise quantitativa são importantes tópicos a serem

considerados.

O objetivo principal deste trabalho foi o desenvolvimento de um conjunto de

métricas de estimativas a serem usados dentro do contexto de um sistema de

hardware/software codesign. Os métodos propostos são baseados em Timed Petri nets

(o modelo intermediário para análise), um formalismo poderoso para análise qualitativa

e quantitativa, que também permite simulação. Este modelo intermediário é obtido pela

tradução de uma especificação na linguagem occam pela ferramenta depend

desenvolvida por [47].

___________________________________________________________________

136

Diversas razões levaram a escolha de Timed Petri nets como o formalismo

considerado neste trabalho. Primeiro, porque tal modelo representa as ações pelas

transições ao invés de lugares (Place Timed Petri nets), facilitando o entendimento do

modelo. Segundo, uma ação de retardo (delay) é mais bem representada por duração do

que por restrições de tempo (Time Petri nets). Terceiro, os modelos obtidos são menores

do que aqueles obtidos usando Time Petri Nets. Quarto, desde que a arquitetura alvo é

conhecida, modelos determinísticos fornecem resultados mais precisos que modelos

estocásticos (GSPN).

O uso de um modelo intermediário permite estimativas de métricas que são

independentes da linguagem de descrição. Levando-se em consideração estas

estimativas, a especificação é particionada em um conjunto de processos. Alguns destes

conjuntos são implementados em software e outros em dispositivos de hardware.

Depois do particionamento, os processos a serem implementados em hardware são

sintetizados e os processos em software são compilados. .

Estimativas de valores para métricas de projeto são requeridas para determinar

se um projeto em particular ao nível de sistema (alto nível de abstração onde há a

partição das funcionalidades do sistema entre os componentes alocados) satisfaz as

restrições, como também serve para comparar alternativas de projeto. Dentre as

métricas utilizadas podemos citar desempenho, tamanho das áreas de hardware e de

software, etc. Componentes da área de hardware têm sido divididos em: área de controle

de alto-nível, área de controle local e área do caminho de dados.

Este trabalho define um conjunto de métodos para estimativa da área do

caminho de dados: unidades funcionais, de armazenamento e de interconexão

(multiplexadores). Foi desenvolvida uma ferramenta de estimativa de área de hardware,

levando-se em consideração a precisão a um custo computacional aceitável.

O modelo de estimativa da área de hardware é assumido para ser implementado

em uma máquina de estados finitos com caminho de dados (FSMD – Finite State

Machine with Datapath). A área do caminho de dados é dada pelo somatório das áreas

das unidades de armazenamento, funcionais e de interconexão. O número de unidades

de armazenamento da descrição é estimado usando duas abordagens: o primeiro método

___________________________________________________________________

137

é baseado nas variáveis simultaneamente “vivas” e o segundo no tempo de vida das

variáveis. O número de unidades funcionais necessárias para implementar as operações,

bem como as unidades de armazenamento, são baseados na análise do grafo de

alcançabilidade, gerado a partir do modelo intermediário (timed Petri nets). As unidades

de interconexão são calculadas a partir do mapeamento das variáveis às unidades de

armazenamento, do mapeamento das transições (modelam operações lógica/aritméticas)

às unidades funcionais e da busca das instruções no modelo intermediário.

O modelo intermediário utilizado é na realidade um grafo de fluxo de dados

(Data Flow Graph – DFG) modelado através de redes de Petri temporizadas. O uso de

um método formal (com semântica bem definida) além da facilidade de modelagem

permitem realizar análises quantitativas e qualitativas. O modelo intermediário utilizado

neste trabalho é um grafo marcado, o que possibilita a obtenção de análises a um baixo

custo computacional. A geração do grafo de alcançabilidade por exemplo apresenta um

custo linear. A estimativa das unidades de armazenamento, funcionais e de interconexão

têm complexidade de ordem quadrática.

7.2 Trabalhos Futuros

Em relação ao modelo de fluxo de dados vemos que ele maximiza o grau de

paralelismo das instruções, obtendo implementações com alto desempenho e

conseqüentemente com a maior utilização de recursos computacionais. A utilização de

informações em conjunto do modelo de fluxo de controle e do modelo de dependência

de dados melhora a qualidade das estimativas, pois permite exploração de uma

quantidade maior de alternativas de projeto. Por exemplo, podemos utilizar as

informações do fluxo de controle no modelo intermediário (fluxo de dados) com o

objetivo de retardar o disparo de transições, fazemos isto inserindo lugares

intermediários no modelo intermediário. A implementação agora passa a requer menos

recursos. O próximo passo é fazer a análise da relação tempo de execução versus custo

___________________________________________________________________

138

de área de hardware. É importante observar que a abordagem proposta não muda, pois o

que está sendo alterado é a quantidade de lugares do modelo intermediário.

Para ilustrar esta abordagem vamos fazer uma breve análise dos modelos de

fluxo de controle e dados da Figura 7.1. A especificação (Figura 7.1 (a)) é composta três

instruções: x:=1+2, z:=4+5 e y:=x+3, modeladas pela rede de fluxo de dados pelas

transições t1, t4 e t3 respectivamente. A primeira e segunda instruções não apresentam

dependência de dados e a terceira instrução depende da primeira, assim, a rede de fluxo

de dados modela as duas primeiras instruções em paralelo e a terceira e primeira

instruções de forma seqüencial, conforme visto na Figura 7.1(c). O grafo de

alcançabilidade, mostrado na Figura 7.1 (d), ratifica o exposto, vemos que as transições

t1 e t4 são disparadas em paralelo (estado s1) e a transição t3 é disparada no estado s3

após o disparo da transição t1. Para este projeto específico necessitaríamos de duas

unidades funcionais.

PAR INT x, y, z: SEQ PAR x:= 1 + 2 z:= 4 + 5 y:= x + 3

p0

p1

p2

p3

p4

p5

p6

(a )

t0

t1 t2

t3

t4

t5

start

p1

p6

p7 p8

p9

end

p1 0

p2 p3 p4 p5

t0

t1

t2

t4

t3

t5

t6

x= 1 + 2 z= 4 + 5

y= x+ 3

s0 (sta rt) t0

s2 (p6 ,p3 ,p1 0 )

s3 (p7 ,p8 ,p3 ,p1 0 )

s4 (p7 ,p9 ,p1 0 )

s5 (end)

t1 ,t4

t2

t3

t5

t6

(b ) (c) (d ) Figura 7.1: Comportamento de um projeto: a) Especificação em occam, b) rede de fluxo de controle, c) rede de fluxo de dados (d) e grafo de alcançabilidade do fluxo de dados.

Como já dissemos anteriormente o objetivo do uso de estimativas é proporcionar

a exploração de um grande número de projetos. Imagine que agora que só dispomos de

uma unidade funcional, se modificássemos a especificação e colocássemos as três

instruções para serem executadas em seqüencial, a rede de fluxo de controle refletiria

esta nova realidade, contudo a rede de fluxo de dados obtida para esta nova

especificação não mudaria, pois este modelo é baseado na dependência de dados entre

___________________________________________________________________

139

as operações. Assim seriam estimados os mesmos componentes computacionais. A

solução para este impasse seria a interação do fluxo de controle com o fluxo de dados,

através de uma rede de fluxo de dados estendida. A Figura 7.2 mostra uma rede de fluxo

de dados estendida. Nesta rede foi acrescentado o lugar p6’, entre as transiçõe s t1 e t4. O

grafo de alcançabilidade (Figura 7.2(b)), gerado para esta rede estendida, mostra que as

transições t1, t4 e t3 são disparadas de forma seqüencial. Assim aplicando a abordagem

de estimativa de área desenvolvida nesta dissertação encontraríamos agora uma unidade

funcional para o projeto.

p0

p1

p6p6 ’

p7 p8

p9

p1 1

p1 0

p2 p3 p4 p5

t0

t1

t2

t4

t3

t5

t6

x= 1+ 2 z= 4 + 5

y= x+ 3

s0 (start) t0

s2 (p6 ,p6’,p3 ,p4 ,p5)

s3 (p7 ,p8 ,p3 ,p1 0 )

s4 (p7 ,p9 ,p10 )

s5 (end)

t1

t2 ,t4

t3

t5

t6

(b )(a ) Figura 7.2: Comportamento de um projeto: a) Rede de fluxo de dados extendida e b) grafo de alcançabilidade gerado

Diversas linguagens são utilizadas para especificação de processos em

hardware/software co-design. Estas especificações são posteriormente mapeadas em

uma representação de projeto intermediário (modelo intermediário). Neste trabalho

citamos: Occam, VHDL, SpecChart, HardwareC, Verilol, Esterel etc, como exemplos

de linguagens de especificação [2].

Hoje assistimos a complexidade do software dominando a complexidade do

hardware e para gerenciar a complexidade de sistemas avançados é necessário cada vez

mais de uma linguagem com um poder maior de modelagem. A linguagem SystemC

[49] é um subconjunto da linguagem de programação C++, utilizada para modelagem e

simulação de hardware/software. O sistema pode ser especificado em diversos níveis de

abstração (hierarquia comportamental) e possui uma biblioteca padrão C++ para

modelagem de sistemas baseados em C (concorrência de processos; tempo em clocks;

___________________________________________________________________

140

tipos de dados em hardware; interrupções; reatividade; hierarquia de módulos, portas e

sinais), com grande aceitação e suporte na indústria. A linguagem de especificação

utilizada neste trabalho foi Occam, uma linguagem pouco conhecida e que não é bem

aceita na indústria.

Apresentamos duas sugestões para a melhoria dos resultados do trabalho

apresentado no contexto de hardware/software co-design. Primeiro, o desenvolvimento

de um modelo de análise que leve em consideração a interação dos modelos

intermediários de fluxo de controle e dados, permitindo assim a exploração rápida de

um número maior de projetos potenciais. Segundo a construção de um tradutor que

tenha como linguagem de entrada SystemC e gere um modelo intermediário em redes

de Petri. Assim, teríamos SystemC como linguagem de especificação de projeto. O que

seria um grande avanço, pois teríamos à disposição uma linguagem com alto poder de

especificação, traduzida em modelos formais (redes de Petri) que possibilitam a

realização de análises de propriedades quantitativas e qualitativas.

Apêndice A

Pequeno Exemplo

A.1 Modelo Intermediário – INA (.pnt )

P M PRE,POST NETZ 0:ex3Mar 0 1 , 0 1 0 0, 1 2 0 1 3 0 0, 2 4 0 0, 3 5 0 0, 6 6 0 0, 15 7 0 0, 13 8 0 0, 9 9 0 0, 18 10 0 0, 30 11 0 0, 35 12 0 0, 21 13 0 0, 25 14 0 2, 4 15 0 2, 32 16 0 3, 4 17 0 3, 47 18 0 4, 5 19 0 5, 10 20 0 0, 7 21 0 7, 8 22 0 8, 1 23 0 9, 11 24 0 9, 1 25 0 10, 11 26 0 10, 14 27 0 11, 12 28 0 12, 22 29 0 14, 16 30 0 14, 27 31 0 15, 16 32 0 15, 1 33 0 16, 17 34 0 17, 31 35 0 0, 19 36 0 19, 20 37 0 20, 1 38 0 21, 23 39 0 21, 1 40 0 22, 23 41 0 22, 26 42 0 23, 24 43 0 24, 38 44 0 26, 28 45 0 26, 1 46 0 27, 28 47 0 27, 1

___________________________________________________________________

142

48 0 28, 29 49 0 29, 39 50 0 31, 33 51 0 31, 1 52 0 32, 33 53 0 32, 42 54 0 33, 34 55 0 34, 44 56 0 0, 36 57 0 36, 37 58 0 37, 1 59 0 38, 40 60 0 38, 1 61 0 39, 40 62 0 39, 43 63 0 40, 41 64 0 41, 1 65 0 43, 45 66 0 43, 1 67 0 44, 45 68 0 44, 1 69 0 45, 46 70 0 46, 1 @ place nr. name capacity time 0: p1.start oo 0 1: p1.dummy oo 0 2: p1.end oo 0 3: p1.v1.0 oo 0 4: p1.v2.0 oo 0 5: p1.v3.0 oo 0 6: p1.v4.0 oo 0 7: p1.v5.0 oo 0 8: p1.v6.0 oo 0 9: p1.v7.0 oo 0 10: p1.v8.0 oo 0 11: p1.v9.0 oo 0 12: p1.v10.0 oo 0 13: p1.v11.0 oo 0 14: p1.v1.1 oo 0 15: p1.v1.2 oo 0 16: p1.v2.1 oo 0 17: p1.v2.2 oo 0 18: p1.val oo 0 19: p1.v3.1 oo 0 20: p1.start oo 0 21: p1.dummy oo 0 22: p1.end oo 0 23: p1.v6.1 oo 0 24: p1.v6.2 oo 0 25: p1.v3.2 oo 0 26: p1.v3.3 oo 0 27: p1.val oo 0 28: p1.v5.1 oo 0 29: p1.v3.4 oo 0 30: p1.v3.5 oo 0 31: p1.v4.1 oo 0 32: p1.v4.2 oo 0 33: p1.val oo 0 34: p1.v7.1 oo 0 35: p1.start oo 0 36: p1.dummy oo 0 37: p1.end oo 0 38: p1.v10.1 oo 0 39: p1.v10.2 oo 0 40: p1.v5.2 oo 0 41: p1.v5.3 oo 0 42: p1.val oo 0 43: p1.v11.1 oo 0 44: p1.v5.4 oo 0 45: p1.v5.5 oo 0

___________________________________________________________________

143

46: p1.v3.6 oo 0 47: p1.v3.7 oo 0 48: p1.val oo 0 49: p1.v8.1 oo 0 50: p1.v7.2 oo 0 51: p1.v7.3 oo 0 52: p1.v1.3 oo 0 53: p1.v1.4 oo 0 54: p1.val oo 0 55: p1.v9.1 oo 0 56: p1.start oo 0 57: p1.dummy oo 0 58: p1.end oo 0 59: p1.v11.2 oo 0 60: p1.v11.3 oo 0 61: p1.v8.2 oo 0 62: p1.v8.3 oo 0 63: p1.val oo 0 64: p1.v1.5 oo 0 65: p1.v8.4 oo 0 66: p1.v8.5 oo 0 67: p1.v9.2 oo 0 68: p1.v9.3 oo 0 69: p1.val oo 0 70: p1.v2.3 oo 0 @ trans nr. name priority time 0: t1.start 0 0 1: t1.end 0 0 2: t1.clone 0 0 3: t1.clone 0 0 4: t1.+ 0 0 5: t1.:= 0 0 6: t1.sink 0 0 7: t1.start 0 0 8: t1.end 0 0 9: t1.clone 0 0 10: t1.clone 0 0 11: t1.* 0 0 12: t1.:= 0 0 13: t1.sink 0 0 14: t1.clone 0 0 15: t1.clone 0 0 16: t1.- 0 0 17: t1.:= 0 0 18: t1.sink 0 0 19: t1.start 0 0 20: t1.end 0 0 21: t1.clone 0 0 22: t1.clone 0 0 23: t1.* 0 0 24: t1.:= 0 0 25: t1.sink 0 0 26: t1.clone 0 0 27: t1.clone 0 0 28: t1.+ 0 0 29: t1.:= 0 0 30: t1.sink 0 0 31: t1.clone 0 0 32: t1.clone 0 0 33: t1.+ 0 0 34: t1.:= 0 0 35: t1.sink 0 0 36: t1.start 0 0 37: t1.end 0 0 38: t1.clone 0 0 39: t1.clone 0 0 40: t1.- 0 0 41: t1.:= 0 0 42: t1.sink 0 0 43: t1.clone 0 0

___________________________________________________________________

144

44: t1.clone 0 0 45: t1.* 0 0 46: t1.:= 0 0 47: t1.sink 0 0 @

A.2 Tempo das Transições – INA (.tmd)

0: 0; 1: 0; 2: 0; 3: 0; 4: 15; 5: 0; 6: 0; 7: 0; 8: 0; 9: 0; 10: 0; 11: 24; 12: 0; 13: 0; 14: 0; 15: 0; 16: 15; 17: 0; 18: 0; 19: 0; 20: 0; 21: 0; 22: 0; 23: 24; 24: 0; 25: 0; 26: 0; 27: 0; 28: 15; 29: 0; 30: 0; 31: 0; 32: 0; 33: 15; 34: 0; 35: 0; 36: 0; 37: 0; 38: 0; 39: 0; 40: 15; 41: 0; 42: 0; 43: 0; 44: 0; 45: 24; 46: 0; 47: 0; @

___________________________________________________________________

145

A.3 Grafo de Estados

State nr. 1 Marking nr. 1 Clocks nr. 1 P.nr: 0 1 2 3 4 5 6 7 8 9 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 44 45 : 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 : 69 70 toks: 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 : 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 : 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 : 0 0 T.nr: 0 1 2 3 4 5 6 7 8 9 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 44 45 : 46 47 time: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 : 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 : 0 0 =={t0}:0=> s2 State nr. 2 Marking nr. 2 Clocks nr. 1 P.nr: 0 1 2 3 4 5 6 7 8 9 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 44 45 : 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 : 69 70 toks: 0 1 0 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 1 0 0 : 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 : 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 : 0 0 T.nr: 0 1 2 3 4 5 6 7 8 9 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 44 45 : 46 47 time: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 : 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 : 0 0 =={t2,t3,t6,t7,t9,t13,t15,t18,t19,t21,t25,t30,t35,t36}:0=> s3 State nr. 3 Marking nr. 3 Clocks nr. 1 P.nr: 0 1 2 3 4 5 6 7 8 9 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 44 45 : 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 : 69 70 toks: 0 1 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 0 0 0 1 0 : 1 1 0 0 0 0 0 0 1 1 0 0 0 1 0 1 1 0 0 0 0 0 0 : 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 : 0 0 T.nr: 0 1 2 3 4 5 6 7 8 9 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 44 45 : 46 47 time: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 : 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 : 0 0 =={t4,t8,t20,t32,t37,t47}:0=> s4 State nr. 4 Marking nr. 4 Clocks nr. 2 P.nr: 0 1 2 3 4 5 6 7 8 9 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 44 45 : 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 : 69 70 toks: 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 : 1 1 0 0 0 0 0 0 1 1 0 0 0 0 1 1 1 0 0 0 0 0 0 : 0 0 0 0 0 0 1 1 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 : 0 0 T.nr: 0 1 2 3 4 5 6 7 8 9 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 44 45 : 46 47 time: 0 0 0 0 15 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 : 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 : 0 0 =={t42}:15=> s5 State nr. 5 Marking nr. 5 Clocks nr. 1

___________________________________________________________________

146

P.nr: 0 1 2 3 4 5 6 7 8 9 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 44 45 : 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 : 69 70 toks: 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 1 : 1 1 0 0 0 0 0 0 1 1 0 0 0 0 1 1 1 0 0 0 0 0 0 : 0 0 0 0 0 0 1 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 : 0 0 T.nr: 0 1 2 3 4 5 6 7 8 9 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 44 45 : 46 47 time: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 : 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 : 0 0 =={t5}:0=> s6 State nr. 6 Marking nr. 6 Clocks nr. 1 P.nr: 0 1 2 3 4 5 6 7 8 9 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 44 45 : 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 : 69 70 toks: 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 1 : 1 1 0 0 0 0 0 0 1 1 0 0 0 0 1 1 1 0 0 0 0 0 0 : 0 0 0 0 0 0 1 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 : 0 0 T.nr: 0 1 2 3 4 5 6 7 8 9 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 44 45 : 46 47 time: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 : 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 : 0 0 =={t10}:0=> s7 State nr. 7 Marking nr. 7 Clocks nr. 1 P.nr: 0 1 2 3 4 5 6 7 8 9 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 44 45 : 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 : 69 70 toks: 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 : 1 1 1 1 0 0 0 0 1 1 0 0 0 0 1 1 1 0 0 0 0 0 0 : 0 0 0 0 0 0 1 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 : 0 0 T.nr: 0 1 2 3 4 5 6 7 8 9 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 44 45 : 46 47 time: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 : 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 : 0 0 =={t11,t14}:0=> s8 State nr. 8 Marking nr. 8 Clocks nr. 3 P.nr: 0 1 2 3 4 5 6 7 8 9 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 44 45 : 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 : 69 70 toks: 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 : 0 1 0 0 0 0 1 1 1 1 0 0 0 0 1 1 1 0 0 0 0 0 0 : 0 0 0 0 0 0 1 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 : 0 0 T.nr: 0 1 2 3 4 5 6 7 8 9 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 44 45 : 46 47 time: 0 0 0 0 0 0 0 0 0 0 0 24 0 0 0 0 0 0 0 0 0 0 0 : 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 : 0 0 =={t16,t27}:15=> s9 State nr. 9 Marking nr. 9 Clocks nr. 4 P.nr: 0 1 2 3 4 5 6 7 8 9 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 44 45 : 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 : 69 70 toks: 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 : 0 1 0 0 0 0 0 0 0 1 1 0 0 0 1 1 1 0 0 0 0 0 0 : 1 1 0 0 0 0 1 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0

___________________________________________________________________

147

: 0 0 T.nr: 0 1 2 3 4 5 6 7 8 9 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 44 45 : 46 47 time: 0 0 0 0 0 0 0 0 0 0 0 9 0 0 0 0 0 0 0 0 0 0 0 : 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 : 0 0 =={t17}:0=> s10 State nr. 10 Marking nr. 10 Clocks nr. 4 P.nr: 0 1 2 3 4 5 6 7 8 9 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 44 45 : 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 : 69 70 toks: 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 : 0 1 0 0 0 0 0 0 0 1 0 1 0 0 1 1 1 0 0 0 0 0 0 : 1 1 0 0 0 0 1 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 : 0 0 T.nr: 0 1 2 3 4 5 6 7 8 9 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 44 45 : 46 47 time: 0 0 0 0 0 0 0 0 0 0 0 9 0 0 0 0 0 0 0 0 0 0 0 : 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 : 0 0 =={t31}:0=> s11 State nr. 11 Marking nr. 11 Clocks nr. 4 P.nr: 0 1 2 3 4 5 6 7 8 9 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 44 45 : 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 : 69 70 toks: 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 : 0 1 0 0 0 0 0 0 0 1 0 0 0 0 1 1 1 0 0 0 0 0 0 : 1 1 0 0 1 1 1 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 : 0 0 T.nr: 0 1 2 3 4 5 6 7 8 9 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 44 45 : 46 47 time: 0 0 0 0 0 0 0 0 0 0 0 9 0 0 0 0 0 0 0 0 0 0 0 : 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 : 0 0 =={t33}:9=> s12 State nr. 12 Marking nr. 12 Clocks nr. 5 P.nr: 0 1 2 3 4 5 6 7 8 9 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 44 45 : 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 : 69 70 toks: 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 : 0 1 0 0 1 0 0 0 0 1 0 0 0 0 1 1 1 0 0 0 0 0 0 : 1 1 0 0 0 1 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 : 0 0 T.nr: 0 1 2 3 4 5 6 7 8 9 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 44 45 : 46 47 time: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 : 0 0 0 0 0 0 0 0 0 0 6 0 0 0 0 0 0 0 0 0 0 0 0 : 0 0 =={t12}:0=> s13 State nr. 13 Marking nr. 13 Clocks nr. 5 P.nr: 0 1 2 3 4 5 6 7 8 9 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 44 45 : 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 : 69 70 toks: 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 : 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1 1 0 0 0 0 0 0 : 1 1 0 0 0 1 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 : 0 0 T.nr: 0 1 2 3 4 5 6 7 8 9 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 44 45 : 46 47 time: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 : 0 0 0 0 0 0 0 0 0 0 6 0 0 0 0 0 0 0 0 0 0 0 0 : 0 0

___________________________________________________________________

148

=={t22}:0=> s14 State nr. 14 Marking nr. 14 Clocks nr. 5 P.nr: 0 1 2 3 4 5 6 7 8 9 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 44 45 : 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 : 69 70 toks: 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 : 0 1 0 0 0 0 0 0 0 1 0 0 0 0 1 1 1 1 1 0 0 0 0 : 1 1 0 0 0 1 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 : 0 0 T.nr: 0 1 2 3 4 5 6 7 8 9 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 44 45 : 46 47 time: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 : 0 0 0 0 0 0 0 0 0 0 6 0 0 0 0 0 0 0 0 0 0 0 0 : 0 0 =={t23,t26}:0=> s15 State nr. 15 Marking nr. 15 Clocks nr. 6 P.nr: 0 1 2 3 4 5 6 7 8 9 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 44 45 : 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 : 69 70 toks: 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 : 0 1 0 0 0 0 0 0 0 1 0 0 0 0 1 0 1 0 0 0 0 1 1 : 1 1 0 0 0 1 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 : 0 0 T.nr: 0 1 2 3 4 5 6 7 8 9 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 44 45 : 46 47 time: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 : 24 0 0 0 0 0 0 0 0 0 6 0 0 0 0 0 0 0 0 0 0 0 0 : 0 0 =={t28}:6=> s16 State nr. 16 Marking nr. 16 Clocks nr. 7 P.nr: 0 1 2 3 4 5 6 7 8 9 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 44 45 : 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 : 69 70 toks: 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 : 0 1 0 0 0 0 0 0 0 1 0 0 0 0 1 0 1 0 0 0 0 0 1 : 0 1 0 0 0 1 0 0 1 0 0 0 1 0 0 0 0 0 0 0 0 0 0 : 0 0 T.nr: 0 1 2 3 4 5 6 7 8 9 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 44 45 : 46 47 time: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 : 18 0 0 0 0 9 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 : 0 0 =={t34}:0=> s17 State nr. 17 Marking nr. 17 Clocks nr. 7 P.nr: 0 1 2 3 4 5 6 7 8 9 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 44 45 : 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 : 69 70 toks: 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 : 0 1 0 0 0 0 0 0 0 1 0 0 0 0 1 0 1 0 0 0 0 0 1 : 0 1 0 0 0 1 0 0 0 1 0 0 1 0 0 0 0 0 0 0 0 0 0 : 0 0 T.nr: 0 1 2 3 4 5 6 7 8 9 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 44 45 : 46 47 time: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 : 18 0 0 0 0 9 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 : 0 0 =={t44}:9=> s18 State nr. 18 Marking nr. 18 Clocks nr. 8 P.nr: 0 1 2 3 4 5 6 7 8 9 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 44 45 : 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 : 69 70 toks: 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1

___________________________________________________________________

149

: 0 1 0 0 0 0 0 0 0 1 0 0 0 0 1 0 1 0 0 0 0 0 1 : 0 1 1 0 0 1 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 1 1 : 0 0 T.nr: 0 1 2 3 4 5 6 7 8 9 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 44 45 : 46 47 time: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 : 9 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 : 0 0 =={t29}:0=> s19 State nr. 19 Marking nr. 19 Clocks nr. 8 P.nr: 0 1 2 3 4 5 6 7 8 9 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 44 45 : 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 : 69 70 toks: 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 : 0 1 0 0 0 0 0 0 0 1 0 0 0 0 1 0 1 0 0 0 0 0 1 : 0 1 0 1 0 1 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 1 1 : 0 0 T.nr: 0 1 2 3 4 5 6 7 8 9 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 44 45 : 46 47 time: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 : 9 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 : 0 0 =={t39}:0=> s20 State nr. 20 Marking nr. 20 Clocks nr. 8 P.nr: 0 1 2 3 4 5 6 7 8 9 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 44 45 : 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 : 69 70 toks: 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 : 0 1 0 0 0 0 0 0 0 1 0 0 0 0 1 0 1 0 0 0 0 0 1 : 0 1 0 0 0 1 0 0 0 0 0 0 1 0 0 1 1 0 0 0 0 1 1 : 0 0 T.nr: 0 1 2 3 4 5 6 7 8 9 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 44 45 : 46 47 time: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 : 9 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 : 0 0 =={t43}:0=> s21 State nr. 21 Marking nr. 21 Clocks nr. 8 P.nr: 0 1 2 3 4 5 6 7 8 9 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 44 45 : 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 : 69 70 toks: 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 : 0 1 0 0 0 0 0 0 0 1 0 0 0 0 1 0 1 0 0 0 0 0 1 : 0 1 0 0 0 1 0 0 0 0 0 0 1 0 0 1 0 0 0 1 1 1 1 : 0 0 T.nr: 0 1 2 3 4 5 6 7 8 9 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 44 45 : 46 47 time: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 : 9 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 : 0 0 =={t45}:9=> s22 State nr. 22 Marking nr. 22 Clocks nr. 9 P.nr: 0 1 2 3 4 5 6 7 8 9 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 44 45 : 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 : 69 70 toks: 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 : 0 1 0 0 0 0 0 0 0 1 0 0 0 0 1 0 1 0 0 1 0 0 1 : 0 1 0 0 0 1 0 0 0 0 0 0 1 0 0 1 0 0 0 0 1 0 1 : 0 0 T.nr: 0 1 2 3 4 5 6 7 8 9 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 44 45 : 46 47 time: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

___________________________________________________________________

150

: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 15 : 0 0 =={t24}:0=> s23 State nr. 23 Marking nr. 23 Clocks nr. 9 P.nr: 0 1 2 3 4 5 6 7 8 9 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 44 45 : 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 : 69 70 toks: 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 : 0 1 0 0 0 0 0 0 0 1 0 0 0 0 1 0 1 0 0 0 1 0 1 : 0 1 0 0 0 1 0 0 0 0 0 0 1 0 0 1 0 0 0 0 1 0 1 : 0 0 T.nr: 0 1 2 3 4 5 6 7 8 9 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 44 45 : 46 47 time: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 : 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 15 : 0 0 =={t38}:0=> s24 State nr. 24 Marking nr. 24 Clocks nr. 9 P.nr: 0 1 2 3 4 5 6 7 8 9 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 44 45 : 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 : 69 70 toks: 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 : 0 1 0 0 0 0 0 0 0 1 0 0 0 0 1 0 1 0 0 0 0 0 1 : 0 1 0 0 0 1 0 0 0 0 0 0 1 1 1 1 0 0 0 0 1 0 1 : 0 0 T.nr: 0 1 2 3 4 5 6 7 8 9 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 44 45 : 46 47 time: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 : 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 15 : 0 0 =={t40}:15=> s25 State nr. 25 Marking nr. 25 Clocks nr. 1 P.nr: 0 1 2 3 4 5 6 7 8 9 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 44 45 : 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 : 69 70 toks: 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 : 0 1 0 0 0 0 0 0 0 1 0 0 0 0 1 0 1 0 0 0 0 0 1 : 0 1 0 0 0 1 0 0 0 0 0 0 1 0 1 0 0 1 0 0 1 0 1 : 1 0 T.nr: 0 1 2 3 4 5 6 7 8 9 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 44 45 : 46 47 time: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 : 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 : 0 0 =={t41,t46}:0=> s26 State nr. 26 Marking nr. 26 Clocks nr. 1 P.nr: 0 1 2 3 4 5 6 7 8 9 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 44 45 : 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 : 69 70 toks: 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 : 0 1 0 0 0 0 0 0 0 1 0 0 0 0 1 0 1 0 0 0 0 0 1 : 0 1 0 0 0 1 0 0 0 0 0 0 1 0 1 0 0 0 1 0 1 0 1 : 0 1 T.nr: 0 1 2 3 4 5 6 7 8 9 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 44 45 : 46 47 time: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 : 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 : 0 0 =={t1}:0=> s27 State nr. 27 Marking nr. 27 Clocks nr. 1 P.nr: 0 1 2 3 4 5 6 7 8 9 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 44 45 : 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68

___________________________________________________________________

151

: 69 70 toks: 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 : 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 : 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 : 0 0 T.nr: 0 1 2 3 4 5 6 7 8 9 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 44 45 : 46 47 time: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 : 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 : 0 0

dead state

Apêndice B

Equação Diferencial de 2a Ordem

B.1 Descrição em VHDL

Este benchmark foi derivado de [5].

------------------------------------------------------------------------------ -- -- Differential Equation Benchmark -- -- Source: Adapted from example in paper -- "HAL: A Multi-Paradigm Approach to Automatic Data Path Synthesis" -- by P. Paulin, J. Knight and E. Girczyc -- 23rd DAC, June 1986, pp. 263-270 -- -- Benchmark author: Joe Lis -- -- Copyright (c) 1989 by Joe Lis -- -- Modified by Champaka Ramachandran on Aug 17th 1992 -- -- Verification Information: -- -- Verified By whom? Date Simulator -- -------- ------------ -------- ------------ -- Syntax yes Champaka Ramachandran 17th Aug 92 ZYCAD -- Functionality yes Champaka Ramachandran 17th Aug 92 ZYCAD ------------------------------------------------------------------------------ entity diffeq is port (Xinport: in integer; Xoutport: out integer; DXport: in integer; Aport: in integer; Yinport: in integer; Youtport: out integer; Uinport: in integer; Uoutport: out integer); end diffeq; --VSS: design_style BEHAVIORAL architecture diffeq of diffeq is begin P1 : process (Aport, DXport, Xinport, Yinport, Uinport)

___________________________________________________________________

153

variable x_var,y_var,u_var, a_var, dx_var: integer ; variable x1, y1, t1,t2,t3,t4,t5,t6: integer ; begin x_var := Xinport; a_var := Aport; dx_var := DXport; y_var := Yinport; u_var := Uinport; while (x_var < a_var) loop t1 := u_var * dx_var; t2 := 3 * x_var; t3 := 3 * y_var; t4 := t1 * t2; t5 := dx_var * t3; t6 := u_var - t4; u_var := t6 - t5; y1 := u_var * dx_var; y_var := y_var + y1; x_var := x_var + dx_var; end loop; Xoutport <= x_var; Youtport <= y_var; Uoutport <= u_var; end process P1; end diffeq;

B.2 Descrição em Occam

INT x_var, y_var, u_var, a_var, dx_var: INT x1, y1, t1, t2, t3, t4, t5, t6: SEQ x_var ? XINPORT; a_var ? APORT; dx_var ? DXPORT; y_var ? YINPORT; u_var ? UINPORT; WHILE (x_var < a_var) SEQ t1 := u_var * dx_var; t2 := 3 * x_var; t3 := 3 * y_var; t4 := t1 * t2; t5 := dx_var * t3; t6 := u_var - t4; u_var := t6 - t5; y1 := u_var * dx_var; y_var := y_var + y1; x_var := x_var + dx_var; XOUTPORT ! x_var; YOUTPORT ! y_var; UOUTPORT ! u_var;

___________________________________________________________________

154

B.3 Modelo Intermediário – INA (.pnt )

P M PRE,POST NETZ 0:DEB1 0 1 , 0 1 0 0, 1 2 0 1 3 0 0, 3 4 0 0, 9 5 0 0, 11 6 0 0, 5 7 0 0, 7 8 0 0, 1 9 0 0, 56 10 0 0, 23 11 0 0, 27 12 0 0, 31 13 0 0, 36 14 0 0, 41 15 0 0, 46 16 0 0, 2 17 0 2, 14 18 0 0, 4 19 0 4, 15 20 0 0, 6 21 0 6, 20 22 0 0, 8 23 0 8, 28 24 0 0, 10 25 0 10, 19 26 0 0, 12 27 0 12, 13 28 0 13, 1 29 0 14, 16 30 0 14, 24 31 0 15, 16 32 0 15, 68 33 0 16, 12 34 0 12, 17 35 0 17, 18 36 0 18, 13 37 0 19, 21 38 0 19, 42 39 0 20, 21 40 0 20, 37 41 0 21, 22 42 0 22, 32 43 0 17, 25 44 0 24, 25 45 0 24, 62 46 0 25, 26 47 0 26, 33 48 0 17, 29 49 0 28, 29 50 0 28, 57 51 0 29, 30 52 0 30, 38 53 0 32, 34 54 0 32, 1 55 0 33, 34 56 0 33, 1 57 0 34, 35 58 0 35, 43 59 0 37, 39 60 0 37, 53 61 0 38, 39 62 0 38, 1 63 0 39, 40

___________________________________________________________________

155

64 0 40, 48 65 0 42, 44 66 0 42, 51 67 0 43, 44 68 0 43, 1 69 0 44, 45 70 0 45, 47 71 0 47, 49 72 0 47, 1 73 0 48, 49 74 0 48, 1 75 0 49, 50 76 0 50, 52 77 0 52, 54 78 0 52, 1 79 0 53, 54 80 0 53, 63 81 0 54, 55 82 0 55, 58 83 0 57, 59 84 0 57, 61 85 0 58, 59 86 0 58, 1 87 0 59, 60 88 0 60, 1 89 0 62, 64 90 0 62, 66 91 0 63, 64 92 0 63, 1 93 0 64, 65 94 0 65, 67 95 0 67, 69 96 0 67, 1 97 0 68, 69 98 0 68, 1 99 0 69, 13 @ place nr. name capacity time 0: p1.start oo 0 1: p1.dummy oo 0 2: p1.end oo 0 3: p1.xVar.0 oo 0 4: p1.yVar.0 oo 0 5: p1.uVar.0 oo 0 6: p1.aVar.0 oo 0 7: p1.dxVar.0 oo 0 8: p1.x1.0 oo 0 9: p1.y1.0 oo 0 10: p1.t1.0 oo 0 11: p1.t2.0 oo 0 12: p1.t3.0 oo 0 13: p1.t4.0 oo 0 14: p1.t5.0 oo 0 15: p1.t6.0 oo 0 16: p1.val[90] oo 0 17: p1.xVar.1 oo 0 18: p1.val[91] oo 0 19: p1.aVar.1 oo 0 20: p1.val[92] oo 0 21: p1.dxVar.1 oo 0 22: p1.val[93] oo 0 23: p1.yVar.1 oo 0 24: p1.val[94] oo 0 25: p1.uVar.1 oo 0 26: p1.start oo 0 27: p1.dummy oo 0 28: p1.end oo 0 29: p1.xVar.2 oo 0 30: p1.xVar.3 oo 0 31: p1.aVar.2 oo 0 32: p1.aVar.3 oo 0

___________________________________________________________________

156

33: p1.val oo 0 34: p1.start oo 0 35: p1.dummy oo 0 36: p1.end oo 0 37: p1.uVar.2 oo 0 38: p1.uVar.3 oo 0 39: p1.dxVar.2 oo 0 40: p1.dxVar.3 oo 0 41: p1.val oo 0 42: p1.t1.1 oo 0 43: p1.val[3] oo 0 44: p1.xVar.4 oo 0 45: p1.xVar.5 oo 0 46: p1.val oo 0 47: p1.t2.1 oo 0 48: p1.val[3] oo 0 49: p1.yVar.2 oo 0 50: p1.yVar.3 oo 0 51: p1.val oo 0 52: p1.t3.1 oo 0 53: p1.t1.2 oo 0 54: p1.t1.3 oo 0 55: p1.t2.2 oo 0 56: p1.t2.3 oo 0 57: p1.val oo 0 58: p1.t4.1 oo 0 59: p1.dxVar.4 oo 0 60: p1.dxVar.5 oo 0 61: p1.t3.2 oo 0 62: p1.t3.3 oo 0 63: p1.val oo 0 64: p1.t5.1 oo 0 65: p1.uVar.4 oo 0 66: p1.uVar.5 oo 0 67: p1.t4.2 oo 0 68: p1.t4.3 oo 0 69: p1.val oo 0 70: p1.t6.1 oo 0 71: p1.t6.2 oo 0 72: p1.t6.3 oo 0 73: p1.t5.2 oo 0 74: p1.t5.3 oo 0 75: p1.val oo 0 76: p1.uVar.6 oo 0 77: p1.uVar.7 oo 0 78: p1.uVar.8 oo 0 79: p1.dxVar.6 oo 0 80: p1.dxVar.7 oo 0 81: p1.val oo 0 82: p1.y1.1 oo 0 83: p1.yVar.4 oo 0 84: p1.yVar.5 oo 0 85: p1.y1.2 oo 0 86: p1.y1.3 oo 0 87: p1.val oo 0 88: p1.yVar.6 oo 0 89: p1.xVar.6 oo 0 90: p1.xVar.7 oo 0 91: p1.dxVar.8 oo 0 92: p1.dxVar.9 oo 0 93: p1.val oo 0 94: p1.xVar.8 oo 0 95: p1.xVar.9 oo 0 96: p1.xVar.10 oo 0 97: p1.aVar.4 oo 0 98: p1.aVar.5 oo 0 99: p1.val oo 0 @ trans nr. name priority time 0: t1.start 0 0 1: t1.end 0 0

___________________________________________________________________

157

2: t1.:= 0 0 3: t1.sink 0 0 4: t1.:= 0 0 5: t1.sink 0 0 6: t1.:= 0 0 7: t1.sink 0 0 8: t1.:= 0 0 9: t1.sink 0 0 10: t1.:= 0 0 11: t1.sink 0 0 12: t1.start 0 0 13: t1.end 0 0 14: t1.clone 0 0 15: t1.clone 0 0 16: t1.< 0 0 17: t1.start 0 0 18: t1.end 0 0 19: t1.clone 0 0 20: t1.clone 0 0 21: t1.* 0 0 22: t1.:= 0 0 23: t1.sink 0 0 24: t1.clone 0 0 25: t1.* 0 0 26: t1.:= 0 0 27: t1.sink 0 0 28: t1.clone 0 0 29: t1.* 0 0 30: t1.:= 0 0 31: t1.sink 0 0 32: t1.clone 0 0 33: t1.clone 0 0 34: t1.* 0 0 35: t1.:= 0 0 36: t1.sink 0 0 37: t1.clone 0 0 38: t1.clone 0 0 39: t1.* 0 0 40: t1.:= 0 0 41: t1.sink 0 0 42: t1.clone 0 0 43: t1.clone 0 0 44: t1.- 0 0 45: t1.:= 0 0 46: t1.sink 0 0 47: t1.clone 0 0 48: t1.clone 0 0 49: t1.- 0 0 50: t1.:= 0 0 51: t1.sink 0 0 52: t1.clone 0 0 53: t1.clone 0 0 54: t1.* 0 0 55: t1.:= 0 0 56: t1.sink 0 0 57: t1.clone 0 0 58: t1.clone 0 0 59: t1.+ 0 0 60: t1.:= 0 0 61: t1.sink 0 0 62: t1.clone 0 0 63: t1.clone 0 0 64: t1.+ 0 0 65: t1.:= 0 0 66: t1.sink 0 0 67: t1.clone 0 0 68: t1.clone 0 0 69: t1.< 0 0 @

___________________________________________________________________

158

B.4 Esquemático do Modelo Intermediário1

0: p 1. sta rt

0: t1 .s tart

1: p 1. dum m y

1: t1 .end

2: p 1. end

3: p 1. xVar.0

3: t1 .s in k

4: p 1. yVa r. 0

9: t1 .s in k

5: p 1. uVar.0

11 :t1 .s ink

6: p 1. aVar. 0

5: t1 .s in k

7: p 1. dxVar.0

7: t1 .s in k

8: p 1. x1 .0

9: p 1. y1.0

56 :t1 .s ink

10 :p1 .t1 .0

23 :t1 .s ink

11 :p1 .t2 .0

27 :t1 .s ink

12 :p1 .t3 .0

31 :t1 .s ink

13 :p1 .t4 .0

36 :t1 .s ink

14 :p1 .t5 .0

41 :t1 .s ink

15 :p1 .t6 .0

46 :t1 .s ink

16 :p1 .va l[9 0]

2: t1 .:=

17 :p1 .xVar.1

14 :t1 .c lone

18 :p1 .va l[9 1]

4: t1 .:=

19 :p1 .aVar.1

15 :t1 .c lone 20 :p1 .va l[9 2]

6: t1 .:=

21 :p1 .dxVa r.1

20 :t1 .c lone

22 :p1 .va l[9 3]

8: t1 .:=

23 :p1 .yVar.1

28 :t1 .c lone

24 :p1 .va l[9 4]

10 :t1 .: =

25 :p1 .uVar.1

19 :t1 .c lone

26 :p1 .s tart

12 :t1 .s tart

27 :p1 .dum m y

13 :t1 .en d

28 :p1 .end

29 :p1 .xVar.2

16 :t1 .< 30 :p1 .xVar.3

24 :t1 .c lone

31 :p1 .aVar.232 :p1 .aVar.3

68 :t1 .c lone

33 :p1 .va l

34 :p1 .s tart

17 :t1 .s tart

35 :p1 .dum m y

18 :t1 .en d

36 :p1 .end

37 :p1 .uVar.2

21 :t1 .*

38 :p1 .uVar.3

42 :t1 .c lone

39 :p1 .dxVa r.2

40 :p1 .dxVa r.3

37 :t1 .c lone

41 :p1 .va l

22 :t1 .: =

42 :p1 .t1 .1

32 :t1 .c lone

43 :p1 .va l[3 ]

25 :t1 .*

44 :p1 .xVar.4 45 :p1 .xVar.5

62 :t1 .c lone

46 :p1 .va l

26 :t1 .: =

47 :p1 .t2 .1

33 :t1 .c lone

48 :p1 .va l[3 ]

29 :t1 .*

49 :p1 .yVar.2 50 :p1 .yVar.3

57 :t1 .c lone

51 :p1 .va l

30 :t1 .: =

52 :p1 .t3 .1

38 :t1 .c lone

53 :p1 .t1 .2

34 :t1 .*

54 :p1 .t1 .3

55 :p1 .t2 .2

56 :p1 .t2 .3

57 :p1 .va l

35 :t1 .: =

58 :p1 .t4 .1

43 :t1 .c lone

59 :p1 .dxVa r.4

39 :t1 .*

60 :p1 .dxVa r.5

53 :t1 .c lone

61 :p1 .t3 .2

62 :p1 .t3 .3

63 :p1 .va l

40 :t1 .: =

64 :p1 .t5 .1

48 :t1 .c lone

65 :p1 .uVar.4

44 :t1 .-

66 :p1 .uVar.5

51 :t1 .s ink

67 :p1 .t4 .2

68 :p1 .t4 .3

69 :p1 .va l

45 :t1 .: =

70 :p1 .t6 .1

47 :t1 .c lone

71 :p1 .t6 .2

49 :t1 .-

72 :p1 .t6 .3

73 :p1 .t5 .2

74 :p1 .t5 .3

75 :p1 .va l

50 :t1 .: =

76 :p1 .uVar.6

52 :t1 .c lone

77 :p1 .uVar.7

54 :t1 .*

78 :p1 .uVar.8

79 :p1 .dxVa r.6

80 :p1 .dxVa r.7

63 :t1 .c lone

81 :p1 .va l

55 :t1 .: =

82 :p1 .y1 .1

58 :t1 .c lone

83 :p1 .yVar.4

59 :t1 .+

84 :p1 .yVar.5

61 :t1 .s ink

85 :p1 .y1 .2

86 :p1 .y1 .3

87 :p1 .va l

60 :t1 .: =

88 :p1 .yVar.6

89 :p1 .xVar.6

64 :t1 .+

90 :p1 .xVar.7

66 :t1 .s ink

91 :p1 .dxVa r.8

92 :p1 .dxVa r.9

93 :p1 .va l

65 :t1 .: =

94 :p1 .xVar.8

67 :t1 .c lone

95 :p1 .xVar.9

69 :t1 .<

96 :p1 .xVar.1 0

97 :p1 .aVar.4

98 :p1 .aVar.5

99 :p1 .va l

1O modelo é reversível se acrescentamos uma transição de fechamento entre o último e o primeiro lugar.

Apêndice C

Filtro de Ondas Elíptico de 5a Ordem.

C.1 Descrição em VHDL

Este benchmark é derivado de descrições em [36] e [54].

---------------------------------------------------------------------------- -- -- -- Elliptical Wave Filter Benchmark -- -- -- VHDL Benchmark author: D. Sreenivasa Rao -- University Of California, Irvine, CA 92717 -- dsr@balboa.eng.uci.edu, (714)856-5106 -- -- Developed on 12 September, 1992 -- -- Verification Information: -- -- Verified By whom? Date Simulator -- -------- ------------ -------- ------------ -- Syntax yes DSR 09/12/92 ZYCAD -- Functionality yes DSR 09/12/92 ZYCAD ------------------------------------------------------------------------------ --use std.std_logic.all; use work.bit_functions.all; entity ellipf is port ( inp : in BIT_VECTOR(15 downto 0); outp : out BIT_VECTOR(15 downto 0); sv2, sv13, sv18, sv26, sv33, sv38, sv39 : in BIT_VECTOR(15 downto 0); sv2_o, sv13_o, sv18_o, sv26_o, sv33_o, sv38_o, sv39_o : out bit_vector(15 downto 0)); end ellipf; architecture ellipf of ellipf is begin process (inp, sv2, sv13, sv18, sv26, sv33, sv38, sv39) -- constant m1, m2, m3, m4, m5, m6, m7, m8 : integer := (1,1,1,1,1,1,1,1); variable n1, n2, n3, n4, n5, n6, n7 : BIT_VECTOR(15 downto 0); variable n8, n9, n10, n11, n12, n13 : BIT_VECTOR(15 downto 0); variable n14, n15, n16, n17, n18, n19 : BIT_VECTOR(15 downto 0);

___________________________________________________________________

160

variable n20, n21, n22, n23, n24, n25 : BIT_VECTOR(15 downto 0); variable n26, n27, n28, n29 : BIT_VECTOR(15 downto 0); -- constant i : integer := (1); begin -- while (i = 1) LOOP n1 := inp + sv2; n2 := sv33 + sv39; n3 := n1 + sv13; n4 := n3 + sv26; n5 := n4 + n2; n6 := n5 ; n7 := n5 ; n8 := n3 + n6; n9 := n7 + n2; n10 := n3 + n8; n11 := n8 + n5; n12 := n2 + n9; n13 := n10 ; n14 := n12 ; n15 := n1 + n13; n16 := n14 + sv39; n17 := n1 + n15; n18 := n15 + n8; n19 := n9 + n16; n20 := n16 + sv39; n21 := n17 ; n22 := n18 + sv18; n23 := sv38 + n19; n24 := n20 ; n25 := inp + n21; n26 := n22 ; n27 := n23 ; n28 := n26 + sv18; n29 := n27 + sv38; sv2_o <= n25 + n15; sv13_o <= n17 + n28; sv18_o <= n28; sv26_o <= n9 + n11; sv38_o <= n29; sv33_o <= n19 + n29; sv39_o <= n16 + n24; outp <= n24; -- end LOOP; end process; end ellipf; --configuration ellipcon of ellipf is -- for ellip_beh -- end for; --end ellipcon;

C.2 Descrição em Occam

PAR INT INP, OUTP, SV2, SV13, SV18, SV26, SV33, SV38, SV39: INT SV2o, SV13o, SV18o, SV26o, SV33o, SV38o, SV39o: INT n1, n2, n3, n4, n5, n6, n7: INT n8, n9, n10, n11, n12, n13, n14: INT n15, n16, n17, n18, n19, n20, n21: INT n22, n23, n24, n25, n26, n27, n28, n29: SEQ n1 := INP + SV2

___________________________________________________________________

161

n2 := SV33 + SV39 n3 := n1 + SV13 n4 := n3 + SV26 n5 := n4 + n2 n6 := n5 n7 := n5 n8 := n3 + n6 n9 := n7 + n2 n10 := n3 + n8 n11 := n8 + n5 n12 := n2 + n9 n13 := n10 n14 := n12 n15 := n1 + n13 n16 := n14 + SV39 n17 := n1 + n15 n18 := n15 + n8 n19 := n9 + n16 n20 := n16 + SV39 n21 := n17 n22 := n18 + SV18 n23 := SV38 + n19 n24 := n20 n25 := INP + n21 n26 := n22 n27 := n23 n28 := n26 + SV18 n29 := n27 + SV38 SV2o := n25 + n15 SV13o := n17 + n28 SV18o := n28 SV26o := n9 + n11 SV38o := n29 SV33o := n19 + n29 SV39o := n16 + n24 OUTP := n24

C.3 Modelo Intermediário – INA (.pnt )

P M PRE,POST NETZ 0:EWFB3 0 1 , 0 1 0 0, 1 2 0 1 3 0 0, 2 4 0 0, 6 5 0 0, 11 6 0 0, 16 7 0 0, 21 8 0 0, 26 9 0 0, 29 10 0 0, 32 11 0 0, 37 12 0 0, 42 13 0 0, 47 14 0 0, 52 15 0 0, 57 16 0 0, 60 17 0 0, 63 18 0 0, 68 19 0 0, 73 20 0 0, 78 21 0 0, 83 22 0 0, 88 23 0 0, 93

___________________________________________________________________

162

24 0 0, 96 25 0 0, 101 26 0 0, 106 27 0 0, 109 28 0 0, 114 29 0 0, 117 30 0 0, 120 31 0 0, 125 32 0 0, 130 33 0 2, 4 34 0 2, 3 35 0 3, 4 36 0 3, 7 37 0 4, 5 38 0 5, 12 39 0 7, 9 40 0 7, 8 41 0 8, 9 42 0 8, 13 43 0 9, 10 44 0 10, 23 45 0 12, 14 46 0 12, 64 47 0 13, 14 48 0 13, 18 49 0 14, 15 50 0 15, 17 51 0 17, 19 52 0 17, 33 53 0 18, 19 54 0 18, 70 55 0 19, 20 56 0 20, 22 57 0 22, 24 58 0 22, 1 59 0 23, 24 60 0 23, 39 61 0 24, 25 62 0 25, 27 63 0 27, 28 64 0 27, 30 65 0 28, 34 66 0 30, 31 67 0 30, 49 68 0 31, 38 69 0 33, 35 70 0 33, 43 71 0 34, 35 72 0 34, 1 73 0 35, 36 74 0 36, 44 75 0 38, 40 76 0 38, 1 77 0 39, 40 78 0 39, 53 79 0 40, 41 80 0 41, 54 81 0 43, 45 82 0 43, 1 83 0 44, 45 84 0 44, 48 85 0 45, 46 86 0 46, 58 87 0 48, 50 88 0 48, 80 89 0 49, 50 90 0 49, 1 91 0 50, 51 92 0 51, 145 93 0 53, 55 94 0 53, 1

___________________________________________________________________

163

95 0 54, 55 96 0 54, 84 97 0 55, 56 98 0 56, 61 99 0 58, 59 100 0 58, 1 101 0 59, 65 102 0 61, 62 103 0 61, 1 104 0 62, 69 105 0 64, 66 106 0 64, 74 107 0 65, 66 108 0 65, 1 109 0 66, 67 110 0 67, 75 111 0 69, 71 112 0 69, 1 113 0 70, 71 114 0 70, 90 115 0 71, 72 116 0 72, 85 117 0 74, 76 118 0 74, 1 119 0 75, 76 120 0 75, 79 121 0 76, 77 122 0 77, 94 123 0 79, 81 124 0 79, 132 125 0 80, 81 126 0 80, 1 127 0 81, 82 128 0 82, 97 129 0 84, 86 130 0 84, 144 131 0 85, 86 132 0 85, 89 133 0 86, 87 134 0 87, 103 135 0 89, 91 136 0 89, 157 137 0 90, 91 138 0 90, 98 139 0 91, 92 140 0 92, 107 141 0 94, 95 142 0 94, 136 143 0 95, 111 144 0 97, 99 145 0 97, 1 146 0 98, 99 147 0 98, 102 148 0 99, 100 149 0 100, 115 150 0 102, 104 151 0 102, 110 152 0 103, 104 153 0 103, 152 154 0 104, 105 155 0 105, 118 156 0 107, 108 157 0 107, 1 158 0 108, 158 159 0 110, 112 160 0 110, 122 161 0 111, 112 162 0 111, 1 163 0 112, 113 164 0 113, 131 165 0 115, 116

___________________________________________________________________

164

166 0 115, 1 167 0 116, 121 168 0 118, 119 169 0 118, 1 170 0 119, 126 171 0 121, 123 172 0 121, 1 173 0 122, 123 174 0 122, 127 175 0 123, 124 176 0 124, 137 177 0 126, 128 178 0 126, 1 179 0 127, 128 180 0 127, 135 181 0 128, 129 182 0 129, 149 183 0 131, 133 184 0 131, 1 185 0 132, 133 186 0 132, 1 187 0 133, 134 188 0 134, 140 189 0 136, 138 190 0 136, 1 191 0 137, 138 192 0 137, 141 193 0 138, 139 194 0 139, 143 195 0 141, 142 196 0 141, 1 197 0 142, 148 198 0 144, 146 199 0 144, 1 200 0 145, 146 201 0 145, 1 202 0 146, 147 203 0 147, 151 204 0 149, 150 205 0 149, 153 206 0 150, 156 207 0 152, 154 208 0 152, 1 209 0 153, 154 210 0 153, 1 211 0 154, 155 212 0 155, 161 213 0 157, 159 214 0 157, 1 215 0 158, 159 216 0 158, 162 217 0 159, 160 218 0 160, 164 219 0 162, 163 220 0 162, 1 221 0 163, 1 @ place nr. name capacity time 0: p1.start oo 0 1: p1.dummy oo 0 2: p1.end oo 0 3: p1.CANAL.0 oo 0 4: p1.n1.0 oo 0 5: p1.n2.0 oo 0 6: p1.n3.0 oo 0 7: p1.n4.0 oo 0 8: p1.n5.0 oo 0 9: p1.n6.0 oo 0 10: p1.n7.0 oo 0 11: p1.n8.0 oo 0 12: p1.n9.0 oo 0

___________________________________________________________________

165

13: p1.n10.0 oo 0 14: p1.n11.0 oo 0 15: p1.n12.0 oo 0 16: p1.n13.0 oo 0 17: p1.n14.0 oo 0 18: p1.n15.0 oo 0 19: p1.n16.0 oo 0 20: p1.n17.0 oo 0 21: p1.n18.0 oo 0 22: p1.n19.0 oo 0 23: p1.n20.0 oo 0 24: p1.n21.0 oo 0 25: p1.n22.0 oo 0 26: p1.n23.0 oo 0 27: p1.n24.0 oo 0 28: p1.n25.0 oo 0 29: p1.n26.0 oo 0 30: p1.n27.0 oo 0 31: p1.n28.0 oo 0 32: p1.n29.0 oo 0 33: p1.CANAL.1 oo 0 34: p1.CANAL.2 oo 0 35: p1.CANAL.3 oo 0 36: p1.CANAL.4 oo 0 37: p1.val oo 0 38: p1.n1.1 oo 0 39: p1.CANAL.5 oo 0 40: p1.CANAL.6 oo 0 41: p1.CANAL.7 oo 0 42: p1.CANAL.8 oo 0 43: p1.val oo 0 44: p1.n2.1 oo 0 45: p1.n1.2 oo 0 46: p1.n1.3 oo 0 47: p1.CANAL.9 oo 0 48: p1.CANAL.10 oo 0 49: p1.val oo 0 50: p1.n3.1 oo 0 51: p1.n3.2 oo 0 52: p1.n3.3 oo 0 53: p1.CANAL.11 oo 0 54: p1.CANAL.12 oo 0 55: p1.val oo 0 56: p1.n4.1 oo 0 57: p1.n4.2 oo 0 58: p1.n4.3 oo 0 59: p1.n2.2 oo 0 60: p1.n2.3 oo 0 61: p1.val oo 0 62: p1.n5.1 oo 0 63: p1.n5.2 oo 0 64: p1.n5.3 oo 0 65: p1.n6.1 oo 0 66: p1.n5.4 oo 0 67: p1.n5.5 oo 0 68: p1.n7.1 oo 0 69: p1.n3.4 oo 0 70: p1.n3.5 oo 0 71: p1.n6.2 oo 0 72: p1.n6.3 oo 0 73: p1.val oo 0 74: p1.n8.1 oo 0 75: p1.n7.2 oo 0 76: p1.n7.3 oo 0 77: p1.n2.4 oo 0 78: p1.n2.5 oo 0 79: p1.val oo 0 80: p1.n9.1 oo 0 81: p1.n3.6 oo 0 82: p1.n3.7 oo 0 83: p1.n8.2 oo 0

___________________________________________________________________

166

84: p1.n8.3 oo 0 85: p1.val oo 0 86: p1.n10.1 oo 0 87: p1.n8.4 oo 0 88: p1.n8.5 oo 0 89: p1.n5.6 oo 0 90: p1.n5.7 oo 0 91: p1.val oo 0 92: p1.n11.1 oo 0 93: p1.n2.6 oo 0 94: p1.n2.7 oo 0 95: p1.n9.2 oo 0 96: p1.n9.3 oo 0 97: p1.val oo 0 98: p1.n12.1 oo 0 99: p1.n10.2 oo 0 100: p1.n10.3 oo 0 101: p1.n13.1 oo 0 102: p1.n12.2 oo 0 103: p1.n12.3 oo 0 104: p1.n14.1 oo 0 105: p1.n1.4 oo 0 106: p1.n1.5 oo 0 107: p1.n13.2 oo 0 108: p1.n13.3 oo 0 109: p1.val oo 0 110: p1.n15.1 oo 0 111: p1.n14.2 oo 0 112: p1.n14.3 oo 0 113: p1.CANAL.13 oo 0 114: p1.CANAL.14 oo 0 115: p1.val oo 0 116: p1.n16.1 oo 0 117: p1.n1.6 oo 0 118: p1.n1.7 oo 0 119: p1.n15.2 oo 0 120: p1.n15.3 oo 0 121: p1.val oo 0 122: p1.n17.1 oo 0 123: p1.n15.4 oo 0 124: p1.n15.5 oo 0 125: p1.n8.6 oo 0 126: p1.n8.7 oo 0 127: p1.val oo 0 128: p1.n18.1 oo 0 129: p1.n9.4 oo 0 130: p1.n9.5 oo 0 131: p1.n16.2 oo 0 132: p1.n16.3 oo 0 133: p1.val oo 0 134: p1.n19.1 oo 0 135: p1.n16.4 oo 0 136: p1.n16.5 oo 0 137: p1.CANAL.15 oo 0 138: p1.CANAL.16 oo 0 139: p1.val oo 0 140: p1.n20.1 oo 0 141: p1.n17.2 oo 0 142: p1.n17.3 oo 0 143: p1.n21.1 oo 0 144: p1.n18.2 oo 0 145: p1.n18.3 oo 0 146: p1.CANAL.17 oo 0 147: p1.CANAL.18 oo 0 148: p1.val oo 0 149: p1.n22.1 oo 0 150: p1.CANAL.19 oo 0 151: p1.CANAL.20 oo 0 152: p1.n19.2 oo 0 153: p1.n19.3 oo 0 154: p1.val oo 0

___________________________________________________________________

167

155: p1.n23.1 oo 0 156: p1.n20.2 oo 0 157: p1.n20.3 oo 0 158: p1.n24.1 oo 0 159: p1.CANAL.21 oo 0 160: p1.CANAL.22 oo 0 161: p1.n21.2 oo 0 162: p1.n21.3 oo 0 163: p1.val oo 0 164: p1.n25.1 oo 0 165: p1.n22.2 oo 0 166: p1.n22.3 oo 0 167: p1.n26.1 oo 0 168: p1.n23.2 oo 0 169: p1.n23.3 oo 0 170: p1.n27.1 oo 0 171: p1.n26.2 oo 0 172: p1.n26.3 oo 0 173: p1.CANAL.23 oo 0 174: p1.CANAL.24 oo 0 175: p1.val oo 0 176: p1.n28.1 oo 0 177: p1.n27.2 oo 0 178: p1.n27.3 oo 0 179: p1.CANAL.25 oo 0 180: p1.CANAL.26 oo 0 181: p1.val oo 0 182: p1.n29.1 oo 0 183: p1.n25.2 oo 0 184: p1.n25.3 oo 0 185: p1.n15.6 oo 0 186: p1.n15.7 oo 0 187: p1.val oo 0 188: p1.CANAL.27 oo 0 189: p1.n17.4 oo 0 190: p1.n17.5 oo 0 191: p1.n28.2 oo 0 192: p1.n28.3 oo 0 193: p1.val oo 0 194: p1.CANAL.28 oo 0 195: p1.n28.4 oo 0 196: p1.n28.5 oo 0 197: p1.CANAL.29 oo 0 198: p1.n9.6 oo 0 199: p1.n9.7 oo 0 200: p1.n11.2 oo 0 201: p1.n11.3 oo 0 202: p1.val oo 0 203: p1.CANAL.30 oo 0 204: p1.n29.2 oo 0 205: p1.n29.3 oo 0 206: p1.CANAL.31 oo 0 207: p1.n19.4 oo 0 208: p1.n19.5 oo 0 209: p1.n29.4 oo 0 210: p1.n29.5 oo 0 211: p1.val oo 0 212: p1.CANAL.32 oo 0 213: p1.n16.6 oo 0 214: p1.n16.7 oo 0 215: p1.n24.2 oo 0 216: p1.n24.3 oo 0 217: p1.val oo 0 218: p1.CANAL.33 oo 0 219: p1.n24.4 oo 0 220: p1.n24.5 oo 0 221: p1.CANAL.34 oo 0 @ trans nr. name priority time 0: t1.start 0 0 1: t1.end 0 0

___________________________________________________________________

168

2: t1.clone 0 0 3: t1.clone 0 0 4: t1.+ 0 0 5: t1.:= 0 0 6: t1.sink 0 0 7: t1.clone 0 0 8: t1.clone 0 0 9: t1.+ 0 0 10: t1.:= 0 0 11: t1.sink 0 0 12: t1.clone 0 0 13: t1.clone 0 0 14: t1.+ 0 0 15: t1.:= 0 0 16: t1.sink 0 0 17: t1.clone 0 0 18: t1.clone 0 0 19: t1.+ 0 0 20: t1.:= 0 0 21: t1.sink 0 0 22: t1.clone 0 0 23: t1.clone 0 0 24: t1.+ 0 0 25: t1.:= 0 0 26: t1.sink 0 0 27: t1.clone 0 0 28: t1.:= 0 0 29: t1.sink 0 0 30: t1.clone 0 0 31: t1.:= 0 0 32: t1.sink 0 0 33: t1.clone 0 0 34: t1.clone 0 0 35: t1.+ 0 0 36: t1.:= 0 0 37: t1.sink 0 0 38: t1.clone 0 0 39: t1.clone 0 0 40: t1.+ 0 0 41: t1.:= 0 0 42: t1.sink 0 0 43: t1.clone 0 0 44: t1.clone 0 0 45: t1.+ 0 0 46: t1.:= 0 0 47: t1.sink 0 0 48: t1.clone 0 0 49: t1.clone 0 0 50: t1.+ 0 0 51: t1.:= 0 0 52: t1.sink 0 0 53: t1.clone 0 0 54: t1.clone 0 0 55: t1.+ 0 0 56: t1.:= 0 0 57: t1.sink 0 0 58: t1.clone 0 0 59: t1.:= 0 0 60: t1.sink 0 0 61: t1.clone 0 0 62: t1.:= 0 0 63: t1.sink 0 0 64: t1.clone 0 0 65: t1.clone 0 0 66: t1.+ 0 0 67: t1.:= 0 0 68: t1.sink 0 0 69: t1.clone 0 0 70: t1.clone 0 0 71: t1.+ 0 0 72: t1.:= 0 0

___________________________________________________________________

169

73: t1.sink 0 0 74: t1.clone 0 0 75: t1.clone 0 0 76: t1.+ 0 0 77: t1.:= 0 0 78: t1.sink 0 0 79: t1.clone 0 0 80: t1.clone 0 0 81: t1.+ 0 0 82: t1.:= 0 0 83: t1.sink 0 0 84: t1.clone 0 0 85: t1.clone 0 0 86: t1.+ 0 0 87: t1.:= 0 0 88: t1.sink 0 0 89: t1.clone 0 0 90: t1.clone 0 0 91: t1.+ 0 0 92: t1.:= 0 0 93: t1.sink 0 0 94: t1.clone 0 0 95: t1.:= 0 0 96: t1.sink 0 0 97: t1.clone 0 0 98: t1.clone 0 0 99: t1.+ 0 0 100: t1.:= 0 0 101: t1.sink 0 0 102: t1.clone 0 0 103: t1.clone 0 0 104: t1.+ 0 0 105: t1.:= 0 0 106: t1.sink 0 0 107: t1.clone 0 0 108: t1.:= 0 0 109: t1.sink 0 0 110: t1.clone 0 0 111: t1.clone 0 0 112: t1.+ 0 0 113: t1.:= 0 0 114: t1.sink 0 0 115: t1.clone 0 0 116: t1.:= 0 0 117: t1.sink 0 0 118: t1.clone 0 0 119: t1.:= 0 0 120: t1.sink 0 0 121: t1.clone 0 0 122: t1.clone 0 0 123: t1.+ 0 0 124: t1.:= 0 0 125: t1.sink 0 0 126: t1.clone 0 0 127: t1.clone 0 0 128: t1.+ 0 0 129: t1.:= 0 0 130: t1.sink 0 0 131: t1.clone 0 0 132: t1.clone 0 0 133: t1.+ 0 0 134: t1.:= 0 0 135: t1.sink 0 0 136: t1.clone 0 0 137: t1.clone 0 0 138: t1.+ 0 0 139: t1.:= 0 0 140: t1.sink 0 0 141: t1.clone 0 0 142: t1.:= 0 0 143: t1.sink 0 0

___________________________________________________________________

170

144: t1.clone 0 0 145: t1.clone 0 0 146: t1.+ 0 0 147: t1.:= 0 0 148: t1.sink 0 0 149: t1.clone 0 0 150: t1.:= 0 0 151: t1.sink 0 0 152: t1.clone 0 0 153: t1.clone 0 0 154: t1.+ 0 0 155: t1.:= 0 0 156: t1.sink 0 0 157: t1.clone 0 0 158: t1.clone 0 0 159: t1.+ 0 0 160: t1.:= 0 0 161: t1.sink 0 0 162: t1.clone 0 0 163: t1.:= 0 0 164: t1.sink 0 0 @

___________________________________________________________________

171

C.4 Esquemático do Modelo Intermediário2

0:p1.start

0 :t1 .start

1 :p1.dumm y

1:t1.end

2:p1.end

3:p1.INP.0

2:t1 .clone

4:p1.OUTP.0

164:t1 .sink

5:p1.SV2.0

3:t1 .clone

6:p1.SV13. 0

13:t1.clone

7:p1.SV18. 0

98:t1.clone

8:p1.SV26. 0

18:t1.clone

9:p1.SV33. 0

7:t1 .clone

10:p1.SV38 .0

102:t1 .clon e

11:p1.SV39 .0

8:t1 .clone

12:p1.SV2o.0

135:t1 .sink

13:p1.SV13 o.0

140:t1 .sink

14:p1.SV18 o.0

143:t1 .sink

15:p1.SV26 o.0

148:t1 .sink

16:p1.SV33 o.0

156:t1 .sink

17:p1.SV38 o.0

151:t1 .sink

18:p1.SV39 o.0

161:t1 .sink

19:p1.n1.0

6:t1 .sink

20:p1.n2.0

11:t1.sink

21:p1.n3.0

16:t1.sink

22:p1.n4.0

21:t1.sink

23:p1.n5.0

26:t1.sink

24:p1.n6.0

29:t1.sink

25:p1.n7.0

32:t1.sink

26:p1.n8.0

37:t1.sink

27:p1.n9.0

42:t1.sink

28:p1.n10.0

47:t1.sink

29:p1.n11.0

52:t1.sink

30:p1.n12.0

57:t1.sink

31:p1.n13.0

60:t1.sink

32:p1.n14.0

63:t1.sink

33:p1.n15.0

68:t1.sink

34:p1.n16.0

73:t1.sink

35:p1.n17.0

78:t1.sink

36:p1.n18.0

83:t1.sink

37:p1.n19.0

88:t1.sink

38:p1.n20.0

93:t1.sink

39:p1.n21.0

96:t1.sink

40:p1.n22.0

101:t1 .sink

41:p1.n23.0

106:t1 .sink

42:p1.n24.0

109:t1 .sink

43:p1.n25.0

114:t1 .sink

44:p1.n26.0

117:t1 .sink

45:p1.n27.0

120:t1 .sink

46:p1.n28.0

125:t1 .sink

47:p1.n29.0

130:t1 .sink

48:p1.INP.1

4:t1 .+

49:p1.INP.2

110:t1 .clon e

50:p1.SV2. 1

51:p1.SV2. 2 52:p1.val

5 :t1 .:=

53:p1.n1.1

12:t1.clone

54:p1.SV33 .1

9:t1 .+

55:p1.SV33 .2

56:p1.SV39 .1

57:p1.SV39 .2

70:t1.clone

58:p1.val

10:t1.:=

59:p1.n2.1

23:t1.clone

60:p1.n1.2

14:t1.+

61:p1.n1.3

64:t1.clone

62:p1.SV13 .1

63:p1.SV13 .2

64:p1.val

15:t1.:=

65:p1.n3.1

17:t1.clone

66:p1.n3.2

19:t1.+67:p1.n3.3

33:t1.clone

68:p1.SV26 .1

69:p1.SV26 .270:p1.val

20:t1.:=

71:p1.n4.1

22:t1.clone

72:p1.n4.2

24:t1.+

73:p1.n4.3

74:p1.n2.2

75:p1.n2.3

39:t1.clone

76:p1.val

25:t1.:=

77:p1.n5.1

27:t1.clone

78:p1.n5.2

28:t1.:=

79:p1.n5.3

30:t1.clone

80:p1.n6.1

34:t1.clone

81:p1.n5.4

31:t1.:=82:p1.n5.5

49:t1.clone

83:p1.n7.1

38:t1.clone

84:p1.n3.4

35:t1.+

85:p1.n3.5

43:t1.clone

86:p1.n6.2

87:p1.n6.3

88:p1.val

36:t1.:=

89:p1.n8.1

44:t1.clone

90:p1.n7.2

40:t1.+

91:p1.n7.3

92:p1.n2.4

93:p1.n2.5

53:t1.clone

94:p1.val

41:t1.:=

95:p1.n9.1

54:t1.clone

96:p1.n3.6

45:t1.+

97:p1.n3.7

98:p1.n8.2

99:p1.n8.3

48:t1.clone

100:p1.val

46:t1.:=

101:p1.n10.1

58:t1.clone

102:p1.n8.4

50:t1.+

103:p1.n8.5

80:t1.clone

104:p1.n5.6

105:p1.n5.7

106:p1.val

51:t1.:=

107:p1.n11.1

145:t1 .clon e

108:p1.n2.6

55:t1.+ 109:p1.n2.7

110:p1.n9.2

111:p1.n9.3

84:t1.clone

112:p1.val

56:t1.:=

113:p1.n12.1

61:t1.clone

114:p1.n10.2

59:t1.:=

115:p1.n10.3116:p1.n13.1

65:t1.clone

117:p1.n12.2

62:t1.:=118:p1.n12.3

119:p1.n14.1

69:t1.clone

120:p1.n1.4

66:t1.+

121:p1.n1.5

74:t1.clone

122:p1.n13.2

123:p1.n13.3

124:p1.val

67:t1.:=

125:p1.n15.1

75:t1.clone

126:p1.n14.2

71:t1.+

127:p1.n14.3

128:p1.SV3 9.3

129:p1.SV3 9.4

90:t1.clone

130:p1.val

72:t1.:=

131:p1.n16.1

85:t1.clone

132:p1.n1.6

76:t1.+

133:p1.n1.7

134:p1.n15.2 135:p1.n15.3

79:t1.clone

136:p1.val

77:t1.:=

137:p1.n17.1

94:t1.clone

138:p1.n15.4

81:t1.+139:p1.n15.5

132:t1 .clon e

140:p1.n8.6

141:p1.n8.7142:p1.val

82:t1.:=

143:p1.n18.1

97:t1.clone

144:p1.n9.4

86:t1.+

145:p1.n9.5

144:t1 .clon e

146:p1.n16.2

147:p1.n16.3

89:t1.clone

148:p1.val

87:t1.:=

149:p1.n19.1

103:t1 .clon e

150:p1.n16.4

91:t1.+

151:p1.n16.5

157:t1 .clon e

152:p1.SV3 9.5 153:p1.SV3 9.6

154:p1.val

92:t1.:=

155:p1.n20.1

107:t1 .clon e

156:p1.n17.2

95:t1.:=

157:p1.n17.3

136:t1 .clon e

158:p1.n21.1

111:t1 .clon e

159:p1.n18.2

99:t1.+

160:p1.n18.3

161:p1.SV1 8.1

162:p1.SV1 8.2

122:t1 .clon e

163:p1.val

100:t1 .:=

164:p1.n22.1

115:t1 .clon e

165:p1.SV3 8.1

104:t1 .+

166:p1.SV3 8.2

127:t1 .clon e

167:p1.n19.2

168:p1.n19.3

152:t1 .clon e

169:p1.val

105:t1 .:=

170:p1.n23.1

118:t1 .clon e

171:p1.n20.2

108:t1 .:=

172:p1.n20.3

173:p1.n24.1

158:t1 .clon e

174:p1.INP.3

112:t1 .+175:p1.INP.4

176:p1.n21.2

177:p1.n21.3178:p1.val

113:t1 .:=

179:p1.n25.1

131:t1 .clon e

180:p1.n22.2

116:t1 .:= 181:p1.n22.3

182:p1.n26.1

121:t1 .clon e

183:p1.n23.2

119:t1 .:=

184:p1.n23.3

185:p1.n27.1

126:t1 .clon e

186:p1.n26.2

123:t1 .+ 187:p1.n26.3

188:p1.SV1 8.3

189:p1.SV1 8.4

190:p1.val

124:t1 .:=

191:p1.n28.1

137:t1 .clon e

192:p1.n27.2

128:t1 .+

193:p1.n27.3

194:p1.SV3 8.3

195:p1.SV3 8.4

196:p1.val

129:t1 .:=

197:p1.n29.1

149:t1 .clon e

198:p1.n25.2

133:t1 .+

199:p1.n25.3

200:p1.n15.6

201:p1.n15.7

202:p1.val

134:t1 .:=

203:p1.SV2 o.1

204:p1.n17.4

138:t1 .+

205:p1.n17.5

206:p1.n28.2207:p1.n28.3

141:t1 .clon e

208:p1.val

139:t1 .:=

209:p1.SV1 3o.1

210:p1.n28.4

142:t1 .:=

211:p1.n28.5212:p1.SV1 8o.1

213:p1.n9.6

146:t1 .+ 214:p1.n9.7

215:p1.n11.2

216:p1.n11.3 217:p1.val

147:t1 .:=

218:p1.SV2 6o.1

219:p1.n29.2

150:t1 .:=

220:p1.n29.3

153:t1 .clon e

221:p1.SV3 8o.1

222:p1.n19.4

154:t1 .+

223:p1.n19.5

224:p1.n29.4

225:p1.n29.5

226:p1.val

155:t1 .:=

227:p1.SV3 3o.1

228:p1.n16.6

159:t1 .+229:p1.n16.7

230:p1.n24.2 231:p1.n24.3

162:t1 .clon e

232:p1.val

160:t1 .:=

233:p1.SV3 9o.1

234:p1.n24.4

163:t1 .:=

235:p1.n24.5

236:p1.OUTP.1

2 O modelo é reversível se acrescentamos uma transição de fechamento entre o último e o primeiro lugar.

Apêndice D

Máquina de Refrigerantes

D.1 Descrição em Occam

CHAN OF INT EM, VM, PR, RE, LD, LR, AC, NAC, HC, HNC, CA50, CA10, NMD50, NMD10: INT change: PAR INT coinValue, totalPaid, price, emv, rev, ac, nac, prv: SEQ SEQ price := 8 change := 0 totalPaid := 0 prv := 0 WHILE prv = 0 SEQ EM ? emv WHILE emv = 0 SEQ EM ? emv VM ? coinValue totalPaid := totalPaid + coinValue PR ? prv RE ? rev IF rev = 0 LD ! 1 rev = 1 SEQ change := totalPaid - price IF change < 0 LD ! 1 change = 0 LR ! 1 change > 0 SEQ ALT AC ? ac LR ! 1 NAC ? nac LD ! 1 LR ! 1 INT nmd50, nmd10, ca50, ca10: SEQ SEQ PAR HC ! 0 HNC ! 0 nmd10 := 0 nmd50:= change/50 CA50 ? ca50 IF

___________________________________________________________________

173

nmd50 <= 0 SKIP nmd50 <= ca50 SEQ change := change - 50 IF change = 0 PAR NMD50 ! nmd50 NMD10 ! nmd10 HC ! 1 TRUE SEQ nmd10 := change/10 CA10 ? ca10 IF nmd10 <= ca10 PAR NMD50 ! nmd50 NMD10 ! nmd10 HC ! 1 TRUE HNC ! 1

D.2 Modelo Intermediário – INA (.pnt )

P M PRE,POST NETZ 0:MaquinaRefrigerantes 0 0 , 7 1 1 , 0 2 0 0, 1 3 0 1 4 0 0, 27 5 0 0, 9 6 0 0, 5 7 0 0, 20 8 0 0, 40 9 0 0, 66 10 0 0, 68 11 0 0, 11 12 0 0, 2 13 0 2, 3 14 0 3, 1 15 0 2, 4 16 0 4, 50 17 0 2, 6 18 0 6, 53 19 0 2, 8 20 0 8, 28 21 0 2, 10 22 0 10, 14 23 0 2, 12 24 0 12, 13 25 0 13, 3 26 0 14, 15 27 0 14, 36 28 0 2, 15 29 0 15, 12 30 0 12, 16 31 0 16, 17 32 0 17, 13 33 0 16, 18

___________________________________________________________________

174

34 0 18, 19 35 0 19, 17 36 0 20, 21 37 0 20, 25 38 0 16, 21 39 0 21, 18 40 0 18, 22 41 0 22, 23 42 0 23, 19 43 0 22, 24 44 0 24, 33 45 0 22, 26 46 0 26, 29 47 0 28, 30 48 0 28, 32 49 0 29, 30 50 0 29, 1 51 0 30, 31 52 0 31, 49 53 0 33, 34 54 0 33, 1 55 0 16, 34 56 0 34, 19 57 0 16, 35 58 0 35, 37 59 0 37, 38 60 0 37, 1 61 0 2, 38 62 0 38, 13 63 0 2, 39 64 0 39, 43 65 0 0, 41 66 0 41, 42 67 0 42, 1 68 0 43, 44 69 0 43, 45 70 0 0, 44 71 0 44, 41 72 0 45, 46 73 0 45, 1 74 0 0, 46 75 0 46, 41 76 0 41, 47 77 0 47, 48 78 0 48, 42 79 0 49, 51 80 0 49, 1 81 0 50, 51 82 0 50, 1 83 0 51, 52 84 0 52, 56 85 0 47, 54 86 0 54, 55 87 0 55, 48 88 0 56, 57 89 0 56, 58 90 0 47, 57 91 0 57, 54 92 0 58, 59 93 0 58, 60 94 0 47, 59 95 0 59, 54 96 0 60, 61 97 0 60, 78 98 0 47, 61 99 0 61, 54 100 0 54, 62 101 0 62, 63 102 0 63, 55 103 0 62, 64 104 0 64, 65

___________________________________________________________________

175

105 0 65, 63 106 0 66, 67 107 0 66, 1 108 0 62, 67 109 0 67, 64 110 0 68, 69 111 0 68, 1 112 0 62, 69 113 0 69, 64 114 1 , 70 115 0 70, 71 116 0 71 117 0 70, 81 118 0 70, 77 119 0 70, 83 120 0 70, 110 121 0 70, 72 122 0 72, 73 123 0 73, 71 124 0 72, 74 125 0 74, 75 126 0 75, 73 127 0 72, 76 128 0 76, 108 129 0 78, 79 130 0 78, 93 131 0 72, 79 132 0 79, 80 133 0 80, 86 134 0 72, 82 135 0 82, 89 136 0 70, 84 137 0 84, 85 138 0 85, 71 139 0 86, 87 140 0 86, 88 141 0 70, 87 142 0 87, 84 143 0 88, 90 144 0 88, 71 145 0 89, 90 146 0 89, 71 147 0 90, 84 148 0 84, 91 149 0 91, 92 150 0 92, 85 151 0 93, 94 152 0 93, 96 153 0 91, 94 154 0 94, 95 155 0 95, 99 156 0 91, 97 157 0 97, 98 158 0 98, 92 159 0 99, 100 160 0 99, 105 161 0 91, 100 162 0 100, 97 163 0 97, 101 164 0 101, 102 165 0 102, 98 166 0 91, 97 167 0 97, 103 168 0 103, 104 169 0 104, 98 170 0 105, 106 171 0 105 172 0 103, 106 173 0 106, 107 174 0 107, 113 175 0 103, 109

___________________________________________________________________

176

176 0 109, 114 177 0 103, 111 178 0 111, 112 179 0 112, 104 180 0 113, 115 181 0 113, 71 182 0 114, 115 183 0 114, 71 184 0 115, 111 185 0 111, 116 186 0 116, 117 187 0 117, 112 188 0 103, 111 @ place nr. name capacity time 0: p0.change.0 oo 0 1: p1.start oo 0 2: p1.dummy oo 0 3: p1.end oo 0 4: p1.coinValue.0 oo 0 5: p1.totalPaid.0 oo 0 6: p1.price.0 oo 0 7: p1.emv.0 oo 0 8: p1.rev.0 oo 0 9: p1.ac.0 oo 0 10: p1.nac.0 oo 0 11: p1.prv.0 oo 0 12: p1.start oo 0 13: p1.dummy oo 0 14: p1.end oo 0 15: p1.val[8] oo 0 16: p1.price.1 oo 0 17: p1.val[0] oo 0 18: p0.change.1 oo 0 19: p1.val[0] oo 0 20: p1.totalPaid.1 oo 0 21: p1.val[0] oo 0 22: p1.prv.1 oo 0 23: p1.start oo 0 24: p1.dummy oo 0 25: p1.end oo 0 26: p1.prv.2 oo 0 27: p1.prv.3 oo 0 28: p1.val[0] oo 0 29: p1.val oo 0 30: p1.start oo 0 31: p1.dummy oo 0 32: p1.end oo 0 33: p1.start oo 0 34: p1.dummy oo 0 35: p1.end oo 0 36: p1.emv.1 oo 0 37: p1.emv.2 oo 0 38: p1.val[0] oo 0 39: p1.val oo 0 40: p1.start oo 0 41: p1.dummy oo 0 42: p1.end oo 0 43: p1.val[99] oo 0 44: p1.emv.3 oo 0 45: p1.val[99] oo 0 46: p1.coinValue.1 oo 0 47: p1.totalPaid.2 oo 0 48: p1.totalPaid.3 oo 0 49: p1.coinValue.2 oo 0 50: p1.coinValue.3 oo 0 51: p1.val oo 0 52: p1.totalPaid.4 oo 0 53: p1.emv.4 oo 0 54: p1.emv.5 oo 0 55: p1.val[0] oo 0

___________________________________________________________________

177

56: p1.val oo 0 57: p1.val[99] oo 0 58: p1.prv.4 oo 0 59: p1.prv.5 oo 0 60: p1.prv.6 oo 0 61: p1.val[0] oo 0 62: p1.val oo 0 63: p1.val[99] oo 0 64: p1.rev.1 oo 0 65: p1.start oo 0 66: p1.dummy oo 0 67: p1.end oo 0 68: p1.rev.2 oo 0 69: p1.rev.3 oo 0 70: p1.val[0] oo 0 71: p1.val oo 0 72: p1.rev.4 oo 0 73: p1.rev.5 oo 0 74: p1.val[1] oo 0 75: p1.val oo 0 76: p1.start oo 0 77: p1.dummy oo 0 78: p1.end oo 0 79: p1.totalPaid.5 oo 0 80: p1.totalPaid.6 oo 0 81: p1.price.2 oo 0 82: p1.price.3 oo 0 83: p1.val oo 0 84: p0.change.2 oo 0 85: p1.start oo 0 86: p1.dummy oo 0 87: p1.end oo 0 88: p0.change.3 oo 0 89: p0.change.4 oo 0 90: p1.val[0] oo 0 91: p1.val oo 0 92: p0.change.5 oo 0 93: p0.change.6 oo 0 94: p1.val[0] oo 0 95: p1.val oo 0 96: p0.change.7 oo 0 97: p0.change.8 oo 0 98: p1.val[0] oo 0 99: p1.val oo 0 100: p1.start oo 0 101: p1.dummy oo 0 102: p1.end oo 0 103: p1.start oo 0 104: p1.dummy oo 0 105: p1.end oo 0 106: p1.ac.1 oo 0 107: p1.ac.2 oo 0 108: p1.val[99] oo 0 109: p1.val oo 0 110: p1.nac.1 oo 0 111: p1.nac.2 oo 0 112: p1.val[99] oo 0 113: p1.val oo 0 114: p2.start oo 0 115: p2.dummy oo 0 116: p2.end oo 0 117: p2.nmd50.0 oo 0 118: p2.nmd10.0 oo 0 119: p2.ca50.0 oo 0 120: p2.ca10.0 oo 0 121: p2.start oo 0 122: p2.dummy oo 0 123: p2.end oo 0 124: p2.start oo 0 125: p2.dummy oo 0 126: p2.end oo 0

___________________________________________________________________

178

127: p2.val[0] oo 0 128: p2.nmd10.1 oo 0 129: p0.change.9 oo 0 130: p0.change.10 oo 0 131: p2.val[50] oo 0 132: p2.val oo 0 133: p2.nmd50.1 oo 0 134: p2.val[99] oo 0 135: p2.ca50.1 oo 0 136: p2.start oo 0 137: p2.dummy oo 0 138: p2.end oo 0 139: p2.nmd50.2 oo 0 140: p2.nmd50.3 oo 0 141: p2.val[0] oo 0 142: p2.val oo 0 143: p2.nmd50.4 oo 0 144: p2.nmd50.5 oo 0 145: p2.ca50.2 oo 0 146: p2.ca50.3 oo 0 147: p2.val oo 0 148: p2.start oo 0 149: p2.dummy oo 0 150: p2.end oo 0 151: p0.change.11 oo 0 152: p0.change.12 oo 0 153: p2.val[50] oo 0 154: p2.val oo 0 155: p0.change.13 oo 0 156: p2.start oo 0 157: p2.dummy oo 0 158: p2.end oo 0 159: p0.change.14 oo 0 160: p0.change.15 oo 0 161: p2.val[0] oo 0 162: p2.val oo 0 163: p2.start oo 0 164: p2.dummy oo 0 165: p2.end oo 0 166: p2.val[TRUE] oo 0 167: p2.start oo 0 168: p2.dummy oo 0 169: p2.end oo 0 170: p0.change.16 oo 0 171: p0.change.17 oo 0 172: p2.val[10] oo 0 173: p2.val oo 0 174: p2.nmd10.2 oo 0 175: p2.val[99] oo 0 176: p2.ca10.1 oo 0 177: p2.start oo 0 178: p2.dummy oo 0 179: p2.end oo 0 180: p2.nmd10.3 oo 0 181: p2.nmd10.4 oo 0 182: p2.ca10.2 oo 0 183: p2.ca10.3 oo 0 184: p2.val oo 0 185: p2.start oo 0 186: p2.dummy oo 0 187: p2.end oo 0 188: p2.val[TRUE] oo 0 @ trans nr. name priority time 0: t1.start 0 0 1: t1.end 0 0 2: t1.start 0 0 3: t1.end 0 0 4: t1.:= 0 0 5: t1.sink 0 0 6: t1.:= 0 0

___________________________________________________________________

179

7: t0.sink 0 0 8: t1.:= 0 0 9: t1.sink 0 0 10: t1.:= 0 0 11: t1.sink 0 0 12: t1.start 0 0 13: t1.end 0 0 14: t1.clone 0 0 15: t1.= 0 0 16: t1.start 0 0 17: t1.end 0 0 18: t1.start 0 0 19: t1.end 0 0 20: t1.clone 0 0 21: t1.= 0 0 22: t1.start 0 0 23: t1.end 0 0 24: t1.:= 0 0 25: t1.sink 0 0 26: t1.:= 0 0 27: t1.sink 0 0 28: t1.clone 0 0 29: t1.clone 0 0 30: t1.+ 0 0 31: t1.:= 0 0 32: t1.sink 0 0 33: t1.clone 0 0 34: t1.= 0 0 35: t1.:= 0 0 36: t1.sink 0 0 37: t1.clone 0 0 38: t1.= 0 0 39: t1.:= 0 0 40: t1.sink 0 0 41: t1.start 0 0 42: t1.end 0 0 43: t1.clone 0 0 44: t1.= 0 0 45: t1.clone 0 0 46: t1.= 0 0 47: t1.start 0 0 48: t1.end 0 0 49: t1.clone 0 0 50: t1.clone 0 0 51: t1.- 0 0 52: t1.:= 0 0 53: t0.sink 0 0 54: t1.start 0 0 55: t1.end 0 0 56: t0.clone 0 0 57: t1.< 0 0 58: t0.clone 0 0 59: t1.= 0 0 60: t0.clone 0 0 61: t1.> 0 0 62: t1.start 0 0 63: t1.end 0 0 64: t1.start 0 0 65: t1.end 0 0 66: t1.clone 0 0 67: t1.= 0 0 68: t1.clone 0 0 69: t1.= 0 0 70: t2.start 0 0 71: t2.end 0 0 72: t2.start 0 0 73: t2.end 0 0 74: t2.start 0 0 75: t2.end 0 0 76: t2.:= 0 0 77: t2.sink 0 0

___________________________________________________________________

180

78: t0.clone 0 0 79: t2./ 0 0 80: t2.:= 0 0 81: t2.sink 0 0 82: t2.:= 0 0 83: t2.sink 0 0 84: t2.start 0 0 85: t2.end 0 0 86: t2.clone 0 0 87: t2.<= 0 0 88: t2.clone 0 0 89: t2.clone 0 0 90: t2.<= 0 0 91: t2.start 0 0 92: t2.end 0 0 93: t0.clone 0 0 94: t2.- 0 0 95: t2.:= 0 0 96: t0.sink 0 0 97: t2.start 0 0 98: t2.end 0 0 99: t0.clone 0 0 100: t2.= 0 0 101: t2.start 0 0 102: t2.end 0 0 103: t2.start 0 0 104: t2.end 0 0 105: t0.clone 0 0 106: t2./ 0 0 107: t2.:= 0 0 108: t2.sink 0 0 109: t2.:= 0 0 110: t2.sink 0 0 111: t2.start 0 0 112: t2.end 0 0 113: t2.clone 0 0 114: t2.clone 0 0 115: t2.<= 0 0 116: t2.start 0 0 117: t2.end 0 0 @

___________________________________________________________________

181

D.3 Esquemático do Modelo Intermediário3

3 O modelo é reversível se acrescentamos uma transição de fechamento entre o último e o primeiro lugar.

Referências

[1] Appel, Andrew W. Modern Compiler Implementation in Java. Cambridge University Press. 1999.

[2] Barros, Edna et al. “Hardware/Software Co-Design: projetando hardware e

software concorrentemente”. São Paulo, IME -USP, 2000. [3] Barros, E., and Sampaio, A. “Towards provable correct hardware/software

partitioning using OCCAM”. In Proc. of 3rd International Workshop on Hardware/Software Co-Design, pages 210-217, Los Alamitos, 1994. IEEE.

[4] Barros, E., Sampaio, A, Lima, M., Silva, L., Jacobi, R. and Calazans, N. “The

PISH methodology for hardware/software co-design”. In Workshop of ProTem-CC, pages 65-98, CNPQ, 1998.

[5] Brewer, F. D., and Gajski, D. D. “Knowledge Based Control in Micro -

Architecture Design”. Proceedings of 24th DAC, 1987. [6] Camposano, R., and Wilberg, J. “Embedded System Design”, Design Automation

for Embedded Systems vol. 1, no. 1/2, pp. 5-50, 1996. [7] Carreras, C., López, J. C., López, M. L., Delgado-KLoos, C., Martínez, M. and

Sanchez, L. “A Co -Design Methodology Base on Formal Specification and High Level Estimation” . Proceedings of EDAC, pp 2-7. 1996.

[8] Cavalcante, S. V. A Hardware-Software Co-Design System for Embedded Real-

Time Applications. PhD thesis, June, 1997. [9] Commoner, F. Deadlock in Petri Nets. Applied Data Research Inc. Massachusetts,

1972. [10] Cormen, T. H., Leiserson, C. E., and Rivest, R. L. Introduction to Algorithms.

MIT Press, Cambridge, MA, 1989. [11] Davis, W. Tools and Techniques for Structures System Analysis and Design.

Addison-Wesley, 1983. [12] De Lima, Manoel A Force-Directed Placement Algorithm with simultaneous

Global Routing for Sea-of-Gates,1993. [13] De Marco, T. Structured Analysis and System Specification. Prentice-Hall, 1979.

___________________________________________________________________

183

[14] Desrochers, A. A., Al-Jaar, R. Y. Applications of Petri Nets in Manufacturing Systems. IEEE Press. 1995.

[15] Dicesare, F., Harhalakis, G., Proth, J. M., Silva, M. and Vernadat, F. B. Practice

of Petri Nets in Manufacturing. Chapman and Hall, 1993. [16] Drusinsky, D. and Harel, D. “Using statecharts for hardware description and

synthesis”. IEEE Transactions on Computer Aided Design, 8(7), Jul. 1989. [17] Eles, P., Kuchcinki, K., Peng, Z. and Minea, M. “Synthesis of VHDL Concurrent

Process”. Proceedings of the EURO-DAC’94 , pp. 540-545. IEEE Computer Society. September, 1994.

[18] Ernst, R. and Henkel, J. “A Path -Based Technique for Estimating Hardware

Runtime in HW/SW Co-synthesis”. IEEE/ACM Proc. of 8th Int’l Symp. on System Level Synthesis, October 1995.

[19] Ernst, R. and Henkel, J. “Hardware -Software Co-Design of Embedded

Controllers Based on Hardware Extraction Handouts”. International Workshop on Hardware-Software Co-Design. October, 1992.

[20] Gajski, D. D., Dutt, N. D., Wu, C. H., e Lin, Y. L. High Level Synthesis:

Introduction to Chip and System Design. Kluwer Academic Publishers, Boston, Massachusetts, 1991.

[21] Gajski, D. D., Varid, F., Narayan, S., and Gong, J. Specification and Design of

Embedded Systems. PTR Prentice Hall. 1994. [22] Gajski, D. D., and Ramachandran, L. “Introduction to High -Level Synthesis”.

IEEE Design and Test for Computers, 11 (4): 44-54, 1994. [23] Gajski, D. D., Zhu, J. and Dömmer, R. Essential Issues in Co-Design. Kluwer

Academic Publishers, pp. 1-45. 1987. [24] Gebotys, C. H., and Elmasry, M. I. “Simultaneous Scheduling and Allocation for

Cost Constrained Optimal Architectural for Cost Constrained Optimal Architectural Synthesis”, Proc. 28th DAC, pp. 2-7, June 1991.

[25] Gupta, R., Coelho, C. N., and De Micheli, G. Synthesis and simulation of digital

systems containing interacting hardware and software components, 1992. [26] Gupta, R. and De Micheli, G. “Hardware/s oftware co-synthesis for digital

systems”. IEEE Design & Test of Computers, pages 29-41, 1993. [27] Gupta, R. and De Micheli, G. “System -Level Synthesis Using Reprogrammable

Components”. European Design Automation Conference, March, 1992.

___________________________________________________________________

184

[28] Gupta, R. and De Micheli, G. “ Constrained Software Generation for Hardware-

Software Systems”. Proceedings of the Fourth Codes/CASHE, pp 56-63. IEEE Computer Society. September, 1995.

[29] Hack, M. H. T. Analysis of Production Schemata by Petri Nets. Master’s thesis,

MIT, 1972. [30] Hashimoto, A. and Stevens. “Wire routing by optimizing channel assigments with

large aperture”. In Proceedings of the Design Automation Conference, 1971. [31] Hoare, C. A. R. Communicating Sequential Process. Prentice Hall International,

1985. [32] Jones, G. Programming in OCCAM. C.A.R. Hoare Series Editor, Prentice-Hall

International Series in Computer Science, 1987. [33] Kenneth, Jane P. Laudon and Kenneth ,C. Laudon. Management Information

Systems, 8/e. Pearson Education, Inc, 2003. [34] Kurdahi, F. J., Gajski, D. D., Ramachandran, C. and Chaiyakul. “Linking register -

transfer in physical levels of design”. In IEICE Transactions on Information and Systems, Vol E76-D, No 9, September 1993.

[35] Kurdahi, F. J and Parker, A.C. “Real: A program for register allocation”. In

Proceedings of the Design Automation Conference, 1987. [36] Kung, S. Y., Whitehouse, H. J., and Kailath, T. VLSI and Modern Digital Signal

Processing. Prentice Hall, 1985, pp. 258-264. [37] Machado, A. P., Maciel, P.and Guilhermino, A. “A Petri net Based Method for

Storage Units Estimation”. In Proc. of International Conference on Systems, Man and Cybernetics, pages 1025-1031, vol. 2. Washington, D.C., USA, Oct. 5-8 2003. SMC Society, IEEE.

[38] Maciel, P. Petri Net Based Estimators for Hardware/Software Co-Design. PhD

thesis, Universidade Federal de Pernanbuco, Recife, PE, Brasil, Dez. 1999. [39] Maciel, P., Barros, E., Lima, M., Silva, D. and Rosenstiel, W. “ Resource Sharing

Estimation by Petri Nets in PISH Co-Design System”. In Proc. of High Performance Computing 2000, Washington D.C., EUA, April, 2000.

[40] Maciel, P., Barros, E., and Rosenstiel, W. “ A Petri Net Based Approach for

estimating Area in Hardware/Software Co-Design” . In Proc. of High Performance Computing ’99 , San Diego, California, USA, April 10-14, 1999.

___________________________________________________________________

185

[41] Maciel, P., Barros, E., and Rosenstiel, W. “ A Petri Model for Hardware/Software Co-Design”. In Design Automation for Embedded Systems, 4: 243-310, 1999.

[42] Maciel, P., Barros, E., and Rosenstiel, W. “ Computing Comunication Cost by

Petri Nets for Hardware/Software Co-Design”. In Proc. of 8th IEEE International Workshop on Rapid System Prototyping, Chapel Hill, NC, EUA, Jun. 24-26, 1997.

[43] Maciel, P., Barros, E., Silva, M., and Filho, F. Cruz. “Resource Sharing

Estimation by Petri Nets in PISH Hardware/Software Co-Design System”. In Proc. of International Conference on Systems, Man and Cybernetics, pages 3165-3170, Nashville, TN, EUA, October 8-11, 2000. SMC Society, IEEE.

[44] Maciel, P., Filho, F. Cruz, and Barros, E. “Estimates Based on Petri Nets for

Hardware/Software Co-Design”. In Proc. of 4th Portuguese Conference on Automatic Control, pages 546-551, Guimarães, Portugal, October 4-6, 2000. APCA, IFAC.

[45] Madsen, J., Grode, J., Knudsen, P. V., Peterson, M. E., and Haxthausen, A.

“LYCOS: the Lyngby Co -Synthesis system”. Design Automation for Embebed Systems, vol. 2, no. 2, pp. 195-236, 1997.

[46] Madsen, J., Grode, J., Knudsen, P. V. “Hardware/Software Partitioning Using the

LYCOS System”. In J. Staunstrup, and W. Wolf (eds.), Hardware/Software Co-Design: Principles and Practice. Amsterdam: Kluwer Academic Publishers, pp. 283-306, 1997.

[47] Monteiro, F. Cruz. Partitioning in Hardware/Software using Petri Nets. Msc

thesis, Universidade Federal de Pernanbuco, Recife, PE, Brasil, Dez. 2000. [48] Monteiro, F. Cruz, Maciel, P., and Barros, E. Using Petri Nets for Data

Dependency Analysis “. In Proc. of International Conference on Systems, Man and Cybernetics, pages 2998-3003, Nashville, TN, EUA, October 8-11, 2000. SMC Society, IEEE.

[49] Muller, Wolfgang; Rosenstiel, Wolfgang and Ruf, Jurgen. Systemc:

Methodologies and Applications. Kluwer Academic Publishers, July 2003 [50] Murata, T. “Petri Nets: Properties, Analysis and Applications”. Proceedings of the

IEEE vol. 77, no. 4, pp. 541-580, 1989. [51] Murata, T. Modelling and Analysis of Concurrent Systems, Handbook of Software

Engineering. Van Norstrand Reinhold Company Inc., 1984. [52] Murata, T. “State Equation, Controllability, and Maximal of Petri Nets ”. IEEE

Trans. on Automatic Control, 1977.

___________________________________________________________________

186

[53] Ohm, Seong Y., Kurdahi, Fadi J., and Dutt, Nikil. “Compre hensive Lower Bound Estimation from Behavioral Descriptions” . IEEE/ACM international conference on Computer-Aided Design. 1994.

[54] Orchard, H. J. “Adjusting the Parameters in Elliptic -Function Filters”. IEEE

Trans. CAS, vol. 37, no. 5, May 1990. [55] Österling, A., Benner, T., Ernst, R., Herrmann, D., Scholz. T., and Ye, W. “The

COSYMA system”. In J. Staunstrup and W. Wolf, editors, Hardware/Software Co-Design: Principles and Practice, pages 263-281. Kluwer Academic Publishers, Amsterdam, 1977.

[56] Paulin, P. G. e Knight, J. P. “Force -directed scheduling for the behavioral

synthesis of ASICS”. IEEE Transactions on Computer-Aided Design, June 1989. [57] Paulin, P. G., and Knight, J. P. Scheduling and Binding Algoritms for High-Level

Synthesis. Proc. 26th DAC, pp. 1-6, June 1989. [58] Peterson, J. L. Petri Nets an Introduction. Pretence-Hall, Inc, 1981. [59] Ramchandani. Analysis of Asynchronous Concurrent Systems by Timed Petri

Nets. Technical Report n120 , Laboratory for Computer Science, MIT, Cambridge, MA. 1974

[60] Reisig, W. Petri Nets: An Introduction. Springer-Verlag, 1982. [61] Rim, M., Jain, R., and Leone, R. D. “ Optimal Allocation and Binding in High-

Level Synthesis”. Proc. 29th DAC, pp. 120-123, June 1992. [62] Rose, F., Carpenter, T., Kumar, S., Shackleton, J. and Steeves, T. “A model for

the Co- Analysis of Hardware and Software Architecture”. Proceedings of the Fourth Codes/CASHE, pp 94-103. IEEE Computer Society. March, 1996.

[63] Sait, S. e Habib, Y. VLSI Physical Design Automation: Theory and Practice,

1997. [64] Sharma, A., and Jain, R. “InSyn: Integrated Scheduling for DSP Applications”.

Proc. 30th DAC, pp. 349-354, June 1993. [65] Starke, P. H. “ Remarks on Timed Petri Nets”. Proc. 9th European Workshop on

Application and Theory of Petri Nets, 1988. [66] Starke, P. H., and Roch, S. INA – Integrated Net Analyzer – Version 2.2. Humbolt

Universität zu Berlin – Institut für Informatik. 1999. [67] Stravers, P. Embebed System Design, 1994.

___________________________________________________________________

187

[68] Tseng C. e Siewiorek D. P. “Automated synthesis of datapaths in digital systems”.

IEEE Transactions on Computer-Aided Design, pages 379-395, July 1986. [69] Weste, N. e Eshraghian, K. Principles of CMOS VLSI Design,1988. [70] Zuberek, W. M. “D -Timed Petri Nets and Modeling of Timeouts and Protocols”.

Trans. of the Society for Computer Simulation, vol. 4, no. 4, pp. 331-357, 1987. [71] Zuberek, W. M. “M -Timed Petri Nets, priorities, preemptions, and performance

evaluation of systems”. In Advances in Petri Nets 1985 (Lecture Notes in Computer Science 222), G. Rosenberg (ed.), pp. 478-498, Spring Verlag 1986.

[72] Zuberek, W. M. “Timed Petri Nets Definitions, Properties and Applications”. In

Microelectronic and Reliability, vol. 31, no. 4, pp. pages 627-644, 1991.

Standard IC(off-the-shelf)

SSI/MSI

PLDs

LSI/VLSI

FPGAs

Gate-Arrays

ASICs(User-specified)

StandardLibrary Cells

Semi-custom

User-Programable

Full-custom

Bit-SliceData Paths

All Masks

Analogic/DigitalMixed tecnologies