Annotations

Para validação da abordagem proposta, a implementação de alguns módulos de um controlador USB Host foi considerada como estudo de caso.

A USB, Universal Serial Bus, é uma especificação para a comunicação entre dispositivos e um controlador. Basicamente ela é uma porta serial de alta velocidade utilizada para a transmissão de dados entre dispositivos eletrônicos. Um sistema USB é composto por dois elementos, o USB host e o device. O USB host é o elemento responsável por gerenciar as transferências de dados que ocorrem utilizando o protocolo USB e por funcionar como uma interface entre o sistema operacional e o dispositivo (o USB host é geralmente encontrado em PCs). O dispositivo é o módulo que se conecta ao USB host para a troca de informações, como por exemplo, um pen-drive ou webcam.

No papel de interface entre o sistema operacional e o dispositivo, o USB Host utiliza uma região de memória compartilhada e um banco de registradores para transmitir informações. Para este estudo de caso focaremos na comunicação dos módulos internos do USB host e o banco de registradores que serve de interface para comunicação com o sistema.

A Figura 20 mostra um esquema simplificado dos módulos que compõem o USB Host.

Figur

A figura acima represen Host. Os módulos Root H e o sistema operacional, interno do sistema, com (States Control) e contro Frame Management). T Operational Registers, qu O estudo de caso é fo compõem o USB Host, Operational Registers. Para a validação da abor um USB Host que per controlador USB Host, comunicação entre o con banco de registradores, q Host e contém alguns r controlador USB Host. O sistema possui sete mó responsável pelo control Frame Management, Stat funcionalidade destes mó

gura 20 Esquema simplificado do USB Host

senta a arquitetura simplificada de um con ot Hub e Avalon Slave fazem a comunicação al, respectivamente. Os outros módulos cui omo interrupções (Interrupt Trigger), estad ntrole da transmissão dos dados (Execute ). Todos os módulos acessam os reg , que contém informações sobre o sistema.

focado nas comunicações entre alguns st, mais precisamente nas comunicações c

bordagem proposta, foi modelada a parte permite o driver controlar e receber in , e ainda alguns módulos de contro controlador USB Host e o driver é feita a s, que contém informações sobre o funciona s registradores operacionais que permite

módulos, sendo um deles o Operational R trole do módulo. Os outros são: Avalon Sla States Control, Execute Transaction e Interr

módulos pode ser abstraída neste estudo d

46

controlador USB ção com o device cuidam do status stado do sistema ute Transaction e registradores do módulos que s com o módulo rte do sistema de informações do trole interno. A ta a partir de um onamento do USB ite o controle do al Registers que é Slave, Root Hub, terrupt Trigger. A do de caso, pois a

47

informação aqui é focada apenas na comunicação destes módulos com o Operational Registers.

O módulo Operational Registers possui 64 registradores de 32 bits, que podem ser acessados tanto pelos módulos internos quanto pelo driver, através do módulo Avalon Slave (barramento avalon).

Os módulos foram especificados usando o profile UML-ESL com a ferramenta Visual Paradigm. Da especificação UML-ESL foi extraído o formato intermediário SLIF, que serviu como entrada para a ferramenta que implementa a abordagem proposta. Na modelagem foram definidos os módulos mencionados e como eles estão interconectados. Os diagramas de classe e de seqüência do módulo USB Host são mostrados nas Figura 21 e Figura 22, respectivamente.

Figura 21 Diagrama de classes do USB Host

O módulo Operational Registers (OR) oferece aos outros módulos os serviços de escrita e leitura de registradores. O tipo de dado do registrador é inteiro, o que significa que ele possui 32 bits, enquanto o endereço é do tipo char, que possui apenas 8 bits. O retorno da função também é um dado do tipo inteiro (32 bits).

48

Figura 22 Diagrama de seqüência do USB Host

As comunicações que podem ocorrer em paralelo são: o módulo Avalon Slave acessando o módulo Operational Register, o módulo Interrupt Ttrigger acessando módulo Operatinal Registers e o Rott Hub acessando também o Operational Register. As demais comunicações não podem ocorrer em paralelo. A Tabela 8 mostra as siglas utilizadas na demonstração do grafo e da arquitetura gerada.

Tabela 8 Siglas dos módulos USB

Nome do módulo Sigla

Avalon Slave AS Execute Transaction ET Frame Management FM Interrupt Trigger IT Root Hub RH States Control SC

As informações do arquivo SLIF que representam a modelagem UML-ESL da Figura 21 e Figura 22 acima resulta no grafo e sua coloração mostrados na Figura 23.

Figura 23 Grafos

O grafo representa as co “AS->OR”, “RH->OR” e paralelas, logo os vértice que indicam restrição. A conexão e os vértices qu meio de conexão. Vértice Figura 24 apresenta a ar partir da abordagem prop

Figura 24

Como resultado a plata Interrupt Trigger e o O Operational Registers, en um barramento.

afos gerados a partir da modelagem UML do USB H

s conexões entre os módulos do USB Host ” e “IT->OR” são representadas na Fig tices que as representam no grafo são unid

. Após a coloração, cada cor representa u que possuem a mesma cor são conectados tices com uma única cor são conectados pon

arquitetura de comunicação obtida para roposta.

24 Arquitetura gerada pela técnina apresentada

lataforma possui duas conexões ponto a Operational Registers e uma entre o R , enquanto os demais módulos são conectad

49

B Host

ost. As conexões Figura 22 como nidos por arestas, ta um recurso de dos a um mesmo ponto a ponto. A ara a USB host a

a ponto entre o o Root Hub e o ctados através de

50

Em relação ao código fonte, foram gerados 33 arquivos que compõem o sistema. O tempo para gerar estes arquivos foi cerca de 2 segundos em um AMD Athlon 64 X2 Dual Core 5000+ 2.60 Ghz com 4GB de memória RAM. Os arquivos gerados e o número de linhas de cada um são mostrados na Tabela 9.

Tabela 9. Arquivos gerados pela ferramenta

Arquivo Grupo N. de Linhas

avalon_slave_services.h modules 26 avalon_slave_interface.h 41 avalon_slave_behavior.h 36 frame_management_interface.h 41 frame_management_behavior.h 41 frame_management_services.h 26 interrupt_trigger_services.h 26 interrupt_trigger_interface.h 37 interrupt_trigger_behavior.h 37 execute_transaction_services.h 26 execute_transaction_interface.h 37 execute_transaction_behavior.h 36 operational_registers_services.h 59 operational_registers_interface.h 30 operational_registers_behavior.h 36 root_hub_services.h 26 root_hub_interface.h 37 root_hub_behavior.h 36 states_control_services.h 26 states_control_interface.h 37 states_control_behavior.h 36 bus0_core.h comunication 1106 bus0_states_control_interface.h 300 bus0_operational_registers_interface.h 300 bus0_interrupt_trigger_interface.h 339 bus0_execute_transaction_interface.h 300 p2p_frame_management2operational_registers_interface.h 303 p2p_root_hub2operational_registers_interface.h 301 p2p_operational_registers2root_hub_interface.h 309 p2p_operational_registers2frame_management_interface.h 309 00_top.cpp outros 311 definitions.h 28

No total foram geradas 3502 linhas de código, sendo 733 linhas de código dos módulos, 2430 linhas de código para estrutura de interconexão e 339 para os outros módulos.

Num teste onde os mó Operational Registers frame_management_beha operational_registers_ser informações temporais e chamadas entre os mód Figura 25 mostra as linh simulação do sistema.

O módulo Frame Mana registradores do Operatio em sua interface (frame_m função wait_sync serve p outros que compõe a root_hub_behavior.h frame_management_beha No módulo Operational adicionadas informações preenchimento do array é necessária porque o SLI como serviços utilizados Após a edição dos arqu compilação e execução d

módulos Frame Management e Root Hu rs foi preciso uma pequena edição

ehavior.h, root_hub_behavior.h

services.h, devido ao fato do UML-ESL gu is entre as comunicações, e não a seqüên

ódulos – o que define o funcionamento inhas adicionadas no módulo frame_manag

Figura 25 Trecho de arquivo editado

anagement utiliza os serviços de escrita ational Registers, para isto ele utiliza as fun e_managementint) que se comunica com o ve para sincronizar o funcionamento do m

a plataforma. A adição de código é bastante similar as modi ehavior.h e se referem a leitura de um regis nal Registers – operational_registers_servi ções referentes a inicialização do sistem ay que representa os registradores. Essa ad LIF guarda apenas informações estruturais os e oferecidos, e não informações de imple rquivos, a plataforma pode ser compilada o da plataforma, neste estudo de caso, fora

51 Hub acessam o o nos arquivos or.h e guardar somente üência inteira de to do sistema. A nagement para a

ita e leitura nos funções definidas o barramento. A o módulo com os igo no arquivo odificações do gistrador. ervices.h – foram tema, no caso o adição de código rais dos módulos,

plementação. da e utilizada. A foram feitas num

ambiente Linux, com a co SystemC. Na Figura 26 é na plataforma gerada pel

F

Na simulação o Frame Operational Registers. Pr os dados referentes a est tamanho 6. Em data[1] requisitada, neste caso o passado o primeiro parâ outros pacotes é enviado último parâmetro é divid pelo barramento, no caso RETRUN 1 significa que Ainda no mesmo exempl a leitura do mesmo regis

a compilação sendo feita com o g++ utilizan é mostrado um exemplo da execução de u pela ferramenta, com o estudo de caso apres

Figura 26 Simulação sendo executada

me Management escreve e lê em um r . Primeiro é escrito o valor 18300 no registr esta requisição são enviados por um paco a[1]: 1 é informado qual a operação qu

o o 1 representa o serviço de escrita. Em arâmetro, que se refere ao endereço do reg

do o valor a ser salvo no registrador. Note ividido em quatro partes para que possa s aso 18300 foi enviado byte a byte, a saber: 1 ue não houve problema na execução do serv

plo mostrado na Figura 26, o Frame Manag egistrador que foi escrito. Este serviço possu

52 zando a biblioteca e uma simulação presentado. registrador do istrador 13, onde acote que contém que está sendo m data[2]: 13 é registrador, e nos te que o valor do a ser transmitido r: 124, 71, 0 e 0. O serviço. nagement solicita ossui apenas dois

53

campos, o data[1]: 0 que representa o serviço, e o data[2]: 13 que representa o endereço. Novamente o RETURN indica o resultado da operação, que neste caso, foi o valor do registrador escrito anteriormente, isto é 18300.