Study about Models of Computatoin for describing Digital Systems

Ivan Jeukens

Um Estudo sobre a Utilização deModelos Computacionais para a

Representação de Sistemas Digitais

Dissertação apresentada à EscolaPolitécnica da Universidade de SãoPaulo para obtenção do título deMestre em Engenharia Elétrica.

São Paulo2000

Ivan Jeukens

Um Estudo sobre a Utilização deModelos Computacionais para a

Representação de Sistemas Digitais

Dissertação apresentada à EscolaPolitécnica da Universidade de SãoPaulo para obtenção do título de Mestreem Engenharia Elétrica.

Área de Concentração:Microeletrônica

Orientador:Prof. Dr . Mar ius Strum

São Paulo2000

Jeukens, Ivan

Um Estudo sobre a Utilização de Modelos Computacionais para a representação de Sistemas Digitais

São Paulo, S. P., Brasil, 2000. p. 108

Dissertação de Mestrado. Escola Politécnica da Universidade de São Paulo. Departamento de Engenharia Elétrica.

1. Sistemas Digitais 2. Modelos computacionais 3. Especificações Executáveis 4. Metodologias. I. Universidade de São Paulo. Escola Politécnica. Departamento de Engenharia Elétrica II. t.

Aos meus pais.

Agradecimentos

Ao meu orientador Prof. Marius Strum pelas inúmeras discussões queacabaram por moldar e assegurar a qualidade desse trabalho.

Aos membros da banca de defesa pela paciência de ler esse texto.

Aos colegas da sala C2−53 Alexandre Giulietti, Oscar Guilarte, AlfredoCoelho e João Paulo.

Ao grupo de desenvolvimento do ambiente Ptolemy por disponibilisar umsoftware de alta qualidade.

A CAPES pelo financiamento desse trabalho através de uma bolsa demestrado.

SUMÁRIOLista de tabelas

Lista de figuras

Resumo

¨Abstract¨

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

1.1 Considerações Iniciais ..............................................................................1

1.2 Trabalhos Relacionados ...........................................................................2

1.3 Estrutura do Texto ...................................................................................3

2 Fundamentos ........................................................................................................4

2.1 Introdução ................................................................................................4

2.2 O Ambiente Ptolemy ................................................................................4

2.2.1 A implementação do Ambiente Ptolemy .............................................4

2.2.1.1 O Pacote Kernel: Sintaxe da Especificação ...................................5

2.2.1.2 O Pacote Actor: Suporte à Semântica ............................................6

2.2.1.3 Outras Classes Importantes ...........................................................8

2.2.2 Utilizando o Ambiente Ptolemy ..........................................................9

2.3 Os Modelos Computacionais ..................................................................11

2.3.1 Discrete Event ...................................................................................11

2.3.2 Synchronous Reactive .......................................................................13

2.3.3 Communicating Sequential Processes ...............................................17

2.3.4 Synchronous Data Flow ....................................................................19

2.3.5 Dynamic Data Flow ..........................................................................21

2.3.6 Kahn Process Networks ....................................................................24

2.4 Outros Modelos Computacionais ............................................................24

2.5 A Ferramenta de Depuração/Profile .......................................................26

2.5.1 Dados Coletados ...............................................................................26

2.5.2 A Interface Gráfica ............................................................................27

3 Pr imitivas Comportamentais .............................................................................32

3.1 Introdução ..............................................................................................32

3.2 Seqüência de Expressões ........................................................................32

3.2.1 Exemplo de Sistema ..........................................................................32

3.2.2 Especificação Executável ..................................................................33

3.2.3 Análise da Execução .........................................................................34

3.2.3.1 SDF .............................................................................................34

3.2.3.2 DDF ............................................................................................34

3.2.3.3 PN ...............................................................................................34

3.2.3.4 DE ..............................................................................................35

3.2.3.5 CSP .............................................................................................35

3.2.3.6 SR ...............................................................................................35

3.3 Desvio Condicional ..........................................................................................35



3.3.2.1 SDF .............................................................................................36

3.3.2.2 DDF ............................................................................................38

3.3.2.3 PN ...............................................................................................39

3.3.2.4 CSP .............................................................................................39

3.3.2.5 DE ..............................................................................................40

3.3.2.6 SR ...............................................................................................41


3.3.3.1 SDF .............................................................................................42

3.3.3.2 DDF ............................................................................................42

3.3.3.3 PN ...............................................................................................43

3.3.3.4 CSP .............................................................................................43

3.3.3.5 DE ..............................................................................................43

3.3.3.6 SR ...............................................................................................43

3.4 Iteração com Duração Fixa .....................................................................44



3.4.2.1 SDF .............................................................................................45

3.4.2.2 DDF ............................................................................................46

3.4.2.3 PN ...............................................................................................46

3.4.2.5 CSP .............................................................................................47

3.4.2.4 DE ..............................................................................................47

3.4.2.6 SR ...............................................................................................48


3.4.3.1 SDF .............................................................................................48

3.4.3.2 DDF ............................................................................................48

3.4.3.3 PN ...............................................................................................49

3.4.3.4 CSP .............................................................................................50

3.4.3.5 DE ..............................................................................................50

3.4.3.6 SR ...............................................................................................50

3.5 Outras Primitivas Comportamentais .......................................................51

3.5.1 Sincronismo ......................................................................................51

3.5.2 Compartilhamento de Recursos .........................................................51

3.5.3 Concorrência .....................................................................................52

3.5.4 Preempção ........................................................................................52

3.5.5 Recursão ...........................................................................................53

3.6 Discussão ...............................................................................................53

4 Estudo de Caso ...................................................................................................56

4.1 Introdução ..............................................................................................56

4.2 O Modem ADSL ....................................................................................56

4.2.1 Introdução .........................................................................................56

4.2.2 Framming .........................................................................................57

4.2.3 Código de Redundância Cíclica .........................................................59

4.2.4 Embaralhamento ...............................................................................60

4.2.5 Correção de Erros .............................................................................60

4.2.6 Interleaver ........................................................................................60

4.2.7 Ordenamento de Tons .......................................................................60

4.2.8 Codificação de Constelações .............................................................61

4.2.9 Modulação ........................................................................................61

4.2.10 A inicialização ................................................................................61

4.3 As Especificações Executáveis ...............................................................63

4.3.1 O sistema ..........................................................................................63

4.3.2 Framming .........................................................................................65

4.3.3 A especificação dos modems ATU−C e ATU−R ...............................66

4.3.3.1 MuxSyncTx ..................................................................................67

4.3.3.2 MuxSyncRx .................................................................................69

4.3.3.3 CRCTx ........................................................................................69

4.3.3.4 CRCRx ........................................................................................70

4.3.3.5 ScramblerTx ................................................................................71

4.3.3.6 ScramblerRx ...............................................................................72

4.3.3.7 FECTx ........................................................................................72

4.3.3.8 FECRx ........................................................................................73

4.3.3.9 InterleaverTx ...............................................................................75

4.3.3.10 InterleaverRx ............................................................................75

4.3.3.11 Map ...........................................................................................76

4.3.3.12 Demap .......................................................................................79

4.3.3.13 IDFT .........................................................................................80

4.3.3.14 DFT ..........................................................................................81

4.3.3.15 Initializer ..................................................................................82

4.4 Discussão ...............................................................................................87

5 Conclusões e Trabalhos Futuros ........................................................................89

5.1 Considerações Finais ..............................................................................89

5.2 Trabalhos Futuros ..................................................................................89

Referências Bibliográficas .....................................................................................91

LISTA DE TABELAS

Tabela 3.1 Comparação dos escalonadores do MoC DE ..........................................50

LISTA DE FIGURAS

Figura 2.1 Diagrama estático de classes simplificado dos pacotes Actor e Kernel.......5

Figura 2.2 Uma topologia não hierárquica .................................................................5

Figura 2.3 Exemplo de topologia hierárquica ............................................................6

Figura 2.4 Exemplo de troca de dados .......................................................................6

Figura 2.5 Exemplo de topologia para ilustrar o uso da classe Director .....................7

Figura 2.6 Type lattice do ambiente Ptolemy .............................................................8

Figura 2.7 Um exemplo genérico de ator atômico ......................................................9

Figura 2.8 Exemplo de arquivo principal de uma especificação executável ..............10

Figura 2.9 Situação de eventos simultâneos no MoC DE .........................................11

Figura 2.10 O ator Delay no MoC DE ....................................................................12

Figura 2.11 Ilustrações das definições do MoC SR ..................................................16

Figura 2.12 Ator de atraso no MoC SR ....................................................................17

Figura 2.13 O comando CDO no ambiente Ptolemy ................................................18

Figura 2.14 Dois grafos SDF ...................................................................................19

Figura 2.15 Dois grafos SDF inválidos mas com matrizes consistentes ....................20

Figura 2.16 O ator Delay no MoC SDF ...................................................................21

Figura 2.17 Os atores Switch e Select no modelo DDF ............................................22

Figura 2.18 Código do ator Select no MoC DDF .....................................................23

Figura 2.19 A janela inicial da ferramenta PTII Analyzer ........................................27

Figura 2.20 A janela da topologia ............................................................................28

Figura 2.21 Janela inicial para o profiling ................................................................29

Figura 2.22 Tabela de dados estatísticos de atores ...................................................29

Figura 2.23 A tabela de dados dos portos .................................................................30

Figura 2.24 Gráfico da evolução do estado de um ator .............................................31

Figura 2.25 Gráfico alternativo da evolução dos estados de um ator ........................31

Figura 2.26 Exemplo de gráfico da evolução da quantidade de tokens em uma

conexão .......................................................................................................31

Figura 3.1 Descrição em linguagem C do cálculo dos pontos da curva borboleta .....33

Figura 3.2 A topologia da especificação executável para o exemplo

curva borboleta.............................................................................................33

Figura 3.3 Situação da execução em um momento inicial utilizando o escalonador

com classificação de ator deferrable .............................................................34

Figura 3.4 Situação da execução em um momento inicial utilizando o escalonador

sem classificação de ator deferrable .............................................................34

Figura 3.5 Descrição em linguagem C do cálculo do coeficiente angular

em uma reta .................................................................................................36

Figura 3.6 Topologia da primeira especificação em SDF .........................................36

Figura 3.7 Trecho do código do ator Mux ................................................................37

Figura 3.8 Topologia da segunda especificação utilizando o MoC SDF ...................37

Figura 3.9 Interface para uma função do exemplo do coeficiente angular ................37

Figura 3.10 Topologia da primeira especificação utilizando o modelo DDF ............38

Figura 3.11 Topologia da segunda especificação utilizando o MoC DDF ................39

Figura 3.12 Trecho de código do ator MuxND no MoC CSP ...................................40

Figura 3.13 Topologia da especificação no MoC DE ...............................................40

Figura 3.14 Trecho de código do ator Coef no MoC DE ..........................................41

Figura 3.15 Método fire() do ator MuxND no MoC SR ............................................41

Figura 3.16 Exemplo da evolução do estado do ator Comp2 para a especificação da

figura 3.10 no MoC DDF .............................................................................42


figura 3.11 no MoC DDF .............................................................................42


figura 3.11 no MoC PN ................................................................................43

Figura 3.19 Multiplicação de duas matrizes de ordem N ..........................................44

Figura 3.20 A primeira especificação para a primitiva de iteração fixa ....................44

Figura 3.21 Implementação alternativa para a geração dos índices da iteração .........45

Figura 3.22 A iteração com duração fixa no MoC SDF ...........................................45

Figura 3.23 Trecho de código dos atores CT e Data ................................................46

Figura 3.24 Código dos atores Data e CT no MoC PN ............................................47

Figura 3.25 Trecho do ator Sequencer no MoC PN ..................................................47

Figura 3.26 Trecho do ator Sequencer no MoC DE .................................................47

Figura 3.27 Evolução do estado dos atores Data (em azul) e Accum (em verde) ......48

Figura 3.28 Evolução do estado dos atores Data e Accum com a alteração do

parâmetro do método waitFor() ...................................................................49

Figura 3.29 Evolução do estado do ator Data quando o tamanho inicial

das filas é 1 ..................................................................................................49

Figura 3.30 Evolução do estado do ator Data quando o tamanho inicial

das filas é 8 ..................................................................................................49

Figura 3.31 Discrete Cosine Transform : exemplo para a primitiva de sincronismo .51

Figura 3.32 Um exemplo para a primitiva de preempção .........................................52

Figura 3.33 Máquina de Mealy para o código da figura 3.32 ...................................53

Figura 4.1 Modelo de referência de sistemas ADSL ................................................56

Figura 4.2 Diagrama funcional do transmissor do modem ATU−C ..........................57

Figura 4.3 A estrutura de frame e superframe do modem ADSL ..............................58

Figura 4.4 A estrutura de um frame de dados do buffer fast .....................................58

Figura 4.5 A estrutura de um frame de dados do buffer interleaved .........................59

Figura 4.6 Constelação quando o comprimento de b for igual à 3 ............................61

Figura 4.7 Ativação e Acknowledgment ...................................................................62

Figura 4.8 Topologia da especificação do sistema ...................................................63

Figura 4.9 Trecho de código do ator BroadBandNet no MoC DE ............................64

Figura 4.10 Trecho de código da classe MuxDataFrame .........................................65

Figura 4.11 Trecho de código da classe FastFECDataFrame ..................................66

Figura 4.12 A topologia da especificação para o modem ATU−C ............................66

Figura 4.13 Trecho de código do ator MuxSyncTx no MoC DE ...............................68

Figura 4.14 Trecho de código do ator CRCTx ..........................................................70

Figura 4.15 Trecho de código do ator CRCRx ..........................................................71

Figura 4.16 Trecho de código do ator ScramblerTx .................................................72

Figura 4.17 Trecho de código do ator FECTx ..........................................................73

Figura 4.18 Trecho de código do ator FECRx ..........................................................74

Figura 4.19 Trecho de código do ator InterleaverTx ................................................75

Figura 4.20 Trecho de código do ator InterleaverRx ................................................76

Figura 4.21 Trecho de código do ator Map ..............................................................78

Figura 4.22 Trecho de código do ator Demap ..........................................................80

Figura 4.23 Trecho de código do ator IDFT no MoC DE .........................................81

Figura 4.24 Trecho de código do ator DFT no MoC DE ..........................................82

Figura 4.25 Classe auxiliar com os símbolos de inicialização ..................................82

Figura 4.26 Método fire() do ator Timer ..................................................................83

Figura 4.27 Método _getSymbol() do ator Initializer ...............................................84

Figura 4.28 Método _sendSymbol() do ator Initializer .............................................84

Figura 4.29 Método _detectSignal() do ator Initializer ............................................85

Figura 4.30 Método _transmitSignal() do ator Initializer .........................................86

Figura 4.31 Método _fire() do ator Initializer ..........................................................87

RESUMO

Neste trabalho abordamos o problema da captura e validação da especificaçãofuncional de um sistema digital através de especificações executáveis. Nosconcentramos na comparação de modelos computacionais, isto é, o suporte semânticode uma linguagem de descrição de sistemas. O ambiente Ptolemy II foi escolhido parao desenvolvimento deste trabalho, uma vez que ele possui uma infra−estrutura para aimplementação de modelos computacionais e criação de especificações executáveis.Comparamos seis modelos computacionais. Fundamentamos nossa metodologia naanalise de comportamentos primitivos presentes em sistemas reais. Trêscomportamentos foram estudados: seqüência de expressões, desvio condicional eiteração com duração fixa. Uma ferramenta de software foi desenvolvida para auxiliarna comparação dos diferentes modelos computacionais através da reprodução daexecução de uma especificação. Foi possível observar que o comportamento deseqüência de expressões foi capturado eficientemente pelos seis modeloscomputacionais. Os comportamentos de desvio condicional e iteração com duraçãofixa apresentaram dificuldades para a captura com alguns modelos. Finalmente,desenvolvemos a especificação de um modem ADSL. Utilizamos o modelocomputacional que se mostrou mais eficiente para a captura dos três comportamentos.Identificamos um novo comportamento primitivo a partir desse estudo.

ABSTRACT

In this dissertation we studied the problem of capture and validation of afunctional specification of a digital system using executable specifications. Wefocused on comparing different models of computation, i.e., the semantic support of asystem description language. We have chosen the Ptolemy II framework for thedevelopment of this work, since it has several models implemented and efficientlysupports the addition of others. We compared six different models. We based ourmethodology on the analysis of primitive behaviors present in real systems. Threedifferent behaviors we studied: sequence of expressions, conditional execution andfixed length iteration. We developed a software tool for helping the comparison ofdifferent models of computation by reproducing an execution. It was possible toefficiently capture the sequence of expressions with all six models. The other twoprimitive behaviors presented some difficulties under certain models. Finally, wedeveloped the specification of an ADSL modem. An executable specification usingthe most efficient model for capturing the three behaviors was employed. We wereable to identify a new primitive behavior from this case study.

1

Capítulo 1

Introdução

1.1 Considerações Iniciais

O desenvolvimento das tecnologias de microeletrônica vem possibilitando a criação de circuitosintegrados cada vez mais complexos. Conforme foi previsto pela lei de Moore [BRE98], a capacidade deintegração dobra a cada um ou dois anos. Os microprocessadores de alto desempenho são um bomexemplo dessa evolução: já existem processadores com mais de 20 milhões de transistores operando afreqüências acima de 1 GHz. Também já é uma realidade o projeto de circuitos de aplicação específica(ASIC) com milhões de transistores. Essa abundância de recursos possibilita a implementação desistemas cada vez mais complexos, que podem ser realizados utilizando vários componentes discretos ouem apenas uma única pastilha. Este último caso é denominado de System−on−Chip (SOC).

Embora o desenvolvimento da tecnologia de circuitos integrados seja fundamental para aimplementação de sistemas cada vez mais versáteis e completos, ele também traz problemas. A principaldificuldade é lidar com a complexidade do projeto. Por exemplo, foi avaliado que durante o período de20 anos, o número de transistores de um CI aumentou à uma taxa de 58% ao ano, enquanto que nomesmo período, a produtividade de um projetista, medida em número de transistores projetados por dia,aumentou à uma taxa de 21% [GAJ00]. Isso significa que não mais a capacidade de manufatura é ogargalo, mas sim o desenvolvimento do CI, ou seja, as ferramentas e metodologias CAD.

A solução que a comunidade científica e industrial considera como sendo a mais promissora éelevar o nível de abstração na qual o projetista trabalha, pois assim a quantidade de detalhes é reduzida.Entretanto, um nível de abstração mais alto significa que linguagens de especificação, ferramentas deprojeto, metodologias, etc, devem ser adequadas. Essa tarefa é bastante complexa pois envolve amudança para um novo paradigma de projeto. Em [GAJ00], Gajski et al. identificam três metodologiassendo empregadas atualmente para o desenvolvimento de sistemas em alto nível: projeto baseado emplataformas (platform based design), integração de propriedade intelectual (IP Assembly), e síntese apartir de especificações (Synthesis from Specifications). Essas três soluções diferem em custo, esforço deprojeto, flexibilidade e qualidade.

O projeto baseado em plataforma [CHA99] fundamenta−se no uso de uma arquitetura pré−definida, otimizada para um tipo de aplicação. A metodologia empregada deve permitir a criação de umaespecificação do sistema, para então mapeá−la na arquitetura.

O projeto utilizando propriedade intelectual (IP) é baseado na reutilização de blocos pré−projetados e pré−caracterizados. A metodologia incorpora as tarefas de seleção de componentes e criaçãoda arquitetura (envolve a interface entre blocos), além das tarefas presentes no projeto baseado emplataforma. O desafio para a solução utilizando blocos IPs é a criação de uma base de dados decomponentes, além de formatos de troca de dados. Já existem esforços da comunidade de ferramentasCAD para atacar esses problemas [SYSC].

A síntese a partir de especificações significa implementar as diferentes funções da especificaçãodiretamente em hardware e software. Essa solução é a mais flexível das três. A metodologia para projetoé bastante similar às outras duas soluções, com o problema adicional de particionar a especificação ecriar métodos eficientes para explorar as inúmeras soluções arquiteturais.

Embora existam três diferentes soluções sendo estudadas, todas elas requerem a criação de umaespecificação executável para capturar o sistema nos diferentes níveis de abstração, desde suafuncionalidade até a implementação em uma arquitetura específica [GAJ00]. Conjuntamente com umaespecificação para o ambiente no qual o sistema será implantado, é possível analisar o comportamentodo sistema sendo desenvolvido através dos resultados da execução, tal qual em uma simulaçãotradicional. Esse tipo de técnica já vem sendo empregada na industria para o projeto de ASICs [SYSC],onde a linguagem de programação C é utilizada para capturar o algoritmo a ser implementado. Só apósextensas análises e otimizações é que tal descrição em linguagem C é refinada para uma descrição emlinguagem VHDL (comportamental/RTL).

2Toda linguagem de programação ou de descrição de hardware possui uma definição sintática e

semântica. A semântica da linguagem define o significado de cada comando, ou seja, como aquelecomando produz alguma alteração no estado do sistema ou ambiente e como ele está relacionado à outroscomandos. A semântica de uma linguagem é definida com base em um modelo computacional (MoC),ou seja , um conjunto de definições e regras que possibilitam a representação formal e não ambígua deum algoritmo. Um exemplo clássico de modelo computacional é a máquina RAM [AHO74] associada àprogramas seqüenciais. O item 3.2 deste texto apresenta uma lista de alguns modelos computacionais.

A escolha de um, ou um conjunto, de MoCs para o desenvolvimento de uma especificaçãoexecutável depende de fatores como o domínio de aplicação, características semânticas do modelo einteração com outros modelos computacionais. Essa escolha irá afetar as tarefas de captura/validação docomportamento do sistema bem como posterior tarefa de sintetizar sua arquitetura.

Nesse trabalho, iremos estudar a eficiência de alguns MoCs para capturar e validar afuncionalidade de um sistema. A motivação para nosso trabalho é:

1. o fato do projeto de sistemas eletrônicos através de metodologias top−down partirem dacaptura de sua especificação através de uma linguagem SLDL;

2. linguagens SLDL são sempre baseadas em um ou um conjunto de modelos computacionais oque pode limitar a possibilidade de capturar as especificações;

3. na existência de uma grande variedade de modelos computacionais.

Portanto, é necessário que exista algum auxílio para o projetista, na forma de ferramentas,critérios, metodologias, tal que este possa identificar os modelos computacionais mais adequados paracapturar as especificações de sua aplicação.

1.2 Trabalhos Relacionados

O problema da escolha de um método de descrição para sistemas surgiu com o desenvolvimentodas técnicas de co−projeto hardware/software (hardware/software codesign), pois uma única linguagemnão era adequada para a captura do comportamento dos módulos em hardware e software. Isto ocorredevido as diferenças intrínsecas entre hardware e software. No nível sistêmico esse problema torna−semais evidente, uma vez que é necessário capturar comportamentos heterogêneos como hardwareanalógico, hardware digital dominado pelo fluxo de dados, hardware digital dominado pelo fluxo decontrole, dispositivos mecânicos, software com restrições temporais, etc.

Três soluções foram estudadas: desenvolver uma nova linguagem, estender uma linguagemexistente ou utilizar várias linguagens conjuntamente. Dentre inúmeros trabalhos que exemplificam taissoluções, podemos enumerar os seguintes:

� [BEC92]: a linguagem de programação C e a linguagem de descrição de hardware Verilog sãoutilizadas conjuntamente para cosimular um sistema hardware/software;

� [COS99]: inicialmente a linguagem SDL é utilizara para capturar a parte eletrônica de umasistema mecatrônico e a linguagem Matlab para capturar o comportamento dos componentesmecânicos. Em seguida, o código em linguagem SDL é refinado para uma descrição utilizandolinguagem C e VHDL;

� [LAV99]: a semântica da linguagem C é estendida com comandos da linguagem Esterel. Essetrabalho concentra−se em sistemas dominados pelo fluxo de controle, mas que necessitam deuma linguagem eficiente para descrever as partes dominadas pelo fluxo de dados;

� [MAR98]: a linguagem de programação Java foi estendida com algumas classes, tornando−aadequada para capturar sistemas reativos;

� [REE95]: a linguagem Haskell é utilizada conjuntamente com um ambiente gráfico paracapturar sistemas dominados pelo fluxo de controle;

3

� [SYSC]: a linguagem C++ é estendida através de um conjunto de classes para permitir adescrição de circuitos síncronos;

� [GAJ00]: uma nova linguagem foi desenvolvida visando a captura e refinamento de sistemasdigitais;

� [DAV99]: a linguagem Java é utilizada conjuntamente com um grupo de classes que permitema implementação de diversos modelos computacionais.

Nenhum dos trabalhos mencionados procura analisar quando cada linguagem ou característicasemântica deve ser empregada. Em geral, uma classe específica de sistema é escolhida e a linguagemmais apropriada é empregada. O único trabalho que encontramos que aborda a comparação de modeloscomputacionais é [LEE98]. Entretanto, a comparação é feita de maneira descritiva e teórica.

1.3 Estrutura do Texto

Esta dissertação apresenta os seguintes capítulos:

� Capítulo 2: descreveremos os fundamentos teóricos e práticos necessários para odesenvolvimento desse trabalho. Descreveremos uma ferramenta de software quedesenvolvemos;

� Capítulo 3: apresentaremos nossa metodologia para o estudo do problema da escolha demodelos computacionais;

� Capítulo 4: apresentaremos o estudo de caso de um sistema real que desenvolvemos paraaplicar alguns dos resultados obtidos no capítulo 3;

� Capítulo 5: contém o resumo final do trabalho e propostas para trabalhos futuros.

4

Capítulo 2

Fundamentos

2.1 Introdução

Nesse capítulo faremos uma breve descrição dos fundamentos utilizados nesse trabalho eintroduziremos termos utilizados ao longo dessa dissertação. Inicialmente, o ambiente Ptolemy serádescrito. Seus componentes internos serão apresentados juntamente com um exemplo de como umaespecificação executável é criada. Em seguida, descreveremos os modelos computacionais queestudamos e enumeraremos outros importantes modelos encontrados na literatura. Ao final do capítuloapresentaremos uma ferramenta que desenvolvemos para a análise da execução de especificações.

2.2 O Ambiente Ptolemy

O ambiente Ptolemy II [DAV99] é a segunda geração de um projeto sendo desenvolvido naUniversidade da Califórnia em Berkeley desde 1990. Inicialmente voltado para o desenvolvimento desistemas (hardware e software) para processamento digital de sinais, atualmente seu principal objetivo édar suporte ao desenvolvimento de sistemas embutidos (embedded systems), principalmente oscomponentes de software do sistema. O fundamento central do ambiente Ptolemy1 é a utilização conjuntade diferentes modelos computacionais para a captura das especificações do sistema. A heterogeneidadeobservada em sistemas embutidos é a justificativa para essa abordagem, isto é, um sistema embutidopode utilizar várias tecnologias distintas como hardware analógico, hardware digital, componentesópticos, componentes mecânicos, software de tempo real, etc. Dessa forma, um único MoC não éeficiente para a captura do sistema.

2.2.1 A Implementação do Ambiente Ptolemy

A linguagem de programação Java foi escolhida pelo grupo de desenvolvimento do ambientePtolemy. Essa também é a linguagem de programação utilizada para criar uma especificação executável,ou seja, um especificação no ambiente Ptolemy é um conjunto de classes criadas pelo usuário mais umconjunto de classes disponíveis no ambiente. A figura 2.12 apresenta resumidamente um diagramaestático de classes pertencentes aos dois pacotes centrais do ambiente: Kernel e Actor. Outros pacotesauxiliares também estão disponíveis, além de pacotes que implementam modelos computacionais.

1 Quando utilizamos o termo Ptolemy, estamos nos referindo à versão II do ambiente, e não a versão Classic (anterior). Caso seja necessário,faremos explicitamente a distinção entre as versões.

2 Por conveniência, as figuras mostradas no item 2.2 foram extraídas da documentação do ambiente Ptolemy[DAV99]. Para uma descriçãocompleta do ambiente, utilize tal referência.

5

Figura 2.1 − Diagrama estático de classes simplificado dos pacotes Actor e Kernel.

2.2.1.1 O Pacote Kernel: Sintaxe da Especificação

O pacote Kernel é composto por um conjunto de classes para implementar e manipular grafoscom nós hierárquicos, também chamados de topologias. Uma topologia não hierárquica é constituída porentidades (Entity) e relações (Relation). A figura 2.2 apresenta um exemplo de topologia3.

Figura 2.2 − Uma topologia não hierárquica.

Cada entidade pode possuir vários portos (Port) e uma relação pode conectar vários portos entresi. O uso de portos e relações torna uma topologia diferente de um grafo matemático. Uma relação é umaconexão entre múltiplos elementos. Já em grafos matemáticos, arcos são conexões entre dois elementos.Um grafo matemático poderia ser representado através de entidades designando os nós do grafos e cadauma possuindo exatamente um porto. No caso de um grafo direcionado, cada entidade possuiria doisportos, uma para arcos de entrada e outro para arcos de saída.

3 Ao contrário da figura 2.2, nas representações gráficas de topologias apresentadas nos capítulos seguintes, utilizaremos retângulos comorepresentação gráfica para atores e setas direcionadas para representar conexões entre dois ou mais atores. O terminal com a seta indica oator de destino e o outro terminal o ator de origem. Dessa forma, não iremos mostrar de forma explícita as relações.

Nameable

<<Interface>>

<<Interface>>Executable

<<Interface>>Actor

NamedObj

Entity

ComponentEntity

AtomicActor

Manager

Port Relation

Workspace

CompositeEntity

CompositeActor

Director

ComponentPort

ComponentRelation

0..n 0..1

0..n

1

0..n

Container 0..n

0..nLink

Link

Container 0..1

0..n

0..1

0..1

1

0..2

Container

0..n 0..1

1

0..1

0..n

ImplementaDeriva

Pertence ao pacote Kernel

Pertence ao pacote Actor

Attribute

Entidade

Porto

Entidade

Porto

Entidade

Porto

Relação

Link Link

Link

6Como mostrado na figura 2.1, cada uma das três principais classes do pacote Kernel possui uma

classe derivada com o prefixo Component. A finalidade dessas classes é permitir a criação de topologiashierárquicas. Além dessas três classes, a classe CompositeEntity é utilizada para conter objetos do tipoComponentEntity e ComponentRelation. Dessa forma, uma CompositeEntity contém uma sub−topologia.Entidades que não contenham sub−grafos são denominadas de atômicas. A figura 2.3 apresenta umexemplo de topologia hierárquica, onde E0 e E1 são entidades do tipo CompositeEntity.

Figura 2.3 − Exemplo de topologia hierárquica.

Os portos P3 e P4 da figura 2.3 são denominados de transparentes (transparent), enquanto queos demais são denominados de opacos (opaque). Esse conceito também se aplica a entidades, como serámostrado mais adiante.

Um porto é opaco quando a entidade que o contém é opaca, e é transparente quando a entidadeque o contém é transparente. Quando um porto for opaco, conexões com uma possível sub−topologia sãoinvisíveis. Já um porto transparente permite que algoritmos percorram todas as conexões associadas aele. Por exemplo, existe um método na classe ComponentPort denominado deepConnectedPortList().Esse método retorna uma lista de todos os portos conectados, independentemente do nível de hierarquia.No caso do porto P1 da figura 2.3, esse procedimento retornaria os portos P2, P5 e P6. Portostransparentes não são retornados. Quando o procedimento atinge o porto P4, através da relação R2, oprocedimento continua pesquisando, através das relações R3 e R4.

2.2.1.2 O Pacote Actor: Suporte à Semântica

As classes do pacote Kernel definem uma topologia onde as entidades não possuem semântica.O pacote Actor é composto por um conjunto de classes para adicionar semântica à topologia e permitir aimplementação de um modelo computacional específico, derivando−se das principais classes do pacoteactor. Além das classes mostradas na figura 2.1, a classe IOPort e a interface Receiver também possuempapel importante.

Duas características são necessárias para a implementação de uma semântica: troca de dadosentre os atores da topologia e o controle da execução.

Troca de Dados

A figura 2.4 ilustra o processo básico de troca de dados.

Figura 2.4 − Exemplo de troca de dados

Dois portos são utilizados na figura 2.4: um de saída (P1) e um de entrada (P2). Eles são

E0

E1

E2

E3

E4

E5

P1

P2

P3

P4 P5

P6

R1

R2

R3

R4

send(0, t0)

send(1, t1) 2 2

2 get(0), get(1)

token t0, t1

receiver.put(0)receiver.put(1)

P1 P2

7instâncias da classe IOPort. Essa classe disponibiliza vários métodos, entre eles o método send(),utilizado por um porto de saída para enviar dados aos portos conectados, e o método get(), utilizado porum porto de entrada para receber dados. No ambiente Ptolemy, os dados são transmitidos encapsuladosem tokens. Uma vez criado, o valor de um token é imutável4.

A função do método send() é transferir os dados para um elemento denominado de receptor(receiver). Cada conexão com um porto de entrada possui associado um receptor. Na figura 2.4, temosduas conexões associadas. Cada conexão também é denominada de canal. Quando um porto possui maisde um canal, como na figura 2.4, deve−se especificar no método send() e get() por qual canal o tokendeve ser enviado ou recebido. Isso é feito através do primeiro argumento desses métodos. Uma vez queos dados estejam presentes no respectivo receptor, o ator de destino pode executar o método get() e obteros dados.

No pacote Actor, o receptor não é uma classe concreta, mas sim uma interface. O receptor éimplementado como parte do modelo computacional, pois diferentes modelos possuem semânticasdistintas de comunicação entre elementos. Por exemplo, atores em um modelo data flow comunicam−seatravés de filas. As filas são implementadas em um receptor. Já no modelo Discrete Event, o receptordeve enviar os dados para uma fila global.

Controle da Execução

A classe Director do pacote Actor tem o principal papel no controle da execução. Aimplementação de um modelo computacional deve derivar essa classe a fim de implementar métodoscomo fire(), prefire() e postfire() definidos na interface Executable. Em um Director, esses métodos sãoresponsáveis pelo controle da execução dos blocos do sistema. Para tal, é introduzido o conceito deiteração. A cada iteração da execução, o método prefire() é o primeiro a ser chamado, em seguida ométodo fire(), seguido pelo método postfire(). O comportamento exato de cada método é definido pelaimplementação de um modelo computacional. Em geral, o escalonador5 de um MoC é implementado nosmétodos fire() e postfire() do respectivo Director. Um Director deve sempre estar associado a um únicoator Composite. Essa associação torna o ator opaco. A utilização de um Director é ilustrada na figura2.5.

Figura 2.5 − Exemplo de topologia para ilustrar o uso da classe Director.

O Director D1 está associado ao ator E0, que representa o nível mais alto da hierarquia (atortoplevel). Nesse nível, existem três atores: E1, E2, E3. O bloco E1 é um ator atômico. O bloco E3 é umator hierárquico transparente, já que não existe nenhum Director associado à ele. Quem governa aexecução da sub−topologia do ator E3 é o Director D1. Já o bloco E2 é um ator hierárquico opaco, poiso Director D2 está associado à ele. Para o Director D1, o bloco E2 é um ator atômico. Ao chamar ométodo fire() de E2, o controle é passado para o Director D2. Dessa forma, a ferramenta implementa ummecanismo transparente para a co−simulação de sistemas utilizando MoCs distintos. A figura tambémapresenta um Manager. Este deve ser único no sistema e associado ao ator toplevel. Sua função é iniciar,interromper e coordenar a execução de todo o sistema.

2.2.1.3 Outras Classes Importantes

4 Como será descrito adiante no texto, o tipo ObjectToken é uma exceção à essa regra.5 Escalonador é um algoritmo utilizado para determinar uma ordem de execução dos atores. O escalonador pode ser seqüencial (apenas um

ator executa a cada momento) ou paralelo (mais de um ator executa a cada momento).

E0 D1: local director

E1P1 P2 P5

E4

P6

E2 D2: local director

E5P7P4P3

E3

8

Além dos pacotes descritos acima e os que implementam diversos modelos computacionais, oambiente Ptolemy apresenta um conjunto de classes auxiliares, como o pacote Plot, uma aplicação paravisualizar gráficos bidimensionais, pacotes de funções matemáticas e um pacote para implementação deum sistema de tipos de dados (type system).

Tipos de Dados no Ambiente Ptolemy

A classe Token e suas derivadas compõem o coração do pacote de dados do ambiente Ptolemy.Como mencionado anteriormente, todos os dados transmitidos entre atores são encapsulados em tokens.A classe Token apresenta apenas a definição de alguns métodos utilitários, como operações aritméticas.Entretanto, o ambiente possui um sistema de tipos com várias subclasses para diferentes tipos de dados.A figura 2.6 apresenta o type lattice do ambiente. Os tipos Numerical e Scalar são classes abstratas.

Figura 2.6 − Type lattice do ambiente Ptolemy.

Em geral, os portos de entrada/saída e os parâmetros6 de um ator podem ser criados com um tipoassociado. Esse tipo pode ser especificado pelo usuário de forma exata, utilizando o métodosetTypeEquals(), ou de forma relativa. Neste caso, três métodos estão disponíveis: setTypeAtLeast(),especifica que o tipo do objeto em questão deve ser maior ou igual ao do parâmetro do método;setTypeAtMost(), indica que o tipo do objeto deve ser menor ou igual ao do parâmetro do método:setTypeSameAs(), indica que o tipo do objeto deve ser igual ao do parâmetro do método.

No início da execução, o ambiente (mais precisamente, uma instância do objeto Manager) iráverificar se existe a consistência de tipos, ou seja, se um porto de entrada conectado à um porto de saídaapresentam o mesmo tipo, ou se existe a possibilidade de conversão sem perdas (baseado no lattice dafigura 2.6). Caso alguns tipos não estejam especificados ou foram especificados de forma relativa, haveráa resolução de tipos.

2.2.2 Utilizando o Ambiente Ptolemy

6 Parâmetro é um objeto que também pode armazenar um token, e dessa forma também é tipado. O parâmetro pode ser utilizado paraespecificar valores de configurações de um objeto, tornando−o mais flexível.

General

String

Matrix

Numerical

Object BooleanMatrix

Boolean

FixMatrix

Fix

Scalar

LongMatrix ComplexMatrix

DoubleMatrix

IntMatrix

Array

Long Complex

Double

Int

NaT

9O item 2.2.1 ilustrou de forma suscinta os principais componentes internos do ambiente

Ptolemy. Utilizando essa infra−estrutura, podemos criar uma especificação executável. Para isso, énecessário criar os atores da especificação, interconectá−los e associar à especificação um ou maismodelos computacionais. A figura 2.7 apresenta o esqueleto básico de um ator atômico.

1− publ i c c l ass At or Exempl o ext ends TypedAt omi cAct or {2−3− publ i c TypedI OPor t ent r ada;4− publ i c TypedI OPor t sai da;5−6− publ i c Par amet er par ;7−8− publ i c At or Exempl o( TypedAt omi cAct or cont ai ner , St r i ng name) 9− t hr ows NameDupl i cat i onExcept i on, I l l egal Act i onExcept i on {10−11− super ( cont ai ner , name) ;12− 13− ent r ada = new TypedI OPor t ( t hi s , ¨ ent r ada¨ , t r ue, f al se) ;14− ent r ada. set TypeEqual s( BaseType. I NT) ;15−16− sai da = new TypedI OPor t ( t hi s , ¨ sai da¨ , f al se, t r ue) ;17− sai da. set TypeEqual s( BaseType. DOUBLE) ;18−19− par = new Par amet er ( t hi s , ¨ par amet r o1¨ , new I nt Token( 1) ) ;20−21− }22−23− publ i c voi d i ni t i al i ze( ) t hr ows I l l egal Act i onExcept i on {24−25− I nt Token i t = ( I nt Token) par . get Token( ) ;26− _var = i t . i nt Val ue( ) ;27−28− }29−30− publ i c bool ean pr ef i r e( ) t hr ows I l l egal Act i onExcept i on {31−32− . . . .33− r et ur n super . pr ef i r e( ) ;34− }35−36− publ i c voi d f i r e( ) t hr ows I l l egal Act i onExcept i on {37−38− I nt Token i t = ( I nt Token) ent r ada. get ( 0) ;39− 40− sai da. br oadcast ( Doubl eToken. conver t ( i t ) ) ;41− }42−43− publ i c bool ean post f i r e( ) t hr ows I l l egal Act i onExcept i on {44−45− . . . .46− r et ur n super . post f i r e( ) ;47− }48−49− publ i c voi d wr apup( ) t hr ows I l l egal Act i onExcept i on {50−51− super . wr apup( ) ;52−53− . . . .54− }55−56− pr i vat e i nt _var ;57− }

Figura 2.7 − Um exemplo genérico de ator atômico.

Na linha 1, o ator é criado derivando a classe TypedAtomicActor, ou seja, é um ator atômico comportos tipados. Em certos modelos computacionais, novas classes de atores atômicos são criadasestendendo a classe TypedAtomicActor. Da linha 3 à linha 6, dois portos e um parâmetro são declaradoscomo variáveis públicas. Da linha 8 à linha 21 está implementado o construtor da classe. Duas exceçõesimplementadas pelo ambiente Ptolemy são declaradas na linha 9. Na linha 13 o porto de entrada (oterceiro parâmetro do construtor é true) é criado . Em seguida, o tipo do porto é determinado como sendoum inteiro. O porto de saída (neste caso, o quarto parâmetro do construtor deve ser true) é criado demaneira similar nas linhas 16 e 17. Na linha 19, o parâmetro do ator é criado e inicializado como tendotipo inteiro com valor inicial igual à 1 (terceiro parâmetro).

10Observando a figura 2.1, note que a classe AtomicActor (pai da classe TypedAtomicActor)

implementa a interface Executable. Nessa interface estão declarados, entre outros, os métodosinitialize(), prefire(), postfire(), fire() e wrapup(). Conforme mencionado no item 2.2.1.2, esses métodossão usados pela classe Director e suas derivadas para o controle da execução. No caso de um atoratômico, esses métodos são definidos pelo usuário para implementar o comportamento desejado. Afunção de cada método é:

� initialize() (linha 23 à 28): chamado uma única vez durante a execução, antes de todos osoutros métodos. No exemplo da figura 2.7, esse método é utilizado para obter e armazenar ovalor do parâmetro do ator em uma variável interna7 (linhas 25 e 26);� prefire() (linha 30 à 34): primeiro a ser chamado, uma única vez, durante uma iteração daexecução. Caso um valor false seja retornado, isso indica que o ator não está apto para serexecutado;� fire() (linha 36 à 41): pode ser chamado várias vezes em uma mesma iteração, após o métodoprefire(). Na linha 38, um token é lido do porto de entrada, utilizando o método get(). Na linha40, o valor do token é convertido de inteiro para real, e enviado utilizando o métodobroadcast(). Esse método envia o dado para todos os portos de entrada conectados à ele;� postfire() (linha 43 à 47): similar ao método prefire(). Ele é o último método a ser chamado emuma iteração;� wrapup() (linha 49 à 54): chamado uma única vez ao final da execução.

Uma vez que todos os atores de uma especificação são criados, é necessário interconectá−los ecriar os objetos que irão controlar a execução. A figura 2.8 apresenta o esqueleto básico de um trecho decódigo para tal função.

1− publ i c c l ass Si st ema {2− 3− publ i c s t at i c voi d mai n( St r i ng ar gs[ ] ) t hr ows4− I l l egal St at eExcept i on, I l l egal Act i onExcept i on,5− NameDupl i cat i onExcept i on {6−7− TypedComposi t eAct or t opl evel = new TypedComposi t eAct or ( ) ;8− t opl evel . set Name( " t est e1" ) ;9−10− Manager exec = new Manager ( " exec" ) ;11− t opl evel . set Manager ( exec) ;12−13− Di r ect or l ocal = new Di r ect or ( t opl evel , " Local " ) ;14−15− At or Exempl o a1 = new At or Exempl o( t opl evel , ¨ a1¨ ) ;16− a1. par . set Token( new I nt Token( 10) ) ;17−18− At or Exempl o a2 = new At or Exempl o( t opl evel , ¨ a2¨ ) ;19− At or Exempl o a3 = new At or Exempl o( t opl evel , ¨ a3¨ ) ;20−21− t opl evel . connect ( a1. sai da, a2. ent r ada) ;22−23− TypedI ORel at i on r 1 = new TypedI ORel at i on( t opl evel , ¨ r 1¨ ) ;24− a2. sai da. l i nk( r 1) ;25− a3. ent r ada. l i nk( r 1) ;26−27− exec. r un( ) ;28− }29− }

Figura 2.8− Exemplo de arquivo principal de uma especificação executável.

Na linha 7, o ator de nível mais alto (toplevel) é criado. Nenhum outro ator Composite éutilizado, dessa forma, o exemplo da figura 2.8 não é hierárquico. Na linha 10, uma instância de objetoManager é criada e associada ao ator hierárquico toplevel (linha 11). Na linha 13, um Director é criado eassociado ao ator hierárquico. Esse ator, um objeto Manager e um objeto Director, sempre estarãopresentes em qualquer especificação executável. Três instâncias do ator da figura 2.7 são utilizadas. Nalinha 16, o valor padrão do parâmetro par do AtorExemplo exemplo é modificado. Na linha 21, é feita aconexão entre dois portos, através do método connect() do ator hierárquico. Outra forma de criar uma

7 Adotamos como notação adicionar um caractere _ ao início de um nome de variável quando esta for private.

11conexão é exemplificada da linha 23 à linha 25, através da criação explícita de um objeto Relation. Ocomando da linha 27 é utilizado para iniciar a execução.

2.3 Os Modelos Computacionais

Descreveremos nesse item a semântica dos seis modelos computacionais (MoC) que utilizamos ecaracterísticas referentes à implementação desses modelos no ambiente Ptolemy. Iremos ressaltar doispontos importantes de um MoC: o escalonador e o modelo de tempo. Em seguida, apresentaremos umalista não exaustiva de outros modelos. É importante notar que um mesmo MoC pode ser implementadode várias maneiras diferentes. Todos os resultados desse trabalho são referentes as implementaçõesadotadas no ambiente Ptolemy.

2.3.1. Discrete Event

O modelo computacional Discrete Event [MUL99] (DE) é baseado no processamento de eventosproduzidos pelos atores. Um evento é um par composto por um token e um valor numérico real. Essevalor numérico é denominado de timestamp e sua função é modelar um valor temporal, ou seja, omodelo DE possui uma noção explícita de tempo. O tempo nesse modelo é compartilhado por todos osatores da especificação. Quando um ator produz um evento, este é enviado para uma fila de eventoscontrolada pelo escalonador, e não para o ator de destino. Os eventos são mantidos ordenados de formacrescente na fila, com base no valor do timestamp. A cada iteração, o escalonador remove o próximoevento da fila e envia−o ao ator de destino. Esse ator é então ativado, isto é, o escalonador executa osmétodos prefire(), fire() e postfire(). É possível criar uma especificação com atores que não manipulam ovalor do timestamp. Esse tipo de ator é denominado de atraso zero (zero delay). A execução de umaespecificação no modelo DE é interrompida quando não há mais nenhum evento na fila ou quando umvalor de tempo especificado para o fim da execução é alcançado.

Uma situação de conflito que pode ocorrer nesse modelo é a presença de eventos simultâneos, ouseja, eventos com um mesmo timestamp. A figura 2.9 ilustra esse situação.

Figura 2.9 − Situação de eventos simultâneos no MoC DE.

Na situação da figura 2.9, o ator A produziu dois eventos com um mesmo timestamp T. Umevento é para o ator B, e o outro para o ator C. Nessa situação, qual deve ser o próximo ator a serativado?

A solução implementada no ambiente Ptolemy associa a cada ator um valor inteiro não negativoe único (prioridade). Esse valor é obtido através de uma ordem topológica de um grafo, onde os nós sãoos atores e os arcos representam as conexões que não apresentam atraso. Como mencionado em[MUL99], essa solução torna a execução da especificação determinística. É possível que o grafo geradocontenha ciclos. Isso significa que a especificação contém um ciclo sem atraso, situação que impede aexecução da especificação, pois introduz um loop com geração infinita de eventos. Neste caso, oambiente gera uma mensagem indicando para o usuário do problema. Os principais passos do algoritmode escalonamento do MoC DE são:

1. caso a fila de eventos esteja vazia ou o instante de tempo final tenha sido alcançado, vá para opasso 9;

2. obtenha o próximo evento da fila;

RampA

RampB

RampC

T

T

123. atualize o instante de tempo atual para o valor do timestamp do evento obtido no passo 2;4. determine o ator de destino do evento obtido e introduza o token no respectivo porto de

destino;5. caso não exista nenhum outro evento simultâneo para o ator do passo 4, vá para o passo 7;6. obtenha todos os eventos simultâneos para o ator do passo 4 e introduza−os nos respectivos

portos do ator;7. ative o ator até que todos os tokens em seus portos tenham sido consumidos;8. vá para o passo 1;9. fim.

Quando mais que um evento com o mesmo timestamp estiver disponível para um ator, todos sãoremovidos da fila de eventos (passos 4, 5, 6). Nessa condição, caso mais que um evento seja para omesmo porto, uma fila é utilizada no porto de entrada/saída, respeitando a ordem desses eventos na filado escalonador.

É possível criar atores de atraso zero utilizando as classes TypedAtomicActor eTypedAtomicPort, mencionadas no item 2.2. Entretanto, para utilizar as características específicas doMoC DE, as classes DEIOPort e DEActor estão disponíveis. A figura 2.10 apresenta um trecho decódigo de um ator utilizando tais classes.

1− . . . .2− i mpor t pt ol emy. domai ns. de. ker nel . * ;3− i mpor t pt ol emy. domai ns. de. l i b. DETr ansf or mer ;4− . . . .5−6− publ i c c l ass Del ay ext ends DETr ansf or mer {7−8− publ i c Del ay( TypedComposi t eAct or cont ai ner , St r i ng name) t hr ows9− NameDupl i cat i onExcept i on, I l l egal Act i onExcept i on {10− super ( cont ai ner , name) ;1112− del ay = new Par amet er ( t hi s , " del ay" , new Doubl eToken( 1. 0) ) ;13− del ay. set TypeEqual s( BaseType. DOUBLE) ;1415− i nput . del ayTo( out put ) ;16− }17−18− publ i c Par amet er del ay;19−20− . . . .21−22− publ i c voi d f i r e( ) t hr ows I l l egal Act i onExcept i on {23− _cur r ent I nput = i nput . get ( 0) ;24− }25−26− publ i c bool ean post f i r e( ) t hr ows I l l egal Act i onExcept i on {27− out put . br oadcast ( _cur r ent I nput ,28− ( ( Doubl eToken) del ay. get Token( ) ) . doubl eVal ue( ) ) ; 29− r et ur n super . post f i r e( ) ;30− }31−32− pr i vat e Token _cur r ent I nput ;33− }

Figura 2.10 − O ator Delay no MoC DE.

O ator da figura 2.10 implementa um atraso por um tempo especificado através de um parâmetro(linha 18). O comando da linha 15 indica que existe um caminho com atraso entre um porto de entrada eum porto de saída. Essa informação é utilizada durante a criação do grafo utilizado para determinar ovalor de prioridade de cada ator. Nas linhas 27 e 28 o evento é criado, através de uma versão específicado método broadcast(). Nessa versão, o segundo parâmetro indica o valor do atraso.

2.3.2 Synchronous Reactive

O modelo computacional Synchronous Reactive [EDW94][EDW97] (SR) é baseado na hipótese

13de sincronismo: o sistema é capaz de produzir uma resposta à estímulos externos de forma infinitamenterápida. Cada reação do sistema é instantânea e atômica, dessa forma, a evolução do tempo é dividida emuma série de instantes discretos. A hipótese de sincronismo também é utilizada por uma classe delinguagens de programação, tais como Esterel, Lustre, Signal, denominada de síncrona[BER98][HAL93][BEN91], além de circuitos digitais síncronos.

Antes de descrevermos com maior detalhe a semântica do modelo SR, é necessário mencionaralgumas definições, proposições e teoremas importantes. As demonstrações para esses teoremas eproposições podem ser encontradas em [EDW97].

Definição 1:

Um conjunto parcialmente ordenado (poset) é um conjunto S com uma relação parcial de ordem� que, para quaisquer x, y, e z pertencentes à S, satisfaz:

� x �

x (reflexiva);� x �

y e y �

x implica que x = y (antissimétrica);� x �

y e y �

z implica que x �

z (transitiva);

Definição 2:

Um limite superior de um conjunto T é um elemento u tal que t�

u para todos t � T. O menorlimite superior de um conjunto T, representado por

�T, é um elemento l tal que l

�u para todos limites

superiores u.

Proposição 1:

O menor limite superior de um conjunto, se existir, é único.

Definição 3:

Uma cadeia é um conjunto totalmente ordenado C, isto é, para todo x, y � C, ou x�

y ou y�

x.

Definição 4:

Um poset, onde toda cadeia em S possui um menor limite superior em S, é denominado deconjunto parcialmente ordenado completo (CPO).

Proposição 2:

O menor limite superior de uma cadeia finita sempre existe e é seu maior elemento.

Corolário 1:

Um poset apenas com cadeias finitas é um CPO.

Definição 5:

O limite inferior de um poset, representado por � , é um membro de S tal que � � s para todo s� S. Um poset com um limite inferior é denominado de poset pontual.

Proposição 3:

14Se D1 e D2 são CPOs, então D1 � D2 é um CPO sob a ordem

(x1, x2) �

(y1, y2) se e somente se x1 �

y1 e x2 �

y2

e se x1 = (x11, x1

2) x2 = (x21, x2

2), ....

� { x1,x2,...} = (�{ x1

1, x21, ...} ,

�{ x1

2, x22, ...} ).

Definição 6:

Uma função f:D � E entre posets D e E é monotônica se para todo x,y � D tal que x�

y, f(x)� f(y).

Definição 7:

Uma função f:D � E entre CPOs D e E é contínua se para todas as cadeias C ⊆ D, f(�C) =�

{ f(c) � c � C} .

Proposição 4:

Uma função contínua é monotônica.

Proposição 5:

Uma função monotônica cujo domínio é um CPO com apenas cadeias finitas é contínua.

Proposição 6:

A composição de duas funções contínuas também é contínua.

Proposição 7:

A composição de duas funções monotônicas também é monotônica.

Proposição 8:

Seja D, E e F CPOs. Se f:D � E e g:D � F contínuas, então f � g também é contínua.

Definição 8:

Seja D um poset, f:D � D uma função e x D:

� se f(x) �

x, então x é um ponto prefixo;� se f(x) = x, então x é também um ponto fixo;� se x é um ponto prefixo e x�

p para todo ponto prefixo p, então x é um menor pontoprefixo;� se x é um ponto fixo e x

�y para todo ponto fixo y, então x é um menor ponto fixo;

Teorema 1:

15Seja f:D � D uma função contínua sobre um CPO pontual D. Então:

fix(f) ≡ �{ �� f( � ), f(f( � )), ...., fk( � ), ...}

existe e é tanto um único menor ponto fixo como um único menor ponto prefixo de f.

Definição 9:

Seja I = I1 � .... � In e O = O1 � .... � Om vetores de CPOs pontuais. Denomina−se bloco umafunção vetorial contínua de I sobre O.

Definição 10:

Seja b : I � O um bloco, J = J1 � .... � Ja um vetor de CPOs pontuais e w1,....,wn umaseqüência tal que wk � { 1, .... , a} . Se Jwk ⊆ Ik, então o bloco conectado à J com as conexões w1, ...., wn

é a função c : J � O tal que

c(j1, ...., ja) = b(jw1, ...., jwn)onde (j1, ...., ja) � J.

Definição 11:

Seja b1 : I � O, b2 : I � O, ...., bn : I � O um conjunto de blocos, I = I1 � .... � In um vetorde CPOs pontuais, O = O1 � .... � Os e J = I � O. O sistema aberto composto por esses blocos é afunção d: J � O tal que

d(j) = c1(j) � c2(j) � .... � cs(j)

onde ck é o bloco bk conectado ao vetor J, e j � J.

O modelo computacional SR enxerga o sistema como sendo uma função. Seja d um sistemaaberto, a função SR é a menor função e:I � O que satisfaça

e(i) = d(i, e(i)), (1)

onde I e O são vetores de CPOs pontuais.

A figura 2.11 apresenta uma ilustração das definições 10, 11 e de uma função SR.

16

Figura 2.11 − Ilustrações das definições do MoC SR: (a) O sistema; (b) O sistema aberto correspondente; (c) Obloco correspondente.

A equação (1) é um ponto fixo, onde a função e é o parâmetro. Dessa forma, podemos escrever:

e = B(e),

onde B:(I � O) � (I � O) é uma função que transforma uma função em outra função.Utilizando o teorema 1, Edwards demonstra que a função B apresenta um único menor ponto fixo. Paratal, ele demonstra que o domínio de B é um CPO pontual e que B é contínua. Isso implica que o MoCSR é determinístico.

O valor de cada sinal no MoC SR pode estar em um de três estados: indefinido, definido eausente (nenhum evento no instante) ou definido e presente (evento com um valor no instante). No iníciode cada instante, todos os sinais, a menos das entradas do sistema, estão no estado indefinido. Uma vezque um sinal passa do estado indefinido para um definido, esse sinal não pode mais mudar de estado ouvalor. Essa regra é necessária para assegurar que o ator implementa uma função monotônica (e pelaproposição 5, contínua). Os três estados formam uma CPO, com o estado indefinido sendo o limiteinferior.

A implementação do MoC SR no ambiente Ptolemy consiste de um escalonador que resolva ocálculo de um menor ponto fixo para o sistema. Edwards descreve um método capaz de determinar emtempo de compilação uma ordem de ativamento de atores que encontra o menor ponto fixo. Entretanto, ométodo é relativamente complexo para ser descrito brevemente nessa dissertação.

O escalonador que utilizamos baseia−se no teorema 1 para encontrar o menor ponto fixo:

1. execute todos os atores e verifique se algum sinal passou do estado indefinido para odefinido;

2. se não houver modificação no estado dos sinais, então o ponto fixo foi encontrado. Docontrário, repita o passo 1.

Em [EDW94], Edwards prova que esse escalonador irá encontrar o menor ponto fixo em um

RampF1

F2

F3

F4

F4

F1

F2

F3

1

2

3

45

1

2

3

4

5

OO

J

I

d

I Oe

(c)

(b)

(a)

17número finito de iterações.

No MoC SR, um ator atômico é dividido em dois tipos: Strict e Non−Strict. Atores Strict sãoaqueles que requerem que todos os sinais de entrada estejam definidos para ocorrer o ativamento. AtoresNon−Strict não possuem essa restrição, e portanto, são mais flexíveis. Uma das razões para a existênciade atores desse tipo é que em caminhos de realimentação, caso apenas atores Strict fossem utilizados, osistema entraria em deadlock. A figura 2.12 apresenta um exemplo de ator Non−Strict que implementaum atraso por um instante.

1− . . . .2− publ i c c l ass SRPr e ext ends TypedAt omi cAct or {3−4− publ i c SRI OPor t i nput ;5− publ i c SRI OPor t out put ;6−7− publ i c SRPr e( TypedComposi t eAct or cont ai ner , St r i ng name) 8− t hr ows I l l egal Act i onExcept i on, NameDupl i cat i onExcept i on {9− super ( cont ai ner , name) ;10−11− i nput = new SRI OPor t ( t hi s , " i nput 1" , t r ue, f al se) ;12− i nput . set TypeEqual s( BaseType. I NT) ;13−14− out put = new SRI OPor t ( t hi s , " out put " , f al se, t r ue) ;15− out put . set TypeEqual s( BaseType. I NT) ;16− out put . set Mul t i por t ( t r ue) ;17−18− ( ( SRDi r ect or ) get Di r ect or ( ) ) . set St r i c t ( t hi s , f al se) ;19− }20− 21− publ i c voi d i ni t i al i ze( ) t hr ows I l l egal Act i onExcept i on {22− super . i ni t i al i ze( ) ;23− _st at e = 0;24− }25− 26− publ i c voi d f i r e( ) t hr ows I l l egal Act i onExcept i on {27− i f ( ! out put . known( 0) ) {28− out put . send( 0, new I nt Token( _st at e) ) ;29− }30− }31−32− publ i c bool ean post f i r e( ) t hr ows I l l egal Act i onExcept i on {33− i f ( i nput . pr esent ( 0) ) {34− _st at e = ( ( I nt Token) i nput . get ( 0) ) . i nt Val ue( ) ;35− }36− r et ur n t r ue;37− }38−39− pr i vat e i nt _st at e;40− }

Figura 2.12 − Ator de atraso no MoC SR.

A linha 18 utiliza o método setStrict() para determinar que o ator é do tipo Non−Strict. Na linha27, é determinado se o sinal de saída ainda não está definido. Caso positivo, o valor atual da variávelinterna é enviado. No MoC SR, o método fire() pode ser chamado inúmeras vezes a cada instante. Dessaforma, ações que o usuário deseje realizar uma única vez por instante devem ser efetuadas no métodopostfire(). No caso do ator da figura 2.12, a atualização do estado (linha 34) é feita nesse método.

2.3.3 Communicating Sequential Processes

O modelo computacional Communicating Sequential Processes (CSP) [HOA78] [HOA85][SMY98] é fundamentado no uso de processos concorrentes, cada ator associado à um único processo. Oescalonamento dos processos é feito pelo ambiente de execução da linguagem Java. Nesse modelo nãohá armazenamento de dados entre processos, a transferência de dados é feita através do protocolo derendezvous. Nesse protocolo, um ator A executa o método send() ou broadcast() para enviar um dado àum ator B. O ator A permanece bloqueado enquanto o ator B não consome o token. O mesmo acontecequando um ator tenta consumir um token quando este ainda não está disponível.

O MoC CSP permite o rendezvous não−determinístico através de comandos de comunicação

18condicional (guarded). Esses comandos apresentam a seguinte forma:

guard; comunicação => lista de comandos;

O guard é uma expressão que retorna um valor booleano. Não é permitido que seu cálculoproduza alterações no estado interno do processo. Caso o valor retornado seja falso, o comando éencerrado. Caso contrário, o comando de comunicação especificado é iniciado e quando ele forcompletado, a lista de comandos é executada.

Dois tipos de comando de comunicação condicional estão disponíveis: CIF e CDO. O comandoCIF apresenta a seguinte forma:

CIF {guard1; comunicação1 => lista de comandos1;

[]guard2; comunicação2 => lista de comandos2;

[]....

}

Para cada caminho do comando CIF, os respectivos guards são verificados. Essa verificação éfeita concorrentemente, ou seja, é irrelevante a ordem dos guards. Caso um ou mais guards sejamverdadeiros, os respectivos comandos de comunicação são iniciados. Caso nenhum comando decomunicação esteja pronto, todo o comando CIF irá bloquear até que uma comunicação esteja pronta.Caso mais que uma comunicação esteja pronta, a escolha de uma é feita de maneira não−determinística.Uma vez que a comunicação é completada, a lista de comandos associada é executada e o comando CIFé encerrado. O comando CIF é ignorado quando todos os guards forem falsos.

O comando CDO é similar ao comando CIF. Entretanto, ao acabar a execução de uma das listasde comandos, o comando CDO é reiniciado. Esse comando é encerrado apenas quando todos os guardsforem falsos.

A implementação do MoC CSP no ambiente Ptolemy apresenta alguns métodos adicionais paraimplementar os comandos CIF e CDO. A figura 2.13 ilustra o comando CDO.

1− bool ean cont i nueCDO = t r ue;2−3− whi l e( cont i nueCDO) {4− 5− Condi t i onal Br anch [ ] br anches = new Condi t i onal Br anch[ 3] ;6−7− br anches[ 0] = new Condi t i onal Recei ve( t r ue, i nput , 0, 0) ;8− br anches[ 1] = new Condi t i onal Recei ve( t r ue, i nput , 0, 1) ;9−10− t oken = new Token( ) ;11− br anches[ 2] = new Condi t i onal Send( t r ue, out put , 0, 2, t oken) ;12−13− i nt r esul t = chooseBr anch( br anches) ;14−15− i f ( r esul t == 0) {16− . . . .17− Token t = br anches[ 0] . get Token( ) ;18− . . . .19− }20− el se21− i f ( r esul t == 1) {22− . . . .23− Token t = br anches[ 1] . get Token( ) ;24− . . . .25− }26− el se27− i f ( r esul t == 2) {28− . . . . 29− }30− el se31− i f ( r esul t == −1) {32− cont i nueCDO = f al se;33− }34− }

19Figura 2.13 − O comando CDO no ambiente Ptolemy.

A primeira tarefa é a criação dos diferentes caminhos do comando utilizando os objetosConditionalReceive e ConditionalSend. Isso é feito da linha 5 à linha 11. No exemplo da figura 2.13,dois caminhos possuem comandos de comunicação para recepção de dados (linha 7 e 8) e um caminho épara envio de um dado (linha 11). O primeiro parâmetro dos construtores é o guard do comando, queneste exemplo é sempre verdadeiro. O quarto parâmetro é um valor inteiro único associado ao caminhoem questão.

A segunda tarefa é a escolha de um dos caminhos, utilizando o método chooseBranch(). Essemétodo irá retornar o número inteiro associado com o caminho escolhido. Finalmente, a lista decomandos para o caminho ativado é executada (linhas 15 à 33).

Embora originalmente esse modelo não apresente uma noção de tempo, a implementação noambiente Ptolemy introduziu essa característica. A exemplo do MoC DE, esse MoC também utiliza otempo centralizado. Cada processo (ator) pode se suspender por uma duração de tempo determinada.Quando esse instante for alcançado, o escalonador ativa novamente o processo. O tempo é avançadoquando todos os processos se suspenderam ou quando todos os processos estão bloqueados devido aorendezvous e pelo menos um processo se suspendeu. Nestas situações, o tempo atual é avançado osuficiente para ativar algum processo que se suspendeu.

2.3.4 Synchronous Data Flow

O modelo computacional Synchronous Data Flow (SDF) [LEE87a][LEE87b pertence à classedos modelos data flow [DAV82][DEN80][KAR66]. O modelo data flow foi inicialmente desenvolvidopara descrever e analisar programas paralelos. Nesse modelo, o sistema é abstraído por um grafo onde osnós são atores e os arcos indicam dependência de dados entre os atores. Em cada arco do grafo existeuma fila unidirecional utilizada para a troca de dados. É introduzido o conceito de ativamento de umator (nó): um nó executa apenas quando todos os dados necessários estiverem disponíveis (o ator estápronto), e sua execução é atômica. Não existe o conceito de fluxo de controle em grafos data flow.

No modelo SDF, além de respeitar a semântica data flow, deve ser especificado, para cada ator,quantos tokens são consumidos (no caso de um porto de entrada) ou produzidos (no caso de um porto desaída) para todos os seus portos. Esses valores (também chamados de taxas de amostragem) são fixos econhecidos em tempo de compilação. Um grafo SDF possui um escalonamento (seqüencial ou paralelo)estático, ou seja, antes da execução é determinado quantas vezes cada ator deve ser ativado e qual é aordem de ativamento. A figura 2.14 apresenta dois grafos SDF. Descreveremos o modelo SDF maisformalmente seguindo [LEE87b]. Iremos considerar o caso de escalonamento seqüencial. O caso paraleloestá descrito em [LEE87a].

Figura 2.14 − Dois grafos SDF. Os números próximos aos nós são as taxas de amostragem.

Um grafo SDF pode ser representado por uma matriz de incidência: as linhas representam osarcos e as colunas os nós. Cada posição da matriz é uma taxa de amostragem: positiva quando o atorproduz o token na respectiva conexão, negativa quando ele consome. Essa matriz é denominada dematriz de topologia. As matrizes de topologia para os grafos da figura 2.14 (a) e (b) são respectivamente:

1

2

3

1

2

3

1

2

11

1

1

1

2

3

1

2

3

1

2

21

1

1

(a) (b)

1 −1 0

2 0 −1

0 1 −1

1 −1 0

2 0 −1

0 2 −1

(a) (b)

Γ Γa b= =

20

Durante a execução, a quantidade de dados em cada fila de comunicação irá variar. Em umdeterminado momento n, a quantidade de dados em cada fila é dada por um vetor coluna b(n). Para umescalonamento seqüencial, o vetor coluna v(n) indica qual ator é ativado em um instante n. Podemosdescrever a variação de dados em cada fila pela equação

b(n + 1) = b(n) + Γv(n).

O valor do vetor b quando n = 0 indica em quais conexões existem dados antes do início daexecução.

Para se determinar um escalonamento de um grafo SDF, é necessário verificar se a matriz detopologia é consistente, ou seja, se as taxas de amostragem especificadas são válidas. Foi demonstradoque o rank da matriz de topologia, igual ao número de nós menos um, é uma condição necessária para aconsistência. Por exemplo, o rank da matriz Γa é igual a três, enquanto que o rank da matriz Γb é igual àdois. Dessa forma, o grafo da figura 2.14 (a) é inválido e o da figura (b) é válido.

Quando a matriz de topologia for válida, existe um vetor coluna q que satisfaz:

Γq = 0.

Para a matriz Γb, q = J[1 1 2]T, para qualquer J positivo. O vetor q determina quantas vezes cadanó deve ser ativado para a obtenção de um escalonamento periódico, ou seja, um escalonamento quequando completado, faz com que o valor do vetor b permaneça inalterado. Dessa forma, o grafo SDFpode ser executado infinitamente com capacidade limitada e conhecida de memória (filas).

Mesmo quando a matriz de topologia é consistente, é possível que a especificação do grafo sejainválida. Isso ocorre quando existirem ciclos no grafo sem a quantidade adequada de dados no momentoinicial da execução. A figura 2.15 ilustra essa situação.

Figura 2.15 − Dois grafos SDF inválidos mas com matrizes consistentes.

O losango da figura 2.15 (b) representa um ator de atraso, ou seja, um ator que no instante nenvia o token recebido no instante n − 1. Para isso, esse ator produz tokens antes do início da execução(a entrada no vetor b com n = 0 para o porto de saída desse ator é maior que zero). Ambos os grafos dafigura 2.15 não possuem condições iniciais válidas: a grafo da figura (a) não possui nenhum atraso, o dafigura (b) apresenta um atraso de apenas um token, o que é insuficiente. A figura 2.16 apresenta aimplementação de um ator de atraso no ambiente Ptolemy.

1− publ i c c l ass Del ay ext ends Tr ansf or mer {2− publ i c Del ay( TypedComposi t eAct or cont ai ner , St r i ng name)3− t hr ows I l l egal Act i onExcept i on, NameDupl i cat i onExcept i on {4−5− super ( cont ai ner , name) ;6− new Par amet er ( out put , " TokenI ni t Pr oduct i on" ,7− new I nt Token( 1) ) ;8−9− out put . set TypeAt Least ( i nput ) ;10− }11−12− publ i c voi d f i r e( ) t hr ows I l l egal Act i onExcept i on {

1

1

1

1

1

2

1

2

D

(a) (b)

2113− Token message = i nput . get ( 0) ;14− out put . br oadcast ( message) ;15− }16−17− publ i c voi d i ni t i al i ze( ) t hr ows I l l egal Act i onExcept i on {18− out put . br oadcast ( new Token( ) ) ;19− }20− }

Figura 2.16 − O ator Delay no MoC SDF.

A linha 6 modifica o parâmetro TokenInitProduction que especifica a quantidade de tokens aserem produzidos antes do início da execução. Outra forma de fazer tal especificação é através dométodo setTokenInitProduction() da classe SDFIOPort. Métodos similares existem para especificar aprodução e consumo de tokens a cada ativamento do ator.

Quando o grafo SDF for consistente e com a quantidade necessária de atrasos, o seguintealgoritmo pode ser usado para a obtenção de um escalonamento seqüencial8:

1. encontre o menor vetor q;2. obtenha uma lista L de todos os atores da especificação;3. percorra a lista L e para cada ator pronto, escalone−o;4. caso cada ator α tenha sido escalonado qα vezes, FIM;5. caso nenhum ator da lista L esteja pronto, ocorreu um deadlock (a especificação é inválida);6. do contrário, vá para 3.

O algoritmo encontra um escalonamento simulando a execução do sistema. Para encontrar ovetor q do passo 1, o seguinte método é utilizado:

1. escolha aleatoriamente um ator e assuma que ele é ativado uma única vez, ou seja, qa = 1;2. para um ator B adjacente à A, calcule o valor de qb = (qa . pa)/cb, onde pa é a quantidade de

tokens produzidos pelo ator A na conexão e cb a quantidade de tokens consumidos por B. Ovalor obtido pode ser fracional mas sempre racional;

3. repita o passo 2 recursivamente para um ator adjacente a B;4. uma vez obtidos todos os valores de q, encontre o menor denominador comum desses

valores a fim de torná−los inteiros.

É fácil perceber que o método descrito irá encontrar o vetor q em tempo linear ao número de nóse arcos do grafo.

No modelo SDF, não é necessário implementar explicitamente filas para a comunicação entre osatores. O fato desse MoC ser escalonado estaticamente permite associar uma posição de memóriaespecífica para cada dado a ser consumido ou escrito por um ator, em cada ativamento do mesmo.Entretanto, a semântica de comunicação por filas é respeitada.

O modelo SDF não apresenta uma noção de tempo.

2.3.5 Dynamic Data Flow

Assim como o modelo SDF, o modelo computacional Dynamic Data Flow [LEE95] (DDF)respeita a semântica data flow, e também não possui uma noção de tempo. Ao contrário do modeloSDF9, não existe a necessidade de especificar as taxas de consumo e produção de tokens de cada porto,embora isso seja permitido. Esses valores podem variar durante a execução. Dois exemplos de atoresDDF são mostrados na figura 2.17.

8 Outros algoritmos para escalonamento seqüencial de grafos SDF estão descritos em [BHA94].9 O modelo SDF é um subconjunto do modelo DDF.

22

Figura 2.17 − Os atores Switch e Select no modelo DDF.

O ator Switch consome um token do porto de dados e baseado no valor do token do porto decontrole, envia o token de dado para um dos dois portos de saída. Dessa forma, apenas um porto de saídaproduzirá dados a cada ativamento do ator Switch. O ator Select consome um token de dados, baseado novalor do token de controle.

Podemos observar que no caso do ator Select, mais de uma condição de presença de dados podeativá−lo. Esse fato é conhecido como as regras de ativamento de um ator (firing rules). No caso domodelo SDF, só existe uma regra para cada ator. No caso do modelo DDF, várias regras podem serespecificadas para um mesmo ator. Por exemplo, o ator Select possui duas regras:

R1 = { [* ], � , [0]}R2 = { � , [* ], [1]}

A primeira posição das regras representa a entrada Dado1, a segunda a entrada Dado2 e aterceira a entrada Controle. O símbolo � indica que a regra pode ser satisfeita independentemente darespectiva entrada. O símbolo * indica que é necessário um token, independente de seu valor. Osnúmeros dentro de colchetes indicam o valor necessário do token.

O modelo DDF é determinístico (assim como o SDF), isto é, dado um mesmo conjunto deentradas, as saídas sempre terão o mesmo valor, independentemente da ordem de ativamento dos atores.Entretanto, para que uma especificação utilizando o MoC DDF seja válida (determinística), todos osatores devem implementar funções contínuas. Isso pode ser obtido utilizando regras de ativamentoseqüenciais. Um algoritmo para determinar quando as regras de ativamento são seqüenciais é:

1. encontre um porto de entrada j tal que [* ]�

Ri,j para todas as regras i = 1, ..., N, isto é,um porto de entrada tal que todas as regras necessitem de pelo menos um token nesteporto. Caso nenhum porto seja encontrada, as regras não são seqüenciais;

2. para o porto j encontrado no passo 1, divida as regras em subconjuntos de acordo com oprimeiro valor de Ri,j para todas as regras. Caso Ri,j = [* , ....], então Ri,j deve aparecer emtodos os subconjuntos;

3. remova o primeiro elemento de Ri,j para todas as regras i;4. caso todos os subconjuntos sejam vazios, então as regras de ativamento são seqüencias.

Caso contrário, repita os passos para cada subconjunto não vazio.

Para as regras do ator Select, o primeiro passo irá identificar j = 3. Dois subconjuntos sãoformados, um para cada regra. As duas novas regras são R1 = { [* ], �� } e R2 = { � , [* ], � } . Oprocedimento encerra trivialmente para cada um dos subconjuntos.

No ambiente Ptolemy, as regras de ativamento de um ator não são enumeradas explicitamente.Para garantir a validade do ator, a semântica de leitura bloqueante é utilizada, ou seja, ao tentar consumirum ou mais tokens, o ator fica bloqueado enquanto os dados não estiverem disponíveis. Note que oalgoritmo para determinar se um conjunto de regras é seqüencial pode ser implementado através do usode leitura bloqueante. A figura 2.18 exemplifica essa situação através do código do ator Select.

1− publ i c c l ass Sel ect ext ends DDFAt omi cAct or {2−3− publ i c DDFI OPor t cont r ol ;4− publ i c DDFI OPor t dat a1;5− publ i c DDFI OPor t dat a2;

Switch SelectDado

Controle Controle

Dado1

Dado2

Saída1

Saída2Saída

236− publ i c DDFI OPor t out put ;7−8− publ i c Sel ect ( TypedComposi t eAct or cont ai ner , St r i ng name) t hr ows9− I l l egal Act i onExcept i on, NameDupl i cat i onExcept i on {10−11− super ( cont ai ner , name) ;12−13− cont r ol = new DDFI OPor t ( t hi s , " cont r ol " , t r ue, f al se) ;14− cont r ol . set TokenConsumpt i onRat e( 1) ;15− cont r ol . set TypeEqual s( BaseType. DOUBLE) ;16− 17− dat a1 = new DDFI OPor t ( t hi s , " dat a1" , t r ue, f al se) ;18− dat a1. set TokenConsumpt i onRat e( 0) ;19− 20− dat a2 = new DDFI OPor t ( t hi s , " dat a2" , t r ue, f al se) ;21− dat a2. set TokenConsumpt i onRat e( 0) ;22− 23− out put = new DDFI OPor t ( t hi s , " out put " , f al se, t r ue) ;24− out put . set TokenPr oduct i onRat e( 1) ;25− }26−27− publ i c voi d f i r e( ) t hr ows I l l egal Act i onExcept i on {28− i nt i ;29−30− i f ( _r eadyToGo == f al se) { 31− Doubl eToken t = ( Doubl eToken) cont r ol . get ( 0) ;32− _ct r l = ( doubl e) t . doubl eVal ue( ) ;33− }34−35− i f ( _ct r l == 0. 0) {36− i f ( dat a1. hasToken( 0) ) {37− _r eadyToGo = f al se;38− wai t For ( cont r ol , 1) ;39− out put . br oadcast ( dat a1. get ( 0) ) ; 40− } 41− el se {42− _r eadyToGo = t r ue;43− wai t For ( dat a1, 1) ;44− }45− }46− el se {47− i f ( dat a2. hasToken( 0) ) {48− _r eadyToGo = f al se;49− wai t For ( cont r ol , 1) ;50− out put . br oadcast ( dat a2. get ( 0) ) ; 51− } 52− el se {53− _r eadyToGo = t r ue;54− wai t For ( dat a2, 1) ;55− } 56− }57− }60−61− publ i c voi d i ni t i al i ze( ) t hr ows I l l egal Act i onExcept i on {62− super . i ni t i al i ze( ) ;63−64− _r eadyToGo = f al se;65− wai t For ( cont r ol , 1) ;66− _ct r l = 0. 0;67− }68− 69− pr i vat e bool ean _r eadyToGo;70− pr i vat e doubl e _ct r l ;71− }

Figura 2.18 − Código do ator Select no MoC DDF.

As linhas 18 e 21 indicam que os portos de entrada data1 e data2 não possuem taxas deconsumo constante. A leitura bloqueante é implementada através da utilização do método waitFor(). Oprimeiro parâmetro desse método é o porto de entrada e o segundo parâmetro indica quantos tokensdevem ser lidos para o ativamento. Inicialmente, o ator Select deve ler o token de controle (linhas 65, 38e 49) para em seguida ler o dado. Caso esse não esteja disponível, a leitura bloqueante é utilizadanovamente para os portos de dados (linhas 43 e 54). Note a utilização de uma variável interna(_readyToGo) para indicar o estado em que o ator se encontra e assim determinar de qual porto opróximo token deve ser consumido.

24Ao contrário do modelo SDF, o escalonador do MoC DDF não é estático. Dois tipos de

escalonadores dinâmicos existem [PAR95]: data driven e demand driven. Escalonadores tipo datadriven ativam um ator assim que uma de suas regras de ativamento seja válida. Já escalonadores tipodemand driven ativam um ator baseado na demanda de tokens de um ator sucessor. O ambiente Ptolemyutiliza um escalonador tipo data driven, classificando os atores prontos para serem ativados comodeferrable ou não. Um ator é deferrable quando alguns de seus sucessores já possuem tokens suficientesna conexão com o ator. Um ator deferrable só é ativado quando não existirem atores classificados comonão deferrable. Nesse caso, um dos atores deferrable é escolhido aleatoriamente para ser ativado. Aclassificação de ator deferrable visa evitar o acúmulo desnecessário de tokens em uma fila.

Outra característica do MoC DDF é que, ao contrário do MoC SDF, não é possível determinar aquantidade necessária de armazenamento de cada fila de comunicação. É possível que uma execuçãovenha a ser prematuramente interrompida devido ao estouro de espaço de memória.

2.3.6 Kahn Process Networks

Assim como o MoC CSP, uma especificação executável utilizando o modelo computacionalKahn Process Networks [KA74][KAH77][GOE98][PAR95] é composta por uma rede de processos, ondecada ator da especificação é associado à um processo. Tal como nos modelos data flow, cada conexãoentre atores contém uma fila. O modelo PN é determinístico quando cada processo implementa umafunção contínua. Assim como no MoC DDF, isso é implementado através de leitura bloqueante: quandoum ator tenta consumir um token de uma fila vazia, o respectivo processo é bloqueado, sendo reativadoquando o token estiver disponível. O MoC PN não permite o teste da presença de um token, pois issotornaria o modelo não−determinístico. Também não é permitido que um ator espere por tokens em maisde um porto ao mesmo tempo.

Tal como no MoC DDF, não é possível determinar a capacidade necessária de cada fila. Asolução adotada no ambiente Ptolemy utiliza a escrita bloqueante, ou seja, quando um ator tenta produzirum token e a respectiva fila está cheia, o processo do ator é bloqueado. Quando houver espaço na fila, oprocesso é reativado.

É possível que uma execução venha a entrar em deadlock, ou seja, quando todos os atoresestiverem bloqueados. Quando não existe nenhum ator bloqueado devido à situação de filas cheias, diz−se que o deadlock é real. Nessa situação a execução chegou ao fim. Caso contrário, temos um deadlockartificial. Neste caso, o ambiente Ptolemy determina uma fila cheia e aumenta seu tamanho, reativando orespectivo processo e prosseguindo com a execução.

A implementação desse MoC no ambiente Ptolemy possui uma noção de tempo, similar ao domodelo CSP, ou seja, um processo pode se suspender até um determinado instante de tempo.

2.4 Outros Modelos Computacionais

Vários outros modelos computacionais foram desenvolvidos, além dos seis modeloscomputacionais que utilizamos nesse trabalho. O próprio ambiente Ptolemy implementa outros trêsmodelos. Enumeramos alguns modelos importantes e descritos na literatura:

� Cyclo−Static Data Flow [BIL96]: modelo data flow que estende o MoC SDF permitindo queum ator tenha mais que uma regra de ativamento. Entretanto, as regras devem apresentar taxasde consumo e produção constantes e a ordem de utilização de cada regra é definida antes daexecução. Esse modelo também apresenta um escalonamento estático;

� Boolean Data Flow [BUC93]: modelo data flow que estende o MoC SDF permitindo avariação das taxas de consumo e produção durante a execução. Entretanto, diferentemente doMoC DDF, essa variação deve sempre estar condicionada à um valor booleano obtido de outroporto (por exemplo, os atores da figura 2.17). Em alguns casos, é possível encontrar umescalonamento estático;

25� Máquinas de Estado Finito [GAJ00]: modelo computacional clássico baseado em autômatosfinitos;

� Redes de Petri [PET81]: modelo de estados explícitos onde a especificação é composta por doistipos de elementos: place e transição. Cada place pode conter um elemento denominado detoken. Um place pode ser conectado à uma transição (place de entrada da transição) e umatransição pode ser conectada à um place (place de saída da transição). Quando todos os placede entrada de uma transição tiverem pelo menos um token, diz−se que a transição está prontapara ser ativada. O ativamento consiste em remover um token de todos os place de entrada eadicionar um token à todos os places de saída. A concorrência é possível pois mais de umatransição pode estar pronta para ser ativada em um mesmo instante. Neste caso, a escolha éfeita de forma não determinística;

� StateChars [HAR87]: modelo que adicionada à máquinas de estado finito o conceito dehierarquia e concorrência. A hierarquia é representada através de estados que contenham outrasmáquinas de estado. Quando ocorre a transição para um estado hierárquico, a máquina deestado interna é ativada. A concorrência é modelada através da possibilidade de que mais deum estado estar ativado simultaneamente. Nesse modelo, é permitido transições de estadospertencentes à diferentes níveis de hierarquia;

� *Charts [GIR99]: modelo implementado no ambiente Ptolemy que adiciona os conceitos dehierarquia e concorrência às máquinas de estados finitos. Diferentemente do modelosStateCharts, o modelo *Charts não define estados concorrentes. A concorrência é obtidaquando vários atores Composite, que implementam subsistemas em *Charts, são incluídos emuma topologia governada por um modelo com concorrência. Não é permitido transições entreestados de diferentes hierarquias;

� Codesign Finite State Machine [LAV00]: modelo baseado em uma rede de máquinas de estado.A comunicação é feita através de broadcast de sinais: uma máquina produz um evento em umsinal e todas as outras máquinas que dependem desse sinal podem obter o novo evento. Ahipótese de sincronismo é assumida para todas as máquinas de estado mas não aplicada àinteração das máquinas, ou seja, uma vez que um novo evento é produzido, a resposta de outramáquina à esse novo evento não é infinitamente rápida. Dessa forma, é possível que eventosnão sejam capturados por máquinas com reação lenta, uma vez que não existe oarmazenamento de eventos;

� Control−Data Flow Graph [MIC94]: modelo utilizado para representar um algoritmoseqüencial através de um grafo direcionado. Existem dois tipos básicos de nós: nós de controlee basic blocks. Um nó tipo basic block contém uma seqüência de comandos. Nós de controledeterminam os diferentes caminhos possíveis para o fluxo de controle;

� Continuous Time [LIU98]: modelo implementado no ambiente Ptolemy fundamentado nautilização de equações diferenciais para representar um sistema. Esse modelo possui uma noçãode tempo contínuo. O escalonador desse modelo é composto por um algoritmo que obtenharesultados aproximados para o sistema de equações em alguns instantes de tempo. Esse modeloé mais apropriado para representar sistemas analógicos e mecânicos;

� Distributed Discrete Event [DAV99]: modelo implementado no ambiente Ptolemy que procurasolucionar os problemas relacionados ao emprego de uma noção global de tempo, tal como nomodelo DE. O modelo mantém uma noção local de tempo em cada conexão entre atores. Cadaator é associado à um processo e este pode avançar seu valor de tempo para o mínimo entre osvalores de suas conexões de entrada.

26

2.5 A Ferramenta de Depuração/Profile

Conforme foi ilustrado no item 2.2, uma especificação executável no ambiente Ptolemy écomposta por classes na linguagem Java, escritas pelo usuário, e por classes disponíveis pelo ambiente.Essas classes passam por um processo de compilação e o código resultante pode ser executado. A análisedo comportamento da execução e dos resultados obtidos fica a cargo do usuário, isto é, o usuário deveadicionar trechos de códigos à especificação para coletar e apresentar informações relevantes à execução.Até o presente momento, o ambiente Ptolemy provê auxilio para esta tarefa apenas através de atores queutilizam o aplicativo PtPlot. Este aplicativo é capaz de ilustrar dados através de vários tipos de gráficosbidimensionais.

Uma alternativa disponível para a análise da execução seria o uso de uma ferramenta dedepuração para a linguagem Java. Essa solução é recomendável para encontrar erros no código fonte decada ator, uma vez que cada comando do código pode ser analisado. Entretanto, esse tipo de ferramentanão é adequada para a análise de características mais genéricas referentes à interação entre diferentesatores sob um modelo computacional. Essas informações podem ser úteis para o usuário entender maisdetalhadamente os resultados da execução da especificação e para encontrar erros lógicos não associadosao código de um ator isoladamente.

Sob a luz do estudo apresentado nessa dissertação, uma ferramenta para a análise da execução deuma especificação torna−se útil, pois tal ferramenta auxilia identificar as diferenças encontradas aoutilizar modelos computacionais distintos na representação de uma mesma primitiva computacional.Dessa forma, uma ferramenta denominada de PTII Analyzer foi desenvolvida com esse objetivo. Suaprincipal função é reproduzir uma execução, ilustrando a troca de tokens entre diferentes atores.Informações estatísticas também podem ser extraídas a partir dos dados coletados.

2.5.1 Dados coletados

A ferramenta desenvolvida baseia−se em dados coletados durante a execução de umaespecificação. Para tal, acrescentamos trechos de código em classes específicas do ambiente Ptolemy.Dois tipos de conjunto de dados são armazenados: a produção ou o consumo de um token e a mudançade estado de um ator.

Para cada evento de consumo ou produção de um token, armazenamos o seguinte conjunto deinformações:

� tipo do evento: consumo ou produção;� identificador do token: um valor inteiro único para cada token durante a execução;� ator de origem;� porto de origem;� ator de destino;� porto de destino;� valor do tempo no momento do evento;� instante.

O instante é um valor inteiro único para cada conjunto de informações e utilizado a fim deordenar os dados coletados permitindo ilustrar a reprodução da execução.

O segundo tipo de conjunto de dados armazenado é referente a mudança de estado de um ator.Definimos três possíveis estados: bloqueado, pronto ou executando. Em alguns MoCs, subdividimos oestado bloqueado em bloqueado no consumo ou na produção de um token. Quando ocorre uma mudançade estado, armazenamos o seguinte conjunto de dados:

� ator;� novo estado;� valor do tempo no momento do evento;� instante.

27Definimos que um ator está no estado executando quando este está consumindo ou produzindo

tokens. A determinação dos outros estados depende da semântica do modelo computacional que controlao ator. Para os seis modelos computacionais utilizados, definimos:

SDF: � bloqueado: não há dados suficientes nos portos de entrada;� pronto: há dados suficientes nos portos de entrada.

DDF: igual ao caso do MoC SDF.

PN: � bloqueado: quando a respectiva fila estiver vazia (bloqueado no consumo) ou quando arespectiva fila estiver cheia (bloqueado na produção);� pronto: quando o ator estava executando mas foi escalonado.

DE: � bloqueado: este estado não existe nesse MoC;� pronto: quando o ator não está executando.

CSP: � bloqueado: quando o ator está esperando para iniciar ou concluir o rendezvous;� pronto: quando o ator estava executando mas foi escalonado.

SR: Quando o ator é Strict:� bloqueado: não há a presença de eventos exigida;� pronto: há a presença dos eventos exigidos.

Quando o ator é Non−Strict:� bloqueado: este estado não existe nesse caso;� pronto: quando o ator não está executando.

2.5.2 A Interface Gráfica

O principal componente da ferramenta PTII Analyzer é sua interface gráfica, pois apresentar osdados coletados da execução na forma de uma tabela não seria útil ao usuário. A ferramenta permite doistipos de análise: depuração e profiling. A depuração é feita reproduzindo−se graficamente a interaçãoentre os atores. O profiling é feito através de estatísticas calculadas a partir dos dados e apresentados aousuário na forma de gráficos e tabelas. A figura 2.19 apresenta a janela com o menu principal daferramenta.

Figura 2.19 − A janela inicial da ferramenta PTII Analyzer.

Dados coletadosUm mesmo token Barra de scroll de instantes

28A janela inicial da ferramenta contém uma tabela para mostrar os dados coletados. Quando o

usuário seleciona o campo de identificação de um token, todos os demais campos da tabela referentes aomesmo token são destacados. Inicialmente a primeira entrada da tabela é selecionada (instante 1). Ajanela inicial possui uma barra de scroll que permite selecionar a próxima entrada da tabela, ou aanterior. Aliado à janela que exibe a topologia da especificação, o usuário pode utilizar essa barra descroll para reproduzir a execução. A janela da topologia é mostrada quando o usuário carrega o layoutgráfico da topologia. A figura 2.20 apresenta essa janela.

Figura 2.20 − A janela da topologia.

Se os dados da execução foram carregados, a janela da topologia irá ilustrar o instante da entradaselecionada na tabela. Os atores são coloridos de acordo com o estado do instante selecionado: verde seestiver executando, amarelo se estiver pronto, vermelho se estiver bloqueado, roxo se estiver bloqueadona produção e rosa se estiver bloqueado no consumo. Os portos são coloridos quando o respectivoevento for selecionado na tabela: vermelho quando é uma produção e azul quando for um consumo.Também é possível inspecionar o estado de cada receiver até o instante selecionado. No canto direitoinferior da figura 2.20, é mostrada uma janela que apresenta tal informação.

A tarefa de depuração é feita com o auxilio da janela principal e da janela de topologia. A tarefade profiling utiliza outras janelas. A figura 2.21 apresenta a janela inicial para essa tarefa.

Ator PortoInformações sobre o nível de hierarquiaBotões de edição da figura

Estado do receiver no instante atualAtores da especificação

29

Figura 2.21 − Janela inicial para o profiling.

A janela da figura 2.21 apresenta na seu lado esquerdo uma árvore representando a hierarquiados atores e portos associados. Selecionando um ator opaco ou porto, o sumário das informaçõesestatísticas para o respectivo objeto é apresentado. Também é possível restringir a análise à umsubconjunto dos dados determinado−se um intervalo de instantes. O valor padrão inclui todos os dados.Através do menu dessa janela o usuário pode visualizar os dados em tabelas e gráficos. A figura 2.22apresenta a tabela de dados referentes à atores.

Figura 2.22 − Tabela de dados estatísticos de atores.

A tabela da figura 2.22 apresenta nove dados para cada ator: as porcentagens de instantes em queo ator esteve em cada um dos três estados e o intervalo mínimo e máximo que um ator esteve em cadaum dos três estados consecutivamente. A figura 2.23 apresenta a tabela de dados referente aos portos.

Sumário das estatísticasHierarquia de atores e portos da especificação

Inclui os dados do ator ou porto nos gráficos

30

Figura 2.23 − A tabela de dados dos portos.

A ferramenta utiliza duas tabelas para apresentar os dados estatísticos referentes aos portos: aprimeira é para cada porto isoladamente e a segunda é referente à conexão entre dois portos. Para cadaporto é calculado quantos dados foram produzidos, consumidos e os intervalos mínimos e máximos entrecada consumo e produção de tokens. Para cada conexão é registrado o valor máximo e a média de tokensacumulados durante o intervalo de instantes especificado.

A janela inicial de profiling (figura 2.21) possui um botão para incluir os dados de um ator ouporto nos gráficos (os dados das tabelas são incluídos automaticamente). A figura 2.24 mostra o gráficoda evolução do estado de um ator com relação aos instantes.

Estatísticas de cada porto

Estatísticas de cada conexao

31

Figura 2.24 − Gráfico da evolução do estado de um ator.

A janela da figura 2.24 utiliza o aplicativo PtPlot presente no ambiente Ptolemy para mostrar ográfico. O valor 1.0 representa o estado executando, o valor 0.0 representa o estado pronto e o valor −1.0o estado bloqueado. A ferramenta dispõe de um gráfico alternativo para a visualização da evolução doestado de um ator, conforme a figura 2.25 demonstra.

Figura 2.25 − Gráfico alternativo da evolução dos estados de um ator.

Com o gráfico da figura 2.25 é mais fácil comparar a evolução de vários atores simultaneamente.A evolução da quantidade de tokens em cada conexão também pode ser estudada através de um

gráfico, exemplificado na figura 2.26.

Figura 2.26 − Exemplo de gráfico da evolução da quantidade de tokens em uma conexão.

Atores

Atores

Conexões

32

Capítulo 3

Primitivas Comportamentais

3.1 Introdução

A metodologia que empregamos para determinar a eficiência de cada MoC é baseada no conceitode pr imitiva comportamental. Definimos uma primitiva comportamental como um tipo decomportamento básico utilizado pelo projetista para capturar um trecho do sistema. Uma primitivacomportamental deve possuir duas características: não ser ambígua e ser genérica. Criamos o conceito deprimitiva comportamental a partir da analogia com o conceito de base em um espaço vetorial: umaespecificação executável pode ser decomposta em um conjunto de primitivas da mesma forma como ospontos de um espaço vetorial podem ser encontrados a partir de bases. Entretanto, ao contrário de bases,primitivas comportamentais não são necessariamente independentes. Para capturar diferentes primitivascomportamentais utilizamos ¨toy benchmarks̈ , que são exemplos de pequenos sistemas que demonstramfortemente a presença da primitiva.

Podemos citar como exemplo de primitivas comportamentais construções de linguagens deprogramação imperativa tais como seqüência de expressões, iteração, desvios condicionais, chamada deprocedimentos, etc. Comportamentos tais como recursão, sincronização, preempção e concorrênciatambém são primitivas.

Neste capítulo apresentaremos o estudo das primitivas comportamentais que enumeramos.Obtivemos essa lista de primitivas a partir de nossa experiência de criação de especificações executáveis.Cada primitiva é capturada através de um toy benchmark. Em seguida, uma ou mais especificações paracada um dos seis modelos computacionais utilizados são descritas e comentadas. Em seguida,observações referentes à análise da execução são apresentadas. Ao final do capítulo, será apresentado umresumo das conclusões referentes à adequação de cada modelo computacional na captura das primitivascomportamentais.

3.2 Seqüência de Expressões

Uma seqüência de expressões (basic block) é um trecho de código caracterizado por ter fluxo decontrole seqüencial sem repetições, desvios condicionais e chamadas de procedimentos. Essa primitivafoi escolhida pois sistemas costumam apresentar este tipo de comportamento.

3.2.1 Exemplo de Sistema

O cálculo dos pontos de uma curva borboleta10 será usado como exemplo para capturar essaprimitiva. Um procedimento em linguagem C que implementa esse cálculo é mostrado na figura 3.1.

but t er f l y( doubl e i nput , doubl e * x, doubl e * y) { doubl e t 1, t 2, t 3;

t 1 = i nput * 1/ 12. 0; / / Scal e1 t 1 = s i n( t 1) ; / / Si ne t 2 = t 1 * t 1; / / Mul t 1 t 2 = t 2 * t 2; / / Mul t 2 t 3 = t 2 * t 1; / / Mul t 3

t 1 = i nput * 4. 0; / / Scal e2 t 1 = cos( t 1) ; / / Cos2 t 1 = −2. 0 * t 1; / / Scal e3

10 Esse exemplo foi extraído do conjunto de demonstrações da versão anterior (Classic) do ambiente Ptolemy.

33 t 2 = cos( i nput ) ; / / Cos1 t 2 = exp( t 2) ; / / Exp

t 3 = t 3 + t 2 + t 1; / / Add

* x = t 3 * cos( i nput ) ; / / Pt oR * y = t 3 * s i n( i nput ) ; / / Pt oR}

Figura 3.1 − Descrição em linguagem C do cálculo dos pontos da curva borboleta.

A entrada para o sistema é um valor inteiro e o sistema produz um ponto da curva com base novalor de entrada.

3.2.2 Especificação Executável

Uma das primeiras decisões a serem tomadas na criação de uma especificação executável noambiente Ptolemy é a escolha de quais atores devem ser utilizados. Isso implica em definir qual é afuncionalidade de cada um e qual será a interação entre eles. Ao final, o conjunto de atores deve capturaro comportamento desejado.

No caso do sistema da figura 3.1, tivemos que determinar a associação entre uma expressão doprocedimento com um ator na especificação, isto é, determinar a granularidade da função implementadapor cada ator. Embora uma solução fosse criar apenas um ator que implemente o procedimento, essasolução trivial não é interessante para o estudo da primitiva, uma vez que implementando−a através deum único ator não iria expor a primitiva às características do modelo computacional. Desta forma,optamos por utilizar uma granularidade a mais fina possível: cada expressão do procedimento éimplementada por um ator. A única exceção são as últimas duas expressões do procedimento que sãoimplementados por um único ator. A figura 3.2 apresenta a topologia obtida. O comentário ao lado decada expressão do procedimento da figura 3.1 indica qual ator implementa a respectiva expressão. Osatores Ramp e Plotter são usados respectivamente para gerar valores e mostrar a curva resultante.

Figura 3.2 − A topologia da especificação executável para o exemplo curva borboleta.

Uma característica da especificação da figura 3.2 é que apenas atores domain polymorphic[DAV99] foram utilizados, devido à simplicidade da funcionalidade de cada ator. Desta forma, a mesmaespecificação pode ser utilizada com diferentes modelos computacionais. A única modificação necessáriaà especificação foi sob o modelo DE, uma vez que esse modelo computacional é baseado noprocessamento de eventos. Nesse caso um ator que gera eventos periodicamente (Clock) foi usado parainiciar um ciclo de execução.

É importante notar que a especificação da figura 3.2 não captura o procedimento da figura 3.1,mas sim o cálculo da curva borboleta, isto porque o modelo computacional do procedimento é umamáquina RAM e outros modelos foram utilizados na especificação da figura 3.2. Por exemplo, mais deum ator pode ser executado simultaneamente utilizando um modelo data flow, o que não ocorre com oprocedimento da figura 3.1.

RampRamp

RampScale1

RampScale2

RampCos1

RampSine

RampCos2

RampExp

RampMult1

RampScale3

RampMult2

RampMult3

RampAdd

RampPtoR

RampPlotter

22

343.2.3 Análise da Execução11

3.2.3.1 SDF

A análise da execução de uma especificação usando o modelo SDF é sempre previsível,conforme foi descrito no capítulo 2. A especificação obtida para a primitiva é um grafo homogêneo(todas as taxas de amostragem são iguais à 1), pois a comunicação entre atores corresponde a escrita eleitura de variáveis temporárias (t1, t2, t3) do procedimento mostrado na figura 3.1. Desta forma, cadaator foi ativado uma vez a cada iteração.

3.2.3.2 DDF

A seqüência de disparos de atores foi similar ao obtido utilizando o MoC SDF, devido aoescalonador utilizar o conceito de ator deferrable. O ator Ramp ilustra essa situação: uma vez que eledispara, é classificado como deferrable até que o ator PtoR dispare. Utilizando um escalonador sem aclassificação de ator deferrable, o ator Ramp e seus sucessores são disparados sucessivamente,permitindo a existência de paralelismo temporal. Nesse caso, o número máximo de tokens foi observadona conexão Ramp/PtoR, variando entre 7 e 8 tokens. Esse limite está relacionado ao caminho de dadosmais longo do grafo a partir do ator Ramp até o ator PtoR. As figuras 3.3 e 3.4 ilustram momentos deuma execução utilizando ou não um escalonador puramente data driven. O número ao lado de algunsatores representa a quantidade de tokens nas respectivas filas de entrada.

Figura 3.3 − Situação da execução em um momento inicial utilizando o escalonador com classificação de atordeferrable.

Figura 3.4 − Situação da execução em um momento inicial utilizando o escalonador sem classificação de atordeferrable.

3.2.3.3 PN

Como no caso do MoC DDF, a conexão Ramp/PtoR foi o empecilho para a presença deparalelismo temporal. Caso não inicializada com um valor diferente, a capacidade inicial de cada fila é 1,só sendo modificada na ocorrência de um deadlock artificial. Modificando esse valor inicial de 1 para 5,a porcentagem de instantes em que o ator Ramp esteve bloqueado caiu de 43 para 8.5. Aumentando esse

11 É importante ressaltar que as análises desse item são referentes às implementações dos modelos computacionais no ambiente Ptolemy.

RampRamp

RampScale1

RampScale2

RampCos1

RampSine

RampCos2

RampExp

RampMult1

RampScale3

RampMult2

RampMult3

RampAdd

RampPtoR

RampPlotter

1

2

2

1

1

13

Executando

Pronto

Bloqueado

RampRamp

RampScale1

RampScale2

RampCos1

RampSine

RampCos2

RampExp

RampMult1

RampScale3

RampMult2

RampMult3

RampAdd

RampPtoR

RampPlotter

1

1

1

Executando

Pronto

Bloqueado

35valor suficientemente obtivemos uma execução similar ao MoC DDF com um escalonador puramentedata driven.

3.2.3.4 DE

Os atores foram ativados seguindo uma ordem topológica. Esse ordem foi gerada conformedescrito no capítulo 2. Apenas o ator Clock, utilizado para disparar o ator Ramp, gera eventos comatraso.

3.2.3.5 CSP

Comparando com o MoC PN, a porcentagem de instantes que um ator esteve bloqueadoaumentou, com conseqüente redução do número de instantes em que o mesmo ator esteve pronto. Asemântica de comunicação rendezvous explica essa observação. O ator Scale3 ilustra tal situação: apósiniciar o envio do token, ele é bloqueado esperando pelo ator Add obter o token. Esse ator também deveconsumir tokens enviados pelos atores Mult3 e Exp. Desta forma, o ator Scale3 fica bloqueado duranteum período que depende de como o ator Add foi implementado. Essa situação não ocorre com o MoCPN, uma vez que a comunicação é feita através de filas unidirecionais.

Observamos que esse exemplo possui uma situação onde um deadlock pode ocorrer, decorrentede como um ator foi implementado e de como a topologia foi construída (vide figura 3.2). O ator Rampenvia um token para quatro outros atores: Scale1, Scale2, Cos1 e PtoR. O ambiente Ptolemy irá enviar taltoken através de cada conexão. A ordem em que essas conexões são acessadas irá depender de como atopologia foi criada. Se a conexão entre o ator Ramp e o ator PtoR foi criada antes da conexão para o atorCos1, a execução entra em deadlock. Isso porque o actor Ramp estaria bloqueado para produção (writeblocked) na conexão com o ator PtoR, o actor PtoR estaria bloqueado para consumo (read blocked) naconexão com o actor Add e o esse ator nunca seria executado uma vez que o caminho a partir do atorCos1 não produziria nenhum token.

3.2.3.6 SR

Assim como o modelo SDF, a análise da execução é previsível. A especificação utilizada écomposta apenas por atores strict e não possui nenhum ciclo. Desta forma, cada ator foi disparado umavez, respeitando uma ordem topológica.

3.3 Desvio Condicional

A primitiva comportamental desvio condicional é caracterizada pela execução ou não de umdeterminado bloco de atores com base no valor de uma expressão condicional. Um desvio condicionalpode ser composto por mais de um bloco (branch) de atores, cada bloco associado à uma expressãocondicional. As condições são verificadas de forma seqüencial, isto é, o resultado final irá depender daordem em que forem especificadas. Uma vez que alguma condição seja satisfeita, o bloco associado éexecutado, sem calcular as condições seguintes. Essa primitiva também foi extraída de linguagens deprogramação imperativa.


O cálculo do coeficiente angular de uma reta foi o toy benchmark escolhido. A figura 3.5apresenta a implementação desse exemplo em linguagem C.

doubl e coef ( i nt x1, i nt y1, i nt x2, i nt y2) { i f ( x1 == x2) { / / Cond1 r et ur n 1. 0; / / Ct e1 }

el se i f ( y1 == y2) { / / Cond2

36 r et ur n 0. 0; / / Ct e2 } el se { r et ur n ( doubl e) ( y1 − y2) / ( x1 − x2) ; / / Coef }}

Figura 3.5 − Descrição em linguagem C do cálculo do coeficiente angular de uma reta.

Nesse exemplo, duas igualdades são as condições a serem computadas e três blocos de atores sãoutilizados. A entrada para o sistema é o valor de dois pontos ( (x1,y1) e (x2,y2) ) da reta e o sistemaproduz como saída o valor do coeficiente angular.


A criação de uma especificação executável que capture a primitiva comportamental desviocondicional foi mais complexa com relação à primitiva anterior. Ao total, cinco diferentes especificaçõesforam criadas. Descreveremos separadamente as soluções obtidas para cada modelo computacionalestudado.

3.3.2.1 SDF

O modelo SDF apresenta uma regra que dificulta a captura da primitiva: cada ator deve consumire produzir um número fixo de tokens, sendo esses valores especificados a priori. Desta forma, a cadaiteração, um ator deve ser ativado pelo menos uma vez. Ao contrário, para capturar adequadamente aprimitiva, apenas um dos possíveis blocos de atores deve ser executado para cada conjunto de entradas.

A topologia da primeira especificação desenvolvida para capturar a primitiva utilizando o MoCSDF é ilustrada na figura 3.6.

Figura 3.6 − Topologia da primeira especificação em SDF.

A topologia é composta pelos seguintes atores:

Cte1 e Cte2: dois atores que produzem um valor constante (e especificado por um parâmetro)toda vez que são ativados; Coef: calcula a expressão do coeficiente angular; Comp1 e Comp2: produzem um valor igual à 1 no porto de saída caso o valor das entradassejam iguais, do contrário produz um valor 0; Mux: recebe os resultados de todos os outros atores e produz o resultado final do desvio.

A especificação criada pôde ser capturada no modelo SDF, pois todos os atores consomem e/ouproduzem um token em cada conexão. Parte do comportamento da primitiva foi capturado pelos atores

Comp1

Comp2

Cte1

Cte2

Coef Mux

X1

X2

Y1

Y2

37Comp1 e Comp2 e parte pelo ator Mux. Embora fosse possível implementar o ator Mux utilizando umcomando tipo if−then−else presente na linguagem Java, isso foi evitado utilizando uma matrizassociando o par de valores condicionais a um porto de entrada. A figura 3.7 mostra o corpo desse ator.

1− . . .2− I nt Token t 1 = ( I nt Token) v1. get ( 0) ;3− I nt Token t 2 = ( I nt Token) v2. get ( 0) ;4− Doubl eToken t 3 = ( Doubl eToken) v3. get ( 0) ;5−6− _t abl e[ 1] [ 0] = t 1. i nt Val ue( ) ;7− _t abl e[ 1] [ 1] = _t abl e[ 1] [ 0] ;8−9− _t abl e[ 0] [ 1] = t 2. i nt Val ue( ) ;10− _t abl e[ 0] [ 0] = t 3. doubl eVal ue( ) ;11−12− i nt i ndex1 = ( ( I nt Token) ct r l 1. get ( 0) ) . i nt Val ue( ) ;13− i nt i ndex2 = ( ( I nt Token) ct r l 2. get ( 0) ) . i nt Val ue( ) ;14− 15− out put . br oadcast (16− new Doubl eToken( _t abl e[ i ndex1] [ i ndex2] ) ) ;17− . . .

Figura 3.7 − Trecho do código do ator Mux.

De maneira geral, a estratégia utilizada na especificação da figura 3.6 é valida para capturar aprimitiva no MoC SDF. Entretanto, essa solução não é totalmente satisfatória, pois todos os atoresimplementando os blocos e condições são sempre ativados e somente em seguida uma decisão é tomada.

Além desse desvantagem, o exemplo do coeficiente angular apresenta uma característicaparticular: o terceiro caminho só pode ser executado quando a condição (x1 == x2) for falsa. Casocontrário, uma divisão por zero irá ocorrer, gerando um erro fatal. Uma possível solução seria adicionarcomo entrada do ator Coef o valor da primeira condição calculada pelo ator Comp1, e utilizar umcomando if−then−else dentro do ator.

Para obter uma especificação válida para o cálculo do coeficiente angular, implementamos outrasolução utilizando o conceito de função high−order [HUD89], ou seja, uma função que tem comoparâmetros funções e/ou que retorna como resultado outras funções. A topologia da especificação obtidaé mostrada na figura 3.8.

Figura 3.8 − Topologia da segunda especificação utilizando o MoC SDF.

O atores são:

Comp1 e Comp2: mesma função que na especificação da figura 3.7; Map: recebe o valor de ambas as condições e determina qual deve ser a função a ser executada.Uma vez determinada, a função é inserida em um token do tipo objeto (ObjectToken) e enviadaao ator Apply. Apply: lê os valores das entradas (parâmetros da função) e executa a função recebida.

Como duas funções diferentes devem ser executadas (geração de constantes e cálculo daexpressão do coeficiente), utilizamos um objeto do tipo Interface da linguagem Java para transmitir afunção do ator Map ao ator Apply. A figura 3.9 apresenta o código desse objeto:

package pt i j . domai ns. sdf . demo. i f el se2;

publ i c i nt er f ace Funct i on { publ i c doubl e appl y( i nt x1, i nt x2, i nt y1, i nt y2) ;}

Figura 3.9 − Interface para uma função do exemplo do coeficiente angular

Comp1

Comp2

X1

X2

Y1

Y2

Map Apply

X1X2 Y1

Y2

38

Cada diferente função implementa a Interface da figura 3.9, definindo o código da função apply.Como a expressão para o cálculo do coeficiente necessita dos valores de ambos os pontos, estes estãoincluídos como parâmetros da função apply. A implementação da geração de um valor constante ignoraesses parâmetros. Isto também é válido para o ator Apply, que deve ter como entradas a união dosparâmetros de todas as funções que podem ser executadas.

A necessidade de adicionar entradas, mesmo que desnecessárias para algumas funções, é umponto negativo da especificação da figura 3.8, isto porque dados serão recebidos desnecessariamente.

3.3.2.2 DDF

O MoC DDF permite a variação em tempo de execução da quantidade de tokens recebidos eenviados por um ator. Desta forma, desenvolvemos novas especificações utilizando tal característica. Afigura 3.10 mostra a topologia da primeira especificação executável.

Figura 3.10 − Topologia da primeira especificação utilizando o modelo DDF.

Os atores Comp1, Comp2, Cte1, Cte2 e Coef implementam as mesmas funções que nasespecificações anteriores. A única modificação necessária foi a inclusão de um porto de entrada (Trigger)aos atores Cte1 e Cte2. A finalidade deste porto é controlar o ativamento dos respectivos atores. Doisnovos atores foram desenvolvidos: Switch e Select (vide item 2.3.5). O ator Switch é responsável porenviar os dados da entrada do sistema aos respectivos atores, com base no valor das condições. O atorSelect determina qual é o porto de entrada que contém o próximo token, a partir do valor das condições.

O ponto favorável da especificação da figura 3.10 é que um bloco do sistema só é executadoquando a expressão condicional associada à ele for verdadeira. Dois pontos negativos podem serobservados: todos os valores de entrada dos blocos do sistema devem passar pelo ator Switch e ambas ascondições são sempre computadas. Com o intuito de remover esses problemas, a especificação ilustradana figura 3.11 foi criada.

Comp1

Comp2

X1

X2

Y1Y2

SwitchRampCoef

Cte2

Cte1

Select

Trigger

Trigger

39

Figura 3.11 − Topologia da segunda especificação utilizando o MoC DDF.

A especificação da figura 3.11 contém os seguintes atores:

Cte0, Cte1 e Cte2: igual à especificação da figura 3.10; Coef: como nas outras especificações; Comp1 e Comp2: como nas outras especificações; D: ator que implementa um demultiplexador. Com base em um token de controle (na figura3.11, é a entrada mostrada no lado superior ou inferior do retângulo) determina para qual portode saída o dado de entrada deve ser enviado. M: similar ao ator D, mas implementando uma função de multiplexador, ou seja, com base notoken de controle, determina qual entrada deve ser a próxima a ser lida.

A especificação da figura 3.11 calcula uma condição apenas quando as anteriores falharam. Osdados Y1 e Y2 são enviados ao ator Comp2 apenas quando a condição C1 é 0 (falsa), desta forma,controlando o ativamento do ator. No caso dos atores Cte1 e Cte2, o resultado dos atores condicionaisroteia um token de controle (gerado pelo ator Cte0). No caso do ator Coef, os atores condicionaiseliminam ou não os dados necessários pelo ator. Essa eliminação é necessária (também no caso do atorComp2) devido às filas unidirecionais utilizadas em cada conexão: caso um ator não fosse ativado, e osdados não fossem descartados, ele iria receber na próxima execução dados antigos.

3.3.2.3 PN

Todas as especificações mostradas até o momento são válidas para o MoC PN. Nenhuma outrafoi desenvolvida utilizando características específicas do mesmo.

3.3.2.4 CSP

As especificações mostradas anteriormente também podem ser usadas com o MoC CSP. Emboraesse MoC não utilize filas entre atores para a comunicação dos dados, todas as especificações transmitem

Comp1X1

X2

D01Cte0

D01

D01

Comp2

D0

1

Cte1

Cte2

M01

M01

RampCoefD

0

1

D01

Y1

Y2

C1

D01

D01

D01

D01

D0

1

D01

X1

X2

Y1

Y2

C1

C1

C1

Trigger

Trigger

40apenas um token em cada conexão.

Neste MoC, fizemos uma tentativa de alteração da especificação da figura 3.11, a fim de torná−la mais eficiente. Os dois atores multiplexer (M) foram substituídos por um ator com comportamento nãodeterminístico (MuxND da figura 3.13). A figura 3.12 mostra parte do código desse ator.

1− Condi t i onal Br anch [ ] br anches = new Condi t i onal Br anch[ 3] ;2−3− br anches[ 0] = new Condi t i onal Recei ve( t r ue, a, 0, 0) ;4− br anches[ 1] = new Condi t i onal Recei ve( t r ue, b, 0, 1) ;5− br anches[ 2] = new Condi t i onal Recei ve( t r ue, c , 0, 2) ;6−7− i nt r esul t = chooseBr anch( br anches) ;8− i f ( r esul t == 0) {9− out put . br oadcast ( br anches[ 0] . get Token( ) ) ;10− }11− el se12− i f ( r esul t == 1) {13− out put . br oadcast ( br anches[ 1] . get Token( ) ) ;14− }15− el se16− i f ( r esul t == 2) {17− out put . br oadcast ( br anches[ 2] . get Token( ) ) ;18− }

Figura 3.12 − Trecho de código do ator MuxND no MoC CSP.

Para implementar o comportamento do ator MuxND, utilizamos o comando de comunicaçãoguarded. Da linha 1 à linha 5 do código da figura 3.12, as três possibilidades são criadas, uma para cadaporto de entrada do ator (a, b, c). A expressão condicional de cada comando de comunicação é sempreverdadeira, desta forma, evitando uma seqüência fixa de verificação dos portos de entrada.

A inclusão do ator MuxND pretendia eliminar a necessidade de comunicar os valorescondicionais aos atores multiplexer da especificação. Esses atores são utilizados para combinar osresultados dos blocos de atores do desvio condicional, enviando o resultado para a saída do sistema.Como apenas um dos três possíveis caminhos pelos atores do corpo do desvio condicional (Cte1, Cte2 eCoef) é utilizado para um dado conjunto de entradas, não seria necessário enviar os valores condicionaisaos atores multiplexer.

O problema com a modificação adotada é que ela torna o comportamento da especificação nãodeterminístico. Isso ocorre pois não é possível garantir que a propagação dos resultados de um conjuntode entrada irá terminar antes da propagação de outro conjunto posterior devido ao escalonamento(desconhecido e aleatório) dos diferentes processos. Na figura 3.11, uma vez que o primeiro bloco deatores D tenha lido os valores C1, X1, X2, Y1, Y2, outro conjunto de entradas pode ser propagado, istoporque o ator Comp1 e os atores que geram os valores (X, Y) estão desbloqueados (terminaram orendezvous) . Caso o próximo grupo de entradas seja propagado pelo ator Cte1, não é possível garantir aordem final dos resultados.

3.3.2.5 DE

Todas as especificações anteriores são válidas nesse MoC. Entretanto, utilizando ascaracterísticas particulares desse MoC, desenvolvemos uma nova especificação. A figura 3.13 apresentaa topologia desta especificação.

Figura 3.13 − Topologia da especificação no MoC DE.

Comp1

Comp2

Cte1

Cte2

Coef

MuxND

X1X2 Y1

Y2

X1

X2

Y1Y2

Trigger

41

Os atores do corpo do desvio, Cte1, Cte2 e Coef permanecem com a mesma função. Apenas oator Coef foi modificado: quando um evento está presente em um dos portos de entrada, ele éarmazenado em uma variável interna. A figura 3.14 mostra um trecho de código deste ator.

1− . . .2− i f ( x1. hasToken( 0) ) {3− _x1 = ( ( I nt Token) x1. get ( 0) ) . i nt Val ue( ) ;4− }5− . . .6− i f ( t r i gger . hasToken( 0) ) {7− t r i gger . get ( 0) ;8− out put . br oadcast ( new Doubl eToken( ( _y1 − _y2) / ( _x1 − _x2) ) ) ;9− }10− . . .

Figura 3.14 − Trecho de código do ator Coef no MoC DE.

Quando um evento está presente no porto Trigger (figura 3.13), um novo valor de saída écomputado com base nos valores armazenados dos dados.

Os atores que calculam os valores condicionais do desvio, Comp1 e Comp2, possuem na novaespecificação três portos de entrada (o porto Trigger do ator Comp1 é ignorado) e dois de saída. Alémdos dois valores de dados a serem comparados, um novo porto de entrada, utilizado para ativar o cálculoda comparação (mesma técnica do trecho de código da figura 3.14), foi incluído. Dois portos de saídasão utilizados, um para cada condição. Apenas um dos dois portos terá um evento para cada par devalores de entrada.

O ator MuxND foi utilizado nessa especificação: ao receber um evento em qualquer porto deentrada, o mesmo é enviado para o porto de saída. Caso existam eventos simultâneos, a ordem seráconforme os portos de entrada são verificados.

3.3.2.6 SR

Utilizando atores strict, é possível implementar as especificações das figuras 3.6, 3.8, 3.10, 3.11.A especificação da figura 3.13 também pode ser utilizada. Nesse caso, o ator MuxND passa a ser um atornon−strict, isto é, tão logo um evento em um dos portos de entrada esteja presente, o evento no porto desaída nesse instante será o valor lido. A figura 3.15 mostra o método fire() desse ator.

1− publ i c voi d f i r e( ) t hr ows I l l egal Act i onExcept i on {2− i f ( a. pr esent ( 0) && ! out put . known( 0) ) {3− out put . br oadcast ( a. get ( 0) ) ;4− }5−6− i f ( b. pr esent ( 0) && ! out put . known( 0) ) {7− out put . br oadcast ( b. get ( 0) ) ;8− }9−10− i f ( c . pr esent ( 0) && ! out put . known( 0) ) {11− out put . br oadcast ( c. get ( 0) ) ;12− }13− }

Figura 3.15 − Método fire() do ator MuxND no MoC SR.

É importante notar que o ator MuxND, implementado como mostra a figura 3.15, não é um atormonotônico12, portanto, sua utilização no MoC SR é inválida. Foi possível executar a modelo noambiente Ptolemy, pois a implementação que fizemos do MoC SR não efetua nenhum tipo de verificaçãode consistência. Entretanto, podemos (o usuário) garantir que mesmo com esse ator, a especificaçãocaptura o comportamento de forma adequada (determinística). Isso se deve à mutua exclusão presente naprimitiva de desvio condicional: é garantido que em um determinado instante, apenas um dos sinais (a,b, c) estará presente, tornando o código da figura 3.15 válido.

12 Na literatura, esse ator (e variantes) é denominado nondeterminate merge [PAN92][LEE95], e foi demonstrado que seu comportamento nãoé monotônico [BRO81].

423.3.3 Análise da Execução

3.3.3.1 SDF

Como todas as especificações para a primitiva de desvio condicional são homogêneas, aexecução ativou cada ator respeitando o escalonamento, que nesse caso é uma ordem topológica dografo.

3.3.3.2 DDF

As figuras 3.16 e 3.17 apresentam um exemplo da evolução do estado do ator Comp2 para asespecificações das figuras 3.10 e 3.11 respectivamente. O eixo da abcissas indica um instante daexecução e o das ordenadas o estado do ator. Nota−se o ativamento constante e repetido do ator paraquatro conjuntos de valores de entrada no caso da especificação da figura 3.10. Já para a especificação dafigura 3.11, após o segundo conjunto de dados, o ator permanece um longo período bloqueado (semdados). Nesse período, dois conjuntos de dados foram aplicados e que não necessitavam do cálculo dasegunda expressão condicional.

Figura 3.16 − Exemplo da evolução do estado do ator Comp2 para a especificação da figura 3.10 no MoC DDF.

Figura 3.17 − Exemplo da evolução do estado do ator Comp2 para a especificação da figura 3.11 no MoC DDF.

Embora a especificação da figura 3.11 seja mais bem elaborada, notamos que a especificação dafigura 3.10 teve um tempo de execução menor (100ms em média) que a especificação da figura 3.11(220ms em média). Isso pode ser explicado pelo maior número de atores na segunda especificação, com

43conseqüente aumento do overhead imposto pelo escalonamento dinâmico. Outro ponto relevante àdiferença no tempo de execução é a simplicidade do código de cada ator, principalmente do código dosatores Comp1 e Comp2. Caso tais atores envolvessem funções mais complexas, a especificação da figura3.11 passaria a ser mais vantajosa.

3.3.3.3 PN

Conforme foi mencionado no capítulo 2, uma característica que diferencia esse MoC comrelação ao MoC DDF é a utilização de processos executando de forma contínua e ininterrupta ao invés deativamentos atômicos de atores. Isso pode ser observado comparando−se a figura 3.18 com a figura 3.17:no caso da figura 3.18, a execução foi fragmentada em vários instantes. O máximo intervalo contínuo emque o ator esteve executando foi por 6 instantes, mas a maioria foi por 1 instante.

Figura 3.18 − Exemplo da evolução do estado do ator Comp2 para a especificação da figura 3.11 no MoC PN.

Nenhuma observação adicional pôde ser feita quando o parâmetro do tamanho inicial das filas decomunicação foi alterado.

3.3.3.4 CSP

Observamos novamente o problema de deadlock no MoC CSP. O ator D da figura 3.11 tinhasido originalmente implementado de forma a obter o primeiro token de controle e em seguida o dado aser roteado. No caso dos modelos data flow e no modelo PN, isso não acarretou problemas. No modeloCSP, ocorreu um deadlock, pois o ator que gerava os valores (X,Y) estava bloqueado tentando enviar ovalor X1 para um ator D, este esperando o valor de controle gerado pelo ator Comp1, que não podiaproduzir um resultado enquanto não obtivesse o valor X2. Modificamos a implementação do ator D, e aespecificação não apresentou mais deadlocks.

3.3.3.5 DE

Como no exemplo da primitiva seqüência de expressões, apenas o Clock gera eventos comatraso. Nenhuma característica particular pôde ser observada, apenas verificamos o comportamentoadequado da especificação da figura 3.13.

3.3.3.6 SR

Nenhuma característica relevante foi observada. O escalonamento é trivial (ordem topológica) ea especificação é válida. Como foi destacado no item 3.3.2.6, observou−se que os sinais a, b e c do atorMuxND nunca possuem eventos simultaneamente.

443.4 Iteração com Duração Fixa

A primitiva comportamental de iteração com duração fixa é a repetição sucessiva de um bloco deatores. O número de repetições é determinado no momento da criação da especificação. Essa primitiva ébaseada em comandos de repetição (laços).


Escolhemos como exemplo de sistema a multiplicação de duas matrizes de ordem N. A figura3.19 mostra o trecho de código utilizado.

1− f or ( i nt i = 0; i < N; i ++) {2− f or ( i nt j = 0; j < N; j ++) {3− f or ( i nt k = 0; k < N; k++) {4− r es[ i ] [ j ] += dat a[ i ] [ k ] * cT[ k] [ j ] ;5− }6− }7− }

Figura 3.19 − Multiplicação de duas matrizes de ordem N.

O exemplo utiliza três iterações encadeadas (linha 1 até 3), cada uma com um contador (i, j, k)diferente. Desta forma, o corpo da iteração (linha 4) é repetido N3 vezes. Utilizamos no estudo daprimitiva matrizes de ordem 8.


A primeira especificação que desenvolvemos pôde ser utilizada com todos os seis modeloscomputacionais, pois a exemplo da especificação da figura 3.2, utilizamos somente atores que consomeme produzem um token por cada porto de entrada/saída. A figura 3.20 apresenta a topologia destaespecificação.

Figura 3.20 − A primeira especificação para a primitiva de iteração fixa.

A função de cada ator da especificação é:

Ramp: gera uma seqüência crescente de valores inteiros, com incremento igual à 1; Modulo: calcula o módulo do valor de entrada por um valor especificado como parâmetro; Divide1 e Divide2: calcula o módulo da divisão do valor de entrada por um valorespecificado como parâmetro. O valor do módulo é o mesmo do divisor utilizado; Ct e Data: são atores que armazenam uma matriz (especificada como um parâmetro). Dadoum valor de linha (R) e coluna (C), produz o valor da posição correspondente na matriz; Mult: multiplica o valor de dois tokens; AccumAdd: calcula a soma de N (parâmetro) números. A cada valor de entrada, gera oresultado parcial; Res: utilizado para armazenar um novo valor em uma matriz.

i

j

kRamp

Divide1

Modulo

Divide2

AccumAdd ResMult

R

R

C

C

CT

Data

45A geração dos contadores da iteração da figura 3.16 é implementada pelos atores Ramp, Divide1,

Divide2 e Modulo. Os outros atores representam o corpo da iteração. Cada iteração é iniciada com odisparo do ator Ramp. Como o exemplo utiliza três laços encadeados, o valor do contador j devepermanecer o mesmo enquanto o contador k vai de 0 até N. O mesmo deve ocorrer com o contador i emrelação ao contador j . Essa é a razão da utilização dos atores Divide1 e Divide2. O primeiro éconfigurado com valor N = 8 e o segundo com valor N = 64.

Outra possível implementação para a geração dos contadores da figura 3.20 é mostrada na figura3.21.

Figura 3.21 − Implementação alternativa para a geração dos índices da iteração.

Neste caso, cada índice é gerado utilizando−se dois atores: um ator de atraso (D) e o atorIndexGen. O ator IndexGen é responsável por calcular os novos valores dos contadores com base nosvalores anteriores. O valor inicial para cada ator de atraso é 0. A função desse ator é armazenar o valoranterior do contador, ou seja, a topologia da figura 3.21 está implementando o conceito de estado demaneira explícita.

O principal problema com a especificação da figura 3.20 é a produção desnecessária do valor doscontadores (por exemplo, o contador i é desnecessariamente repetido por 63 vezes), ou seja, atores sãodesnecessariamente ativados. Utilizamos características específicas dos diferentes modeloscomputacionais para aprimorar a especificação. Descreveremos os resultados obtidos.

3.4.2.1 SDF

O modelo computacional SDF permite uma iteração implícita de atores através da especificaçãode valores de consumo e produção de tokens variados. Considere o exemplo: um ator A produz dadospara um ator B. Caso seja especificado que o ator A produz um token a cada ativação e que o ator Bconsome dez, então o ator A será ativado dez vezes mais que o ator B.

A figura 3.22 mostra a especificação executável utilizando o modelo SDF.

Figura 3.22 − A iteração com duração fixa no MoC SDF.

Com relação à figura 3.20, apenas a geração dos contadores foi modificada. Ela é feita através detrês atores Sequencer. Esse tipo de ator gera uma seqüência crescente de inteiros até um valorespecificado (parâmetro) e então reinicia a seqüência a partir de 0. Os números próximos a cada conexãosão as taxas de amostragem dos respectivos portos. Por exemplo, foi especificado que para cada token

IndexGen

i

k

j

D

D

D

1Sequencer2

Sequencer1

Sequencer3

AccumAdd ResMult

R

R

C

C

CT

Data

1

1

8

1

1

64

1

1

81 1 8

8

1

8

64

46que o ator Data consome proveniente do ator Sequencer1, 64 tokens devem ser consumidos provenientesdo ator Sequencer1. Nessa especificação, não há produção redundante de tokens.

3.4.2.2 DDF

Implementamos outra solução permitindo que alguns valores de consumo/produção não fossemespecificados, como no caso dos atores CT e Data. Neles, a utilização da leitura bloqueante através docomando waitFor() pode ser empregada como forma de garantir o consumo da quantidade correta detokens em cada porto. A figura 3.23 apresenta um trecho de código de um desses atores para ilustrar essasolução.

1− . . . .2− publ i c voi d f i r e( ) t hr ows I l l egal Act i onExcept i on {3−4− i f ( _st at e == 0) {5− i f ( _r owCount == 1) {6− _Por t 0Token = ( I nt Token) r ow. get ( 0) ;7− wai t For ( col , 1) ;8− }9− el se {10− _Por t 0Token = ( I nt Token) col . get ( 0) ;11− wai t For ( r ow, 1) ;12− }14− _st at e = 1;15− }16− el se {17− I nt Token i t ;18− i f ( _r owCount == 1) {19− i t = ( I nt Token) col . get ( 0) ;20− dat a. br oadcast ( new I nt Token(21− _dat a[ _Por t 0Token. i nt Val ue( ) ] [ i t . i nt Val ue( ) ] ) ) ;22−23− _st at e++;24− i f ( _st at e == _col Count ) {25− wai t For ( r ow, 1) ;26− _st at e = 0;27− }28− el se {29− wai t For ( col , 1) ;30− }31− }32− el se {33− i t = ( I nt Token) r ow. get ( 0) ;34− dat a. br oadcast ( new I nt Token(35− _dat a[ i t . i nt Val ue( ) ] [ _Por t 0Token. i nt Val ue( ) ] ) ) ;36− 37− _st at e++;38− i f ( _st at e == _r owCount ) {39− wai t For ( col , 1) ;40− _st at e = 0;41− }42− el se {43− wai t For ( r ow, 1) ;44− }45− }46− }47− }48− . . . .

Figura 3.23 − Trecho de código dos atores CT e Data.

As variáveis _rowCount e _colCount armazenam a quantidade de tokens a serem consumidosnos portos row e col, respectivamente. Uma dessas variáveis deve ter o valor igual à 1, enquanto que aoutra pode apresentar qualquer valor maior ou igual a 1. A variável _state é utilizada para determinar dequal porto o próximo token deve ser lido.

3.4.2.3 PN

A especificação empregada no MoC DDF também foi utilizada nesse MoC. Como não é um

47modelo data flow, nenhuma taxa de amostragem é especificada. Desta forma, o código dos atores CT eData foram adaptados. A figura 3.24 mostra essa modificação.

1− i f ( _r owCount == 1) {2− r = ( I nt Token) r ow. get ( 0) ;3− f or ( i nt i = 0; i < _col Count ; i ++) {4− c = ( I nt Token) col . get ( 0) ;5− dat a. br oadcast ( new I nt Token( _dat a[ r . i nt Val ue( ) ] [ c . i nt Val ue( ) ] ) ) ;6− }7− }8− el se {9− c = ( I nt Token) col . get ( 0) ;10− f or ( i nt i = 0; i < _r owCount ; i ++) {11− r = ( I nt Token) r ow. get ( 0) ;12− dat a. br oadcast ( new I nt Token( _dat a[ r . i nt Val ue( ) ] [ c . i nt Val ue( ) ] ) ) ;13− }14− }

Figura 3.24 − Código dos atores Data e CT no MoC PN.

3.4.2.4 CSP

A especificação empregada no MoC PN também é válida nesse modelo. Nenhuma modificaçãofoi necessária.

3.4.2.5 DE

A topologia da especificação utilizada nesse modelo foi basicamente a mesma da figura 3.22,com apenas a inclusão de um ator tipo Clock, como nos exemplos das primitivas anteriores, conectado àcada ator Sequencer. Entretanto, o código dos atores Sequencer, MatrixHolder, AccumAdd e Res teveque ser alterado. Isso se deve à semântica de comunicação no MoC DE, diferente dos MoCs anteriores.Utilizaremos o ator Sequencer como exemplo. A figura 3.25 mostra o código desse ator no MoC PN e afigura 3.26 no modelo DE.

1− . . . .2− publ i c voi d f i r e( ) t hr ows I l l egal Act i onExcept i on {3− out put . br oadcast ( new I nt Token( _st at e) ) ;4− _st at e = ( _st at e + 1) % _l i mi t ;5− }6− . . . .

Figura 3.25 − Trecho do ator Sequencer no MoC PN.

1− . . . .2− publ i c voi d f i r e( ) t hr ows I l l egal Act i onExcept i on {3−4− i f ( i nput . hasToken( 0) ) {5− i nput . get ( 0) ;6− _count er ++;7− i f ( _count er == _l i mi t ) {8− out put . br oadcast ( new I nt Token( _st at e) ) ;9− _st at e = ( _st at e + 1) % _t o;10− _count er = 0;11− }12− }13− }14− . . . .

Figura 3.26 − Trecho do ator Sequencer no MoC DE.

No código da figura 3.25, o comando na linha 3 cria um novo token com o valor atual daseqüência e envia tal token para os atores conectados. A atualização do valor da seqüência é feita na linha4. Note a utilização de uma variável de estado interna. Esse código é válido no MoC PN devido àutilização de filas nas conexões, o que armazena os valores produzidos, e a semântica de escritabloqueante. Não é possível utilizar esse trecho no MoC DE, pois a cada execução do ator um novo dadoé gerado.

No código da figura 3.26, o comando na linha 4 verifica se há um token no porto input. Este

48porto é utilizado para ativar o ator. O valor lido não é relevante (linha 5). Um contador (linha 6) éutilizado para determinar quando um novo dado deve ser produzido. Esse limite (linha 7) é determinadopelo usuário. Desta forma, é possível que diferentes atores Sequencer gerem dados a taxas diferentes.Note que uma outra alternativa para a implementação de um contador seria como na figura 3.21, ao invésde utilizar uma variável interna.

É interessante notar que o trecho da figura 3.26 é valido nos modelos PN, CSP e DDF, poisnesses casos é possível que um ator não produza nenhum dado em determinados momentos.

Um aprimoramento que pode ser feito é que ao invés de conectar o ator Clock a todos os atoresSequencer, fazê−lo apenas com o ator Sequencer1 e modificar tais atores para que quando a seqüênciaatingir o valor máximo, gerar um evento em um novo porto de saída. Desta forma, conectando os atoresSequencer de maneira encadeada, teremos uma especificação válida e que não escalona nenhum ator deforma desnecessária.

3.4.2.6 SR

A especificação utilizada é igual à do modelo DE, a menos do ator Clock. As modificações feitasnos atores Sequencer, MatrixHolder, AccumAdd e Res para o modelo DE também foram necessárias.Esses modificações utilizaram os comandos próprios desse MoC, como o comando makeAbsent() paratornar um valor de saída ausente em um determinado instante.

3.4.3 Análise da Execução

3.4.3.1 SDF

A única observação feita durante a execução das duas especificações é que a segunda (figura3.22) utilizou filas de capacidade maior. Por exemplo, a conexão Sequencer1 para o ator Data necessitade uma fila com 64 posições. Como esse MoC é escalonado de forma estática, isso já era previsível. Oaumento do tamanho das filas está ligado à duração de cada iteração e ao nível de encadeamento de umaiteração.

3.4.3.2 DDF

Conforme descrito no item 3.3.2.2, utilizamos a leitura bloqueante através do comandowaitFor() para controlar a capacidade máxima necessária das filas de comunicação. A figura 3.27apresenta a evolução do estado do ator Data e do ator Accum.

Figura 3.27 − Evolução do estado dos atores Data (em azul) e Accum (em verde).

É possível observar que após o ator Data obter o valor do contador i (primeiro pico) , ele obtêmum valor do contador k e produz um novo valor de saída, para cada ativação. Quando oito valores sãocriados, o ator Accum é ativado.

Utilizando essa especificação, a capacidade máxima necessária da fila entre os atores Sequencer1e Data caiu de 64 para 1. Em contrapartida, o ator foi escalonado por um maior número de vezes, o que

49pode acarretar um overhead adicional. Entretanto, é possível explorar outras configurações dosparâmetros capacidade máxima das filas/número de ativamentos do ator. Isso pode ser feitomodificando−se o segundo parâmetro do comando waitFor(). A figura 3.28 apresenta um exemplo ondeo valor do segundo parâmetro foi aumentado de 1 para 4 (linhas 29 e 43 do código da figura 3.23).

Figura 3.28 − Evolução do estado dos atores Data e Accum com a alteração do parâmetro do método waitFor().

Observando−se a figura 3.28, o ator Data foi escalonado três vezes, ao invés de nove.Entretanto, a capacidade máxima da fila entre os atores Sequencer1 e Data subiu de 1 para 4.

3.4.3.3 PN

Variamos o valor do tamanho inicial de cada fila de comunicação. Aumentado esse valor, aporcentagem de instantes em que cada ator esteve em cada um dos três possíveis estados permaneceumuito similar. Notamos que a partir de um determinado instante, vários atores estiveram bloqueadosdevido à falta de espaço na fila de comunicação. O aumento do valor do tamanho inicial de cada filaapenas retardou o instante em que esses atores começaram a ficar bloqueados. A figura 3.29 ilustra aevolução do estado do ator Data quando o tamanho inicial das filas é 1, e a figura 3.30 quando otamanho inicial é 8.

Figura 3.29 − Evolução do estado do ator Data quando o tamanho inicial das filas é 1.

Figura 3.30 − Evolução do estado do ator Data quando o tamanho inicial das filas é 8.3.4.3.4 CSP

50

Notamos novamente que a porcentagem de instantes em que os atores estiveram bloqueadosaumentou, com relação ao MoC PN. Nenhum deadlock foi detectado.

3.4.3.5 DE

O escalonamento obtido foi trivial (ordem topológica), uma vez que as especificações utilizadassão sem atraso. Essa situação também ocorreu nas especificações para as outras duas primitivas.

Observamos uma situação que possibilita otimizar o escalonador. Quando existirem várioseventos com um mesmo timestamp, a ordem dos eventos é decidida com base no valor de prioridade,calculado através da ordenação topológica do grafo da especificação. Isto significa que nesta situação, aordem de ativação é conhecida antes da execução. Desenvolvemos então o seguinte escalonador :

1. caso a fila de eventos esteja vazia ou o tempo final foi superado, vá para o passo 9;2. remova o próximo evento da fila;3. atualize o valor de tempo atual para o do evento obtido no passo 2;4. determine para qual ator o evento é destinado e envie o respectivo token;5. remova da fila todos os eventos que tenha o timestamp igual ao tempo atual, enviando os

respectivos tokens aos atores correspondentes;6. respeitando uma ordem topológica, ative cada ator que tenha algum token em um porto de

entrada até que ele tenha consumido dos os tokens. Envie os eventos produzidos comtimestamp maior que o tempo atual para a fila de eventos. Envie os eventos produzidos sematraso para os respectivos atores;

7. caso existam atores com tokens nos portos de entrada, vá para o passo 6;8. vá para o passo 1.9. fim.

O escalonador modificado ativa os atores em um dado timestamp de forma até que nenhum atoresteja produzindo mais eventos. Os eventos para um tempo futuro são introduzidos na fila de eventos,enquanto que os eventos sem atraso são enviados diretamente para os portos dos atores. A validade desseescalonador é garantida pelo respeito à ordenação topológica. A principal vantagem dessa modificação éreduzir o número de eventos da fila central do escalonador. A tabela 3.1 apresenta alguns dadoscomparativos.

Tabela 3.1 − Comparação dos escalonadores do MoC DE.Atorescom

atraso

Atoressem

Atraso

Eventos na Fila

EscalonadorOriginal

Eventos na fila

EscalonadorModificado

Tempo de Execução(ms)

Escalonador Original

Tempo de Execução(ms)

Escalonador Modificado

6 28 27131 8662 5272 4666

1 14 20021 1001 4468 3150

3 3 9884 1945 5317 4620

A tabela 3.1 mostra uma redução considerável do tráfego de eventos na fila do escalonador.Consequentemente, há uma redução no tempo de execução, pois algum overhead relacionado àmanipulação da fila é removido.

É interessante notar que o escalonador modificado é bastante similar ao escalonador do MoC SR.Isso ocorre pois podemos relacionar um instante do MoC SR com um valor de timestamp do MoC DE.

3.4.36 SR

Nenhuma característica adicional foi observada. O escalonamento é trivial.3.5 Outras Primitivas Comportamentais

51

Além das três primitivas descritas e analisadas nos itens anteriores, enumeramos outrasprimitivas comportamentais relevantes à captura de sistemas. Iremos descrever o comportamento de cadaprimitiva e apresentar um toy benchmark.

3.5.1 Sincronismo

A primitiva comportamental de sincronismo corresponde à especificação em que determinadobloco de atores deve ser ativado antes ou depois de outro bloco, ou seja, impor uma restrição na ordemda ativação de atores em determinadas situações. Essa primitiva é amplamente encontrada emespecificações de sistemas concorrentes. Em linguagens de programação seqüenciais, ou em modeloscomputacionais não concorrentes, essa primitiva é utilizada de forma implícita, pois ao criar aespecificação, a ordem da execução entre os comandos (atores) é fixada. A figura 3.31 apresenta umaimplementação do algoritmo Discrete Cosine Transform (DCT) que pode ser utilizado para estudar aprimitiva. A entrada do sistema é uma matriz (data, linha 6) e a saída outra matriz (outv, linha 16).

1− f or ( i = 0; i < _N; i ++) {2− f or ( j = 0; j < _N; j ++) {3− t emp[ i ] [ j ] = 0. 0;4− f or ( k = 0; k < _N; k++) {5− t emp[ i ] [ j ] += ( ( ( i nt ) ( dat a[ i ] [ k ] ) − 128) * _cT[ k] [ j ] ) ;6− }7− }8− }9−10− f or ( i = 0; i < _N; i ++) {11− f or ( j = 0; j < _N; j ++) {12− t emp1 = 0. 0;13− f or ( k = 0; k < _N; k++) {14− t emp1 += ( _c[ i ] [ k ] * t emp[ k] [ j ] ) ;15− }16− out v[ i ] [ j ] = ( i nt ) Mat h. r ound( t emp1) ;17− }18− }

Figura 3.31 − Discrete Cosine Transform: exemplo para a primitiva de sincronismo.

O algoritmo DCT é composto por duas multiplicações de matrizes de ordem N (linhas 1 à 8 e 10à 18), ou seja, por dois blocos de atores que implementam a primitiva do item 3.3. A primitiva desincronismo se manifesta no exemplo da figura 3.31, pois a segunda multiplicação utiliza o resultado daprimeira, ou seja, existe uma dependência de dados entre a primeira e a segunda multiplicação.

A captura do exemplo da figura 3.31 implica em sincronizar as duas multiplicações. Nesseexemplo, isso pode ser feito de maneira implícita gerando os contadores da segunda multiplicaçãoatrelados aos contadores da primeira multiplicação, ou de forma explícita através de novos atores paracontrolar as ativações/geração de eventos.

3.5.2 Compartilhamento de Recursos

Um dos fatores que limita a implementação de um sistema é a disponibilidade de um recurso,como por exemplo área no caso de um circuito integrado ou a quantidade de memória em um sistemamicroprocessado. Desta forma, o compartilhamento de recursos é amplamente utilizado e deve sercapturado por uma especificação executável.

Um exemplo para capturar essa primitiva é o problema dos Dinning Philosophers13 [HOA78].Neste exemplo, o recurso a ser compartilhado são os garfos disponíveis. É um exemplo clássico deprogramação concorrente e foi criado inicialmente para o estudo de propriedades como liveness efairness. Além disso, esse exemplo foi utilizado para o estudo de primitivas de sincronismo. Podemosconsiderar essa primitiva como sendo uma outra forma de sincronismo (neste caso, não temos

13 Um fator para essa escolha é que, além da relevância e adequação do problema, uma especificação utilizando o MoC CSP que implementauma solução está disponível no ambiente Ptolemy II.

52dependências entre os processos disputando os recursos).

3.5.3 Concorrência

A concorrência é uma característica básica de qualquer sistema embutido. Todas asespecificações que foram criadas nesse trabalho utilizam concorrência de forma implícita, uma vez quetodos os MoCs empregados são concorrentes. Entretanto, é bastante importante testar a captura de umalgoritmo concorrente, ou seja, utilizar essa primitiva de maneira explícita. Podemos mencionar ocálculo da integral de uma função f(x) no intervalo [a,b] utilizando a regra do trapézio14, dada pelafórmula: n

Σ (f(xi) + f(xi − 1)) * h/2 i = 1

Nessa fórmula, o intervalo [a,b] é dividido em n intervalos de tamanho h. A concorrência está nofato que o cálculo do valor nos n intervalos pode ser feita de forma independente, propiciando umparalelismo trivial.

3.5.4 Preempção

A primitiva comportamental de preempção é a interrupção de um cálculo ou tarefa para o iníciode outra tarefa, quando uma determinada condição for verdadeira. Esse tipo de primitiva é fundamentalpara a captura de sistemas a serem implementados em hardware [GUP97]. Um exemplo simples dessetipo de primitiva é a reinicialização do sistema. A figura 3.32 apresenta um trecho de código15 nalinguagem Esterel para exemplificar essa situação.

1− modul e ABRO:2− i nput A, B, R;3− out put O;4− l oop5− [ awai t A | | awai t B ] ;6− emi t O;7− each R8− end modul e

Figura 3.32 − Um exemplo para a primitiva de preempção.

A linha 1 declara um novo módulo do sistema (ator), e os portos de entrada e saída sãodeclarados nas linhas 2 e 3. O corpo do sistema é constituído por um laço infinito (linhas 4 a 7) queespera em paralelo por dois eventos (linha 5), um no porto A e outro no porto B, para em seguida gerarum novo evento no porto O (linha 6). Em seguida, o sistema espera por um sinal no porto R. Caso,durante a espera dos eventos nos portos A e B, ocorra um evento no porto R, o laço é reinicializado. Afigura 3.33 apresenta uma máquina de estados de Mealy que descreve o comportamento do código dafigura 3.32.

14 Esse exemplo foi retirado de [ARV82].15 Esse exemplo foi extraído de [BER98].

53

Figura 3.33 − Máquina de Mealy para o código da figura 3.32.

3.5.5 Recursão

A recursão é a especificação de uma função com base nela mesma. Embora seja sempre possíveltransformar um processo recursivo em uma iteração, essa primitiva é relevante pois torna a especificaçãode uma função mais concisa e simples. Dentre inúmeros exemplos, temos o cálculo da sequência deFibonacci como um possível toy benchamark. Outro possível exemplo, este mais significativo, é oalgoritmo da transformada discreta de Fourier, que pode ser descrito de forma recursiva [LEE95].

3.6 Discussão

O principal objetivo desse trabalho é avaliar a eficiência de diferentes modelos computacionaispara representar e validar um sistema digital. Para alcançar tal objetivo, fundamentamos nossametodologia na definição de primitivas comportamentais e no estudo da eficiência dos diferentes MoCspara representá−las.

A partir das características semânticas de cada modelo computacional e do estudo das trêsprimitivas comportamentais descritas nas seções 3.2, 3.3 e 3.4, podemos obter as seguintes conclusões:

SDF:

Esse MoC foi desenvolvido visando a captura eficiente de algoritmos para processamento digitalde sinais. Esses algoritmos são caracterizados pela transformação de um fluxo (stream) de dados atravésde várias operações matemáticas. Isso justifica a escolha da semântica data flow. As três primeirasprimitivas que analisamos comprovaram essa observação.

No caso da primeira e da terceira primitivas, uma descrição eficiente pôde ser efetuada, poisambas as primitivas envolvem a transformação de uma seqüência de dados. A captura da primeiraprimitiva foi extremamente simples, pois se trata de um grafo homogêneo. A terceira primitiva demandao uso de diferentes taxas de amostragem, todos elas constantes. Entretanto, a terceira primitiva expôsuma situação relevante: como as taxas de amostragem devem ser valores inteiros, é possível que umaespecificação apresente taxas com valores altos, como no caso da figura 3.22. Isso implica diretamenteno tamanho necessário para cada fila de comunicação, isto é, na quantidade necessária de memória. Aalternativa seria utilizar uma especificação que produza valores repetidos nos portos com uma taxa deconsumo menor, como foi feito na especificação da figura 3.20.

A fraqueza do modelo SDF foi demostrada na captura da segunda primitiva, que envolvia oativamento de um ator condicionado ao resultado de outro ator. Neste caso, não foi possível criar umaespecificação satisfatória. Utilizamos o recurso de função high−order para obter uma especificaçãoválida. Isso já era previsível, pois o MoC SDF necessita que um ator seja sempre ativado pelo menosuma vez a cada iteração.

A partir desses resultados, podemos concluir que é favorável utilizar o MoC SDF quando:

RR

RAB/O

A

B

B

A

54

� desejamos capturar um sistema transformacional, em que as taxas de amostragem sãoconhecidas a priori e constantes;� é imprescindível que características da execução sejam conhecidas a priori(escalonamento estático).

É importante notar que a utilização de composição de atores pode solucionar ou gerar problemaspara a captura de uma especificação no MoC SDF. Isto ocorre porque esse MoC não preserva suaspropriedades através da composição. A segunda primitiva pode ser utilizada como exemplo: acomposição dos atores Cte1, Cte2, Coef, e Mux em um único ator permite a criação de uma especificaçãoválida.

DDF:

O modelo DDF procura eliminar as limitações presentes no MoC SDF, permitindo variação dastaxas de amostragem. A primeira e a terceira primitivas foram capturadas com sucesso, com as mesmasespecificações utilizadas para o MoC SDF. Neste caso, é mais vantajoso utilizar o MoC SDF, devido aoescalonamento estático.

A captura da segunda primitiva exigiu a utilização das características específicas do modelo.Duas especificações válidas foram criadas, mais eficientes com relação ao MoC SDF. Entretanto,pudemos demonstrar que a característica de leitura bloqueante, presente em modelos data flow,atrapalhou a obtenção de uma especificação totalmente satisfatória.

Desta forma, podemos concluir que o modelo DDF deve ser usado principalmente para capturarsistemas transformacionais que não possam ser descritos pelo modelo SDF.

PN:

O modelo PN é bastante similar ao modelo DDF. A principal diferença está no fato do modeloDDF utilizar ativamentos atômicos e o modelo PN processos concorrentes. A vantagem da solução domodelo DDF é que o overhead devido ao escalonamento de processos é eliminado. Em contrapartida, émais simples descrever o código fonte de um ator no MoC PN, pois não é necessário manter informaçõesreferentes ao estado do ator (vide 3.4.2.2 e 3.4.2.3).

Podemos afirmar que esse MoC deve ser empregado nas mesmas situações que o MoC DDF.Determinar qual é mais vantajoso irá depender da implementação da especificação.

CSP:

Para as três primitivas que estudamos, o modelo CSP utilizou as mesmas especificações que omodelo PN. Na captura da segunda primitiva, foi feita uma tentativa de utilizar o rendezvous nãodeterminístico, mas a especificação resultante não era válida.

Não foi possível chegar à conclusões específicas para esse modelo. Devido à comunicação porrendezvous, esse modelo apresenta as mesmas limitações que os modelos data flow. Um ponto negativodo modelo CSP são as situações de deadlock. Embora seja possível detectar tais situações [FDR], essatarefa demanda algum esforço, o que não ocorre com outros modelos.

SR:

O modelo SR foi bastante eficiente na captura das três primitivas, inclusive na primitiva dedesvio condicional. Isso se deve à flexibilidade do modelo em permitir a ausência/indeterminação deeventos em alguns sinais. O escalonamento estático é outro ponto favorável desse modelo.

Podemos enumerar três pontos desfavoráveis desse modelo. Primeiramente, embora seja possível[EDW97], as conexões entre atores não apresentam armazenamento de dados. Desta forma, sistemas

55transformacionais com taxas de amostragem não unitárias não podem ser capturados eficientemente poresse modelo. O segundo ponto desfavorável desse modelo pode ser observado nas figuras 3.25 e 3.2616: anão utilização de leitura bloqueante torna o código fonte de um ator um pouco mais complexo. Ahipótese de sincronismo também pode ser um ponto problemático do modelo, caso a implementação dosistema não seja capaz de satisfaze−la.

A menos das observações acima, o MoC SR pode ser empregado na captura de diversossistemas. Sistemas reativos, caracterizados pela operação baseada na iteração com o ambiente através deeventos, são forte candidatos, uma vez que os modelos data flow e CSP são menos eficientes (videprimitiva comportamental de desvio condicional).

DE:

Assim como o modelo SR, todas as primitivas foram capturadas eficientemente no modelo DE.Esse modelo também permite a ausência/indeterminação de eventos em alguns sinais. Ao contrário doMoC SR, sistemas transformacionais podem ser capturados satisfatoriamente por esse modelo, poisquando múltiplos eventos com um mesmo timestamp são enviados para um porto, uma fila é utilizada.

O modelo DE é o mais flexível dos seis modelos que estudamos. É possível utilizar esse modelopara simular a semântica dos outros cinco modelos. Desta forma, para as três primitivas que estudamos,esse modelo se mostrou o mais adequado.

16 O código da figura 3.26 está no MoC DE mas é basicamente o mesmo para o MoC SR.

56

Capítulo 4

Estudo de Caso

4.1 Introdução

Neste capítulo apresentaremos o desenvolvimento de especificações executáveis para capturar ocomportamento de um subconjunto de um modem ADSL [ADSL]. Ao contrário dos exemplos docapítulo 3, o sistema em questão representa uma aplicação real e o desenvolvimento foi feito a partir daespecificação em língua inglesa para a tecnologia. Inicialmente iremos apresentar um resumo dessaespecificação, mencionando apenas a funcionalidade que foi capturada. Em seguida, a criação dasespecificações executáveis no ambiente Ptolemy será detalhada. Concluiremos esse capítulo comcomentários à respeito do estudo de caso.

4.2 O Modem ADSL

4.2.1 Introdução

Asymmetric Digital Subscriber Line (ADSL) é uma tecnologia de modem baseada no uso demodulação Discrete Multitone (DMT), utilizada para atingir altas taxas de transmissão de dados emlinhas telefônicas convencionais. O princípio básico da modulação DMT é dividir a banda disponível emum grande número de subcanais (tons). A modulação é capaz de alocar uma certa quantidade de dados deforma que cada subcanal seja utilizado ao máximo. Caso algum subcanal não apresente uma qualidade detransmissão razoável, ele não é utilizado. A figura 4.1 apresenta o modelo de referência para sistemasADSL, destacando os principais blocos.

Figura 4.1 − Modelo de referência de sistemas ADSL

Os dados provenientes da rede broadband são recebidos pelo modem ATU−C (ADSLTransceiver Unit − Central Office) e convertidos em sinais analógicos. Os sinais analógicos sãotransmitidos conjuntamente com sinais de telefone convencional (POTS), até o modem remoto (ATU−R). O modem ATU−C também recebe e decodifica dados provenientes do modem remoto. A figura 4.2mostra o diagrama de blocos funcionais do transmissor do modem ATU−C.

ATU−C ATU−R

SplitterSplitter

Telefone ouModem

Voiceband

RedeCustomer

RedeNarrowband

RedeBroadband

V−C T−R

U−C2 U−R2

57

Figura 4.2 − Diagrama funcional do transmissor do modem ATU−C.

Até quatro canais seriais simplex (ASx) e até três canais seriais duplex (LSx) são sincronizados àuma taxa de transmissão de 4 kHz. Os dados provenientes dos canais seriais são multiplexados em doiscaminhos de dados diferentes: fast e interleaved. Um código de redundância cíclica (CRC),embaralhamento e uma codificação do tipo forward error correction (FEC) devem ser aplicados aosdados dos dois buffers separadamente. Os dados do buffer interleaved devem então ser submetidos àuma função de intercalação. Em seguida, dados provenientes dos dois buffers devem passar por umafunção de ordenamento de tons e formar um frame. Esse frame é enviado à um módulo de codificação deconstelações. Após essa codificação, o frame deve ser modulado em um símbolo DMT para finalmentegerar um sinal analógico pronto para a transmissão.

Devido à adição de bytes redundantes pelo módulo FEC e à função de intercalamento, os pacotesde dados apresentam estruturas diferentes nos três pontos de referência indicados na figura 4.2. Os trêspontos de referência são:

� A (mux data frame): nesse ponto os dados já foram multiplexados, sincronizados e o CRC foiadicionado. Mux data frames devem ser gerados à uma taxa média de 4.0 kHz;

� B (FEC output data frame): nesse ponto foi adicionado os bytes referentes à correção de erros;

� C (constellation encoder input data frame): nesse ponto um frame é a entrada para ocodificador de constelações.

O transmissor do modem ATU−R é similar ao do ATU−C, exceto pela ausência dos canaisseriais simplex (ASx). Isso implica que uma quantidade menor de dados podem ser enviados por essetransmissor, e seu respectivo data path é mais simples. Por exemplo, o bloco IDFT do modem ATU−Cpossui 256 entradas, enquanto o do modem ATU−R 64.

4.2.2 Framing

O modem ADSL utiliza a estrutura de superframe apresentada na figura 4.3. Cada superframe écomposto por 68 ADSL frames, codificados e modulados em símbolos DMT. A nível do padrão de bits,a taxa de transmissão de um símbolo DMT é de 4000 baud (período = 250 µs). Devido ao símbolo desincronismo introduzido ao final de cada superframe, a taxa real de dados transmitidos é de 68/69 * 4000baud. O símbolo de sincronização é utilizado para recuperar o posicionamento dos frames quandoocorrerem micro−interrupções na transmissão. Do contrário, seria necessário reinicializar os modems.

ControleMux/Sync

CRCF

CRCI

Scram & FEC

Scram & FEC

Interleaver

Ordenamento deTons

Codificadorde

ConstelaçõesIDFT

Buffer Paralelo/Serial

DAC e geração do

sinal

AS0

AS1AS2AS3LS0LS1LS2

V−C

U−C2

Amux data frame

BFEC data frame

CCE input frame

Zi

i = 0 to 255

xn

n = 0 to 511

58

Figure 4.3 − A estrutura de superframe e frame do modem ADSL.

O byte denominado de fast do frame para os dados provenientes do buffer fast contém oresultado do cálculo do CRC ou informações de controle. O frame possui um byte similar para os dadosprovenientes do interleaved buffer, denominado de synchronization bytes Cada canal serial ASx ou LSxé associado à um dos dois buffers de dados, durante a inicialização do modem.

A estrutura de superframe e frame não utiliza um padrão de bits para determinar os intervalosentre cada frame. Essa função é feita por um prefixo cíclico introduzido no símbolo DMT pelomodulador. Os intervalos entre superframes são determinados pelo símbolo de sincronismo, tambémintroduzido pelo modulador, e que não carrega dados do usuário.

Figura 4.4 − A estrutura de um frame de dados do buffer fast.

A figura 4.4 apresenta a estrutura do frame com dados extraídos do buffer fast. No ponto dereferência A (mux data frame), o frame construído a partir dos dados do buffer fast deve sempre conterpelo menos o byte fast. Este pode ser seguido por BF((ASx) byte para cada canal ASx e por BF(LSx) paracada canal LSx. Caso algum dos valores BF(ASx) seja maior que zero, então um byte AEX e um byteLEX devem ser incluídos após os dados do último canal LSx. Caso algum dos valores Bf(LSx) sejamaior que zero, então apenas o byte LEX deve ser incluído. O frame no ponto de referência B é obtidoacrescentando−se ao mux data frame RF bytes, utilizados para detecção e correção de erros.

Frame 0 Frame 1 Frame 2 Frame 34 Frame 35 Frame 66 Frame 67 Sync frame

Byte fast Bytes de dados FEC

Buffer fast Buffer interleaved

Buffer de frames de dadosr (68/68 x 250 µsec )

Bytes de dados

Superframe (17 µsec)

1 byteK

F bytes R

F bytes

NF bytes N

I bytes

Bytefast AS0 AS1 AS2 AS3 LS0 LS1 LS2 AEX LEX FEC bytes

NF bytes

KF bytes

1 byteB

F (AS0)

bytes

BF (AS1)

bytes

BF (AS2)

bytes

BF (AS3)

bytes

BF (LS0)

bytes

BF (LS1)

bytes

BF (LS2)

bytes

AF

bytes

LF

bytes

RF

bytes

59

Figura 4.5 − A estrutura de um frame de dados do buffer interleaved.

A figura 4.5 ilustra a estrutura de um frame construído a partir de dados do buffer interleaved.No ponto de referência A, o frame da figura 4.5 deve conter pelo menos o byte de sincronização. Orestante desse frame é construído de maneira similar ao caso do buffer fast, substituindo BF por BI. Otamanho de um mux data frame é de K I bytes.

Para os dados do buffer interleaved, o codificador FEC deve obter S mux data frames e adicionarRI FEC bytes de redundância para produzir uma palavra código. Esta palavra possui comprimento igual àN − FECI = S x K I + RI bytes. Os frames resultantes devem conter NI = N −FECI/S bytes, onde NI é umnúmero inteiro. Quando S > 1, para S frames em uma palavra código FEC, o frame resultante (ponto dereferência B) deve conter mais que um mux data frame em todos os casos a menos do último frame. Esseframe deve conter os RI bytes de redundância, além de uma fração de mux data frame

4.2.3 Código de Redundância Cíclica

O principio para o código de redundância cíclica (CRC) é interpretar os dados a seremtransmitidos como uma palavra binária M . Essa palavra é então dividida por uma chave k (polinômiogerador), conhecido pelo transmissor e receptor. O resto da divisão constitui a ¨palavra de verificação¨para o conjunto de dados. O transmissor deve enviar os dados juntamente com a palavra de verificaçãopara que o receptor possa refazer a divisão e comparar com a palavra de verificação recebida.

Para um modem ADSL, o código de redundância cíclica é aplicado para os dados do buffer fast einterleaved, independentemente. A palavras de verificação obtidas para cada superframe devem serenviadas no primeiro frame do próximo superframe. O bits cobertos pela palavra de verificação incluem:

� buffer fast:� frame 0 : bytes ASx (x = 0, 1, 2, 3), bytes LSx (x = 0, 1, 2) e qualquer byte AEX e LEX;� todos os outros frames: byte fast, bytes ASx (x = 0, 1, 2, 3), bytes LSx (x = 0, 1, 2) equalquer byte AEX e LEX.

� buffer interleaved� frame 0: bytes ASx (x = 0, 1, 2, 3), bytes LSx(x = 0, 1, 2) e qualquer byte AEX e LEX;� todos os outros frames: byte sync, bytes ASx (x = 0, 1, 2,3), bytes LSx (x = 0, 1, 2) equalquer byte AEX e LEX.

O polinômio gerador utilizado para modems ADSL é: : x8 + x4 + x3 + x2 + 1.

ByteSync AS0 AS1 AS2 AS3 LS0 LS1 LS2 AEX LEX

KI bytes

1 byte BI (AS0)

bytes

BI (AS1)

bytes

BI (AS2)

bytes

BI (AS3)

bytes

BI (LS0)

bytes

BI (LS1)

bytes

BI (LS2)

bytes

AI

bytes

LI

bytes

Mux data frame 0 Mux data frame 1 Mux data frame S −1

FEC bytes

FEC data frame 0 FEC data frame 1 FEC data frame S − 1

KI bytes K

I bytes K

I bytes R

I bytes

NI bytes N

I bytes N

I bytes

604.2.4 Embaralhamento

Os dados presentes nos buffers fast e interleaved devem ser embaralhados bit a bitseparadamente utilizando a seguinte fórmula:

dn’ = dn ⊕ dn−18’⊕ dn−23’

,onde dn é a n−éssima saída do buffer fast ou interleaved e dn’ é a n−éssima saída docorrespondente embaralhador. O embaralhamento é feito no nível de bits, independentemente do símbolode sincronismo e da estrutura dos frames.

4.2.5 Correção de Erros

A correção de erros do tipo Forward Error Correction (FEC) é utilizada para assegurar odesempenho da transmissão. A correção é baseada no algoritmo de codificação Reed−Solomon. O tipode código empregado por esse algoritmo é denominado de código de bloco cíclico, pois utiliza bitsredundantes adicionados ao final dos dados.

O algoritmo RS particiona os dados em símbolos contendo m bits. Cada símbolo é processadocomo sendo uma unidade pelo codificador e pelo decodificador. O código RS pode ser descrito pelo par(n, k), onde k é o tamanho da palavra de dados não codificada e n é o tamanho da palavra de dados comos bits redundantes. Os (n − k) símbolos redundantes são chamados de símbolos de verificação deparidade. O código RS deve satisfazer: n ≤ 2m − 1 e n − k ≥ 2t, onde t é a quantidade possível desímbolos corrigíveis.

Para o modem ADSL, m é fixo em 8 bits. O valor de n e k irá depender do número de bytestransmitidos por cada canal serial ASx e LSx. O número de bytes de paridade por cada palavra é limitadoentre 0 e 16.

4.2.6 Interleaver

A maioria dos algoritmos utilizados para correção de erros são otimizados para situações onde oserros aparecem randomicamente na palavra de dados. Interleaving é uma técnica utilizada para rearranjaros bits da palavra de dados tal que os erros apareçam em posições randômicas e distribuídos por váriaspalavras de dados, ao invés de poucas palavras.

Para o modem ADSL, os frames FEC devem ser sofrer um interleaving convolucional, à umadada profundidade. O processo de interleaving irá atrasar cada byte do frame FEC por um tempodiferente, tal que o codificador de constelações recebe bytes pertencentes a vários frames diferentes. Aregra utilizada para o interleaving é:

Cada um dos N bytes B0, B1, Bn−1 de uma palavra código RSé atrasada por uma quantidade detempo que varia linearmente com a posição do byte na palavra. Desta forma, o byte Bi é atrasado por(D−1) * i bytes, onde D é a profundidade do interleaving.

Para modems ADSL, A profundidade de interleaving deve ser uma potência de dois menor ouigual a 64.

4.2.7 Ordenamento de Tons

Devido as características do sinal ADSL e do conversor digital/analógico, as maioresprobabilidades de erros de transmissão estão associados aos subcanais com maior número de bits. Dessaforma, para que o sistema de codificação FEC consiga eficientemente corrigir tais erros, é mais favorávelque os tons com maior número de bits recebam dados provenientes do buffer interleaved.

61O ordenamento de tons do modem ADSL associa os primeiros BF bytes para os tons com menor

número de bits e os restantes BI bytes são associados aos tons restantes.

4.2.8 Codificação de Constelações

Codificação de constelações é um processo que recebe uma palavra de bits e transforma−a emum número complexo. Para um dado subcanal ADSL, o codificador de constelações seleciona um par denúmero inteiros ímpares (X, Y) a partir de um mapa numérico, baseado no vetor b de bits (vb−1, vb−2, ...,v1, vb−0).

Para uma palavra b com comprimento par, os valores inteiros X e Y do ponto da constelação édeterminado pela regra: os números inteiros ímpares X e Y são formados tomando a representaçãocomplemento de dois dos vetores vb−1, vb−3, ..., v1, 1 e vb−2, vb−4, ...., v0, 1, respectivamente.

Quando o comprimento de b for igual a 3, a constelação da figura 4.6 é utilizada.

Figura 4.6 − Constelação quando o comprimento de b for igual à 3.

Quando o comprimento for ímpar maior que 3, o ponto da constelação é determinado da seguintemaneira: os dois bits mais significativos de X e de Y são determinados com base nos 5 bits maissignificativos de b. Seja c = (b+1)/2, então X e Y tomam a representação complemento de dois dosvetores Xc, Xc−1, vb−4, vb−6, ...., v3, v1, 1 e Yc, Yc−1, vb−5, vb−7, vb−9, ..., v2, v0, 1, respectivamente. A relaçãoentre Xc, Xc−1, Yc, Yc−1 e vb−1, vb−2, .., vb−5 é dada por uma tabela presente no padrão ADSL.

4.2.9 Modulação

Após o codificador de constelações, os dados são modulados através da transformada discretainversa de Fourier (IDFT). Essa operação define uma relação entre os 512 valores reais xk e 256 númeroscomplexos Zi. Como o codificador de constelação gera apenas 255 valores complexos, a fim de obter os512 valores reais xk, o vetor Z deve ser aumentado em 256 valores, tal que:

Zi = conj(Z512 − i) para i = 257 to 511.

4.2.10 A Inicialização

A inicialização é o processo utilizado para estabelecer uma conexão entre o par de modemsATU−C e ATU−R. Para que a qualidade da transmissão e a quantidade de dados transmitidos sejamaximizada, o transmissor/receptor ADSL deve determinar certos parâmetros do canal de conexão eestabelecer as características de processamento de cada modem. A inicialização é composta por quatropartes: ativação e acknowledgment, treinamento do transmissor/receptor, análise do canal e troca de

Y

X0

1

2

3

4

5

6

7

62informações.

A determinação das características do canal de comunicação e o estabelecimento dascaracterísticas da transmissão exigem que cada transmissor/receptor gere, e responda apropriadamente,um conjunto de sinais pré−definidos e temporizados. Regras são definidas determinando o início e fimde cada um desses sinais. Essas regras são descritas através da definição dos estados de inicialização dotransmissor/receptor, e através da definição dos sinais que eles irão gerar.

Devido a complexidade do procedimento de inicialização, descreveremos somente a partereferente a ativação e acknowledgment. A seqüência de estados/sinais para a fase de ativação eacknowledgment é apresentada na figura 4.7.

Figura 4.7 − Ativação e acknowledgment.

Os sinais para o modem ATU−C são:

� C−QUIET1: após o power−up e um auto teste opcional, o modem ATU−C deve entrar noestado C−QUIET1. Quando o modem está no estado C−QUIET1, um comando docontrolador central do modem ou a detecção correta do sinal R−ACT−REQ faz com queocorra uma transição para o estado C−ACT. Para assegurar a compatibilidade entrediferentes implementações do modem, o transmissor ATU−C deve permanecer no estadoC−QUIET1 até que o sinal R−ACT−REQ não seja mais detectado por 128 símbolosconsecutivos;� C−ACT: o modem ATU−C deve transmitir o sinal C−Active a fim de iniciar uma conexãocom o modem ATU−R. Quatro diferentes sinais C−Active são definidos. Isso ocorre paradistinguir diferentes requisições do sistema referentes à temporização da conexão e o uso ounão de um tom piloto. Na implementação que desenvolvemos, utilizamos o sinal C−ACT2,definido por:

0, i ≠ 44, 0 ≤ i ≤ 256Zi = AC−ACT2 , i = 44

AC−ACT2 deve possuir um nível de potência de transmissão igual à −3.65 dBm para osprimeiros 64 símbolos, e ser 24 dB menor para os restantes 64 símbolos. Esse sinal deve sertransmitido por 128 símbolos consecutivos e nenhum prefixo cíclico deve ser adicionado;� C−QUIET2: a função do estado C−QUIET2 é permitir a detecção do sinal R−ACK1 ou R−ACK2, sem a necessidade de treinar o cancelador de echo do modem ATU−C. A duração doestado C−QUIET2 é de 128 símbolos. Após o estado C−QUIET2, o modem ATU−C deveentrar em um de três estados:� C−REVEILLE: caso o ATU−C tenha detectado o sinal R−ACK, ele deverá entrar

no estado C−REIVELLE. Mesmo que o ATU−C venha a detectar o sinal R−ACKem menos que 128 símbolos, este deverá esperar pela duração completa do sinal,mantendo−se no estado C−QUIET2;� C−ACT: caso o modem ATU−C falhe em detectar o sinal R−ACK, e ele não tenha

C−IDLE/C−QUIET1/

C−TONE

C−ACT1−2−3−4 C−QUIET2

R−ACT−REQ/R−QUIET1

R−ACK1−2

ATU−R

ATU−C

63entrado no estado C−ACT por mais que duas vezes, então o ATU−C deve entrar noestado C−ACT;� C−QUIET1: caso o modem ATU−C não detecte o sinal R−ACK após ter entrado noestado C−ACT pela segunda vez, ele deverá retornar ao estado C−QUIET1.

Os sinais para o modem ATU−R são:

� R−ACT−REQ: o sinal R−ACT−REQ é utilizado quando o modem ATU−R deve iniciar oestabelecimento de uma conexão com o modem ATU−C. O sinal R−ACT−REQ étransmitido após o power−up e um auto teste opcional. O sinal R−ACT−REQ é definido talcomo o sinal C−ACT2, mas com i = 8. O modem ATU−R deve permanecer no estado R−ACT−REQ indefinidamente (isto é, transmitir o sinal pela duração de 128 símbolo para emseguida permanecer quieto por 896 símbolos, e então repetir o processo) até que o sinal C−ACT2 seja detectado com sucesso;� R−Acknowledge: esse sinal é transmitido com um acknowledgment da detecção correta dosinal C−ACT2. Três variações do sinal são definidas. Utilizamos nesse estudo a versão R−ACK2. Esse sinal é definido tal qual o sinal C−ACT2, mas com i = 12 e com o nível depotência de transmissão igual à −1.65 dBm para os primeiros 64 símbolos e 20 db menor paraos 64 símbolos restantes.

4.3 As Especificações Executáveis

4.3.1 O Sistema

A figura 4.8 apresenta a topologia do nível hierárquico mais alto da especificação. Neste nívelexistem quatro atores: duas instâncias da especificação do modem (ATU−C e ATU−R) e dois blocosrepresentando o ambiente (rede broadband e customer). As especificações para os modems serãodescritas mais adiante neste texto.

Figura 4.8 − Topologia da especificação do sistema.

Os atores modelando o ambiente são responsáveis por enviar e receber dados para os modemsatravés dos sinais de comunicação serial (ASx e LSx)17. A fim de tornar a especificação mais simples,sem perder a representatividade, implementamos apenas dois sinais (um de cada tipo): AS0 e LS0. Comoa especificação determina que esses sinais estejam sincronizados à uma taxa de 4 kHz, o MoC utilizadodeve ter uma noção de tempo.

Escolhemos o modelo Discrete Event para a captura da especificação do sistema. As razões paratal escolha são a flexibilidade desse MoC e a presença de uma noção de tempo. Também tentamosutilizar o modelo Process Networks, uma vez que a implementação do modelo no ambiente Ptolemypossui uma noção de tempo e pelas características do sistema (a grande quantidade de blocostransformacionais). Entretanto, encontramos diversas situações em que esse modelo não se mostrouadequado. A primeira situação problemática ocorreu quando tentamos criar os atores representando oambiente: devido à semântica de leitura bloqueante, não é possível criar apenas um ator que faça as duasoperações de envio e recebimento de dados. A semântica de leitura bloqueante também foi um empecilhopara a captura da especificação do modem: como não é possível verificar se um porto contém dados, os

17 Os atores modelando o ambiente são utilizados para simular e validar o comportamento do modem.

RedeBroadband ATU−C ATU−R Rede

Customer

Tx

TxRx

RxAS0 AS0

LS0 LS0

DataTx DataRx

64sinais DataTx e DataRx devem ser utilizados para indicar qual é o porto que contém dados. Esses sinaissão dispensáveis na especificação com o MoC DE. A figura 4.9 apresenta um trecho do código do atorBroadBandNet no modelo DE.

1− publ i c c l ass Br oadBandNet ext ends DEAct or {2−3− publ i c TypedI OPor t AS0;4− publ i c TypedI OPor t dat aTx;5− publ i c TypedI OPor t LS0; 6− 7− publ i c Par amet er AS0_Rat e;8− publ i c Par amet er LS0_Rat e;9−10− publ i c Br oadBandNet ( TypedComposi t eAct or cont ai ner , St r i ng name) t hr ows11− NameDupl i cat i onExcept i on, I l l egal Act i onExcept i on {12−13− . . . .14− }15−16− publ i c voi d f i r e( ) t hr ows I l l egal Act i onExcept i on {17−18− i f ( _next Fi r e == get Cur r ent Ti me( ) ) {19− i f ( _next Fi r eAS0 == 0) {20− Obj ect Token ot =21− new Obj ect Token( new I nt eger ( _dat a[ _count er ] ) ) ;22− AS0. br oadcast ( ot ) ;23− dat aTx. br oadcast ( new I nt Token( 0) ) ;24−25− _count er = ( _count er + 1) % _dat a. l engt h;26− _next Fi r eAS0 = 1000. 0 / _AS0_Rat e;27− }28− . . . .29− _next Fi r e( ) ; 30− }31−32− Obj ect Token ot ;33− i nt [ ] t mp = nul l ;34− whi l e( LS0. hasToken( 1) ) {35− ot = ( Obj ect Token) LS0. get ( 1) ;36− t mp = ( i nt [ ] ) ot . get Val ue( ) ;37− f or ( i nt i = 0; i < t mp. l engt h; i ++) {38− _LS0Dat a. i nser t El ement At ( new Byt e( ( byt e) t mp[ i ] ) , _LS0Count er ) ;39− _LS0Count er ++;40− }41− } 42− }43− . . . .44−45− pr i vat e voi d _next Fi r e( ) t hr ows I l l egal Act i onExcept i on {46− 47− doubl e mi n = 1000. 0;48− bool ean sched = f al se;49−50− i f ( _next Fi r eAS0 < mi n) mi n = _next Fi r eAS0;51− i f ( _next Fi r eLS0 < mi n) mi n = _next Fi r eLS0;52−53− i f ( _next Fi r eAS0 − mi n == 0) {54− f i r eAt ( get Cur r ent Ti me( ) + _next Fi r eAS0) ;55− _next Fi r e = get Cur r ent Ti me( ) + _next Fi r eAS0;56− sched = t r ue;57− }58− _next Fi r eAS0 −= mi n;59−60− i f ( ( sched == f al se) && ( _next Fi r eLS0 − mi n == 0) ) {61− f i r eAt ( get Cur r ent Ti me( ) + _next Fi r eLS0) ;62− _next Fi r e = get Cur r ent Ti me( ) + _next Fi r eLS0;63− }64− _next Fi r eLS0 −= mi n;65− }66− . . . .

Figura 4.9 − Trecho de código do ator BroadBandNet no MoC DE.

Dois parâmetros (linhas 7 e 8) são utilizados para indicar a taxa de transmissão de cada sinalserial. Da linha 18 à linha 30 está mostrado o código para a transmissão de dados através do sinal AS0(igual para o sinal LS0). A variável _nextFireAS0 contém o valor do próximo momento em que um novo

65dado deve ser enviado através do sinal AS0. Essa variável é atualizada pelo método _nextFire() (linha 45à 65). Esse método é responsável por escalonar o ativamento futuro do ator, baseado no valor dosparâmetros AS0_Rate e LS0_Rate, utilizando o método fireAt() (linhas 54 e 61).

O trecho de código da linha 32 à linha 41 é utilizado para receber um dado proveniente do sinalLS0. Note que o ator BroadBandNet é ativado por duas condições (e que podem ser simultâneas):quando um novo token é recebido ou quando o instante de tempo indicado em uma das chamadas dométodo fireAt() for alcançado. Não é possível implementar tal comportamento com o modelo PN, bemcomo em qualquer outro modelo data flow.

O ator para a rede customer apresenta uma implementação similar à da figura 4.9. A diferençadesse ator é que apenas o sinal LS0 é utilizado para transmitir dados e ambos os sinais são verificadospara determinar a presença de dados.

4.3.2 Framing

Como mencionado no capítulo 2, o ambiente Ptolemy permite a associação de um tipo de dado àum porto de entrada/saída. Na especificação executável para o modem ADSL, utilizamos amplamente otipo ObjectToken por dois motivos: é possível criar uma especificação mais genérica e próxima daespecificação em linguagem natural, e devido ao menor tempo de execução da especificação.

Duas classes auxiliares implementado a estrutura de framming, descritas no item 4.2.2, foramcriadas: uma para o Mux Data Frame e outra para o Fast Data Frame. Não existe uma classe específicapara o Interleaved Data Frame, pois os dados são misturados após o bloco de Interleaver, sendo vistoapenas como um vetor de bytes. O trecho de código da figura 4.10 apresenta a classe MuxDataFrame.

1− publ i c c l ass MuxDat aFr ame {2− 3− publ i c MuxDat aFr ame( i nt nbAS0, i nt nbAS1, i nt nbAS2, i nt nbAS3, 4− i nt nbLS0, i nt nbLS1, i nt nbLS2) {5−6− _f ast Byt e = 0;7− _AS0 = new i nt [ nbAS0] ;8− . . . . .9− _AEXcond = ( nbAS0 ! = 0) | | ( nbAS1 ! = 0) | | 10− ( nbAS2 ! = 0) | | ( nbAS3 ! = 0) ;11− _AEX = 0;12−13− _LEXcond = _AEXcond | | ( nbLS0 ! = 0) | | 14− ( nbLS1 ! = 0) | | ( nbLS2 ! = 0) ;15− _LEX = 0;16− }17−18− publ i c voi d set AS0Byt e( i nt b, i nt nb) {19− _AS0[ nb] = b;20− } 21− 22− publ i c i nt get AS0Byt e( i nt nb) {23− r et ur n _AS0[ nb] ;24− }25− 26− publ i c i nt [ ] get AS0( ) {27− r et ur n _AS0;28− }29− . . . .30− pr ot ect ed i nt _f ast Byt e;31− pr ot ect ed i nt _AS0[ ] ;32− . . . .33− pr ot ect ed i nt _AEX;34− pr ot ect ed i nt _LEX;35− pr ot ect ed bool ean _AEXcond;36− pr ot ect ed bool ean _LEXcond;37− }

Figura 4.10 − Trecho de código da classe MuxDataFrame.

Da linha 30 à linha 36 estão declaradas as variáveis representando os campos de um mux dataframe. Essas variáveis são inicializadas no construtor (linha 3 à 16), que possui parâmetros indicando aquantidade de bytes por cada canal serial ASx e LSx. As condições para a utilização dos bytes AEX e

66LEX são calculadas nas linhas 9, 10, 13 e 14. A classe MuxDataFrame possui uma série de métodos(linha 18 à linha 27 para o caso do sinal AS0) para acessar e modificar as variáveis internas.

A classe auxiliar para o Fast Data Frame está apresentada na figura 4.11. Trata−se de umaclasses derivada da classe MuxDataFrame (linha 1), adicionando um campo (linha 18) para armazenar ovalor da paridade do frame, além dos métodos utilizados para manipular o novo campo (linhas 10 à 16).

1− publ i c c l ass Fast FECDat aFr ame ext ends MuxDat aFr ame {2−3− publ i c Fast FECDat aFr ame( i nt nbAS0, i nt nbAS1, i nt nbAS2, i nt nbAS3, 4− i nt nbLS0, i nt nbLS1, i nt nbLS2, i nt npar ) {5− 6− super ( nbAS0, nbAS1, nbAS2, nbAS3, nbLS0, nbLS1, nbLS2) ;7− _par i t y = new i nt [ npar ] ;8− }9− . . . . 10− publ i c voi d set Par i t yByt e( i nt b, i nt nb) {11− _par i t y [ nb] = b;12− }13− 14− publ i c i nt get Par i t yByt e( i nt nb) {15− r et ur n _par i t y [ nb] ;16− }17− . . . .18− pr i vat e i nt _par i t y [ ] ;

Figura 4.11 − Trecho de código da classe FastFECDataFrame.

4.3.3 A especificação dos Modems ATU−R e ATU−C

A especificação do sistema da figura 4.8 possui duas instâncias da especificação executável domodem ADSL: uma para o ATU−C e outra para o ATU−R. Ambos os modems são similares: adiferença está no número de sinais seriais e consequentemente, a configuração do data path. Durante orestante desse capítulo, todos os exemplos serão dados com base no modem ATU−C.

A figura 4.12 apresenta a topologia para o modem ATU−C utilizando o MoC DE. Ela écomposta por atores implementando o data path (MuxSyncTx/Rx, CRCTx/Rx, ScramblerTx/Rx,FECTx/Rx, InterleaverTx/Rx, Map, Demap, IDFT, DFT), um ator implementando a máquina de estadospara a inicialização do modem, e um ator gerador de eventos. Descreveremos a seguir a implementaçãode cada um desses atores.

Figura 4.12 − A topologia da especificação para o modem ATU−C. As setas em azul indicam a transmissão dedados e as em vermelho sinais de controle.

4.3.3.1 MuxSyncTx

AS0LS0

DataTxMuxSyncTx CRCTx ScramblerTx FECTx

InterleaverTxMap IDFT

InitializerTimer

Reset

Start

Start

StopEvent

Mode

Tx

MuxSyncRx CRCRx ScramblerRx FECRx

InterleaverRx

DeMap DFTLS0 Rx

Datapath

67

O ator MuxSyncTx é responsável por obter os bytes provenientes dos sinais seriais e construirmux data frames para o caminho de dados utilizando o buffer fast e interleaved. Ele corresponde aobloco Mux/Sync da figura 4.2, embora o sincronismo não tenha sido implementado na especificaçãoexecutável. O porto de entrada Start é utilizado para indicar quando o ator deve iniciar o processamentodos dados provenientes do ambiente. A figura 4.13 apresenta um trecho do código desse ator.

1− . . . .2− publ i c Par amet er AS0Byt es;3− publ i c Par amet er LS0Byt es;4− 5− publ i c Par amet er AS0Map;6− publ i c Par amet er LS0Map;7− 8− publ i c Par amet er S;9−10− . . . .11− 12− publ i c voi d f i r e( ) t hr ows I l l egal Act i onExcept i on {13− 14− i f ( s t ar t . hasToken( 0) ) {15− Bool eanToken bt = ( Bool eanToken) st ar t . get ( 0) ;16− _mode = bt . bool eanVal ue( ) ;17− }18− 19− i f ( _mode) {20− sendDat a( ) ;21− }22− el se {23− i f ( dat aTx. hasToken( 0) ) dat aTx. get ( 0) ;24− i f ( AS0. hasToken( 0) ) AS0. get ( 0) ;25− i f ( LS0. hasToken( 0) ) LS0. get ( 0) ;26− }27− }28− . . . .29− pr i vat e voi d _sendDat a( ) t hr ows I l l egal Act i onExcept i on {30− 31− i f ( ! dat aTx. hasToken( 0) ) r et ur n;32−33− I nt Token i t = ( I nt Token) dat aTx. get ( 0) ;34− swi t ch( i t . i nt Val ue( ) ) {35− case 0: {36− _ot = ( Obj ect Token) AS0. get ( 0) ;37− I nt eger b = ( I nt eger ) _ot . get Val ue( ) ;38− . . . .39− i f ( _AS0Wr ot e == _AS0Byt es) {40− _AS0Wr ot e = 0;41− i f ( _AS0Map) {42− _cur r ent AS0Fr ame = _get Next I nt er Fr ame( _cur r ent AS0Fr ame) ;43− el se {44− _cur r ent AS0Fr ame = _get Next Fast Fr ame( _cur r ent AS0Fr ame) ;45− }46− }47− _cur r ent AS0Fr ame. set AS0Byt e( b. i nt Val ue( ) , _AS0Wr ot e) ;48− _AS0Wr ot e++;49− } br eak;50− . . . .51− }52− _checkFul l Fr ames( ) ;53− }54−55− pr i vat e MuxDat aFr ame _get Next Fast Fr ame( MuxDat aFr ame f r ame) {56− 57− i nt i = _f ast Fr ames. f i r s t I ndexOf ( f r ame) ;58− i f ( i == _f ast Fr ames. s i ze( ) − 1) {59− _mf = _newFast Fr ame( ) ;60− _f ast Fr ames. i nser t Last ( _mf ) ; 61− }62− el se {63− _mf = ( MuxDat aFr ame) _f ast Fr ames. at ( i + 1) ;64− }65− r et ur n _mf ; 66− }67− . . . .68− pr i vat e voi d _checkFul l Fr ames( ) t hr ows I l l egal Act i onExcept i on { 69−

6870− whi l e( t r ue) {71− i f ( _sent Fr ame == 0) {72− _mf = ( MuxDat aFr ame) _f ast Fr ames. at ( 0) ;73− i f ( _cur r ent AS0Fr ame ! = _mf && _cur r ent LS0Fr ame ! = _mf ) {74− _f ast Fr ames. r emoveAt ( 0) ;75− _ot = new Obj ect Token( _mf ) ; 76− out put . br oadcast ( _ot ) ;77− _sent Fr ame = 1;78− 79− i f ( _AS0Map && _LS0Map) {80− _mf = _newFast Fr ame( ) ;81− _f ast Fr ames. i nser t Last ( _mf ) ;82− }83− }84− el se {85− r et ur n;86− }87− }88− el se {89− . . . .90− }91− el se {92− r et ur n;93− }94− }95− i f ( _sent Fr ame > _S) _sent Fr ame = 0;96− }97− }98−99− pr i vat e MuxDat aFr ame _newFast Fr ame( ) { 100− _mf = new MuxDat aFr ame( _AS0Map ? 0 : _AS0Byt es, 0, 0, 0, 101− _LS0Map ? 0 : _LS0Byt es, 0, 0) ;102− r et ur n _mf ;103− }104− . . . .105− pr i vat e bool ean _mode;106− pr i vat e Li nkedLi st _f ast Fr ames;107− pr i vat e Li nkedLi st _i nt er Fr ames;108− pr i vat e MuxDat aFr ame _cur r ent AS0Fr ame;109− pr i vat e i nt _AS0Wr ot e;110− . . . .111− pr i vat e i nt _sent Fr ame;112− pr i vat e Obj ect Token _ot ;113− pr i vat e MuxDat aFr ame _mf ;114− . . . .

Figura 4.13 − Trecho de código do ator MuxSyncTx no MoC DE.

Cinco parâmetros são declarados da linha 2 à linha 8: ?0Bytes indica o número de bytes de cadasinal serial em um mux data frame; ?S0Map determina para qual buffer de dados o respectivo sinal serialestá associado; S é o número de mux data frame por cada interleaved data frame. Esses parâmetrostambém são utilizados por vários outros atores do data path (dos atores MuxSyncTx/Rx até os atoresMap/Demap).

O corpo do método fire() (linha 12 à 27) determina se os dados devem ser processados ou não,dependendo de eventos no porto Start. Esses eventos são gerados pela máquina de estados deinicialização. Durante o começo da execução (etapa de inicialização) a máquina de estados instrui o atorpara descartar os dados recebidos. Uma vez que a inicialização tenha sido concluída, um evento éenviado ao porto Start, indicando o início da transmissão de dados.

O método _sendData() (linha 29 à 53) implementa a funcionalidade do ator. Inicialmente, aexistência de dados nos canais seriais é verificada (linha 31). Caso existam dados, primeiramente elessão lidos (linhas 36 e 37). Em seguida, é verificado se o campo do frame para o buffer de dados dorespectivo sinal serial já está cheio (linha 39 para o sinal AS0). Caso negativo, os dados são armazenadosno mux data frame disponível (linha 69−70 para o sinal AS0, LS0 não é mostrado). Caso positivo, umnovo mux data frame é criado (linhas 40 à 45). Finalmente, o método determina se existe algum muxdata frame que esteja completo (linha 52), isto é, todos os campos referentes aos sinais seriais já estãopreenchidos. Isso é implementado pelo método _checkFullFrames().

4.3.3.2 MuxSyncRx

69Esse ator é bastante simples. Sua única função é obter mux data frames provenientes do ator

CRCRx e enviar os dados aos respectivos sinais seriais.

4.3.3.3 CRCTx

Esse ator obtêm mux data frames e aplica o algoritmo de CRC descrito no item 4.2.3. Énecessário determinar os limites de um superframe, tal que o ator seja capaz se armazenar o valor deCRC calculado no começo do próximo superframe. A figura 4.14 apresenta um trecho do código desseator.

1− . . . .2− publ i c voi d f i r e( ) t hr ows I l l egal Act i onExcept i on {3− 4− Obj ect Token ot = ( Obj ect Token) i nput . get ( 0) ;5− MuxDat aFr ame mf = ( MuxDat aFr ame) ot . get Val ue( ) ;6−7− i f ( _f r ameCount er == 0) {8− i f ( _i t er at i on == 0) {9− _f ast CRC( mf , f al se) ;10− _i t er at i on = 1;11− }12− el se {13− _CRC( 0, _f ast Reg) ;14− mf . set Fast Byt e( _f ast Reg) ;15− _f ast Reg = 0;16− _f ast CRC( mf , t r ue) ;17− }18− }19− el se20− i f ( _f r ameCount er == 1) {21− i f ( _i t er at i on == 1) {22− _i nt er CRC( mf , f al se) ;23− _i t er at i on = 2;24− }25− el se {26− _CRC( 0, _i nt er Reg) ;27− mf . set Fast Byt e( _i nt er Reg) ;28− _i nt er Reg = 0;29− _i nt er CRC( mf , t r ue) ;30− }31− }32− el se {33− i f ( _f r ameCount er % ( _S + 1) == 0) {34− _f ast CRC( mf , t r ue) ;35− }36− el se {37− _i nt er CRC( mf , t r ue) ;38− }39− }40−41− _f r ameCount er ++;42− i f ( _f r ameCount er == ATUC. f r amesPer Super f r ame + 43− ATUC. f r amesPer Super f r ame* _S)44− _f r ameCount er = 0;45−46− ot = new Obj ect Token( mf ) ;47− out put . br oadcast ( ot ) ;48− }49− 50− publ i c voi d i ni t i al i ze( ) t hr ows I l l egal Act i onExcept i on {51− . . . .52− _i t er at i on = 0;53− _f r ameCount er = 0;54− _i nt er Reg = 0;55− _f ast Reg = 0;56− }57− 58− pr i vat e voi d _f ast CRC( MuxDat aFr ame mf , bool ean f i r s t ) {59− i f ( f i r s t ) {60− _f ast Reg = _CRC( mf . get Fast Byt e( ) , _f ast Reg) ;61− }62−63− i f ( ! _AS0Map) {

7064− f or ( i nt i = 0; i < _AS0Byt es; i ++)65− _f ast Reg = _CRC( mf . get AS0Byt e( i ) , _f ast Reg) ;66− }67− . . . .68− i f ( mf . hasAEX( ) ) {69− _f ast Reg = _CRC( mf . get AEXByt e( ) , _f ast Reg) ;70− }71− . . . . .72− }73− 74− pr i vat e i nt _CRC( i nt b, i nt r eg) {75− i nt out ;76− f or ( i nt i = 0; i < 8; i ++) {77− out = r eg & 0x80;78− r eg = ( r eg << 1) | ( ( b >> i ) & 0x01) ;79− i f ( out ! = 0) r eg = r eg ^ _pol y;80− }81− r et ur n r eg;82− }83− . . . .84− pr i vat e i nt _f r ameCount er ;85− pr i vat e i nt _f ast Reg;86− pr i vat e i nt _i nt er Reg;87− pr i vat e f i nal s t at i c i nt _pol y = 0x1d;88− pr i vat e byt e _i t er at i on;89− . . . .

Figura 4.14 − Trecho de código do ator CRCTx.

O trecho de código das linhas 7 à 39 verifica as diferentes condições para o cálculo do CRC. Avariável _frameCounter (linha 84) é utilizada para identificar o início de um novo superframe. Quandoesta variável for igual à zero, significa que o ator esta processando o primeiro frame para o buffer fast.Desta forma, o CRC calculado anteriormente deve ser armazenado (linhas 13 à 16). A mesma situação seaplica ao primeiro frame para o buffer interleaved (linhas 20 à 31). A variável _frameCounter éatualizada nas linhas 41 e 44. A constante ATUC.framesPerSuperframe indica a quantidade de framesem um superframe. Embora o padrão ADSL determine o valor 67 para essa constante, utilizamos umvalor menor a fim de aumentar o desempenho da execução.

O método _fastCRC() (linhas 52 à 72) calcula o CRC correspondente aos dados do buffer fast.Para tal, é aplicado o algoritmo do CRC (linhas 74 à 82) para cada campo do frame. Um método similaré utilizado para os dados do buffer interleaved.

4.3.3.4 CRCRx

A funcionalidade do ator CRCRx é bastante parecida com a de seu irmão transmissor. A únicadiferença é que quando o CRC é calculado, ocorre uma comparação com o valor do CRC recebido. Issoé feito nas linhas 11 à 16 e 29 à 34 do código da figura 4.15, para os dados buffer fast e interleaved,respectivamente.

1− . . . .2− publ i c voi d f i r e( ) t hr ows I l l egal Act i onExcept i on {3− . . . .4− i f ( _f r ameCount er == 0) {5− i f ( _i t er at i on == 0) {6− . . . .7− }8− el se {9− _CRC( 0, _f ast Reg) ;10− i nt check = mf . get Fast Byt e( ) ;11− i f ( ( byt e) check ! = ( byt e) _f ast Reg) {12− Syst em. out . pr i nt l n( " \ t \ t \ t ! ! ATUC−CRCRx : FAST CRC FAI LED ! ! " ) ;13− }14− el se {15− Syst em. out . pr i nt l n( " \ t \ t \ t ## ATUC−CRCRx : FAST CRC OK ##" ) ;16− } 17− _f ast Reg = 0;18− _f ast CRC( mf , t r ue) ;19− }20− }21− el se

7122− i f ( _f r ameCount er == 1) { 23− i f ( _i t er at i on == 1) {24− . . . .25− }26− el se {27− _CRC( 0, _i nt er Reg) ; 28− i nt check = mf . get Fast Byt e( ) ;29− i f ( ( byt e) check ! = ( byt e) _i nt er Reg) {30− Syst em. out . pr i nt l n( " \ t \ t ! ! ATUC−CRCRx: I NTER CRC FAI LED ! ! " ) ;31− }32− el se {33− Syst em. out . pr i nt l n( " \ t \ t ## ATUC−CRCRx: I NTER CRC OK ##" ) ;34− }35− _i nt er Reg = 0;36− _i nt er CRC( mf , t r ue) ;37− }38− }39− el se {40− . . . .41− }42− . . . .43− }44− . . . .

Figura 4.15 − Trecho de código do ator CRCRx.

4.3.3.5 ScramblerTx

Esse ator implementa a função de embaralhamento dos dados a serem transmitidos. A figura4.16 apresenta um trecho de seu código. Inicialmente um novo mux data frame é obtido (linhas 4 e 5) e édeterminado se os dados são destinados ao buffer fast ou interleaved, dependendo do valor da variável_frameCounter. Das linhas 9 à 20 esta implementado o processamento dos dados para o buffer fast.Neste caso, o método _processFast() (linhas 31 à 43) é responsável por embaralhar os dados. Os dadospara o buffer interleaved são transformados de maneira similar. Este ator também pode ser implementadoutilizando qualquer um dos seis MoCs.

1− . . . .2− publ i c voi d f i r e( ) t hr ows I l l egal Act i onExcept i on {3−4− Obj ect Token ot = ( Obj ect Token) i nput . get ( 0) ;5− MuxDat aFr ame mf = ( MuxDat aFr ame) ot . get Val ue( ) ;6− i nt b;7−8− i f ( _f r ameCount er == 0) {9− b = _pr ocessFast ( mf . get Fast Byt e( ) ) ;10− mf . set Fast Byt e( b) ;11−12− i f ( ! _AS0Map) {13− f or ( i nt i = 0; i < _AS0Byt es; i ++) {14− b = _pr ocessFast ( mf . get AS0Byt e( i ) ) ;15− mf . set AS0Byt e( b, i ) ;16− }16− }17− . . . .18− i f ( mf . hasAEX( ) ) {19− b = _pr ocessFast ( mf . get AEXByt e( ) ) ;19− mf . set AEXByt e( b) ;20− }21− . . . .22− }23− el se {24− . . . .25− }26− _f r ameCount er ++;27− i f ( _f r ameCount er == 1 + _S) _f r ameCount er = 0;28− . . . . .29− }30− . . . . 31− pr i vat e i nt _pr ocessFast ( i nt b) {32− i nt r et = 0;33− i nt b1, b2, b3;34−35− f or ( i nt i = 0; i < 8; i ++) {36− b1 = ( _f ast Reg >> 23) & 0x01;

7237− b2 = ( _f ast Reg >> 18) & 0x01;38− b3 = ( b >> i ) & 0x01;39− r et | = ( ( b1 ^ b2 ^ b3) << i ) ;40− _f ast Reg = ( _f ast Reg << 1) | ( b1 ^ b2 ^ b3) ;41− }42− r et ur n r et ;43− } 44− . . . . 45− pr i vat e i nt _f ast Reg;46− pr i vat e i nt _i nt er Reg;47− pr i vat e i nt _f r ameCount er ;48− . . . .

Figura 4.16 − Trecho de código do ator ScramblerTx.

4.3.3.6 ScramblerRx

Esse ator implementa o desembaralhamento e seu comportamento é idêntico ao do atorScramblerTx.

4.3.3.7 FECTx

Esse ator é responsável por calcular os bytes de paridade com base no algoritmo RS, conformemencionado no item 4.2.5. A figura 4.17 apresenta parte do código desse ator. Novamente, a variável_frameCounter é utilizada para determinar quando o mux data frame recebido está alocado no bufferfast ou interleaved. Dois novos parâmetros foram introduzidos, _parityFast e _parityInter (linha 2).Esses parâmetros especificam o número de bytes de paridade que devem ser utilizados para os dados dobuffer fast e interleaved.

1− . . . .2− publ i c Par amet er par i t yFast , par i t y I nt er ;3− . . . .4− publ i c voi d f i r e( ) t hr ows I l l egal Act i onExcept i on { 5−6− i f ( _f r ameCount er == 0) {7− Obj ect Token ot = ( Obj ect Token) i nput . get ( 0) ;8− MuxDat aFr ame mf = ( MuxDat aFr ame) ot . get Val ue( ) ;9− i nt [ ] dat a = mf . get AsAr r ay( ) ;10− i f ( _nnFast ! = _kkFast ) { 11− i nt [ ] par i t y = _r sEncode( dat a, _nnFast , _kkFast , Gg_pol yFast ) ;12− Fast FECDat aFr ame df = _newFast FECDat aFr ame( dat a, par i t y) ;13− f ast . send( 0, new Obj ect Token( df ) ) ;14− }15− el se {16− ot = new Obj ect Token( _newFast FECDat aFr ame( dat a, new i nt [ 0] ) ) ;17− f ast . send( 0, ot ) ;18− }19− _f r ameCount er = 1;20− }21− el se22− i f ( _f r ameCount er < _S + 1) {23− Obj ect Token ot = ( Obj ect Token) i nput . get ( 0) ;24− MuxDat aFr ame mf = ( MuxDat aFr ame) ot . get Val ue( ) ;25− i nt [ ] w = mf . get AsAr r ay( ) ;26− f or ( i nt j = 0; j < w. l engt h; j ++) {27− _i nt er dat a[ _i nt er count ] = w[ j ] ;28− _i nt er count ++;29− }30− _f r ameCount er ++;31− }32− el se {33− i f ( _nnI nt er ! = _kkI nt er ) {34− i nt [ ] par i t y = _r sEncode( _i nt er dat a, _nnI nt er , 35− _kkI nt er , Gg_pol yI nt er ) ;36− f or ( i nt i = 0; i < ( _nnI nt er − _kkI nt er ) ; i ++) 37− _i nt er dat a[ _kkI nt er + i ] = par i t y [ i ] ;38− }39− i nt er . br oadcast ( new Obj ect Token( _i nt er dat a) ) ;40− _f r ameCount er = 0;41− _i nt er count = 0;42− }

7343− } 44− 45− publ i c voi d i ni t i al i ze( ) t hr ows I l l egal Act i onExcept i on {46− . . . .47− _kkFast = _kkI nt er = 1;48− i f ( ! _AS0Map) {49− _kkFast += _AS0Byt es;50− }51− el se {52− _kkI nt er += _AS0Byt es;53− }54− i f ( ! _LS0Map) {55− _kkFast += _LS0Byt es;56− }57− el se {58− _kkI nt er += _LS0Byt es;59− }60− i f ( ! _AS0Map / * | | ! _AS1Map | | . . . * / ) {61− _kkFast += 1;62− }63− i f ( ! _AS0Map | | ! _LS0Map) {64− _kkFast += 1;65− }66− i f ( _AS0Map) {67− _kkI nt er += 1;68− }69− i f ( _AS0Map | | _LS0Map) {70− _kkI nt er += 1;71− }72− _kkI nt er * = _S;73−74− i t = ( I nt Token) par i t yFast . get Token( ) ;75− _nnFast = _kkFast + i t . i nt Val ue( ) ;76−77− i t = ( I nt Token) par i t y I nt er . get Token( ) ;78− _nnI nt er = _kkI nt er + i t . i nt Val ue( ) ;79− . . . .80− } 81− . . . . 82− pr i vat e i nt _f r ameCount er ;83− pr i vat e i nt _i nt er dat a[ ] ;84− pr i vat e i nt _i nt er count ;85−86− pr i vat e i nt _nnFast , _kkFast ;87− pr i vat e i nt _nnI nt er , _kkI nt er ;88− . . . .

Figura 4.17 − Trecho de código do ator FECTx.

Os dados destinados ao buffer fast são processados nas linhas 7 à 19. Os dados são obtidos domux data frame (linhas 7 à 9) e utilizados pelo método _rsEncode() (linha 11) para gerar os bytes deparidade. Em seguida, um novo FastFECDataFrame é construído (linha 12) e enviado (linha 13) aopróximo ator.

Os dados destinados ao buffer interleaved são processados nas linhas 22 à 42. Como os dados deum frame destinados à esse buffer podem estar divididos em vários mux data frame (parâmetro S), o atorFECTx deve primeiramente obter a quantidade necessária de mux data frame. Isto está implementadoentre as linhas 22 e 30. Uma vez que todos os dados sejam obtidos, os bytes de paridade são calculados(linha 34 e 35) e um novo frame é enviado (linha 39).

O método initialize() (linhas 45 à 80) calcula, entre outras informações, o valor das variáveis_nnFast, _kkFast, _nnInter e_kkInter. As variáveis _kkFast e _kkInter armazenam o número de dadosdestinados ao buffer fast e interleaved em um frame. As variáveis _nnFast e _nnInter armazenam onúmero total de bytes.

4.3.3.8 FECRx

Esse ator é responsável por receber frames do buffer fast e interleaved e verificar a integridadedos dados baseado no algoritmo RS. A figura 4.18 apresenta um trecho do código desse ator.

1− . . . .

742− publ i c voi d f i r e( ) t hr ows I l l egal Act i onExcept i on {3−4− Obj ect Token ot ;5− i f ( _f r ame == 0 && f ast . hasToken( 0) ) { 6− ot = ( Obj ect Token) f ast . get ( 0) ;7− Fast FECDat aFr ame f ast f = ( Fast FECDat aFr ame) ot . get Val ue( ) ;8− i nt [ ] dat a = f ast f . get AsAr r ay( ) ;9− i f ( _nnFast ! = _kkFast ) {10− i f ( _syndr omeFast ( dat a) == −1) {11− Syst em. out . pr i nt l n( " ATUC−FECRx : Er r or s wi t h f ast dat a. . . " +12− " t r y i ng t o f i x . . . . " ) ;13− dat a = _r sdecode( dat a, _synFast , _nnFast , _kkFast ) ;14− }15− el se {16− Syst em. out . pr i nt l n( " ATUC−FECRx : No er r or s wi t h f ast dat a" ) ;17− }18− }19− MuxDat aFr ame mf = _newMuxDat aFr ame( dat a) ;20− out put . send( 0, new Obj ect Token( mf ) ) ;21− _f r ame = 1;22− }23− i f ( _f r ame == 1 && i nt er . hasToken( 0) ) {24− ot = ( Obj ect Token) i nt er . get ( 0) ;25− i nt [ ] dat a = ( i nt [ ] ) ot . get Val ue( ) ;26− i f ( _nnI nt er ! = _kkI nt er ) {27− i f ( _syndr omeI nt er ( dat a) == −1) {28− Syst em. out . pr i nt l n( " ATUC−FECRx : Er r or s wi t h i nt er l eaved " +29− " dat a. . . t r y i ng t o f i x . . . . " ) ;30− dat a = _r sdecode( dat a, _synI nt er , _nnI nt er , _kkI nt er ) ;31− }32− el se {33− Syst em. out . pr i nt l n( " ATUC−FECRx : No er r or s wi t h " +34− " i nt er l eaved dat a" ) ;35− } 36− }37− i nt k = 0;38− f or ( i nt i = 0; i < _S; i ++) {39− MuxDat aFr ame r et = new MuxDat aFr ame( 0, 0, 0, 0,40− _LS0Map ? _LS0Byt es : 0, 0, 0) ;41− r et . set Fast Byt e( dat a[ k] ) ;42− k++;43−44− i f ( _LS0Map) {45− f or ( i nt j = 0; j < _LS0Byt es; j ++) {46− r et . set LS0Byt e( dat a[ k] , j ) ;47− k++;48− }49− }50− i f ( r et . hasLEX( ) ) {51− r et . set LEXByt e( dat a[ k] ) ;52− k++;53− }54− out put . send( 0, new Obj ect Token( r et ) ) ;55− }56− _f r ame = 0;57− }58− }59− . . . .

Figura 4.18 − Trecho de código do ator FECRx.

Entre as linhas 5 e 22 os dados provenientes do buffer fast são processados. Após os dadosserem obtidos (linha 6 à 8), o método _syndrome() verifica a consistência dos dados (linha 10). Casoalgum erro seja encontrado, o método _rsDecode() (linha 13) tenta corrigi−los. O dados resultantes sãoprocessados pelo método _newMuxDataFrame() (linha 19) para a construção de um novo mux dataframe. Os dados provenientes do buffer interleaver sofrem um tratamento similar (linha 23 à 36). Adiferença é que ao invés de um, _S mux data frame devem ser criados. Isto é implementado entre aslinhas 37 e 57.

4.3.3.9 InterleaverTx

Esse ator implementa a função de interleave dos dados. O buffer de dados é implementado como

75um vetor grande o suficiente para armazenar a quantidade necessária de dados. Esse tamanho depende daprofundidade D de interleave (linha 2). A figura 4.19 apresenta um trecho do código desse ator.

1− . . . . 2− publ i c Par amet er D;3− . . . . 4− publ i c voi d f i r e( ) t hr ows I l l egal Act i onExcept i on {5− i nt j ;6− Obj ect Token ot = ( Obj ect Token) i nput . get ( 0) ;7− i nt [ ] d = ( i nt [ ] ) ot . get Val ue( ) ;8−9− i nt i ndex = 0;10− i f ( _i sEven) {11− i ndex = 1;12− }13− f or ( j = 0; j < d. l engt h; j ++) {14− _buf f er [ ( _wr i t ePos + i ndex + ( _D − 1) * i ndex) % _buf Si ze] = d[ j ] ;15− i ndex++;16− }17− i f ( _i sEven) {18− _r eadPos = ( _r eadPos + 1) % _buf Si ze;19− }20− i nt out [ ] = new i nt [ _nnI nt er ] ;21− f or ( j = 0; j < _nnI nt er ; j ++) {22− out [ j ] = _buf f er [ _r eadPos] ;23− _r eadPos = ( _r eadPos + 1) % _buf Si ze;24− }25− _wr i t ePos = _r eadPos;26− out put . send( 0, new Obj ect Token( out ) ) ;27− }28−29− publ i c voi d i ni t i al i ze( ) t hr ows I l l egal Act i onExcept i on {30− . . . .31− i f ( _nnI nt er % 2 == 0) {32− _i sEven = t r ue;33− _buf Si ze = _nnI nt er + 1 + ( _D − 1) * ( _nnI nt er + 1) ;34− }35− el se {36− _i sEven = f al se;37− _buf Si ze = _D * _nnI nt er ;38− }39− _buf f er = new i nt [ _buf Si ze] ;40− _r eadPos = 0;41− _wr i t ePos = 0;42− }43−44− pr i vat e i nt _buf f er [ ] ;45− pr i vat e i nt _buf Si ze;46− pr i vat e i nt _r eadPos;47− pr i vat e i nt _wr i t ePos;48− pr i vat e bool ean _i sEven;49− pr i vat e i nt _nnI nt er , _kkI nt er ; 50− . . . .

Figura 4.19 − Trecho de código do ator InterleaverTx.

Uma vez que o frame é obtido(linha 6 e 7), cada um de seus bytes é armazenado na respectivaposição do buffer interleaved (linha 13 à 16). Um novo frame é criado extraindo seqüencialmente osdados do buffer (linhas 20 à 26). Os primeiros D frames enviados pelo ator irão conter algumaquantidade de dados inválidos e deverão ser descartados pelo receptor do outro modem. O métodoinitialize() (linhas 29 à 42) calcula (linha 33 à 37) o tamanho mínimo do buffer interleaved para suportara profundidade especificada.

4.3.3.10 InterleaverRx

Esse ator executa o comportamento inverso ao do ator InterleaverTx: os dados são armazenadosno buffer de forma seqüencial (linhas 6 à 13) e os tokens são produzidos extraindo dados de váriasposições do buffer (linha 19 à 31).

1− . . . .

762− publ i c voi d f i r e( ) t hr ows I l l egal Act i onExcept i on {3− Obj ect Token ot = ( Obj ect Token) i nput . get ( 0) ;4− i nt d[ ] = ( i nt [ ] ) ot . get Val ue( ) ;5−6− i f ( _i sEven) {7− _wr i t ePos = ( _wr i t ePos + 1) % _buf Si ze;8− }9− f or ( i nt j = 0; j < _nnI nt er ; j ++) {10− _buf f er [ _wr i t ePos] = d[ j ] ;11− _wr i t ePos = ( _wr i t ePos + 1) % _buf Si ze;13− }14−15− i nt i ndex = 0;16− i f ( _i sEven) {17− i ndex = 1;18− }19− i f ( _i t er at i on == _D − 1) {20− i nt [ ] out = new i nt [ _nnI nt er ] ;21− f or ( i nt j = 0; j < _nnI nt er ; j ++) {22− out [ j ] = _buf f er [ ( _r eadPos + i ndex + ( _D − 1) * i ndex) % _buf Si ze] ;23− i ndex++;24− }25− i f ( _i sEven) {26− _r eadPos = ( _r eadPos + _nnI nt er + 1) % _buf Si ze;27− }28− el se {29− _r eadPos = ( _r eadPos + _nnI nt er ) % _buf Si ze;30− }31− out put . send( 0, new Obj ect Token( out ) ) ;32− }33− el se {34− _i t er at i on++;35− }36− . . . .

Figura 4.20 − Trecho do código do ator InterleaverRx.

A variável _iteration é utilizada para contar as D primeiras iterações, uma vez que nesse períodonão há dados válidos suficientes para criar um frame.

4.3.3.11 Map

O ator Map obtêm frames fast do ator FECTx e frames interleaved do ator InterleaverTx, e combase nesses dados, produz 256 números complexos através da codificação de constelações. A figura 4.21apresenta um trecho do código desse ator. Implementamos duas formas para a transmissão dos 256valores: através de 256 portos individuais, um para cada valor, ou através de um porto que transmite osdados como um vetor. Inicialmente utilizamos a primeira versão, mas devido a velocidade da execução,a segunda opção foi adotada.

1− . . . .2− publ i c TypedI OPor t f ast ;3− publ i c TypedI OPor t i nt er ;4− 5− publ i c TypedI OPor t subChannel [ ] ;6− . . . .7− publ i c Map( TypedComposi t eAct or cont ai ner , St r i ng name, i nt out put Mode)8− t hr ows NameDupl i cat i onExcept i on, I l l egal Act i onExcept i on {9− super ( cont ai ner , name) ;10− _cr eat eI nt er f ace( out put Mode) ;11− }12− 13− publ i c voi d f i r e( ) t hr ows I l l egal Act i onExcept i on {14− 15− swi t ch( _f unc) {16− case 0 : {17− i f ( f ast . hasToken( 0) ) {18− Obj ect Token ot = ( Obj ect Token) f ast . get ( 0) ;19− Fast FECDat aFr ame f ast f = ( Fast FECDat aFr ame) ot . get Val ue( ) ;20− i nt [ ] dat a = f ast f . get AsAr r ay( ) ;21− f or ( i nt i = 0; i < dat a. l engt h; i ++) {22− _dat aBuf f er [ _dat aCount er ] = dat a[ i ] ;23− _dat aCount er ++;24− } 25− _f unc = 1;

7726− }27− } br eak;28− 29− case 1 : {30− i f ( i nt er . hasToken( 0) ) {31− Obj ect Token ot = ( Obj ect Token) i nt er . get ( 0) ;32− i nt [ ] dat a = ( i nt [ ] ) ot . get Val ue( ) ;33− f or ( i nt j = 0; j < dat a. l engt h; j ++) {34− _dat aBuf f er [ _dat aCount er ] = dat a[ j ] ;35− _dat aCount er ++;36− }37− _f unc = 2;38− }39− } br eak;40−41− case 2 : {42− i f ( _out put Mode == 0) {43− i nt k = 0;44− i nt w = 0;45− f or ( i nt i = 0; i < 255; i ++) {46− i f ( i == 63) {47− subChannel [ 63] . send( 0, new48− Doubl eToken( _gai nTabl e[ 63] . r eal ) ) ;49− subChannel [ 63] . send( 0, new 50− Doubl eToken( _gai nTabl e[ 63] . i mag) ) ;51− cont i nue;52− }53− i nt b = 0;54− f or ( i nt j = 0; j < _bi t Tabl e[ i ] ; j ++) {55− b | = ( ( ( _dat aBuf f er [ w] >> k) & 0x01) << j ) ;56− k++;57− i f ( k == 8) {58− k = 0;59− w++;60− }61− }62− Compl ex Z = _const el l at i on( b, _bi t Tabl e[ i ] ) ;63− subChannel [ _subChannel Tabl e[ i ] ] . send( 0, 64− new Doubl eToken( Z. r eal ) ) ;65− subChannel [ _subChannel Tabl e[ i ] ] . send( 0,66− new Doubl eToken( Z. i mag) ) ;67− }68− }69− el se {70− i nt k = 0;71− i nt w = 0;72− doubl e symbol [ ] = new doubl e[ 510] ;73− f or ( i nt i = 0; i < 255; i ++) {74− i f ( i == 63) {75− symbol [ 2* i ] = _gai nTabl e[ 63] . r eal ;76− symbol [ 2* i + 1] = _gai nTabl e[ 63] . i mag;77− }78− i nt b = 0;79− f or ( i nt j = 0; j < _bi t Tabl e[ i ] ; j ++) {80− b | = ( ( ( _dat aBuf f er [ w] >> k) & 0x01) << j ) ;81− k++;82− i f ( k == 8) {83− k = 0;84− w++;85− }86− }87− Compl ex Z = _const el l at i on( b, _bi t Tabl e[ i ] ) ;88− symbol [ 2* i ] = Z. r eal ;89− symbol [ 2* i + 1] = Z. i mag;90− }91− subChannel [ 0] . send( 0, new Obj ect Token( symbol ) ) ;92− }93− _dat aCount er = 0;94− _f unc = 0;95− } br eak;96− }97− }98−99− publ i c voi d i ni t i al i ze( ) t hr ows I l l egal Act i onExcept i on {100− . . . .101− _bi t Tabl e = new i nt [ 255] ;102− _subChannel Tabl e = new i nt [ 255] ;103− _gai nTabl e = new Compl ex[ 255] ;104−

78105− i nt t ot = ( _nnFast + _nnI nt er ) * 8;106− f or ( i nt i = 0; i < 255; i ++) {107− _subChannel Tabl e[ i ] = i ;108− i f ( i == 63) {109− _bi t Tabl e[ i ] = 0;110− _gai nTabl e[ i ] = new Compl ex( 1, 1) ;111− cont i nue;112− }113− _gai nTabl e[ i ] = new Compl ex( 1, 1) ;114−115− i f ( t ot > 4) {116− _bi t Tabl e[ i ] = 5;117− t ot −= 5;118− }119− el se120− i f ( t ot > 0) {121− _bi t Tabl e[ i ] = t ot ;122− t ot = 0;123− }124− el se {125− _bi t Tabl e[ i ] = 0;126− }127− }128− _dat aBuf f er = new i nt [ _nnI nt er + _nnFast ] ;129− _dat aCount er = 0;130− _f unc = 0;131− }132−133− pr i vat e voi d _cr eat eI nt er f ace( i nt out put Mode) t hr ows 134− I l l egal Act i onExcept i on, NameDupl i cat i onExcept i on {135− . . . .136− i f ( _out put Mode == 0) {137− subChannel = new TypedI OPor t [ 255] ;138− f or ( i nt i = 0; i < 255; i ++) {139− subChannel [ i ] = new TypedI OPor t ( t hi s , " subChannel _" + i ,140− f al se, t r ue) ;141− subChannel [ i ] . set TypeEqual s( Doubl eToken. c l ass) ;142− }143− }144− el se {145− subChannel = new TypedI OPor t [ 1] ;146− subChannel [ 0] = new TypedI OPor t ( t hi s , " subChannel 0" , f al se, t r ue) ;147− subChannel [ 0] . set TypeEqual s( Obj ect Token. c l ass) ;148− }149− . . . .150− }151− pr i vat e i nt _bi t Tabl e[ ] ;152− pr i vat e i nt _subChannel Tabl e[ ] ;153− pr i vat e Compl ex _gai nTabl e[ ] ;154− 155− pr i vat e i nt _dat aBuf f er [ ] ;156− pr i vat e i nt _dat aCount er ;157− pr i vat e i nt _f unc;158− pr i vat e i nt _out put Mode;159− . . . .

Figura 4.21 − Trecho de código do ator Map.

Entre as linhas 16 e 26 os dados do frame fast são obtidos, e entre as linha 30 e 38 os dados doframe interleaved. Entre as linhas 43 e 67 (utilizando a versão com 256 portos de saída) ou entre as linha70 e 91 (utilizando a versão com um porto de saída), os dados são divididos para cada subcanal (linha 53à 61, ou 78 à 86) baseados em uma tabela (o vetor _bitTable da linha 151) que especifica os números debits por subcanal. Essa tabela já deve estar ordenada por tom. Como não implementamos toda a máquinade inicialização, determinamos o número de bits por subcanal de maneira aleatória (método initialize()).O método _constellation() (linhas 62 ou 87) implementa a codificação de constelações descrita no item4.2.8. O método _createInterface() (linhas 133 à 150) é responsável por construir o ator com a versãocorreta dos portos de saída.

4.3.3.12 Demap

O ator Demap executa a função inversa do ator Map: recebe uma certa quantidade de valorescomplexos e produz um frame fast e um frame interleave. A figura 4.22 apresenta um trecho de código

79do ator. Como este ator é utilizado pelo modem ATU−C, ele recebe 32 valores complexos. Assim comono caso do ator Map, duas versão para a quantidade de portos de saída foram empregadas: uma com 32portos individuais e outra com apenas um porto que recebe um vetor de números complexos.

1− . . . . 2− publ i c voi d f i r e( ) t hr ows I l l egal Act i onExcept i on {3−4− i nt bc = 0, wc = 0;5− i nt dat a[ ] = new i nt [ _nnI nt er + _nnFast ] ;6−7− i f ( _i nput Mode == 0) {8− f or ( i nt i = 0; i < 31; i ++) {9− i f ( i == 15) {10− subChannel [ 15] . get ( 0) ;11− subChannel [ 15] . get ( 0) ;12− cont i nue;13− }14− Doubl eToken dt r = 15− ( Doubl eToken) subChannel [ _subChannel Tabl e[ i ] ] . get ( 0) ;16− Doubl eToken dt i = 17− ( Doubl eToken) subChannel [ _subChannel Tabl e[ i ] ] . get ( 0) ;18− 19− Compl ex Z = new Compl ex( dt r . doubl eVal ue( ) , dt i . doubl eVal ue( ) ) ; 20− i nt b = _const el l at i on( Z, _bi t Tabl e[ i ] ) ;21− f or ( i nt j = 0; j < _bi t Tabl e[ i ] ; j ++) {22− dat a[ wc] | = ( ( ( b >> j ) & 0x01) << bc) ;23− bc++;24− i f ( bc == 8) {25− bc = 0;26− wc++;27− }28− }29− }30− }31− el se {32− Obj ect Token ot = ( Obj ect Token) subChannel [ 0] . get ( 0) ;33− doubl e [ ] i ndat a = ( doubl e [ ] ) ot . get Val ue( ) ;34− f or ( i nt i = 0; i < 31; i ++) {35− i f ( i == 15) {36− cont i nue;37− }38− Compl ex Z = new Compl ex( i ndat a[ 2* i ] , i ndat a[ 2* i + 1] ) ; 39− i nt b = _const el l at i on( Z, _bi t Tabl e[ i ] ) ;40− f or ( i nt j = 0; j < _bi t Tabl e[ i ] ; j ++) {41− dat a[ wc] | = ( ( ( b >> j ) & 0x01) << bc) ;42− bc++;43− i f ( bc == 8) {44− bc = 0;45− wc++;46− }47− }48− }49− }50− wc = 0;51− Fast FECDat aFr ame f ast f = new Fast FECDat aFr ame( 0, 0, 0, 0, 52− _LS0Map ? 0 : _LS0Byt es, 0, 0, _nnFast − _kkFast ) ;53−54− f ast f . set Fast Byt e( dat a[ wc] ) ;55− wc++;56− i f ( ! _LS0Map) {57− f or ( i nt i = 0; i < _LS0Byt es; i ++) {58− f ast f . set LS0Byt e( dat a[ wc] , i ) ;59− wc++;60− }61− }62− i f ( f ast f . hasLEX( ) ) {63− f ast f . set LEXByt e( dat a[ wc] ) ;64− wc++;65− }66− f or ( i nt i = 0; i < ( _nnFast − _kkFast ) ; i ++) {67− f ast f . set Par i t yByt e( dat a[ wc] , i ) ;68− wc++;69− }70− f ast . send( 0, new Obj ect Token( f ast f ) ) ;71−72− i nt [ ] out = new i nt [ _nnI nt er ] ;73− f or ( i nt i = 0; i < _nnI nt er ; i ++) {

8074− out [ i ] = dat a[ wc] ;75− wc++;76− }77− i nt er . br oadcast ( new Obj ect Token( out ) ) ;78− }79− . . . .

Figura 4.22 − Trecho de código do ator Demap.

Entre as linha 8 e 29 ou 32 e 48, o conjunto de valores complexos são obtidos, transformados emum vetor de bits e armazenados em um buffer. Esse bloco utiliza a mesma tabela que o ator Map eutiliza−a para construir os diferentes frames (linha 50 à 77).

4.3.3.13 IDFT

Esse ator é responsável por implementar a transformada discreta inversa de Fourier. A entrada écomposta por 256 valores complexos, que são estendido para 512 valores (linhas 25 à 29 ou 36 à 39).Esse ator também utiliza as duas versões para os portos de saída.

1− . . . . 2− publ i c voi d f i r e( ) t hr ows I l l egal Act i onExcept i on {3− i nt i ndex;4−5− i f ( mode. hasToken( 0) ) {6− Bool eanToken bt = ( Bool eanToken) mode. get ( 0) ;7− _mode = bt . bool eanVal ue( ) ;8− }9− el se { 10− i f ( _mode) {11− i ndex = 0;12− }13− el se {14− i ndex = 1;15− }16− 17− _dat a[ 0] = 0;18− _dat a[ 1] = 0;19− _dat a[ 512] = 0;20− _dat a[ 513] = 0;21−22− i f ( _i nput Mode == 0) {23− f or ( i nt i = 1; i < 256; i ++) {24− Doubl eToken dt = ( Doubl eToken) subChannel [ i − 1] . get ( i ndex) ;25− _dat a[ 2* i ] = dt . doubl eVal ue( ) ;26− _dat a[ 1024 − 2* i ] = _dat a[ 2* i ] ;27− dt = ( Doubl eToken) subChannel [ i − 1] . get ( i ndex) ;28− _dat a[ 2* i + 1] = dt . doubl eVal ue( ) ;29− _dat a[ 1025 − 2* i ] = −1 * _dat a[ 2* i + 1] ;30− }31− }32− el se {33− Obj ect Token ot = ( Obj ect Token) subChannel [ 0] . get ( i ndex) ;34− doubl e [ ] t mp = ( doubl e [ ] ) ot . get Val ue( ) ;35− f or ( i nt i = 1; i < 256; i ++) {36− _dat a[ 2* i ] = t mp[ 2* i − 2] ;37− _dat a[ 1024 − 2* i ] = _dat a[ 2* i ] ;38− _dat a[ 2* i + 1] = t mp[ 2* i − 1] ;39− _dat a[ 1025 − 2* i ] = −1 * _dat a[ 2* i + 1] ;40− }41− }42− _i df t ( ) ;43−44− i f ( _out put Mode == 0) {45− f or ( i nt i = 0; i < 512; i ++) {46− out put . send( 0, new Doubl eToken( _dat a[ 2* i ] ) ) ;47− }48− }49− el se {50− doubl e [ ] symbol = new doubl e[ 512] ;51− f or ( i nt i = 0; i < 512; i ++) symbol [ i ] = _dat a[ 2* i ] ;52− out put . send( 0, new Obj ect Token( symbol ) ) ;53− }54− }

8155− }56− . . . .

Figura 4.23 − Trecho de código do ator IDFT no MoC DE.

Conforme pode ser observado na figura 4.12, o ator IDFT possui duas conexões nos seus portosde entrada: uma proveniente do ator Map e outra do ator Initializer. A conexão com o ator Map éreferente ao processamento normal dos dados a serem transmitidos. A conexão com o ator Initializer énecessária para enviar os sinais de inicialização. Dessa forma, esse ator deve ser capaz de a qualquermomento, obter os dados de diferentes portos, conforme um modo de operação especificado (linhas 5 à15). Isso implica que os modelos data flow e o modelo PN não são adequados para capturar tal ator.Utilizamos o modelo DE.

4.3.3.14 DFT

Esse ator implementa a transformada discreta de Fourier. Ele recebe 64 valores reais (linhas 12ou 18) e produz 32 valores complexos (linhas 34 à 37 ou 40 à 44). Assim como o ator IDFT, énecessário que esse ator possua duas conexões diferentes para seus portos de saída.

1− . . . .2− publ i c voi d f i r e( ) t hr ows I l l egal Act i onExcept i on { 3−4− i nt i ndex;5− i f ( mode. hasToken( 0) ) {6− Bool eanToken bt = ( Bool eanToken) mode. get ( 0) ;7− _mode = bt . bool eanVal ue( ) ;8− }9− el se {10− i f ( _i nput Mode == 0) {11− f or ( i nt i = 0; i < 128; i += 2) {12− Doubl eToken dt = ( Doubl eToken) i nput . get ( 0) ;13− _dat a[ i ] = dt . doubl eVal ue( ) ;14− _dat a[ i +1] = 0;15− }16− }17− el se {18− Obj ect Token ot = ( Obj ect Token) i nput . get ( 0) ;19− doubl e [ ] t mp = ( doubl e [ ] ) ot . get Val ue( ) ;20− f or ( i nt i = 0; i < 64; i ++) {21− _dat a[ 2* i ] = t mp[ i ] ;22− _dat a[ 2* i + 1] = 0;23− }24− }25− _df t ( ) ;26−27− i f ( _mode) {28− i ndex = 0;29− }30− el se {31− i ndex = 1;32− }33− i f ( _out put Mode == 0) {34− f or ( i nt i = 1; i < 32; i ++) {35− subChannel [ i − 1] . send( i ndex, new36− Doubl eToken( Mat h. r ound( _dat a[ 2* i ] ) ) , 1. 0) ;37− subChannel [ i − 1] . send( i ndex, new38− Doubl eToken( Mat h. r ound( _dat a[ 2* i + 1] ) ) , 1. 0) ;39− }40− }41− el se {42− doubl e [ ] out = new doubl e[ 62] ;43− f or ( i nt i = 2; i < 64; i ++) {44− out [ i − 2] = Mat h. r ound( _dat a[ i ] ) ;45− }46− subChannel [ 0] . send( i ndex, new Obj ect Token( out ) , 1. 0) ;47− }48− }49− }50− . . . .

Figura 4.24 − Trecho de código do ator DFT no MoC DE.

824.3.3.15 Initializer

Esse ator implementa a máquina de estados responsável pela inicialização do modem. Conformeo item 4.2.10, a inicialização corresponde a troca de símbolos pré−definidos durante durações exatas, e aexecução de operações de configuração e treinamento de blocos do data path.

A fim de tornar a implementação desse ator mais clara, criamos a classe auxiliar InitSymbols quecontém constantes representando os diferentes estados e sinais de inicialização para ambos os modems.A figura 4.25 apresenta um trecho de código do ator.

1− publ i c c l ass I ni t Symbol s {2−3− publ i c s t at i c f i nal i nt C_QUI ET1 = 0;4− publ i c s t at i c f i nal i nt MY_CSI LENT1 = 1;5− publ i c s t at i c f i nal i nt C_I DLE = 2;6− publ i c s t at i c f i nal i nt C_TONE = 3;7− publ i c s t at i c f i nal i nt C_ACT = 4;8− publ i c s t at i c f i nal i nt C_QUI ET2 = 5;9− 10− publ i c s t at i c f i nal i nt R_ACT_REQ = 0;11− publ i c s t at i c f i nal i nt MY_DETECT_C_ACT = 1;12− publ i c s t at i c f i nal i nt R_QUI ET1 = 2;13− publ i c s t at i c f i nal i nt R_ACK = 3;14−12− publ i c s t at i c f i nal i nt SHOWTI ME = 60000;13−14− publ i c s t at i c f i nal i nt C_ACT1_S1 = 0;15− publ i c s t at i c f i nal i nt C_ACT1_S2 = 1;16− . . . .17− publ i c s t at i c f i nal i nt R_ACT_REQ_S1 = 0;18− publ i c s t at i c f i nal i nt R_ACT_REQ_S2 = 1;19− . . . .20− 21− publ i c I ni t Symbol s( ) {22−23− _ATUCSymbol Tabl e = new doubl e[ 12] [ 510] ;24−25− _ATUCSymbol Tabl e[ C_ACT1_S1] [ 96] = 1;26− _ATUCSymbol Tabl e[ C_ACT1_S1] [ 97] = 1;27− _ATUCSymbol Tabl e[ C_ACT1_S2] [ 96] = 2;28− _ATUCSymbol Tabl e[ C_ACT1_S2] [ 97] = 2;29− . . . .30− 31− _ATURSymbol Tabl e = new doubl e[ 9] [ 62] ;32−33− _ATURSymbol Tabl e[ R_ACT_REQ_S1] [ 16] = 1;34− _ATURSymbol Tabl e[ R_ACT_REQ_S1] [ 17] = 1;35− . . . .36− }37− 38− publ i c bool ean checkATURSymbol ( i nt symbol , doubl e [ ] val ue) {39− f or ( i nt i = 0; i < 62; i ++) {40− i f ( val ue[ i ] ! = _ATURSymbol Tabl e[ symbol ] [ i ] ) {41− r et ur n f al se;42− }43− }44− r et ur n t r ue;45− }46− . . . .47− publ i c doubl e [ ] get ATURSymbol ( i nt symbol ) {48− r et ur n _ATURSymbol Tabl e[ symbol ] ;49− }50− . . . .51− pr i vat e doubl e _ATUCSymbol Tabl e[ ] [ ] ;52− pr i vat e doubl e _ATURSymbol Tabl e[ ] [ ] ;53− }

Figura 4.25 − Classe auxiliar com os símbolos de inicialização.

Os estados para o modem ATU−C estão representados entre as linhas 3 e 8 e para o modemATU−R entre as linhas 10 e 13. A potência de transmissão de cada sinal é codificada por um valor realarmazenado em uma matriz (linhas 51 e 52), onde a primeira dimensão indica um sinal e a segunda umafreqüência. A codificação do sinal C−ACT1 é feita nas linhas 14 e 15, e é dividida em duas constantes:C_ACT1_S1 e C_ACT1_S2. As duas constantes representam os dois níveis de potência do sinal C−

83ACT1. Isso é feito similarmente para os outros sinais de inicialização. O método _checkATURSymbol()(linhas 38 à 45) é utilizado para obter o código de um sinal do modem ATU−R, dado um vetor denúmeros reais. O método _getATURSymbol() (linhas 47 à 49) é utilizado para a função inversa. Métodossimilares também existem para o modem ATU−C.

A partir da definição do processo de inicialização, é possível observar que o momento daocorrência e o tempo de duração de um sinal é de fundamental importância para a correta inicializaçãodo modem. Dessa forma, é necessário utilizar um modelo computacional flexível e com um modelo detempo. Como os atores do data path do modem utilizam o modelo DE, e este MoC apresenta ascaracterísticas mencionadas, decidimos utilizá−lo também na captura da máquina de inicialização.Entretanto, deparamos com uma dificuldade na utilização do método fireAt() para o escalonamento deativamentos futuros. Por exemplo, o sinal R−ACT−REQ é definido como 128 símbolos consecutivosseguidos por um período sem transmissão. Poderíamos modelar essa situação com uma chamada do tipofireAt(currentTime + quietTime), onde quietTime é o tempo sem atividade de transmissão. Entretanto,caso o modem ATU−C tenha detectado o sinal R−ACT−REQ e respondido apropriadamente, o modemATU−R deve mudar para outro estado muito provavelmente antes do tempo quietTime. Entretanto, oativamento futuro devido à chamada do método fireAt() continuaria válido e iria escalonar o ator. Issopode levar à um comportamento indevido.

Uma solução para o problema mencionado seria introduzir a capacidade de eliminar eventosfuturos da fila do modelo DE. Entretanto, tal solução parece complexa. Adotamos outra solução queutiliza o ator Timer. A figura 4.26 apresenta o método fire() desse ator. Esse ator é responsável por gerareventos em momentos requisitados através de um evento no porto StartTimer. A requisição fica ativa atéo momento da geração do evento ou até que um evento no porto StopTimer() seja detectado. Neste caso,embora o ator seja ativado (divido ao método fireAt()), nenhum evento é produzido.

1− . . . .2− publ i c voi d f i r e( ) t hr ows I l l egal Act i onExcept i on {3−4− i f ( s t opTi mer . hasToken( 0) ) {5− i f ( _act i ve == 0) {6− t hr ow new I l l egal Act i onExcept i on( t hi s , " Tr y i ng t o st op when " +7− " i t was not s t ar t ed" ) ;8− }9− s t opTi mer . get ( 0) ;10− _act i ve = 0;11− }12− i f ( s t ar t Ti mer . hasToken( 0) ) {13− i f ( _act i ve ! = 0) {14− t hr ow new I l l egal Act i onExcept i on( t hi s , " Tr y i ng t o st ar t when " +15− " i t was not s t oped" ) ;16− }17− Doubl eToken dt = ( Doubl eToken) st ar t Ti mer . get ( 0) ;18− doubl e t = dt . doubl eVal ue( ) + get Cur r ent Ti me( ) ;19− f i r eAt ( t ) ;20− _act i ve = t ;21− }22− i f ( get Cur r ent Ti me( ) == _act i ve) {23− _act i ve = 0;24− t i mer Event . send( 0, new Token( ) ) ;25− }26− }27− pr i vat e doubl e _act i ve;28− . . . .

Figura 4.26 − Método fire() do ator Timer.

Entre as linhas 4 e 11 está implementada a anulação de uma requisição. Isso ocorre quando ovalor da variável _active é igualado à zero. Entre as linhas 12 e 21 uma nova requisição é processada. Avariável _active armazena o instante de tempo em que um evento deve ser produzido. Entre as linhas 22e 25 um evento é produzido. Note que apenas uma requisição pode ser processada ao mesmo tempo.

Além da classe auxiliar InitSymbols e do ator Timer, desenvolvemos alguns métodos auxiliarespara o ator Initializer.

O método _getSymbol() (figura 4.27) é utilizado para receber e armazenar símbolos. Devido asconexões entre o ator Initializer e os atores IDFT e DFT, o ator Initializer deve possuir as duas versões(vários portos recebendo valores numéricos ou um porto recebendo um vetor) de portos de comunicação.

841− pr i vat e voi d _get Symbol ( ) t hr ows I l l egal Act i onExcept i on {2−3− _l ast Fi r e = _cur r ent Fi r e;4− _cur r ent Fi r e = get Cur r ent Ti me( ) ;5−6− i f ( f r omATUR[ 0] . hasToken( 0) ) {7− f or ( i nt i = 0; i < _symbol . l engt h; i ++) {8− _l ast symbol [ i ] = _symbol [ i ] ;9− }10− i f ( _f r omATURMode == 0) {11− Doubl eToken dt ;12− f or ( i nt i = 0; i < 31; i ++) {13− dt = ( Doubl eToken) f r omATUR[ i ] . get ( 0) ;14− _symbol [ 2* i ] = dt . doubl eVal ue( ) ;15− dt = ( Doubl eToken) f r omATUR[ i ] . get ( 0) ;16− _symbol [ 2* i + 1] = dt . doubl eVal ue( ) ;17− }18− }19− el se {20− Obj ect Token ot = ( Obj ect Token) f r omATUR[ 0] . get ( 0) ;21− _symbol = ( doubl e [ ] ) ot . get Val ue( ) ;22− }23− _hassymbol = t r ue;24− }25− el se {26− f or ( i nt i = 0; i < _symbol . l engt h; i ++) {27− _l ast symbol [ i ] = _symbol [ i ] ;28− _symbol [ i ] = 0;29− }30− _hassymbol = f al se;31− }32− }

Figura 4. 27 − Método _getSymbol() do ator Initializer.

Na linha 4 o momento da recepção do símbolo é armazenado. Entre as linha 7 e 9 o valor doúltimo símbolo é armazenado e entre as linhas 10 e 18 ou 19 e 22 o valor do símbolo recebido éarmazenado. A variável _hassymbol (linha 30) indica se um símbolo foi recebido.

O método auxiliar _sendSymbol() é utilizado para enviar um símbolo. A figura 4.28 apresenta ocódigo.

1− pr i vat e voi d _sendSymbol ( i nt symbol ) t hr ows I l l egal Act i onExcept i on {2− doubl e [ ] s = _i ni t Symbol s. get ATUCSymbol ( symbol ) ;3− i f ( _t oATURMode == 0) {4− f or ( i nt i = 0; i < 255; i ++) {5− t oATUR[ i ] . send( 0, new Doubl eToken( s[ 2* i ] ) ) ;6− t oATUR[ i ] . send( 0, new Doubl eToken( s[ 2* i + 1] ) ) ;7− }8− }9− el se {10− t oATUR[ 0] . send( 0, new Obj ect Token( s) ) ;11− }12− }

Figura 4.28 − Método _sendSymbol() do ator Initializer.

Na linha 2, o vetor de sinais necessário para enviar o símbolo especificado é obtido com oauxílio da classe InitSymbols.

A figura 4.29 apresenta o método _detectSignal(). Esse método foi desenvolvido a fim desimplificar a implementação da máquina de estados. Sua função é determinar quando um sinal foirecebido com sucesso.

1− pr i vat e byt e _det ect Si gnal ( i nt S1, i nt S2) t hr ows I l l egal Act i onExcept i on {2−3− i f ( _r xCount er == 0) {4− i f ( _hassymbol ) {5− i f ( _i ni t Symbol s. checkATURSymbol ( S1, _symbol ) ) {6− _r xCount er ++;7− }8− el se {9− _r xCount er = 0;10− r et ur n 0;11− }12− }13− el se {

8514− _r xCount er = 0;15− r et ur n 0;16− }17− }18− el se19− i f ( _r xCount er < 64/ _BASE) {20− i f ( _hassymbol && ( ( _cur r ent Fi r e − _l ast Fi r e) == 250) ) {21− i f ( _i ni t Symbol s. checkATURSymbol ( S1, _symbol ) ) {22− _r xCount er ++;23− }24− el se {25− _r xCount er = 0;26− r et ur n 0;27− }28− }29− el se {30− _r xCount er = 0;31− r et ur n 0;32− }33− }34− el se35− i f ( _r xCount er < 128/ _BASE) {36− i f ( _hassymbol && ( ( _cur r ent Fi r e − _l ast Fi r e) == 250) ) {37− i f ( _i ni t Symbol s. checkATURSymbol ( S2, _symbol ) ) {38− _r xCount er ++;39− i f ( _r xCount er == 128/ _BASE) {40− _r xCount er = 0;41− r et ur n 2;42− }43− }44− el se {45− _r xCount er = 0;46− r et ur n 0;47− }48− }49− el se {50− _r xCount er = 0;51− r et ur n 0;52− }53− }54− r et ur n 1;55− }

Figura 4.29 − Método _detectSignal() do ator Initializer.

O código da figura 4.29 é dividido em três situações. Entre as linhas 3 e 17 ocorre a recepção doprimeiro símbolo do sinal. Apenas o valor do símbolo é verificado (linha 5). Quando alguma condiçãode recepção for violada, a variável _rxCounter, responsável por contar a quantidade de símbolosrecebidos, é igualada à zero. A segunda situação está implementada entre as linha 19 e 33. Neste trechoocorre a verificação do primeiro nível de potência do sinal. Na linha 20 é verificado se o símbolo foirecebido no instante adequado e na linha 21 o valor do símbolo é verificado. O mesmo ocorre para osegundo nível de potência do sinal entre as linhas 35 e 53. O método _detectSignal() retorna três valores:0 caso ocorra um erro, 1 caso o ator tenha recebido um símbolo válido mas não é o último do sinal e 2caso seja o último símbolo.

O método _transmitSignal() é apresentado na figura 4.30. Sua função é transmitir um sinal.

1− pr i vat e byt e _t r ansmi t Si gnal ( i nt S1, i nt S2) t hr ows I l l egal Act i onExcept i on {2− i f ( _t xCount er < 64/ _BASE) {4− _sendSymbol ( S1) ;5− s t ar t Ti mer . send( 0, new Doubl eToken( 249) ) ;6− _t xCount er ++;7− }8− el se9− i f ( _t xCount er < 128/ _BASE) {10− _sendSymbol ( S2) ;11− _t xCount er ++;12− i f ( _t xCount er == 128/ _BASE) r et ur n 1;13− s t ar t Ti mer . send( 0, new Doubl eToken( 249) ) ;14− }15− r et ur n 0;16− }

Figura 4.30 − Método _transmitSignal() do ator Initializer.

Entre as linhas 2 e 7 o primeiro nível de potência do sinal é enviado e entre as linhas 9 e 14 o

86segundo nível de potência. O método retorna 0 enquanto o sinal não tenha sido enviado e 1 quando atransmissão for completada.

Finalmente, o código para a máquina de estados ATU−C é apresentado na figura 4.31.

1− . . . .1− publ i c voi d f i r e( ) t hr ows I l l egal Act i onExcept i on {2−3− i f ( t i mer Event . hasToken( 0) ) {4− t i mer Event . get ( 0) ;5− _t i mer Event = t r ue;6− }7− el se {8− _t i mer Event = f al se;9− }10− _get Symbol ( ) ;11−12− i f ( r eset . hasToken( 0) ) {13− . . . .14− }15− el se {16− swi t ch( _st at e) {17− case _i ni t Symbol s. C_QUI ET1: {18− _r et = _det ect Si gnal ( _i ni t Symbol s. R_ACT_REQ_S1,19− _i ni t Symbol s. R_ACT_REQ_S2) ;20− i f ( _r et == 2) {21− _st at e = _i ni t Symbol s. MY_CSI LENT1;22− s t ar t Ti mer . send( 0, new Doubl eToken( 251) ) ;23− } 24− } br eak;25−26− case _i ni t Symbol s. MY_CSI LENT1: {27− i f ( ! _hassymbol ) {28− _st at e = _i ni t Symbol s. C_ACT;29− _C_ACTCount er ++;30− }31− el se {32− _st at e = _i ni t Symbol s. C_QUI ET1;33− _C_ACTCount er = 0;34− }35− s t ar t Ti mer . send( 0, new Doubl eToken( 250) ) ;36− _r xCount er = 0; 37− } br eak;38−39− case _i ni t Symbol s. C_ACT: {40− _r et = _t r ansmi t Si gnal ( _i ni t Symbol s. C_ACT2_S1,41 _i ni t Symbol s. C_ACT2_S2) ;42− i f ( _r et == 1) {43− _t xCount er = 0;44− _st at e = _i ni t Symbol s. C_QUI ET2;45− s t ar t Ti mer . send( 0, new Doubl eToken( 250 * 129) ) ;46− } 47− } br eak;48−49−50− case _i ni t Symbol s. C_QUI ET2: {51− _r et = _det ect Si gnal ( _i ni t Symbol s. R_ACK2_S1,52− _i ni t Symbol s. R_ACK2_S2) ;53− i f ( _r et == 2) {54− _st at e = _i ni t Symbol s. SHOWTI ME;55− _r xCount er = 0;56− s t ar t Ti mer . send( 0, new Doubl eToken( 250) ) ;57− i f ( ! _t i mer Event ) s t opTi mer . send( 0, new Token( ) ) ;58− _C_ACTCount er = 0;59− }60− el se61− i f ( _r et == 0) {62− i f ( _C_ACTCount er < 2) {63− _st at e = _i ni t Symbol s. C_ACT;64− _C_ACTCount er ++;65− }66− el se {67− _st at e = _i ni t Symbol s. C_QUI ET1;68− _C_ACTCount er = 0;69− }70− _r xCount er = 0;71− i f ( ! _t i mer Event ) s t opTi mer . send( 0, new Token( ) ) ;72− }73− el se

8774− i f ( _r et == 1) {75− i f ( _t i mer Event ) {76− i f ( _C_ACTCount er < 2) {77− _st at e = _i ni t Symbol s. C_ACT;78− _C_ACTCount er ++;79− }80− el se {81− _st at e = _i ni t Symbol s. C_QUI ET1;82− _C_ACTCount er = 0;83− }84− _r xCount er = 0;85− }86− }87− } br eak;88− . . . .89− }90− }91− }92− . . . .

Figura 4.31 − Método fire() do ator Initializer.

Entre as linhas 3 e 9 é verificado a presença de um evento enviado pelo ator Timer. Na linha 10 apresença de um símbolo é testada. Entre as linhas 12 e 14 a condição de reinicialização é verificada. Oestado C−QUIET1 está implementado entre as linhas 17 e 23. Caso um sinal válido seja detectado (linha18), ocorre a transição para o estado MY−CSILENT1 (linha 20 e 21). Esse estado (linhas 26 à 37) éutilizado para verificar a ausência do sinal R−ACT−REQ. O estado C−ACT (linhas 39 à 47) é utilizadopara transmitir o respectivo sinal (linha 40 e 41). Na linha 45 está implementado a máxima duraçãopermitida para a espera do sinal de acknowledgment do modem ATU−R. Caso esse sinal seja detectado,o código da linha 54 à 58 é executado e a fase de ativação está encerrada. Caso contrário, o máquina deestados irá esperar até atingir o limite máximo ou continuar recebendo o sinal.

A máquina de estados para o modem ATU−R é implementada de maneira similar, masrespeitando os estados e transições descritos no item 4.2.10.

4.4 Discussão

Esse capítulo apresentou o estudo de caso que desenvolvemos. Criamos uma especificaçãoexecutável para um subconjunto de um modem ADSL. O principal objetivo desse esforço é identificaralguma estratégia para utilizar os resultados obtidos através do estudo das primitivas comportamentais naescolha de um modelo computacional.

Após termos analisado a especificação textual do modem (item 4.2), determinamos que o MoCPN parecia ser o mais adequado, devido à grande quantidade de blocos transformacionais (primitivacomportamental ¨seqüência de expressões̈ ). Além disso, esse modelo também apresentava uma noção detempo (ao contrário dos modelos data flow), o que era necessário para capturar o comportamento dainicialização. De fato, foi possível criar uma especificação eficiente para todo o data path do modem(vide figura 4.12). Entretanto, quando tentamos introduzir o bloco de inicialização, não foi possívelimplementar eficientemente os atores IDFT e DFT. Conforme foi mostrado no item 4.3.3.15, énecessário que esses atores se comuniquem com a máquina de inicialização, além dos atores do datapath. Alem disso, o padrão de comunicação não é conhecido. Dessa forma, temos a primitivacomportamental de desvio condicional. Como foi demonstrado no capítulo 2, o modelo PN não é o maisadequado para capturar essa primitiva.

Para terminar a descrição do modem, tivemos então que escolher entre dois MoCs: SR e DE.Escolhemos o modelo DE devido ao modelo explícito de tempo. Entretanto, a utilização do modelo SR épossível e deve ser considerada como um trabalho futuro. O modelo DE se mostrou adequado na capturado restante do modem. O único problema encontrado foi referente à necessidade de anular eventos jáescalonados, conforme foi mencionado no item 4.3.3.15. Desenvolvemos uma solução eficiente queemprega um ator temporizador.

Podemos considerar a captura da máquina de inicialização como um exemplo de uma novaprimitiva comportamental: protocolo de comunicação. Essa primitiva se caracteriza pela definiçãoprecisa da troca de eventos entre dois ou mais atores, incluindo restrições temporais. Como trabalhofuturo, utilizaremos nossa ferramenta para depuração/profiling na especificação executável do modem, a

88fim de estudar tal primitiva.

89

Capítulo 5

Conclusões e Trabalhos Futuros

5.1 Considerações Finais

Nessa dissertação abordamos o problema da adequação/eficiência de um modelo computacionalpara a criação de especificações executáveis. O ambiente Ptolemy II foi utilizado como ferramenta desoftware para o desenvolvimento do trabalho, uma vez que além de possuir implementado algunsmodelos computacionais, ele também provê uma infra−estrutura eficiente para a implementação deoutros MoCs. Seis modelos computacionais foram comparados. Nossa metodologia fundamenta−se noconceito de primitiva comportamental, conforme definida no capítulo 3. Desenvolvemos especificaçõespara capturar três primitivas e analisamos a adequação de cada uma com relação aos seis modelos.Outras cinco primitivas comportamentais foram enumeradas. Uma ferramenta para depurar a execuçãode uma especificação foi desenvolvida para auxiliar a análise de cada primitiva. Essa ferramenta tambémpode ser utilizada para outras finalidades, como melhorar a eficiência de uma especificação ou comparardiferentes implementações de um mesmo modelo computacional. Finalmente, desenvolvemos um estudode caso de um sistema real, com o intuito de aplicar os resultados da análise das três primitivascomportamentais. Como resultado, identificamos como cada parte do sistema utilizava uma primitivacomportamental. Além disso, uma nova primitiva foi identificada.

5.2 Trabalhos Futuros

Podemos enumerar as seguintes contribuições pretendidas por este trabalho:

1. uma biblioteca de critérios para auxiliar o projetista nas tarefas de escolher os modeloscomputacionais mais adequados e construir as especificações executáveis. Duas métricasdevem ser consideradas: captura/validação e implementação física (síntese);

2. ferramentas de análise de especificações executáveis;3. uma estratégia de como aplicar os resultados das contribuições anteriores em um sistema de

grande porte.

Neste trabalho ainda não alcançamos tais objetivos. Analisamos três primitivas comportamentasconsiderando o critério de captura/validações e desenvolvemos o protótipo de uma ferramenta paraanálise de especificações executáveis. As seguintes tarefas futuras devem ser efetuadas para alcançarmostais objetivos:

1. ampliar o número de primitivas comportamentais analisadas;2. avaliar outros modelos computacionais que não estão implementados no ambiente Ptolemy;3. criar variantes de modelos computacionais implementados no ambiente Ptolemy;4. analisar a utilização de combinações (pares, triplas, etc.) de MoCs para descrever sistemas

(toy benchmarks) compostos por uma ou mais primitivas comportamentais;5. incorporar à análise uma métrica que permita estimar a eficiência da utilização de um

determinado MoC para a implementação física de uma primitiva comportamental;6. desenvolver estudos de caso de sistemas de grande porte.

A primeira tarefa consiste em realizar a análise de primitivas comportamentais que jáidentificamos como relevantes. São seis primitivas ao total: sincronismo, compartilhamento de recursos,concorrência, preempção, recursão e protocolo de comunicação. Outras primitivas poderão ser incluídas

90durante o desenvolvimento do trabalho.

As tarefas 2 e 3 procuram ampliar o leque de alternativas para a análise das primitivas. Para tal,pretendemos introduzir novos modelos computacionais ao ambiente Ptolemy e modificar modelos jáimplementados através da variação de alguma de suas características, como por exemplo o escalonador.

O ambiente Ptolemy é implementado de tal forma que é possível utilizar, em uma mesmaespecificação executável, vários modelos computacionais distintos, por exemplo modelos data flow,discrete event, synchronous reactive, redes de Petri etc. O principal argumento para a necessidade dessacaracterística é a heterogeneidade das aplicações, ou seja, em um único sistema existem subsistemas dehardware dominados pelo fluxo de dados, software de tempo real, circuitos assíncronos, circuitosanalógicos, hardware dominado pelo fluxo de controle, etc. Dessa forma, um único modelocomputacional não é capaz de capturar eficientemente tais aplicações. A tarefa 4 visa estudar a aplicaçãode mais de um modelo computacional em uma única aplicação. Com base no resultado da adequação dopar primitiva/MoC, iremos utilizar especificações executáveis de sistema reais, ou parte desses sistemas,para verificar se o particionamento da especificação em vários MoCs é vantajosa.

É necessário considerar a implementação dos sistemas a partir de especificações executáveis. Istoimplica em analisar as metodologias de síntese, ou seja, uma seqüência de tarefas (e ferramentas CADassociadas) que refinam a especificação inicial até atingir um grau de abstração conhecido e dominado.Por exemplo, no caso da síntese de circuitos, o objetivo é criar uma descrição em nível comportamental[MIC94], ou uma descrição RTL para posterior síntese [MIC94]. No caso de software o objetivo é obterum programa em alguma linguagem seqüencial (por exemplo C), mais o sistema operacional. Na tarefa5, pretendemos escolher um número reduzido de MoCs adequados para síntese, e estudar a viabilidadede tradução/refinamento dos outros modelos para os modelos de síntese.

Na tarefa 6, iremos aplicar os resultados e conclusões obtidos nas 5 tarefas anteriores. A fim deevitar o tempo (longo) necessário para estudar as especificações de um sistema de grande porte e geraruma descrição inicial, adotaremos a estratégia de interagir com grupos de pesquisa que já realizaram essatarefa e com os quais estamos em contato. Possíveis exemplos18 para estudo de caso são:

� sistema para tradução de textos: em [FRA00], foi descrito um sistema embutido para atradução de textos utilizando uma solução com microprocessadores e ASIC. Tal sistema foidesenvolvido por colegas da Universidade Federal do Rio Grande do Sul;� codificador/Decodificador de Voz: em [GAJ00] está descrito detalhadamente em váriosníveis de abstração um sistema vocoder para telefones celulares;� sistemas para comunicação sem fio: nosso grupo de pesquisa possui um conjunto depesquisadores desenvolvendo soluções relacionadas à comunicação sem fio. Já foidesenvolvido em [GIU98] um módulo codificador/decodificador de canal utilizando códigosconvolucionaiss. Atualmente um aluno de mestrado e outro de doutorado estão aprimorandotal módulo utilizando técnicas iterativas [GIU00]. Outro aluno de doutorado estadesenvolvendo como parte de seu trabalho a implementação de alguns módulos do sistemaBluetooth [BLUE], um padrão de comunicação em radio freqüência para curtas distâncias;� modem ADSL: podemos ampliar o estudo de caso desenvolvido nesse trabalho ampliando afuncionalidade capturada, implementando novos módulos e utilizando outros MoCs.

18 Oportunamente, um ou mais destes exemplos, ou outros que possam surgir, serão usados para esta tarefa.

91

Referências Bibliográficas

[ADSL] ANSI/T1E1.413, Asymmetr ic Digital Subscr iber L ine (ADSL) Mettalic Inter face, June 12,1998.

[ARV82] Arvind, K. P. Gostelow, The U−Interpreter , Computer, February, 1982.

[BEN91] A. Benveniste, G. Berry, The Synchronous Approach to Reactive and Real−Time Systems,Proceedings of the IEEE, Vol. 79, No. 9, September 1991.

[BEC92] D. Becker, R. K. Singh, S. G. Tell, An Engineer ing Environment for HW/SW Co−Simulation, Proceedings of the Design Automation Conference, 1992.

[BER98] G. Berry, The Esterel v5 Language Primer , Centre de Mathématiques Appliquées, Ecole desMines and INRIA, March, 1998.

[BHA94] S. S. Bhattacharyya, Compiling Dataflow Programs for Digital Signal Processing, PhDDissertation, Dept. EECS, University of California, Berkeley, July, 1994.

[BIL96] G. Bilsen, M. Engels, R. Lauwereins, J. Peperstraete, Cyclo−Static Dataflow, IEEETransactions on Signal Processing, Vol. 44, No. 2, February, 1996.

[BLUE] Especificação do Padrão Bluetooth: http://www.bluetooth.com

[BRE98] J. E. Brewer, A New and Improved Roadmap, IEEE Circuits & Devices, March, 1998.

[BRO81] J. D. Brock, W. B. Ackerman, Scenar ios, a model of nondeterminate computation¨, Conf.on Formal Definition of Programming Concepts, LNCS 107, 1981.

[BUC93] J. T. Buck, Scheduling Dynamic Dataflow Graphs with Bounded Memory using theToken Flow Model, PhD Dissertation, Dept. EECS, University of California, Berkeley, 1993.

[CHA99] H. Chang, L. Cooke, M. Hunt, G. Martin, A. McNelly, L. Todd, Surviving the SOCRevolution : A Guide to Platform−Based Design, Kluwer Academic Publishers, ISBN 0−7923−8679−5, November, 1999.

[COS99] P. Coste, et al, Multilanguage Systems Codesign, 7th International Workshop onHardware/Software Codesign, May, 1999.l

[DAV82] A. L. Davis, R. M. Keller, Data Flow Program Graphs, Computer, February, 1982.

[DAV99] J. Davis II, et al, Ptolemy I I : Heterogeneous Concurrent Modeling and Design in Java,Report ERL No. M99/63, Dept. EECS, University of California, Berkeley, December, 1999.

[DEN80] J. B. Dennis, Data Flow Supercomputers, Computer, November, 1980.

[EDW94] S. Edwards, An Esterel Compiler for a Synchronous/Reactive Development System,Report ERL No. M94/43, Dept,. EECS, University of California, Berkeley, December, 1994.

[EDW97] S. Edwards, The Specification and Execution of Synchronous Reactive Systems, PhDDissertation, Report ERL, No. M97/31, Dept. EECS, University of California, Berkeley, 1997.

[FDR] Ferramenta FDR2, www.formal.demon.co.uk/FDR2.html , Formal Systems.

92[FRA00] D. T. Franco, L. Carro, Printed Text Translation System in FPGA, XV InternationalConference on Microelectronics and Packaging (SBMicro), September, 2000.

[GAJ00] D. D. Gajski, J. Zhu, R. Dömer, A. Gerstlauer, S. Zhao, SPECC: Specification Language andMethodology, Kluwer Academic Publishers, 2000.

[GIR99] A. Girault, B. Lee, E. A. Lee, Hierarchical Finite State Machines with MultipleConcurrency Models, IEEE Transactions on Computer−Aided Design of Integrated Circuits andSystems, Vol. 18., No. 6, June, 1999.

[GIU98] A. Giulietti, Projeto de um Par Codificador/Decodificador Convolucional Integrado,Dissertação de Mestrado, Departamento de Engenharia Elétrica, Escola Politécnica, Universidade de SãoPaulo, 1998.

[GIU00] A. Giulietti, et al., A Trade−off Study on Concatenated Channel Coding Techniques forHigh Data Rate Satellite Communications, 2nd International Symposium on Turbo Codes & RelatedTopics (BREST), September 2000.

[GOE98] M. Goel, Process Networks in Ptolemy I I , Report ERL M98/69, Dept. EECS, University ofCalifornia, Berkeley, December, 1998.

[GUP97] R. K. Gupta, S. Y. Liao, Using a Programming Language for Digital System Design, IEEEDesign & Test of Computers, April−June, 1997.

[HAL93] N. Halbwachs, Synchronous programming of reactive systems, Kluwer AcademicPublishers, ISBN 0−7923−9311−2, 1993.

[HAR87] D. Harel, StateCharts: A visual formalism for complex systems, Sci. Comput. Prog., vol 8,pp. 231−274, 1987.

[HUD89] P. Hudak, Conception, Evolution, and Application of Functional ProgrammingLanguages, ACM Computing Surveys, Vol. 21, No. 3, September 1989.

[HOA78] C. A. R. Hoare, Communicating Sequential Processes, Communications of the ACM, Vol.21, No. 8, August, 1978.

[HOA85] C. A. R. Hoare, Communicating Sequential Processes, Prentice Hall International, ISBN 0−13−153271−5, 1985.

[KAH74] G. Kahn, The Semantics of a Simple Language for Parallel Programming, InformationProcessing, 1974.

[KAH77] G. Kahn, D. B. MacQueen, Coroutines and Networks of Parallel Processes, InformationProcessing, 1977.

[KAR66] R. M. Karp, R. E. Miller, Properties of a Model for Parallel Computations: Determinacy,Termination, Queueing, SIAM J. Appl. Math, Vol. 14, No. 6, November, 1966.

[LAV99] L. Lavagno, E. Sentovich, ECL: A Specification Environment for System−Level Design,Proceedings of the ACM Design Automation Conference, 1999.

[LAV00] L. Lavagno, A. Sangiovanni−Vincentelli, E. Sentovich, Models of Computation for SystemDesign, em: Egon Boerger (ed.), Architecture Design and Validation Methods, Springer−Verlag, January2000, pp. 243−296.

93[LEE87a] E. A. Lee, D. G. Messerschmitt, Static Scheduling of Synchronous Data Flow Programs ofDigital Signal Processing, IEEE Transactions on Computer, Vol. C−36, No. 1, January, 1997.

[LEE87b] E. A. Lee, D. G. Messerschmitt, Synchronous Data Flow, Proceedings of the IEEE, Vol. 75,No. 9, September, 1987.

[LEE95] E. A. Lee, T. M. Parks, Dataflow Process Networks, Proceedings of the IEEE, Vol 83., No. 5,May, 1995.

[LEE98] E. A. Lee, A. Sangiovanni−Vincentelli, A Framework for Comparing Models ofComputation, IEEE Transactions on Computer−Aided Design of Integrated Circuits and Systems, Vol.17, No. 12, December, 1998.

[LIU98] J. Liu, Continuous Time and Mixed−Signal Simulaiton in Ptolemy I I , Report ERL M98/74,Dept. EECS, University of California, Berkeley, December, 1998.

[MAR98] J. Martin, et al, Modeling Reactive Systems in Java, ACM Transaction on DesignAutomation of Electronic Systems, Vol 3, No. 4, October 1998.

[MIC94] G. De Micheli, Synthesis and Optimization of Digital Circuits, McGraw−Hill InternationalEditions, ISBN 0−07−016333−2, 1994.

[MUL99] L. Muliadi, Discrete Event Modeling in Ptolemy I I , MS Report, Dept. EECS, University ofCalifornia, Berkeley, May, 1999.

[PAN92] P. Panagaden, V. Shanbhogue, The expressive power of indeterminate dataflow pr imitives,Inf. And Computation, Vol. 98, No. 1, May, 1992.

[PAR95] T. M. Parks, Bounded Scheduling of Process Networks, PhD Dissertation, Dept. EECS,University of California, Berkeley, December, 1995.

[PET81] J. L. Peterson, Petr i Net Theory and the Modeling of Systems, Pretince−Hall, ISBN 0−13−661983−5, 1981.

[REE95] H. J. Reekie, Realtime Signal Processing, PhD Dissertation, School of Electrical Engineering,University of Technology at Sydney, September, 1995.

[SMY98] N. Smyth, Communicating Sequential Processes Domain in Ptolemy I I , Report ERLM98/70, Dept. EECS, University of California, Berkeley, December, 1998.

[SYSC] System C User’s Guide, Version 1.0. http://www.systemc.org.

Study about Models of Computatoin for describing Digital Systems

Engineering

Transcript of Study about Models of Computatoin for describing Digital Systems