suporte de hardware para a rede de trabalho do
TRANSCRIPT
UNIVERSIDADE FEDERAL DE SANTA CATARINA
PROGRAMA DE PÓS-GRADUAÇÃO EM CIÊNCIA DA
COMPUTAÇÃO
EGEU EDUARDO BERNI SOARES
SUPORTE DE HARDWARE PARA A REDE DE
TRABALHO DO MULTICOMPUTADOR CRUX
Dissertação submetida à Universidade Federal de Santa Catarina como parte dos requisitos
para a obtenção do grau de Mestre em Ciência da Computação
Orientador – Prof. Dr. Luiz Cláudio Villar dos Santos
Co-orientador – Prof. Dr. Thadeu Botteri Corso
Florianópolis, Agosto de 2002
SUPORTE DE HARDWARE PARA A REDE DE TRABALHO
DO MULTICOMPUTADOR CRUX
Egeu Eduardo Berni Soares
Esta Dissertação foi julgada adequada para a obtenção do título de Mestre em Ciência da
Computação, Área de Concentração Sistemas de Computação, e aprovada em sua forma final
pelo Programa de Pós-Graduação em Ciência da Computação.
________________________________________________
Prof. Fernando A. Osthuni Gauthier, Dr.– Coordenador
Banca Examinadora:
_________________________________________________________
Prof. Luiz Cláudio Villar dos Santos, Dr. – Orientador – INE – UFSC
___________________________________________________
Prof. Thadeu Botteri Corso, Dr. – Co-orientador – INE – UFSC
___________________________________________
Prof. Rômulo Silva de Oliveira, Dr. – DAS – UFSC
DEDICATÓRIA
À minha mãe Maria Luiza, à minha esposa Eliane Maria e à Maria de Nazaré,
as três Marias que me ajudaram a seguir adiante na conclusão deste trabalho.
AGRADECIMENTOS
À Letícia, minha filha, por seu amor que em muitos momentos difíceis foram um
bálsamo de alegria.
Ao meu filho Jonathan, o qual sempre esteve em meu coração.
Aos meus irmãos pelo incentivo, especialmente à Marli por sua grande dedicação.
Ao meu orientador Prof. Luiz Cláudio Villar dos Santos, por sua amizade, paciência e
estímulo nas horas mais difíceis.
Ao Prof. Thadeu B. Corso, por seu apoio na co-orientação deste trabalho e pela
oportunidade de participar de seu projeto, o Ambiente Multicomputador Crux.
Aos Engenheiros Fred Dart e Andy Dougan da FTDI e ao Engenheiro Brenden Ede da
Gigatechnology, por seu suporte com os módulos conversores USB.
Ao Engenheiro de Sistemas Bill Ryder, pela ajuda e esclarecimentos quanto ao driver
dos conversores USB e sistema operacional.
Ao Engenheiro Don Powrie, por seu suporte com o conversor USB/Paralelo.
Aos meus queridos colegas de estudos Rogério Xavier, Dione Ferrari, Madianita
Bogo, Luciana Rech e Patrícia Plentz.
E muito especialmente a meu pai, Venâncio Ayres (in memoriam).
RESUMO
Pesquisas em Computação Paralela realizadas na Universidade Federal de Santa
Catarina, resultaram no desenvolvimento da arquitetura de um multicomputador com rede de
interconexão configurável dinamicamente, conhecida como arquitetura Crux. Resultados
experimentais, obtidos através de simulações, mostraram fortes evidências de um desempenho
superior a arquiteturas paralelas clássicas. A chave desse ganho em desempenho é a escolha
de uma rede de interconexão deliberamente simples, pois a simplicidade elimina o "overhead"
devido ao conflito de mensagens nos meios de conexão.
Vários trabalhos já foram desenvolvidos tendo o Crux como arquitetura-alvo. Em
particular, foram desenvolvidos trabalhos de projeto do sistema de interconexão dos
elementos de processamento da arquitetura utilizando Links Transputer. No entanto, os Links
Transputer apresentaram uma alta complexidade e dificuldade de prototipação. No intuito de
encontrar uma solução mais simples para a implementação da rede de interconexão, resolveu-
se buscar uma alternativa de menor complexidade, baseada em componentes de fácil
aquisição no mercado, tornando a prototipação mais simples e rápida. O presente trabalho
apresenta uma alternativa que utiliza interfaces seriais padrão. Embora diminuindo a
velocidade de comunicação em relação aos Links Transputer, a alternativa proposta mantém a
simplicidade dos meios de conexão. Assim, apesar da diminuição da velocidade de
comunicação, espera-se que a degradação do desempenho seja pequena, pois se continua
garantindo a ausência de "overhead" devido a conflitos entre mensagens.
Este trabalho apresenta o projeto do protótipo de um "crossbar" e apresenta
componentes auxiliares de hardware para a rede de interconexão alternativa. São apresentados
diagramas esquemáticos do sistema digital que implementa tal "crossbar". O sistema digital
foi validado através de simulação temporal e mapeado para lógica programável. A descrição
esquemática do sistema digital foi feita em uma ferramenta de projeto auxiliado por
computador, o que permite sua futura implementação através de mapeamento automático para
um dispositivo lógico programável (e.g. FPGA).
ABSTRACT
As a result of research on Parallel Computing at the Santa Catarina Federal University
an architecture was developed for a multicomputer with dynamic network configuration,
known as the Crux architecture. Experimental results obtained through simulation have
shown strong evidence that the Crux architecture has superior performance when compared to
classical parallel architectures. The key for such performance gain is the choice of a network
whose simplicity avoids the overhead due to message conflicts over the interconnection
media.
Several research activities have been performed so far, using Crux as the target
architecture. In particular, a system was designed for the interconnection of the architecture's
processing elements, by means of Transputer Links. However, Transputer Links turn out to
lead to complex and difficult prototyping. In order to find a simpler solution for the network,
a less complex should be investigated for the sake of a fast and simpler prototyping. This
work presents an alternative to the implementation of the network, which is based on standard
serial interfaces. Although such alternative is slower as compared with Transputer Links, it
keeps the interconnection media simple. Therefore, despite the slower communication, the
degradation on performance can be expected to be very small, since the overhead due to
message conflicts is kept absent.
This work describes the design of a crossbar prototype and shows ancillary hardware
components for this implementation alternative. It shows schematic diagrams of the digital
system implementing the crossbar. The digital system has been validated through timing
simulation and mapped to programmable logic. The design was done with the help of a CAD
tool chosen to allow the future implementation of the circuit, through automatic mapping to a
programmable logic device (e.g. FPGA).
SUMÁRIO
LISTA DE FIGURAS ................................................................................................................v
LISTA DE TABELAS..............................................................................................................vii
LISTA DE ALGORITMOS .....................................................................................................vii
LISTA DE ACRÔNIMOS.........................................................................................................ix
1 – INTRODUÇÃO....................................................................................................................1
2 – VISÃO GERAL DO MULTICOMPUTADOR CRUX .......................................................3
2.1 – Arquitetura.....................................................................................................................3
2.2 – Trabalhos Anteriores .....................................................................................................6
2.3 – Contribuição deste Trabalho..........................................................................................6
3 – ANÁLISE DE REQUISITOS PARA O “CROSSBAR” .....................................................9
3.1 – Propriedades Gerais de um “Crossbar” Típico..............................................................9
3.1.1 – Interface ..................................................................................................................9
3.1.2 – Conectividade .........................................................................................................9
3.1.3 – Conexão Bidirecional .............................................................................................9
3.1.3 – Conclusões............................................................................................................11
3.2 – Especificação das Características Físicas ....................................................................11
3.3 – Especificação das Funções de Controle ......................................................................14
4 – A ESTRUTURA DO “CROSSBAR”.................................................................................17
4.1 – Descrição Geral do “Crossbar” ...................................................................................17
4.2 – Interfaces com os conversores USB ............................................................................20
4.2.1 – Interface com o Conversor USB/Serial ................................................................20
4.2.2 – Interface com o Conversor USB/Paralelo ............................................................21
4.3 – Descrição do “Datapath” .............................................................................................23
4.3.1 – Descrição da Célula de Conexão..........................................................................25
4.4 – Descrição do Controlador............................................................................................28
4.4.1 – Descrição do Decodificador .................................................................................30
4.4.2 – Descrição do Demultiplexador da Palavra ...........................................................31
4.4.3 – Descrição da Estrutura da Máquina de Estados ...................................................32
4.4.4 – Descrição do Funcionamento da Unidade de Controle ........................................33
4.4.5 – Construção das Máquinas de Estados...................................................................35
4.4.5.1 – Revisão Teórica .............................................................................................35
4.4.5.2 – Descrição dos Diagramas das Máquinas de Estados .....................................36
4.4.5.3 – A Entrada usb_sleep ......................................................................................39
4.4.5.4 – Sincronismo das Entradas..............................................................................40
4.4.5.5 – Sincronismo da Saída rd para Eliminação dos “Hazards” ............................40
4.5 – Conseqüências da Implementação em FPGA..............................................................42
4.5.1 – Mapeamento para o FPGA ...................................................................................42
4.5.2 – Discussão..............................................................................................................43
5 – VALIDAÇÃO EXPERIMENTAL.....................................................................................45
5.1 – O Sistema de CAD Utilizado ......................................................................................45
5.2 – Simulações Temporais.................................................................................................46
5.2.1 – Estabelecimento de Conexão................................................................................47
5.2.2 – Desconexão...........................................................................................................49
5.2.3 – Reinicialização da Unidade Operativa .................................................................50
5.2.4 – Operações no “Crossbar” .....................................................................................51
6 – A INTEGRAÇÃO DO HARDWARE DO “CROSSBAR” ...............................................53
6.1 - Componentes da Placa Mãe, Placas, Cabos e Custo do Sistema .................................53
6.2 – Estrutura da Placa Mãe................................................................................................55
7 – CONCLUSÕES..................................................................................................................57
7.1 – Contribuições desta Dissertação..................................................................................57
7.2 – Escalabilidade e Limitações da Implementação..........................................................58
7.3 – Perspectivas e Trabalhos Futuros ................................................................................59
APÊNDICE A - Diagramas Esquemáticos do "Crossbar" .......................................................61
A.1 – Diagramas Esquemáticos:...........................................................................................61
A.2 – Minimização das Funções das Máquinas de Estado...................................................67
APÊNDICE B – Módulos Conversores USB...........................................................................71
B.1 – Informações Adicionais sobre os Conversores USB ..................................................71
B.1.1 – Conversor USB/Serial..........................................................................................71
B.1.2 – Conversor USB/Paralelo......................................................................................73
B.1.3 – Alternativa ao Conversor USB/Paralelo ..............................................................75
B.1.4 – Software e Hardware para os Conversores USB .................................................77
B.2 – Principais Vantagens da Utilização dos Conversores USB. .......................................78
APÊNDICE C – Melhorias e Cuidados Operacionais. ............................................................81
C.1 – Melhorias Introduzidas ...............................................................................................81
C.2 – Melhorias Sugeridas ...................................................................................................86
C.3 – Cuidados Operacionais ...............................................................................................87
C.3.1 – Conectividade ......................................................................................................87
C.3.2 – Inicialização do Sistema ......................................................................................88
APÊNDICE D – “Crossbar” com Interfaces RS-232 (115,2 Kpbs).........................................91
D.1 - Componentes da Placa Mãe, Placas,Cabos e Custo do Sistema .................................91
D.2 – Estrutura da Placa Mãe ...............................................................................................93
APÊNDICE E – Discussão Sobre a Integração com o Sistema Operacional...........................95
E.1 – Desempenho do Driver de Dispositivo .......................................................................95
E.2 – Tempo de Atraso para Configuração do “Crossbar” ..................................................96
REFERÊNCIAS BIBLIOGRÁFICAS .....................................................................................99
iv
v
LISTA DE FIGURAS
Figura 1 - A arquitetura do multicomputador Crux....................................................................3
Figura 2 – Exemplo de conexão bidirecional entre dois nós trabalhadores .............................10
Figura 3 – Exemplo de conexão bidirecional entre quatro nós trabalhadores..........................10
Figura 4 – Esquema de interconexão dos módulos conversores com o FPGA. .......................13
Figura 5 – Diagrama em Blocos do “crossbar” ........................................................................17
Figura 6 – Diagrama de conexão do conversor USB/Serial com o DATAPATH. ....................20
Figura 7 – Diagrama da conexão entre o conversor USB/Paralelo e CONTROL ....................21
Figura 8 – Ciclo de leitura da fila do conversor USB/Paralelo em função do tempo. .............21
Figura 9 – Diagrama de Blocos do “datapath” .........................................................................23
Figura 10 – Diagrama de blocos da célula de conexão. ...........................................................25
Figura 11 – Diagrama de blocos da unidade de controle .........................................................28
Figura 12 – Diagrama de blocos do decodificador...................................................................30
Figura 13 – Diagrama de blocos de DEMUX_MSG_REG. ......................................................31
Figura 14 – Diagrama de blocos do circuito FSM e de seus componentes. .............................32
Figura 15 – Diagrama funcional para uma operação de conexão na unidade de controle .......34
Figura 16 – Diagrama de transição de estados de FSM_READ (máquina de leitura) .............36
Figura 17 – Diagrama de transição de estados de FSM_CFG (máquina de configuração)......37
Figura 18 – Diagrama de transição de estados de FSM_READ com a saída rd adiantada......41
Figura 22 – Primeira conexão na Unidade Operativa ..............................................................47
Figura 23 – Segunda conexão na Unidade Operativa ..............................................................48
Figura 24 – Desconexão na Unidade Operativa .......................................................................49
Figura 25 – Reinicialização da Unidade Operativa ..................................................................50
Figura 26 – Operações no “crossbar” .......................................................................................52
Figura 27 – “Layout” da estrutura da placa mãe do “crossbar”. ..............................................55
Figura 28 – Diagrama esquemático do “crossbar” ...................................................................61
Figura 29 – Diagrama esquemático do “datapath”...................................................................62
Figura 30 – Diagrama esquemático da célula de conexão........................................................63
Figura 31 – Diagrama esquemático do controlador (CONTROL). ...........................................63
Figura 32 – Diagrama do módulo CTRL do controlador (FSM e DEMUX_MSG_REG).........64
Figura 33 – Diagrama esquemático da estrutura do circuito FSM ...........................................64
Figura 34 – Diagrama do circuito DEMUX_MSG_REG..........................................................65
vi
Figura 35 – Diagrama esquemático do circuito REG_DEMUX ...............................................65
Figura 36 – Diagrama esquemático de DECODER..................................................................66
Figura 37 – Diagrama esquemático de OP_DECODER. .........................................................66
Figura 38 – Diagrama esquemático de DEST_DECODER. .....................................................66
Figura 39 – Diagrama esquemático da máquina de leitura (FSM_READ)...............................70
Figura 40 – Diagrama esquemático da máquina de configuração (FSM_CFG). .....................70
Figura 41 – Diagrama de temporização do ciclo de leitura do conversor USB/Paralelo .........73
Figura 42 – PIC16F877 Development Board” da Futurlec ......................................................75
Figura 43 – Conversor RS-232 / 8-bit paralelo TTL ligado ao FPGA. ....................................76
Figura 44 – Módulos conversores USB em tamanho natural...................................................79
Figura 45 – Diagrama esquemático de DECODER..................................................................81
Figura 46 – Diagrama de blocos da célula de conexão. ...........................................................82
Figura 47 – Mux de 2 entradas livre de “hazard”.....................................................................85
Figura 48 – Circuito verificador de CRC4 ITU-T....................................................................86
Figura 49 – Diagrama de Null-Modem para os conversores USB/Serial ................................87
vii
LISTA DE TABELAS
Tabela 1 – Codificação binária das mensagens de configuração .............................................15
Tabela 2 – Cabos e placas adaptadoras e seu custo para interfaces USB.................................53
Tabela 3 – Componentes da placa mãe e seu custo para interfaces USB.................................54
Tabela 4 – TTES correspondente ao DTE da Figura 18. .........................................................67
Tabela 5 – TTES correspondente ao DTE da Figura 17. .........................................................69
Tabela 6 – Cabos e placas adaptadoras e seu custo para interfaces RS-232 (115,2 Kbps). .....91
Tabela 7 – Componentes da placa mãe e seu custo para interfaces RS-232 (115,2Kbps). ......92
LISTA DE ALGORITMOS
Algoritmo 1 - Comunicação pela rede de trabalho.....................................................................4
Algoritmo 2 - Comunicação pela rede de controle.....................................................................5
viii
ix
LISTA DE ACRÔNIMOS
CAD: “Computer Aided Design”
CI: Circuito Integrado
DFF: Flip-flop do tipo D
DTE: Diagrama de transição de estados
E/S: Entrada e Saída
ECL: “Emitter Coupled Logic”
FIFO: “First In First Out”
FPGA: “Field Programable Gate Array”
FSM: Máquina de estados finitos
LVTTL: “Low Voltage Transistor Transistor Logic”
MUX: Multiplexador
PLD: Dispositivo lógico programável
RPC: Rede de processos comunicantes
TTES: Tabela de transição de estados e saídas
TTL: “Transistor Transistor Logic”
USB: “Universal Serial Bus”
x
1 – INTRODUÇÃOUm multicomputador é uma máquina que possui elementos de processamento
denominados de nós. Dados dois nós quaisquer de um multicomputador, eles podem se
comunicar através de um meio de conexão denominado de canal físico. Cada nó é composto
por um processador e uma memória dedicada.
Canais físicos são organizados na forma de redes de interconexão. Tais redes podem
ser assim classificadas:
• As redes estáticas são ligadas por canais físicos permanentes (exemplo: anel,
árvore, grelha, tórus, hipercubo, grafo completo) [Cor99].
• As redes dinâmicas são ligadas por canais físicos temporários (exemplo:
barramento, multiestágios, “crossbar”) [Cor99][Hen98].
Um canal lógico é um canal virtual que pode ser mapeado sobre um ou mais canais
físicos diferentes durante a sua existência.
Uma rede de processos comunicantes (RPC) é um programa paralelo composto por
processos que interagem exclusivamente por troca de mensagens através de canais lógicos.
Um programa paralelo pode ter uma topologia estática durante toda sua execução ou ainda
apresentar variações topológicas resultantes da criação dinâmica de processos e/ou canais
lógicos.
O desempenho de uma RPC está ligado ao mapeamento da rede lógica sobre a rede
física (rede de interconexão). Este mapeamento consiste de um mapeamento de processos
(atribuição de processos a nós) e de um mapeamento de canais lógicos (atribuição de canais
lógicos a canais físicos).
Algumas situações especiais de mapeamento podem ser caracterizadas como segue. O
mapeamento de um processo é dito perfeito quando a ele é atribuído com exclusividade um nó
pela duração exata do processo. O mapeamento de um canal lógico é dito perfeito quando a
ele é atribuído com exclusividade um canal físico dedicado pela duração exata do canal
lógico. O mapeamento de uma RPC é dito perfeito quando o mapeamento de todos os seus
processos e canais lógicos forem perfeitos.
Quando o mapeamento perfeito não é possível, o mapeamento de redes lógicas para
obter uma execução eficiente pode ser uma tarefa complexa [Ree87] apud [Cor98]. No
entanto, o mapeamento perfeito leva ao mais alto desempenho possível e ao mecanismo de
comunicação mais simples possível.
2
Pesquisas na área de Computação Paralela realizadas nesta universidade, resultaram no
desenvolvimento da arquitetura de um multicomputador, denominado Crux. Para suportar a
execução de programas paralelos como redes de processos comunicantes, o mecanismo de
comunicação da máquina Crux baseia-se na atribuição de canais físicos dirigida por demanda.
Esse novo ambiente multicomputador garante a transferência de mensagens completas de
qualquer tamanho e de uma só vez através de canais físicos dedicados entre qualquer par de
nós, garantindo o mapeamento perfeito sempre que possível e permitindo o compartilhamento
simultâneo de seus recursos físicos entre diversas RPCs de variadas topologias [Cor98].
Resultados experimentais gerados via simulação revelaram a superioridade do Crux sobre
outros multicomputadores de tamanho médio.
O objetivo deste trabalho é o projeto do hardware de uma rede de interconexão
dinâmica do tipo “crossbar” e a determinação dos componentes de hardware que integrarão a
rede de trabalho da máquina Crux. Ao invés de se utilizar de “links transputer” como em
trabalhos anteriores [Zef96] [Gav00], este trabalho baseia-se em meios de comunicação
alternativos, de maior disponibilidade no mercado. O protótipo do “crossbar” utilizará
dispositivos lógicos programáveis.
Este trabalho é organizado como segue. O Capítulo 2 esboça a arquitetura do
multicomputador Crux, reporta os principais resultados de trabalhos anteriores e apresenta a
contribuição deste trabalho. No Capítulo 3 são analisados os requisitos para o novo
“crossbar”. A estrutura do “crossbar” é apresentada no Capítulo 4. A validação experimental
do projeto conceitual pode ser encontrada no Capítulo 5. No Capítulo 6 é esboçada a
integração dos módulos de comunicação com o FPGA em uma mesma placa, doravante
denominada de placa-mãe, e são apresentados os demais componentes de hardware
necessários e custo do sistema. No Capítulo 7 são apresentadas conclusões e perspectivas para
trabalhos futuros. Os diagramas esquemáticos do “crossbar” gerados em um sistema de CAD
podem ser encontrados no Apêndice A. Informações adicionais sobre os módulos de
comunicação utilizados na interface são encontradas no Apêndice B . Melhorias introduzidas
no sistema e cuidados operacionais são apresentados no Apêndice C. No Apêndice D são
apresentados os componentes de hardware da rede de trabalho, com um meio de transmissão
alternativo, para comparação com a solução adotada no que diz respeito a custo e benefício.
2 – VISÃO GERAL DO MULTICOMPUTADOR CRUX
2.1 – Arquitetura
O multicomputador Crux foi concebido para prover um alto grau de flexibilidade.
Com o objetivo de maximizar o desempenho sem abrir mão da simplicidade do sistema, o
Crux utiliza as seguintes idéias-chave [Cor98]:
• Deve-se permitir o compartilhamento de seus recursos físicos entre diversas RPCs
de variadas topologias;
• Deve-se garantir o mapeamento perfeito sempre que possível;
• Deve-se buscar a comunicação direta através de mensagens completas.
A arquitetura do multicomputador Crux é composta dos seguintes elementos,
conforme ilustra a Figura 1:
• Um número expressivo de nós trabalhadores . Os processos da RPC serão
alocados nos nós trabalhadores, que possuem processador, memória dedicada e
canais de comunicação.
• Um nó controlador responsável pela configuração da rede de trabalho e que
gerencia a conexão e desconexão dos canais físicos entre nós trabalhadores e a
alocação/liberação dos nós trabalhadores.
• Uma rede de trabalho (“crossbar”) para transportar mensagens entre os nós
trabalhadores através de canais físicos, que são configurados pelo nó controlador.
• Uma rede de controle (barramento) para conduzir mensagens entre os nós de
trabalho e o nó de controle.
Figura 1 - A arquitetura do multicomputador Crux
Rede de trabalho (crossbar)
Canal decomunicação econtrole
Nó traba-lhador
Nó traba-lhador
Nó traba-lhador
Nó decontrole
Canal deconfiguração
Canais decomuni-cação
Rede de controle (barramento)
4
Conforme já mencionado anteriormente, o Crux utiliza um mecanismo de conexão
dinâmica com atribuição de canais físicos dirigida por demanda. Tal mecanismo ocorre em
dois níveis distintos:
• Alto nível: A rede de trabalho é utilizada para transportar as mensagens da RPC
através de canais físicos diretos entre os nós trabalhadores onde os processos são
executados. Estes canais físicos são configurados pelo nó de controle. Este nível se
caracteriza por uma rede de uso geral e por mensagens longas entre dois nós
trabalhadores quaisquer.
• Baixo nível: A rede de controle é utilizada para gerenciar a conexão e desconexão
de canais físicos entre nós trabalhadores e alocação e liberação de nós
trabalhadores. Ela transporta mensagens entre os nós trabalhadores e o nó de
controle contendo pedidos de conexão e desconexão. Este nível se caracteriza por
uma rede de uso específico e por mensagens curtas entre o nó controlador e um nó
trabalhador qualquer.
O mecanismo de comunicação dirigido por demanda é descrito pelo Algoritmo 1 e
Algoritmo 2.
Algoritmo 1 - Comunicação pela rede de trabalho
se não existe conexão então
Solicita Conexão ();
envia/recebe mensagem;
se a conexão não interessa mais então
Solicita Desconexão ();
5
Algoritmo 2 - Comunicação pela rede de controle
Conforme se depreende do Algoritmo 1, antes de a comunicação entre dois nós
trabalhadores ser executada, verifica-se a existência de um canal de comunicação entre eles.
Caso exista, a comunicação é logo iniciada; caso não exista, a comunicação é precedida por
um procedimento de conexão, descrito no Algoritmo 2.
Como pode ser observado no Algoritmo 1, a duração de um canal físico pode variar
desde o tempo de transmissão de uma única mensagem até o tempo de execução de um
programa paralelo completo, pois o procedimento de desconexão é condicionado à
necessidade de comunicação de um dado nó trabalhador.
Esse mecanismo de comunicação pode ser implementado por um componente central
executado no nó controlador e por componentes locais executados em cada nó trabalhador. O
componente central é responsável pela configuração da rede de trabalho, conectando e
desconectando canais físicos em resposta a requisições vindas dos nós trabalhadores. Os
componentes locais, acessíveis através de um pequeno conjunto de operadores, interagem
com o componente central para a implementação do mecanismo de comunicação.
Para complementar o suporte básico para a execução de RPCs, é também necessário
um mecanismo de alocação/liberação de nós trabalhadores dirigido por demanda, associado
com a criação/destruição de processos. De forma análoga ao mecanismo de comunicação, este
serviço pode ser realizado por um componente central executado no nó controlador e por
componentes locais executados em cada nó trabalhador [Cor98]. Este mecanismo, entretanto,
está fora do âmbito deste trabalho.
Solicita Conexão ()
{
envia mensagem solicitando conexão;
recebe resposta confirmando conexão;
}
Solicita Desconexão ()
{
envia mensagem solicitando desconexão;
recebe resposta confirmando desconexão;
}
6
2.2 – Trabalhos Anteriores
Muitos trabalhos já foram realizados no âmbito do multicomputador Crux. A
arquitetura já está bem definida e várias simulações já foram feitas. Os resultados da avaliação
de desempenho através de simulações são bastante promissores. Grande parte do software
básico para a realização do multicomputador já foi desenvolvido. Já foram realizados
trabalhos de simulação [Can00][Boi96], softwares de comunicação [Sil00], sistema
operacional [Mer96][Cor99], etc. Quanto ao projeto do hardware em particular desenvolveu-
se um projeto completo do sistema de comunicação para o multicomputador Crux [Zef96],
utilizando para isto “links transputer” e o “crossbar” IMS C004 da INMOS [Inm88]. Devido à
dificuldade de aquisição deste “crossbar”, desenvolveu-se uma rede de interconexão do tipo
“crossbar”, utilizando dispositivos lógicos programáveis, mantendo as mesmas características
funcionais do “crossbar” programável IMS C004 da INMOS, mas adaptando-o
especificamente para o sistema de comunicação do multicomputador paralelo [Gav00].
Em um trabalho preliminar, que serviu de base para esta dissertação, foi desenvolvido
um projeto conceitual de um “crossbar” com controle baseado em interface serial assíncrona
[Soa01].
2.3 – Contribuição deste Trabalho
O primeiro trabalho proposto para interconexão do multicomputador pressupunha a
utilização de um “crossbar” comercialmente disponível [Zef96]. O segundo trabalho propôs a
substituição do “crossbar” comercial, de difícil aquisição, por um protótipo baseado em
dispositivos lógicos programáveis do tipo FPGA [Gav00]. Ambos os projetos utilizavam
“links transputer” em sua concepção. Atualmente está se buscando projetar os meios de
interconexão tornando-os o mais simples possível. Nesta busca de simplicidade surgiu a idéia
de se projetar um “crossbar” que não requeira a utilização de um “link transputer”. Ao invés
de "links transputer”, as redes utilizam como meio de comunicação conexões via interfaces
seriais padrões.
A contribuição deste trabalho é justamente a concepção de um “crossbar” para compor
a rede de trabalho do multicomputador Crux, utilizando para isto os meios de conexão citados
acima. O projeto da estrutura do “crossbar” será realizado diretamente em nível lógico. O
mapeamento para um dispositivo lógico programável escolhido será feito automaticamente
usando um sistema de CAD e será mostrado no Capítulo 4. Os diagramas do sistema digital
resultante podem ser encontrados no Apêndice A. Além do projeto deste sistema digital será
7
também especificado o hardware necessário para interconexão entre o “crossbar” e o nó de
controle e os nós de trabalho do multicomputador.
A rede de controle não faz parte do escopo deste trabalho. Para esta, será utilizado
provavelmente um barramento Ethernet.
Este trabalho complementa o projeto conceitual apresentado em [Soa01] nos seguintes
aspectos:
• foram definidas na prática as interfaces e meio de transmissão entre o “crossbar” e
os nós do multicomputador;
• as interfaces com o meio de transmissão e com o “crossbar” foram separadas em
módulos independentes;
• uma série de refinamentos foram aplicados à unidade de controle e à unidade
operativa do projeto conceitual para adequar os mesmos às condições de operação
de um protótipo real;
• o projeto foi simulado sob condições que buscam capturar as reais condições de
funcionamento do futuro protótipo;
• o projeto foi simulado levando-se em conta as características de um dispositivo
lógico programável específico.
8
3 – ANÁLISE DE REQUISITOS PARA O “CROSSBAR”
3.1 – Propriedades Gerais de um “Crossbar” Típico
Um “crossbar” [Inm88] possui algumas propriedades específicas que serão descritas
nesta seção. Estas propriedades dizem respeito à sua interface e à suas características de
conectividade.
3.1.1 – Interface
Um “crossbar” típico possui um conjunto de entradas e um conjunto de saídas. O
roteamento dos dados entre uma entrada e uma saída é implementado através de chaves
unidirecionais. Conseqüentemente, são necessários canais separados de transmissão e de
recepção de dados, para suportar a comunicação bidirecional entre os nós de um
multicomputador.
3.1.2 – Conectividade
São as seguintes, as regras de conectividade de um “crossbar” típico:
• Essencialmente, dada uma entrada qualquer do “crossbar”, ela pode ser conectada
a qualquer saída, desde que os meios de conexão no caminho entre entrada e saída
estejam livres.
• Dada uma saída, apenas uma entrada pode ser selecionada para ser a ela conectada
em um dado instante de tempo.
• Dada uma entrada, ela pode ser conectada a várias saídas simultaneamente
(“multicasting”).
3.1.3 – Conexão Bidirecional
Quando dois nós precisam trocar mensagens entre si, eles demandam duas conexões
unidirecionais para implementar uma conexão bidirecional. Assuma que dois nós x e y,
utilizem canais de comunicação distintos, um para transmissão e outro para recepção.
Suponha que xout (yout) designe o canal utilizado pelo nó x (y) para transmissão e que xin (yin)
designe o canal utilizado pelo nó x (y) para recepção. O canal bidirecional entre x e y é assim
obtido:
• xout é conectado a yin;
• yout é conectado a xin.
10
A Figura 2 e a Figura 3 mostram exemplos de conexões bidirecionais para dois e
quatro nós, respectivamente. Em cada figura, a conexão interna ao “crossbar” (mostrada
esquematicamente com linhas pontilhadas) refere-se a apenas uma das possíveis conexões
listadas (destacada em negrito).
Figura 2 – Exemplo de conexão bidirecional entre dois nós trabalhadores
Figura 3 – Exemplo de conexão bidirecional entre quatro nós trabalhadores
Rx
RxTx
Tx N0
N1
Possíveis conexões:
N0 N0
N0 N1
N1
N0
0 0
1 1
2 2
3 3
N3
N2
Possíveis conexões:
N0 N0
N0 N1
N0 N2
N0 N3
N1 N1
N1 N2
N1 N3
N2 N2
N2 N3
N3 N3
11
3.1.3 – Conclusões
Em face das propriedades de um “crossbar” típico acima analisadas, algumas
conclusões podem ser derivadas:
• Regra de conectividade externa ao “crossbar”: Dado um nó trabalhador Ni, seu
canal transmissor deve ser conectado à entrada Ii do “crossbar” e seu canal
receptor deve ser conectado à saída Oi do “crossbar”.
• Máxima conectividade do “crossbar”: Um “crossbar” N x N é capaz de conectar
no máximo N nós trabalhadores de forma bidirecional.
• Conexão bidirecional: Dados dois nós trabalhadores Ni e Nj, sua conexão
bidirecional pressupõe a conexão de dois caminhos através do “crossbar” se i ≠ j.
3.2 – Especificação das Características Físicas
O projeto aqui proposto para o “crossbar” terá 32 entradas e 32 saídas; ou seja, trata-se
de um “crossbar” 32 x 32.
Um cenário possível para tal configuração seriam 8 PCs com 4 portas de E/S cada,
totalizando 32 portas de E/S.
Uma das diretrizes do projeto é a futura implementação do “crossbar” utilizando-se
um circuito integrado personalizável através de dispositivos lógicos programáveis, devido à
facilidade de prototipação. Para se obter menor custo e maior simplicidade/confiabilidade,
decidiu-se impor uma restrição ao projeto: todo o “crossbar” deverá estar contido em um
único circuito integrado baseado em lógica programável. A escolha do estilo de lógica
programável recaiu sobre dispositivos do tipo FPGA (Field Programmable Gate Array), um
dispositivo baseado em arranjo de blocos de portas lógicas [Mic94].
O FPGA adotado pertence à família de dispositivos da Altera (um dos fornecedores
dessa tecnologia) [Alt01]. A opção pelos circuitos integrados da Altera justifica-se pela
existência de um “Altera Design Center” associado ao Curso de Engenharia Elétrica da
UFSC, onde se dispõe de hardware e software para a personalização daqueles circuitos
lógicos programáveis. O circuito será construído com multiplexadores, registradores,
decodificadores e portas lógicas.
O projeto do “crossbar” em um único FPGA foi realizado através de ferramentas de
entrada e captura esquemáticas de um sistema de CAD fornecido pela Altera, denominado
MAX+PLUS II. Esse pacote compreende não só ferramentas de edição esquemática de
circuitos lógicos, mas também ferramentas para a compilação, a simulação, a análise
12
temporal, bem como a programação do dispositivo. O dispositivo escolhido para o protótipo
pertence à família Acex 1K [Ace01], e irá operar à freqüência de 12 MHz.
Como o FPGA da Altera opera em níveis de tensão compatíveis com tecnologia TTL,
o canal de configuração e as entradas e saídas deverão operar de acordo com a
correspondência entre tensões e níveis lógicos TTL.
Uma premissa básica do projeto é a simplicidade de conexão dos canais aos PCs, o
que requer o uso de interfaces padrão comercialmente disponíveis. Por representar um bom
compromisso entre disponibilidade e velocidade, adotou-se como requisito o uso de interfaces
USB [USB00] como forma de conexão aos PCs.
Em suma, há um requisito de compatibilidade com o padrão USB do lado do PC e um
requisito de compatibilidade elétrica com o FPGA do lado do "crossbar". Para atender ao
último, conversores USB/TTL precisam ser inseridos em cada canal. Para o canal de
configuração, adotou-se um módulo de conversão com entrada USB e saída paralela de 8 bits.
Para os canais de comunicação, adotaram-se módulos de conversão com entrada USB e saída
serial.
Ambos os módulos conversores são desenvolvidos pela Gigatechnology.com Pty Ltd
[Gig02] e compõem-se de circuitos integrados fabricados pela Future Technology Devices
Intl. (FTDI) [Ftd02]. Estes conversores são os módulos USBMOD1 (USB/Serial) e
USBMOD2 (USB/Paralelo) que suportam taxas de transmissão máximas de 3Mbps e 8Mbps,
respectivamente.
Note que, ao prover a compatibilidade elétrica entre o crossbar e os PCs, estes
módulos simplificam o protótipo (uma das premissas do projeto). A confecção do protótipo
consistirá praticamente em conectar os módulos conversores diretamente ao FPGA. Por
simplicidade, tais módulos conversores serão doravante chamados de conversor
USB/Paralelo e conversor USB/Serial.
13
Figura 4 – Esquema de interconexão dos módulos conversores com o FPGA.
A Figura 4 ilustra como o "crossbar" será conectado aos módulos conversores.
Observe que há um conversor USB/Serial conectado a cada canal de comunicação. Os
sinais d+ e d- associados ao conversor representam o par diferencial utilizado no padrão USB
para transmissão “half-duplex” [USB00]. TX e RX são os sinais de transmissão e recepção da
interface serial padrão, respectivamente. RTS e CTS são os sinais de “handshaking” para
transmissão serial assíncrona [Man88]. O comportamento do conversor USB/Serial é
brevemente descrito na Seção 4.2.1. A estrutura do conversor e aspectos técnicos mais
relevantes são apresentados no Apêndice B. Uma descrição detalhada do conversor pode ser
encontrada em [F3200][G3201].
14
Note que há um conversor USB/Paralelo conectado ao canal de configuração. O sinal
dat[7..0] representa um barramento que transporta bytes da saída do conversor para o
controlador do "crossbar". Os sinais de “handshaking” rxf, rd e usb_sleep são usados para a
o controle da transmissão assíncrona de bytes para o "crossbar". O comportamento do
conversor USB/Paralelo é brevemente descrito na Seção 4.2.2. A estrutura do conversor e
aspectos técnicos mais relevantes são apresentados no Apêndice B. Uma descrição detalhada
do conversor pode ser encontrada em [F3200][G3201].
3.3 – Especificação das Funções de Controle
A comunicação do nó de controle com o “crossbar” ocorrerá através do canal de
configuração. A partir do nó de controle fluirão mensagens para o “crossbar”, expressas
simbolicamente da seguinte forma:
opcode ([fonte , destino]),
onde opcode é o código da operação desejada e fonte e destino são, respectivamente,
os identificadores dos nós trabalhadores que produzem e consomem dados em um canal
unidirecional. Os colchetes indicam que a existência dos campos por eles delimitados depende
de opcode.
As mensagens têm sempre dois bytes e seu formato binário é o seguinte:
ooff fffd dddd 0000,
onde oo representa os dois bits do campo opcode, ff fff representa os cinco bits do
identificador de fonte e d dddd representa os cinco bits do identificador de destino.
Os quatro bits menos significativos da mensagem são reservados para futura
implementação de um código de correção de erro, conforme sugerido na Seção C.2.
As possíveis mensagens recebidas pela unidade de controle são as seguintes:
• connect (x, y): comanda a conexão do nó x com o nó y utilizando para isto uma
linha de conexão livre do “crossbar”. A existência de linha de conexão livre é
monitorada e controlada pelo sistema operacional.
• disconnect (x, y): comanda a desconexão do nó x como o nó y. A saída
correspondente ao nó y (destino) é levada para o nível 1. O sistema operacional
garante que esta mensagem seja enviada apenas para conexões existentes.
• reset ( ): reinicializa o “crossbar” levando todas as saídas para o nível 1 (todas as
linhas desconectadas).
15
A correspondência entre o mnemônico de cada mensagem e seu respectivo formato
binário é mostrada na Tabela 1.
Tabela 1 – Codificação binária das mensagens de configuração
Mnemônico Byte mais significativo Byte menos significativo
Connect(x,y) 01ff fffd dddd 0000
Disconnect(x,y) 10ff fffd dddd 0000
reset() 0000 0000 0000 0000
A transmissão serial da mensagem será feita de forma que, para uma dada mensagem,
o byte menos significativo é enviado em primeiro lugar.
16
4 – A ESTRUTURA DO “CROSSBAR”Neste capítulo é apresentada a estrutura do “crossbar” proposto, através de diagramas
em blocos, seguindo uma abordagem hierárquica descendente, do geral para o detalhado. O
projeto foi realizado com circuitos lógicos cujos níveis de tensão são compatíveis com
tecnologia TTL (“transistor-transistor logic”). Adotou-se como convenção grafar em itálico
no texto as referências aos componentes, entradas, saídas e sinais contidos nestes diagramas.
4.1 – Descrição Geral do “Crossbar”
O “crossbar”, ilustrado na Figura 5, é formado por uma unidade de controle
(CONTROL) e uma unidade operativa (DATAPATH).
Ao diagrama em blocos da Figura 5 corresponde o diagrama esquemático da Figura
28, que pode ser encontrado no Apêndice A.
Figura 5 – Diagrama em Blocos do “crossbar”
A unidade de controle possui três entradas (usb_sleep, rxf e dat[7..0]) e seis saídas (cd,
load_cd, src, load_src, cdreset e rd), além das entradas clk (relógio do sistema) e rst (reset do
sistema).
As entradas da unidade de controle (usb_sleep, rxf e dat[7..0]), em conjunto com a
saída rd, formam o mecanismo assíncrono de leitura dos bytes do conversor USB/Paralelo,
como será descrito na Seção 4.2.2. Através da entrada dat[7..0], o conversor USB/Paralelo
envia um byte por vez ao controlador do "crossbar". Cada par de bytes recebidos codifica uma
18
mensagem do nó controlador, que consiste de opcode, endereço fonte e endereço destino (veja
Seção 3.3).
As demais saídas da unidade de controle (cd, load_cd, src, load_src, cdreset) são os
sinais que comandam o DATAPATH e serão doravante denominados de sinais de controle.
Depois que os dois bytes da mensagem forem recebidos, a unidade de controle decodifica o
opcode e identifica os endereços fonte e destino. Em seguida, ela emite os sinais de controle
que comandam a operação decodificada entre os nós identificados. Os sinais de controle
comandam uma operação de conexão, de desconexão ou de “reset” no DATAPATH. Por
razões a serem discutidas posteriormente, cada operação se concretiza após dois ciclos de
relógio, após a emissão dos sinais de controle.
A Figura 5 mostra que o DATAPATH possui um conjunto de 32 canais de entrada,
representados pelo sinal in[31..0][1..0]. (Dado um canal genérico k, os sinais in[k][0] e
in[k][1] são conectados às saídas TX e RTS# do respectivo conversor USB/Serial, como será
explicado na Seção 4.2.1). Por outro lado, o DATAPATH possui um conjunto de 32 canais de
saída, representados pelo sinal out[31..0][1..0]. (Dado um canal genérico k, os sinais
out[k][0] e out[k][1] são conectados às entradas RX e CTS# do respectivo conversor
USB/Serial, como será explicado na Seção 4.2.1). Além das seis entradas do DATAPATH
associadas aos sinais de controle (cd, load_cd, src, load_src, cdreset e rd), ele também é
acionado pelas entradas clk (relógio do sistema) e rst (reset do sistema).
O roteamento de canais através do "crossbar" consiste de três ações básicas: a seleção
do canal de entrada a partir do endereço fonte, a seleção do canal de saída a partir da
decodificação do endereço destino e o execução da operação a partir da decodificação do
opcode.
A seleção do canal de entrada é comandada pelo sinal de controle src, que
corresponde aos 5 bits do endereço fonte extraídos diretamente da mensagem, sem qualquer
decodificação. Se o endereço fonte é i, este sinal provoca a seleção do canal in[i][1..0].
A seleção do canal de saída é comandada pelo sinal de controle load_src que se
compõe de 32 bits. Somente um destes bits será ativado, como resultado da decodificação do
endereço destino contido na mensagem. Se o endereço destino é j, apenas o j-ésimo bit dos
sinais load_src é ativado. A ativação do j-ésimo bit do sinal load_src provoca o roteamento
entre o canal de entrada in[i][1..0] com o canal de saída out[j][1..0].
A execução da operação é comandada por dois sinais de controle correlatos (cd e
load_cd). O sinal cd indica se o canal de saída será conectado ou desconectado do canal de
entrada. Quando o opcode da mensagem corresponder a uma operação de conexão, o sinal de
19
controle cd é ativado (cd=1), sendo desativado (cd=0) se a operação for de desconexão. O
sinal load_cd, que também consiste de 32 bits, tem um de seus bits ativado a partir da
decodificação do endereço destino contido na mensagem. É este sinal que efetivamente
provoca a operação indicada pelo sinal cd (conexão ou desconexão) entre os canais de
entrada e saída selecionados.
Quando o opcode da mensagem corresponder à operação “reset” o sinal de controle
cdreset é ativado fazendo com que todos os canais de saída sejam desconectados. Neste caso,
o valor do sinal cd (conexão/desconexão) é irrelevante.
20
4.2 – Interfaces com os conversores USB
4.2.1 – Interface com o Conversor USB/Serial
Relembrando que a cada porta de comunicação com nós trabalhadores estará associado
um conversor USB/Serial, descreve-se a seguir o comportamento dos sinais na interface entre
tal conversor e o DATAPATH do "crossbar" como ilustrado na Figura 6:
Figura 6 – Diagrama de conexão do conversor USB/Serial com o DATAPATH.
• TX: Transmite dados a partir do nó trabalhador, através do “Datapath”, para outro
nó trabalhador em formato serial assíncrono TTL.
• RX Recebe dados vindos de outro nó trabalhador através do “datapath” em
formato serial assíncrono TTL.
• RTS#: Quando em nível 1 impede que dados sejam enviados de outro nó
trabalhador para a entrada RX. Quando em nível 0 indica que mais dados podem
ser recebidos
• CTS#: Quando recebe o nível 1 de RTS#, do nó trabalhador correspondente, pára a
transmissão de dados a partir da saída TX. Quando recebe o nível 0 continua a
transmissão a partir de TX
• RI#: Deve ser conectado a CTS# e permite que o conversor seja “acordado”, caso
esteja em um estado de repouso (“suspend mode”) quando de uma chegada de
dados (veja a Seção B.1.1 para detalhes de operação do módulo conversor).
Importantes observações e cuidados operacionais sobre este conversor USB/Serial são
discutidos nos Apêndices (Seção B.1.1 e Seção C.3).
21
4.2.2 – Interface com o Conversor USB/Paralelo
Conforme ilustra a Figura 7, as entradas para a unidade de controle são usb_sleep, rxf
e dat[7..0], que em conjunto com a saída rd, formam o mecanismo assíncrono de transmissão
de bytes da mensagem para a unidade de controle do "crossbar”.
Figura 7 – Diagrama da conexão entre o conversor USB/Paralelo e CONTROL
Figura 8 – Ciclo de leitura da fila do conversor USB/Paralelo em função do tempo.
Os bytes recebidos através do barramento USB são armazenados em um “buffer” de
recebimento, que implementa uma estrutura de fila (FIFO), enquanto não são levados à saída
do conversor. Segue abaixo uma descrição sucinta do mecanismo da interface entre o
conversor USB/Paralelo e a unidade de controle do "crossbar", que pode ser acompanhado
pela Figura 7 e pelo diagrama do ciclo de leitura da fila do conversor em função do tempo
ilustrado na Figura 8.
22
• RD# (rd): Quando em nível lógico 0, RD# provoca o envio do primeiro byte na
fila do conversor para a entrada dat[7..0] da unidade de controle. Quando em nível
lógico 1, RD# coloca as entradas dat[7..0] em alta impedância e prepara o próximo
byte armazenado na fila (se houver) para ser lido.
• RXF# (rxf): Quando em nível lógico 0, este sinal indica que pelo menos 1 byte
está armazenado na fila do conversor, o qual está pronto para ser lido. Quando em
nível lógico 1, RXF# indica que a fila do conversor está vazia.
• RCCLK# (usb_sleep): Quando o conversor USB entra em estado de repouso
(“suspend mode”), este sinal é colocado em nível lógico 0, impedindo que a
máquina de estados da unidade de controle tente ler bytes do conversor (veja a
Seção B.1.2 para detalhes de operação do módulo conversor).
Em resumo, quando o PC hospedeiro envia uma mensagem para a unidade de controle
do "crossbar" via USB, o conversor USB/Paralelo irá ativar o "flag" RXF# após receber o
primeiro byte, indicando à unidade de controle que seu "buffer" não está vazio, ou seja, que
pelo menos parte de uma mensagem está disponível. A unidade de controle então lê os bytes
da mensagem ativando o sinal RD#. Mensagens são lidas do conversor até que o "flag" RXF#
seja desativado, indicando que o "buffer" do conversor está vazio.
Observe que, após cada leitura de um byte através do pulso em RD#, a linha RXF#
também vai para nível 1, por alguns períodos de relógio, para fins de sincronização interna.
Importantes observações e cuidados operacionais sobre este conversor USB/Paralelo
são discutidos nos Apêndices (Seção B.1.2 e Seção C.3).
23
4.3 – Descrição do “Datapath”
Figura 9 – Diagrama de Blocos do “datapath”
24
A Figura 9 mostra o diagrama de blocos da unidade operativa, que é por onde
trafegam as mensagens da rede de trabalho propriamente dita. A unidade operativa consiste
de 32 células de conexão (CELL 0 a CELL 31). Observe que cada célula está conectada a
todos os canais de entrada e a todos os sinais de controle, exceto os sinais load_src[31..0] e
load_cd[31..0], que correspondem respectivamente à seleção do canal de entrada e a
conexão/desconexão do canal de saída, os quais conectam apenas uma via a cada célula de
conexão (load_src k e load_cd k). Além disso, a saída de cada célula corresponde a um canal
de saída distinto (out k [1..0]). Consequentemente, cada célula permite a conexão de um dos
32 canais de entrada (in[31..0][1..0]) com um dado canal de saída (out k [1..0]), sob o
comando dos sinais de controle .
Os sinais de controle src, load_src, cd e load_cd permitem conectar ou desconectar
qualquer canal de entrada in[i][1..0] a um canal de saída livre out[j][1..0]. Por exemplo, na
Figura 9, estando a entrada cdreset em nível baixo, com cd=1 (conexão), se o sinal src tem o
valor binário correspondente ao decimal 5 e os sinais load_src1 e load_cd1 estiverem
sucessivamente em nível alto, isto significa que a entrada in[5][1..0] será conectada à saída
out1[1..0].
Estando, no entanto, a entrada cdreset (que recebe o sinal cdreset), em nível alto, todas
as saídas (out0[1..0] a out31[1..0]) serão desconectadas e levadas para o nível alto.
A cada mensagem de 16 bits recebida pelo canal dat[7..0] é possível conectar ou
desconectar uma dada entrada com uma dada saída bem como desconectar todas as saídas se a
mensagem corresponder a “reset”.
O diagrama esquemático correspondente a Figura 9 pode ser encontrado na Figura 29
do Apêndice A.
25
4.3.1 – Descrição da Célula de Conexão
Será analisado nesta seção o que ocorre em uma dada célula de conexão (CELL) da
unidade operativa ao receber os sinais de controle.
A célula de conexão, ilustrada na Figura 10, possui seis entradas (in[31..0][1..0], cd,
load_cd j, src[4..0], load_src j ,e cdreset) e uma única saída (out j[1..0]), além da entrada clk,
que está conectada ao relógio do sistema e rst que é o reset do sistema.
O diagrama esquemático da célula de conexão está na Figura 30 do Apêndice A.
A entrada in[31..0][1..0] (64 bits) corresponde aos 32 canais de entrada, que são
recebidos pela célula de conexão, sendo que apenas um deles poderá ser conectado a única
saída da célula, ou seja, out j[1..0] (2 bits).
As entradas cd (1 bit), load_cd j (1 bit), src[4..0] (5 bits), load_src j (1 bit) e cdreset
(1 bit) são os sinais de controle que provêm da unidade de controle (CONTROL).
Figura 10 – Diagrama de blocos da célula de conexão.
A entrada cd recebe o sinal da unidade de controle que determina uma conexão (cd =
1) ou uma desconexão (cd = 0). A entrada src[4..0] recebe o sinal que seleciona um dos
26
canais de entrada. As entradas load_cd j e load_src j, neste diagrama têm apenas 1 bit, e
correspondem ao j-ésimo bit dos sinais load_cd[31..0] e load_src[31..0] provenientes da
unidade de controle que são conectados apenas à j-ésima célula de conexão. Quando estes
sinais são ativados em dois períodos de relógio sucessivos, uma operação de conexão ou
desconexão pode ser realizada sobre a j-ésima célula de conexão, dependendo ainda dos sinais
de controle cd e src. A entrada cdreset recebe o sinal cdreset da unidade de controle e, quando
em nível alto, provoca a desconexão da saída out j[1..0], levando-a para o nível alto em todas
as células.
Como ilustrado na Figura 10, os componentes básicos da célula de conexão são
registradores (REG) e multiplexadores (MUX).
O conjunto REG1/MUX1 é responsável pela seleção do canal de entrada pois, quando
load_src j é ativado, o sinal src, conectado à entrada de REG1, é passado para a saída,
selecionando assim um dos canais (in[31..0][1..0]) à entrada do MUX1 conectando-o com a
saída para o MUX2.
O conjunto REG2/MUX2 é responsável pela conexão ou desconexão com a saída
out[1..0] j pois, quando load_cd j é ativado, o sinal cd, conectado à entrada de REG2, é
transferido para a saída, selecionando uma das entradas do MUX2 para ser conectada à saída
out j[1..0]. Com cd = 1 (conexão), a entrada que provém do MUX1 é selecionada, a qual
corresponde ao canal de entrada já selecionado. Com cd = 0 (desconexão), a entrada que está
fixa em nível lógico 1 (VCC), é selecionada. Assim, a desconexão de um canal de saída
corresponde a “amarrar” a saída em nível lógico 1.
Cada célula de conexão suporta três operações distintas que ocorrem em dois ciclos de
relógio:
• “Reset”: No primeiro ciclo de relógio o sinal load_src será desabilitado em todas as
células. No segundo ciclo de relógio o sinal cdreset, que é o reset síncrono do registrador
REG2 da Figura 10, é ativado e habilitado pelo sinal load_cd em todas as células, zerando
a saída de REG2 em todas elas. No conjunto REG2/MUX2, o valor zero na saída do
registrador seleciona a entrada que está fixa em nível lógico 1 (VCC) do multiplexador,
levando a saída out j[1..0] para nível 1. Como o sinal cdreset é habilitado por load_cd em
todas as 32 células de conexão, todas elas serão desconectadas simultaneamente. O
resultado desta operação será mantido pelos registradores das células até que hajam novas
conexões.
27
• Conexão: Para uma operação de conexão ou desconexão de um canal de entrada
in[i][1..0] com uma saída out[j][1..0] são emitidos pela unidade de controle os sinais cd,
load_cd, src e load_src. Suponha que foi recebida uma mensagem de conexão do canal de
entrada 5 com o canal de saída 9. Após a decodificação, cd terá o valor 1, src terá um
valor binário correspondente ao decimal 5 e apenas o décimo bit de load_src (load_src 9)
e load_cd (load_cd 9) estarão em nível alto. Isto significa que apenas a décima célula de
conexão (CELL 9) terá seu sinal load_src j e load_cd j ativados em períodos de relógio
sucessivos. Suponha, sem perda de generalidade, que a célula da Figura 10 seja a célula 9.
No conjunto REG1/MUX1, no primeiro período de relógio, o sinal load_src j ativo, faz
com que o valor de src (5), conectado à entrada do registrador REG1, seja passado à saída,
selecionando o canal de entrada in[5][1..0] do MUX1 para a saída. No conjunto
REG2/MUX2, no período de relógio seguinte, a ativação do sinal load_cd j e o fato de cd
estar em nível alto, faz com que a entrada que provém do MUX1 (canal de entrada
selecionado) seja conectado à saída out j[1..0] desta célula (que por hipótese está
conectada à out[9][1..0] na unidade operativa). Note que os registradores da célula de
conexão mantêm a informação de qual entrada in[i][1..0] está conectada com a saída
out[j][1..0]. Assim, a configuração da conexão ocorre dentro de dois ciclos de relógio e
será mantida até que haja uma desconexão, ou uma operação de “reset”.
• Desconexão: Esta operação é em tudo similar à anterior, exceto que, no conjunto
REG2/MUX2, a ativação do sinal load_cd j e o fato de cd estar em nível baixo fazem com
que a saída do MUX2 seja “amarrada” em nível lógico 1 (VCC), o que corresponde à
desconectar a saída da célula selecionada. O resultado desta operação será mantido até que
haja uma operação de conexão.
O modelo da célula de conexão apresentado anteriormente [Soa01] era conceitual e
sua validação limitava-se à simulação funcional. Para operação em um protótipo real, algumas
adaptações foram realizadas com a finalidade de filtrar os “hazards” que ocorrem entre as
entradas e saídas assíncronas dos canais de comunicação do “crossbar” durante a conexão,
desconexão e reset de uma dada célula de conexão. O detalhamento das adaptações está na
Seção C.1.
28
4.4 – Descrição do Controlador
A Figura 11 mostra o diagrama de blocos da unidade de controle (CONTROL) do
“crossbar”, cujo funcionamento será explicado a seguir.
O respectivo diagrama esquemático da unidade de controle está na Figura 31 e Figura
32 do Apêndice A.
As entradas para a unidade de controle são três: dat[7..0], entrada paralela que recebe
as mensages para posterior configuração da unidade operativa e rxf e usb_sleep, linhas de
“handshaking” cujas funções foram explicadas na Seção 4.2.2. Além destas há também a
entrada clk que é o relógio do sistema e rst que é o reset mestre do sistema.
As saídas são rd, linha de “handshaking” cuja função é explicada na Seção 4.2.2, e os
cinco sinais de controle que vão para a unidade operativa: cdreset que é o sinal que
desconecta todas as saídas da unidade operativa; src, que envia o sinal de seleção do canal de
entrada para a unidade operativa; load_src, que habilita o sinal src apenas na célula de
conexão de destino da unidade operativa; cd, que envia o sinal de conexão ou desconexão do
canal de entrada selecionado e load_cd, que habilita a carga do sinal cd apenas na célula de
conexão de destino da unidade operativa.
Figura 11 – Diagrama de blocos da unidade de controle
A unidade de controle é composta pelo circuito FSM que implementa um conjunto de
máquinas de estados finitos e que será visto em maiores detalhes adiante; pelo circuito
DEMUX_MSG_REG que demultiplexa os bytes recebidos na entrada dat[7..0] para formar a
palavra de 16 bits word[15..0] na sua saída; além do decodificador (DECODER) que têm a
29
função de decodificar a mensagem recebida na palavra word[15..0] e gerar os sinais de
controle.
O objetivo da unidade de controle, como pode ser observado na Figura 11, é ler a
mensagem recebida na entrada dat[7..0] e transformá-la na palavra de 16 bits word[15..0], a
partir da qual são gerados todos os sinais de saída da unidade.
De acordo com a Tabela 1 (vide Capítulo 3), a interpretação dos campos da palavra de
16 bits word[15..0] é a seguinte:
• word[3..0]: reservado.
• word[8..4]: endereço de destino;
• word[13..9]: endereço de fonte;
• word[15..14]: opcode;
30
4.4.1 – Descrição do Decodificador
(1º ciclo de relógio)
(2º ciclo de relógio)
Figura 12 – Diagrama de blocos do decodificador
O diagrama da Figura 12 mostra o funcionamento do decodificador em conjunto com
os registradores das células de conexão. dst é o endereço de destino extraído da mensagem.
No 1º ciclo de relógio, ilustrado na figura, src é o endereço fonte extraído da
mensagem. Neste ciclo, apenas o sinal load_src k correspondente ao código dst é ativado
(seleção de destino), fazendo com que o respectivo registrador REG1 (k) seja carregado com o
código do sinal src , que selecionará o canal de entrada a ser roteado para a saída.
No 2º ciclo de relógio, ilustrado na figura, cd é o sinal de conexão ou desconexão
extraído do opcode da mensagem. Neste ciclo, apenas o sinal load_cd k correspondente ao
mesmo código dst é ativado, fazendo com que o respectivo registrador REG2 (k) seja
carregado com o sinal cd que causará uma conexão ou desconexão com a saída .
É importante notar que cada registrador mostrado na Figura 12 está embutido em uma
célula de conexão distinta como a que aparece na Figura 10 . O esquemático do decodificador
se encontra na Figura 36 da Seção A.1 e é detalhado na Figura 37 e Figura 38 subsequentes.
31
4.4.2 – Descrição do Demultiplexador da Palavra
O circuito DEMUX_MSG_REG da unidade de controle (ilustrada na Figura 11) tem
seu diagrama de blocos ilustrado na Figura 13 abaixo, e será descrito a seguir.
O bloco REG_DEMUX demultiplexa os bytes recebidos na entrada paralela dat[7..0],
armazenando-os no par de registradores q[7..0] e q[15..8], como ilustrado na figura. Logo
após, o bloco MESSAGE_REG é carregado com o par de registradores formando a palavra
word[15..0] em sua saída, a qual gera os sinais que após decodificados realizam uma
operação sobre a unidade operativa.
Em REG_DEMUX, para cada byte disponível no conversor USB/Paralelo, a máquina
de estados FSM (ilustrada na Figura 11) ativa o sinal ren habilitando a leitura do byte na
entrada paralela dat[7..0] diretamente do conversor USB. A máquina de estados alterna o
valor do bit na entrada sel2 fazendo com que cada byte recebido seja armazenado
respectivamente no registrador q[7..0] e q[15..8] de REG_DEMUX, como ilustra o
esquemático na Figura 35 da Seção A.1.
Um ciclo de relógio após o par de registradores de REG_DEMUX ser carregado a
máquina de estados FSM ativa a entrada en que habilita a carga do registrador de mensagens
MESSAGE_REG com este par formando a palavra word[15..0] em sua saída.
Figura 13 – Diagrama de blocos de DEMUX_MSG_REG.
O diagrama em blocos da Figura 13 está detalhado na Figura 34 e Figura 35 da Seção
A.1.
32
4.4.3 – Descrição da Estrutura da Máquina de Estados
A Figura 14 ilustra o diagrama de blocos do circuito FSM. As entradas rxf e usb_sleep
para o circuito FSM são utilizadas apenas pelo bloco FSM_READ como ilustrado, enquanto as
entradas clk e rst são conectadas aos dois blocos. As funções destas entradas, bem como as
funções das saídas do circuito FSM que são rd, ren, sel_2, en, e dec_en , e o sinal cf que vai
do bloco FSM_READ para o bloco FSM_CFG são descritas abaixo.
Os blocos FSM_READ e FSM_CFG são circuitos seqüenciais. FSM_READ é o
circuito que habilita a entrada paralela assíncrona através do mecanismo de “handshaking”
das linhas rxf e rd, ilustradas, para leitura de cada byte. Quando a entrada usb_sleep está em
nível baixo este mecanismo é suspenso. A saída cf de FSM_READ comanda periodicamente
um novo estado de configuração no circuito FSM_CFG. Após cada byte lido pelo
“hadshaking” o sinal ren de FSM_READ é ativado sob o nível periodicamente baixo e alto de
sel2 que sai do circuito FSM_CFG, promovendo a carga, através da entrada dat[7..0], dos 2
bytes da palavra em registradores distintos. Após a leitura de cada par de bytes o sinal en
carrega o registrador de mensagens com este par. No ciclo de relógio seguinte o sinal dec_en
(mnemônico para “decoder enable”) possibilita que a configuração da unidade operativa seja
realizada uma única vez por operação.
Figura 14 – Diagrama de blocos do circuito FSM e de seus componentes.
O diagrama esquemático correspondente à Figura 14 pode ser encontrado na Figura 33
da Seção A.1 e detalhado na Figura 39 e Figura 40 da Seção A.2.
33
4.4.4 – Descrição do Funcionamento da Unidade de Controle
A seguir descreve-se o funcionamento da unidade de controle para uma operação de
conexão, que deve ser acompanhado pelas ilustrações anteriores da Seção 4.4, e pela Figura
15 que ilustra o mecanismo da unidade de controle em função do tempo.
Como visto no diagrama da Figura 15, inicialmente, em resposta ao nível baixo (ativo)
da entrada rxf, que provém do conversor USB/Paralelo e é monitorada pelo circuito FSM, a
saída rd de FSM, que vai para o conversor, é levada para nível zero (ativo) por dois períodos
de relógio. Durante estes dois períodos de relógio a entrada dat[7..0] será retirada de alta
impedância e receberá o primeiro byte da fila do conversor. Para lê-lo, durante o segundo
período de relógio em que rd está ativo a saída ren de FSM é ativada, estando a saída sel2 de
FSM previamente em nível zero. Isto promove a carga do primeiro byte no registrador q[7..0]
de REG_DEMUX. Em resposta ao retorno de rd para nível alto, a entrada rxf vai novamente
para nível alto por 4 períodos de relógio por motivos de sincronização interna, e retorna então
para nível baixo indicando que há outro byte a ser lido na fila do conversor. Novamente, em
resposta ao nível baixo de rxf, a saída rd vai, 2 períodos de relógio adiante, novamente para
nível zero e o mesmo processo de leitura se repete, agora com a saída sel 2 de FSM em nível
1. Isto promove a carga do segundo byte no registrador q[15..8] de REG_DEMUX. A saída en
de FSM é ativada no período de relógio seguinte carregando MESSAGE_REG com a palavra
word[15..0] a partir dos registradores q[15..8] e q[7..0] de REG_DEMUX.
Nos dois períodos de relógio que se seguem à carga do registrador de mensagem, a
operação é decodificada e realizada sobre a unidade operativa. Após a carga do registrador de
mensagem são ativados no circuito DECODER em um ciclo de relógio os sinais src e
load_src, que selecionam o canal de entrada, e no próximo ciclo os sinais cd e load_cd, que
conectam o canal de entrada selecionado com a saída. Pode-se observar que, no período de
relógio que se segue a ativação da saída en de FSM (carga da mensagem), a saída dec_en é
ativada por FSM, limitando a apenas um ciclo de relógio os sinais load_src e load_cd,
garantindo assim que a configuração da unidade operativa ocorra uma única vez por operação,
como mostra a simulação da Figura 15.
Note que os sinais cd, load_cd e cdreset ocorrem um ciclo de relógio em atraso
simplesmente por estarem sincronizados por um flip-flop, como ilustrado no esquemático de
DECODER na Figura 36 do Apêndice A.
34
Figura 15 – Diagrama funcional para uma operação de conexão na unidade de controle
A Figura 15 ilustra uma simulação, no circuito da unidade de controle, do efeito de
uma mensagem, que é recebida pela entrada dat[7..0] tendo sido enviada pelo mecanismo
paralelo assíncrono descrito logo acima. A mensagem é composta pelos bytes 0100 0010 e
0010 0000 (“42h” e “20h”), que correspondem a uma operação de conexão da entrada 1 com
a saída 2.
35
4.4.5 – Construção das Máquinas de Estados
4.4.5.1 – Revisão Teórica
Os circuitos FSM_READ e FSM_CFG da Seção 4.4.3 são circuitos seqüenciais e
podem portanto ser modelados como máquinas de estados finitos (FSM) [Kat94].
Convém recordar que uma máquina de estados finitos (FSM) pode estar apenas em
um número fixo de estados possíveis. A função de saída de uma FSM determina o valor das
saídas a partir das entradas e do estado atual. A função de transição de uma FSM determina o
próximo estado a partir das entradas e do estado atual. No projeto de circuitos seqüenciais,
entradas, saídas e estados de uma FSM são associados a variáveis Booleanas. Assim, as
funções de saída e de transição podem ser escritas como funções Booleanas e,
conseqüentemente, podem ser mapeadas para circuitos combinacionais. Além disso, o estado
atual de uma FSM é armazenado através de flip-flops que, a cada transição de relógio, são
carregados com o valor obtido pela função de transição. Nos circuitos seqüenciais que
implementam as máquinas de estado deste projeto foram utilizados flip-flops do tipo D.
Uma FSM pode ser representada por diagramas de transição de estado (DTE). Estes
diagramas descrevem o comportamento do circuito. Para projetar um circuito seqüencial que
implemente um DTE, é necessário criar uma tabela de transição de estados e de saídas
(TTES). Uma TTES relaciona os próximos estados e as saídas em função dos estados
presentes e das entradas, sendo portanto uma representação tabular das funções de saída e de
transição.
36
4.4.5.2 – Descrição dos Diagramas das Máquinas de Estados
A seguir são descritos os diagramas de transição de estados da máquina FSM_READ
ilustrada na Figura 16 e da máquina FSM_CFG ilustrada na Figura 17. Pode-se também
acompanhar, sem perda de generalidade, a descrição das máquinas de estados pelo diagrama
de entradas e saídas em função do tempo na unidade de controle para uma operação de
conexão que está ilustrado na Figura 15 da Seção 4.4.4. Na descrição das máquinas de
estados será adotado grafar em negrito e itálico as entradas e saídas para maior clareza.
Figura 16 – Diagrama de transição de estados de FSM_READ (máquina de leitura)
x, x / (1, 0, 0)
x, x / (0, 0, 0)
1, 0 / (1, 0, 0)
010
x, x / (1, 0, 0)
0, 0 0, 1 / (1, 0, 0) 1, 1
repouso neutrohabilita rd (0)
000 001
reset
Entradas:usb_sleep: desabilitanova leitura do módulo.rxf: sinaliza presença dedados na fila.
Saídas:rd: habilita byte da filapara ser lido.ren: habilita leitura dobyte para o registrador.cf: causa transição namáq. de configuração.
entradas / saídas:
usb_sleep, rxf / (rd, ren, cf)
habilitaren e cf
desabi-lita rd,ren e cf
011100
x, x / (0, 1, 1)
37
Figura 17 – Diagrama de transição de estados de FSM_CFG (máquina de configuração)
x / (0, 1, 0)
1 / (0, 0, 0)
10
1 / (1, 0, 0)
0 / (0, 0, 0)
sel2 (0) sel2 (1) ativa en (1)
00 01
reset
Entradas:cf: vem da máq. de leiturae comanda as transiçõesna máq. de configuração.
Saídas:sel2: habilita a leitura de cadabyte em 2 registradoresdistintos.en: habilita a carga doregistrador de mensagenscom os 2 bytes distintos.dec_en: habilita odecodificador.
entradas / saídas:
cf / (sel2, en, dec_en)
ativadec_en (1)
11
0 / (1, 0, 0)
x / (0, 0, 1)
38
Considere-se inicialmente que a entrada usb_sleep permanece sempre em nível 1.
Enquanto a entrada rxf estiver em nível alto a máquina de leitura FSM_READ
permanecerá em repouso no estado 000, com as saídas rd=1, ren=0 e cf=0 .
Quando pelo menos um byte estiver presente na fila do conversor, rxf irá para nível
baixo causando uma transição para o estado 001 em FSM_READ o qual não sofre alteração
nas suas saídas (rd=1, ren=0 e cf=0) (nos demais estados o nível das entradas é irrelevante).
FSM_READ passa, no próximo ciclo de relógio, para o estado 010 onde rd é ativado
em nível 0 (rd=0, ren=0 e cf=0) fazendo com que os bits na entrada dat[7..0] fiquem em
estado válido.
FSM_READ passa, no próximo ciclo de relógio, para o estado 011 onde ren é ativado
em nível 1 (rd=0, ren=1 e cf=1) carregando o registrador 0 (q[7..0]) do circuito
REG_DEMUX, ilustrado na Figura 35 do Apêndice A.1, com o byte válido pois a saída sel2
da máquina de configuração (FSM_CFG), que seleciona o registrador, está em nível 0.
Observe que a máquina de configuração (FSM_CFG) até então estava em repouso no estado
00 com as saídas sel2=0, en=0 e dec_en=0, enquanto a entrada cf (configuração) estava em
nível 0. Neste estado de FSM_READ, a saída cf também é ativada, levando FSM_CFG para
seu estado 01 onde sel2 passa para nível 1 (sel2=1, en=0 e dec_en=0).
FSM_READ passa no próximo ciclo de relógio, para o estado 100 onde a saída rd é
desativada (rd=1, ren=0 e cf=0) levando a entrada 8-bits paralela novamente para alta
impedância e selecionando o próximo byte da fila do conversor para ser lido. A desativação
da saída rd causa a imediata subida da entrada rxf , que provém do conversor, para nível 1 por
4 cliclos de relógio, por razões de sincronização interna, mesmo quando houverem mais bytes
na fila para serem lidos. Neste mesmo estado as saídas ren e cf retornam a seus níveis
desativados.
FSM_READ retorna então, no próximo ciclo de relógio, para o estado inicial 000.
O ciclo de leitura então se repete da mesma forma. Quando FSM_READ chega ao
estado 011, novamente a saída ren é ativada, carregando agora o registrador 1 (q[15..8]) do
circuito REG_DEMUX com o byte válido pois a saída sel2 da máquina de configuração
(FSM_CFG) havia mudado para nível 1 como visto acima. Neste mesmo estado de
FSM_READ, a entra cf para a máquina FSM_CFG é ativada novamente, retirando a mesma
do seu estado 01 para o estado 10 onde a saída en é ativada (sel2=0, en=1 e dec_en=0)
carregando o registrador de mensagens ilustrado na Figura 13 com a palavra de 16 bits
armazenada nos dois registradores de 1 byte de REG_DEMUX. Logo após, independente da
entrada cf, a máquina FSM_CFG passa no próximo ciclo de relógio para o estado 11 onde
39
dec_en é ativado (sel2=0, en=0 e dec_en=1), sendo desativado no estado seguinte, ou seja,
no estado 00, garantindo assim que os decodificadores estejam habilitados por apenas um
período de relógio, impedindo que seus sinais configurem mais de uma vez o DATAPATH. O
estado 11 ocorrerá exatamente junto com o estado 000 da máquina FSM_READ. A máquina
de estados FSM_CFG retorna então ao seu estado inicial 00, no pior caso, exatamente junto
com o estado 001 (neutro) de FSM_READ, sem causar problemas ao ciclo das máquinas. Na
prática porém, a máquina FSM_READ fica por mais 4 períodos de relógio no estado 000,
devido à sincronização interna do módulo conversor, coincidindo neste estado o retorno ao
estado inicial 00 de FSM_CFG.
4.4.5.3 – A Entrada usb_sleep
A entrada usb_sleep em FSM_READ só irá para nível 0 (ativada) após 3 ms de
inatividade no barramento USB, indicando que o conversor USB/Paralelo está em modo
suspenso. Se a entrada usb_sleep estiver em nível 0, não será iniciado um novo ciclo de
leitura na máquina FSM_READ mesmo que a entrada rxf esteja ativada em nível 0
sinalizando a presença de dados na fila do conversor.
Não se espera que esta situação ocorra na prática pois, de acordo com o diagrama
ilustrado na simulação temporal da Figura 26 da Seção 5.2.4, o período do ciclo de leitura de
cada byte é de 750 ns com um relógio de 12MHz. Isto confere à máquina de estados do
“crossbar” a capacidade de consumir mensagens da fila do conversor a 10,66 Mbps, enquanto
que a velocidade máxima de recepção de dados a partir do barramento USB pelo conversor é
de apenas 8 Mbps. E toda a chegada de dados na fila será prontamente consumida pois a
máquina de estados não fica ocupada com outras tarefas. Lembrando que a fila possui 128
bytes [F4500], se ela estiver preenchida totalmente será consumida em 96 us pela máquina de
estados, muito antes dos 3 ms de “timeout” para o modo “sleep” [USB00].
40
4.4.5.4 – Sincronismo das Entradas
Todas as entradas para a unidade de controle utilizam flip-flops como circuitos
sincronizadores, pois são entradas assíncronas. Isto pode ser observado no circuito CTRL
ilustrado na Figura 32 do Apêndice A. Os circuitos sincronizadores são circuitos que "são
capazes de garantir que a ocorrência de anomalias devidas a eventos assíncronos seja bastante
improvável" [Gla85].
Como a entrada rxf de FSM_READ é sincronizada (portanto atrasada em um ciclo de
relógio), se por hipótese a saída rd fosse retornada para o nível 1 apenas na volta ao estado
inicial 000, a saída RXF# do conversor USB/paralelo, referida na Seção 4.2.2, subiria no
mesmo ciclo de relógio, mas a entrada rxf, sincronizada, subiria apenas no estado seguinte, ou
seja, 001. Desta forma, como rxf, estaria ainda em nível 0 no estado 000, um novo ciclo de
leitura se iniciaria imediatamente causando a falha da máquina de estados.
Para solucionar este problema a saída rd é retornada para nível 1 no último estado de
FSM_READ, ou seja, 100 que antecede o retorno ao estado inicial, causando a subida de
RXF# neste estado. Desta forma a entrada sincronizada rxf estará em nível 1 no estado
seguinte, 000, como se espera, e não será iniciado um novo ciclo de leitura até que rxf volte
para nível 0 indicando que o conversor está realmente pronto para nova leitura.
4.4.5.5 – Sincronismo da Saída rd para Eliminação dos “Hazards”
A saída rd que provém da máquina de estados FSM_READ e habilita os dados para
serem lidos, em um circuito real, conterá “hazards” os quais são inaceitáveis nesta linha
assíncrona de “handshaking”. Portanto se fez necessário sincronizar a saída rd passando a
mesma por um flip-flop. Isto pode ser observado no circuito CTRL ilustrado na Figura 32 do
Apêndice A. A sincronização atrasa a saída rd, portanto se fez necessário também adiantar a
saída rd na máquina de leitura FSM_READ, constituindo a saída rd_a (mnemônico para “rd
ahead”) que é exatamente a mesma saída rd apenas adiantada em um ciclo de relógio, para
que após a sincronização se tenha como resultado a saída esperada. O “estado neutro” da
máquina FSM_READ foi introduzido justamente para acomodar esta sincronização. A
máquina de estados FSM_READ resultante está ilustrada na Figura 18.
41
Figura 18 – Diagrama de transição de estados de FSM_READ com a saída rd adiantada.
A minimização das equações das funções de transição e de saída das máquinas de
estado FSM_READ e FSM_CFG são descritas na Seção A.2.
x, x / (1, 0, 0)
x, x / (0, 0, 0)
1, 0 / (1, 0, 0)
010
x, x / (0, 0, 0)
0, 0 0, 1 / (1, 0, 0) 1, 1
repouso neutrohabilita rd (0)
000 001
reset
Entradas:usb_sleep: desabilitanova leitura do módulo.rxf: sinaliza presença dedados na fila.
Saídas:rd_a sincronizada: habilitabyte da fila para ser lido.ren: habilita leitura do bytepara o registrador.cf: causa transição na máq.de configuração.
entradas / saídas:
usb_sleep, rxf / (rd_a, ren, cf)
habilitaren e cf
desabi-lita rd,ren e cf
011100
x, x / (1, 1, 1)
42
4.5 – Conseqüências da Implementação em FPGA
4.5.1 – Mapeamento para o FPGA
O dispositivo lógico programável escolhido é o FPGA ACEX1K50 da Altera [Ace01].
Este dispositivo foi escolhido por seu baixo custo, pelo seu número de arranjos de blocos de
portas lógicas que comporta este projeto, mas principalmente por ser o único dispositivo
disponível com esta capacidade incluído na licença “student” do sistema de CAD utilizado, a
única licença disponível para o desenvolvimento deste projeto.
O dispositivo ACEX tem uma tensão de alimentação de 2,5 Volts e uma tensão
Entrada/Saída padrão de 2,5 Volts ou 3.3 Volts em nível LVTTL, mas pode operar também na
tensão de E/S de 5,0 Volts em nível TTL.
Por outro lado, a família de dispositivos FLEX, que tem uma tensão de alimentação de
5,0 Volts e opera com tensão de Entrada/Saída de 5,0 ou 3,3 V em nível TTL, tornaria mais
simples o projeto dos componentes de alimentação do dispositivo em conjunto com os
módulos conversores USB. Com uma licença menos restrita, um dispositivo FLEX com
capacidade similar poderia substituir o dispositivo ACEX.
No entanto, caso seja utilizada a segunda geração dos módulos conversores USB, que
está sendo lançada e que tem uma tensão de E/S alternativamente compatível com níveis TTL
e LVTTL, então a interface de E/S com o FPGA ACEX se dará em sua forma padrão
(LVTTL).
Foi realizado o mapeamento físico para o FPGA EP1K50FC256-3, que é um
ACEX1K50. Este FPGA possui 50.000 “gates” (2.880 células lógicas) em um
encapsulamento do tipo “fine line ball-grid array”. O FPGA possui 256 pinos de E/S, dos
quais 180 são destinados para “E/S de usuário”, ou seja, podem ser utilizados para
implementar entradas e saídas primárias do sistema digital sob projeto.
43
O mapeamento físico para o FPGA resultou nas seguintes características de
implementação:
• Entradas e Saídas utilizadas pelo “crossbar”:
Número de entradas: 76.
Número de saídas: 65.
Número total de pinos: 141
• Taxa de ocupação do dispositivo:
Pinos de E/S dedicados utilizados: 6/6 (100 %)
Pinos de E/S para usuário utilizados: 135/180 (75 %)
Número de células lógicas utilizadas: 2011/2880 (69 %)
• Relógio do sistema:
Freqüência de operação: 12MHz
Período do relógio do sistema (T): 83,3 ns
• Análise de temporização:
Tempo de “Setup/Hold” típico: 5,0 ns / 0,0 ns
Atrasos de propagação:
• Entre entradas in [i][k] e out [j][k]: mínimo de 16,1 ns e máximo de 29,4 ns.
• Entre relógio e saída rd e sinais de controle: máximo: 18,0 ns* (22 % de T)
Freqüência de operação máxima: 55 MHz (1/18 ns*)
4.5.2 – Discussão
A velocidade de transmissão entre os canais de comunicação será no máximo de
3Mbps [FA101]. Isto significa que o período de relógio nas linhas seriais assíncronas da
unidade operativa será no mínimo de 333,3 ns (Ts).
O atraso de propagação de 29,4 ns entre entradas e saídas da unidade operativa
corresponde a 8,8 % de Ts. A natureza assíncrona da comunicação serial torna este atraso
insignificante.
Poder-se-ia imaginar que a propagação dos sinais TX e RTS# por caminhos distintos
no "crossbar" poderia gerar problemas de temporização. Entretanto, no pior caso, a diferença
dos atrasos de propagação entre os sinais TX e RTS# é de 13,3 ns (29,4 ns – 16,1 ns). Esta
diferença corresponde a 4,0 % de Ts, podendo ser considerada insignificante.
44
5 – VALIDAÇÃO EXPERIMENTALNo capítulo anterior foi apresentada uma abordagem hierárquica descendente para
facilitar o entendimento da estrutura e comportamento do sistema. Entretanto, durante a
validação do projeto foi utilizada uma abordagem hierárquica ascendente. Dado um
determinado circuito, antes de validá-lo, seus sub-circuitos foram submetidos separadamente
a simulação temporal.
Neste projeto utilizaram-se ferramentas pertencentes a um sistema de CAD
desenvolvido pela Altera Corporation [Alt01], denominado MAX+PLUS II 10.1 Baseline. Os
diagramas esquemáticos apresentados no Apêndice A bem como os resultados das simulações
ilustrados neste capítulo foram elaborados neste sistema.
5.1 – O Sistema de CAD Utilizado
O MAX+PLUS II permite a edição esquemática de circuitos lógicos combinacionais e
seqüenciais possibilitando a criação de projetos lógicos completos de forma hierárquica. Após
a edição estes circuitos podem ser:
compilados para um arquivo de simulação funcional.
compilados e sintetizados logicamente para um arquivo de simulação temporal
baseado em um determinado dispositivo lógico programável.
compilados e sintetizados logicamente para um arquivo de montagem utilizado na
programação de um determinado dispositivo lógico programável.
A partir dos arquivos de simulação funcional e temporal podem ser gerados gráficos
de simulação funcional e temporal respectivamente. Além disso, após a geração do gráfico de
simulação temporal, pode-se gerar tabelas de temporização de atraso, de estabilização e
manutenção e de desempenho.
Embora tenha sido utilizada a edição de esquemáticos como entrada para o projeto é
possível utilizar como entrada também uma linguagem de descrição de hardware como
VHDL [Ash98].
46
5.2 – Simulações Temporais
As simulações realizadas a partir do projeto conceitual do “crossbar” e apresentadas
em [Soa01] tinham apenas caráter funcional, isto é, não eram aplicadas a um dispositivo em
particular, não sendo considerados atraso de propagação nos componentes. Neste trabalho, a
simulação das temporizações com relação a um dispositivo particular serão apresentadas
especificamente para o dispositivo EP1K50FC256-3 da Altera, cujo mapeamento está descrito
na Seção 4.5.1.
As simulações apresentadas visam validar o projeto lógico ora exposto. Utilizando-se
os diagramas de tempo do MAX+PLUS II, são aplicadas seqüências de mensagens à entrada
paralela de configuração do “crossbar” bem como sinais de entrada nos canais de
comunicação e verificados os sinais de saída.
Os diagramas de tempo das simulações temporais são apresentados a seguir. Nos
diagramas, duas ondas quadradas de períodos diferentes são aplicadas as entradas in1 [1..0] e
in2 [1..0] para representar os dados enviados pelos canais de comunicação. Para cada
diagrama, uma mensagem é recebida pela entrada dat[7..0], que está associada ao canal de
configuração sob o controle dos sinais rxf, rd e usb_sleep. Os resultados obtidos podem ser
observados nas saídas out1 [1..0] e out2 [1..0].
Observe que as ondas quadradas aplicadas às entradas são meramente ilustrativas, pois
uma conexão, desconexão ou mesmo reset no “crossbar” são sempre precedidos e sucedidos
por um estado “idle” onde o nível de entrada é sempre alto. Uma conexão ou desconexão no
“crossbar” nunca ocorre em estado de transmissão.
É importante ressaltar que a temporização da simulação procura reproduzir o
interfaceamento real com o conversor USB/Paralelo do canal de configuração. Os atrasos na
resposta dos sinais rxf (25ns) e dat[7..0] (50ns) vindos do conversor são os mesmos
amostrados em osciloscópio [FA401].
Embora não ilustrado nas simulações a máquina de estados finitos foi testada para
qualquer intervalo de tempo entre os ciclos de leitura e não apenas para rajadas.
Os diagramas de temporização apresentados nas figuras das seções seguintes ilustram
resultados de simulações para a seqüência de eventos relatada. Em todas as simulações,
adotou-se a freqüência de 12,02 MHz para o relógio.
47
5.2.1 – Estabelecimento de Conexão
A Figura 22 ilustra o resultado para uma mensagem de conexão do canal de entrada
in1 [1..0] com o canal de saída out2 [1..0] que é recebida pela entrada dat[7..0].
Seqüência Evento Relógio Observar em
1 carrega byte baixo 20H 665,6 ns rd e dat[7..0]
2 Carrega byte alto 42H 1,4144 us rd e dat[7..0]
3 Conexão 1,664 us in1 [1..0] e out2 [1..0]
Figura 22 – Primeira conexão na Unidade Operativa
A carga de cada byte no registrador apropriado coincide com o momento da subida do
sinal rd. Após a segunda subida de rd há um intervalo de 3 ciclos de relógio até a operação ser
realizada: 1 ciclo para carregar o registrador de mensagens; 1 ciclo para selecionar o canal de
entrada e 1 ciclo para conectar/desconectar/ressetar a célula, como está ilustrado na simulação
funcional da Figura 15 da Seção 4.4.4.
48
Logo após a conexão anterior uma mensagem de conexão do canal de entrada in2
[1..0] com o canal de saída out1 [1..0] é recebida pela entrada dat[7..0], conforme ilustra a
Figura 23:
Seqüência Evento Relógio Observar em
1 carrega byte baixo 10H 2,1632 us rd e dat[7..0]
2 carrega byte alto 44H 2,912 us rd e dat[7..0]
3 Conexão 3,1616 us in2 [1..0] e out1 [1..0]
Figura 23 – Segunda conexão na Unidade Operativa
49
5.2.2 – Desconexão
Logo após as duas conexões anteriores uma mensagem de desconexão do canal de
entrada in1 [1..0] com o canal de saída out2 [1..0] é recebida pela entrada dat[7..0], conforme
ilustra a Figura 24:
Seqüência Evento Relógio Observar em
1 carrega byte baixo 20H 3,6608 us rd e dat[7..0]
2 carrega byte alto 82H 4,4096 us rd e dat[7..0]
3 desconexão 4,6592 us in1 [1..0] e out2 [1..0]
Figura 24 – Desconexão na Unidade Operativa
50
5.2.3 – Reinicialização da Unidade Operativa
Logo após as duas primeiras conexões substitui-se a mensagem de desconexão
anterior por uma mensagem de “reset” recebida na entrada dat[7..0], a qual desconecta todas
as saídas da unidade operativa como ilustrado na Figura 25:
Seqüência Evento Relógio Observar em
1 carrega byte baixo 00H 3,6608 us rd e dat[7..0]
2 carrega byte alto 00H 4,4096 us rd e dat[7..0]
3 reinicialização 4,6592 us out1 [1..0] e out2 [1..0]
Figura 25 – Reinicialização da Unidade Operativa
51
5.2.4 – Operações no “Crossbar”
A simulação ilustrada na Figura 26 tem como objetivo mostrar a dinâmica do
“crossbar”. São recebidas pela entrada dat[7..0] as seguintes mensagens nesta ordem:
1. Conexão de in1 [1..0] com out2 [1..0];
2. Conexão de in2 [1..0] com out1 [1..0];
3. Desconexão de in1 [1..0] com out2 [1..0];
4. Desconexão de in2 [1..0] com out1 [1..0];
Os resultados podem ser observados nas saídas out1 [1..0] e out2 [1..0].
Embora a variação do sinal usb_sleep não tenha sido apresentada nesta seção ele foi
também validado por simulação temporal a qual foi omitida por razões práticas.
Da mesma forma, embora não apresentado nesta seção, uma operação de
“multicasting” é possível através de sucessívas operações de conexão entre o nó de origem e
os nós de destino.
52
Figura 26 – Operações no “crossbar”
6 – A INTEGRAÇÃO DO HARDWARE DO “CROSSBAR”Neste capítulo descreve-se sucintamente os componentes da futura placa mãe que
implementará a rede de trabalho. Apresenta-se também uma estimativa de custos incluindo a
placa mãe, os cabos de interligação e as placas adaptadoras nos PCs. Ao final, apresenta-se
um esboço do “layout” do sistema.
6.1 - Componentes da Placa Mãe, Placas, Cabos e Custo do Sistema
Abaixo estão detalhados os componentes necessários juntamente com o custo
individual de cada componente para um “crossbar” com interfaces USB no canal de
configuração e canais de comunicação. Todos os componentes são encontrados no mercado
nacional, com exceção dos módulos conversores USB.
A Tabela 3 mostra os componentes da placa mãe e seus respectivos custos. A Tabela 2
mostra os custos dos cabos e placas adaptadoras. O custo total do “crossbar” projetado com
interfaces USB é portanto de US$ 1.664,80. A título de comparação o Apêndice D apresenta
também uma estimativa de custos, caso o "crossbar" fosse implementado com interfaces
seriais RS-232. Uma tal alternativa custaria US$ 1543,84. Observe que a adoção do padrão
USB resulta em um sistema cerca de 26 vezes mais veloz (3Mbps do USB e 115,2kbps para o
RS-232), mas com um custo apenas 8 % maior. Em resumo, a escolha adotado no projeto
representa um melhor compromisso entre custo e benefício.
Tabela 2 – Cabos e placas adaptadoras e seu custo para interfaces USB.
Quant. Componentes Custo unit. em
US$
Subtotal em US$
c/ impostos (1)
Fonte
33 Cabos USB A-B
3 m
3,42 120,08 (2) www.digimer.co
m.br (RS)
8 Placas PCI/USB
4 saídas (3)
28,61 228,90 (4) www.integral.co
m.br (SP)
Total em US$ c/ impostos 348,98
Notas:(1) Custo total pelo dólar comercial com a carga tributária máxima já incluída sem considerar nenhuma
lei de redução de impostos sobre material destinado a instituições de ensino.(2) Frete incluso (Sedex R$19,42). Cotação original em Reais. O ICMS incluído é de 12%(3) Placas USB de 4 portas da Integral Sistemas com “chipset” OPTI de muito boa qualidade. Garantia
de 6 meses.(4) Frete não incluso. Cotação original em Reais. O ICMS incluído é de 12%
54
Tabela 3 – Componentes da placa mãe e seu custo para interfaces USB.
Quant. Componentes Custo unit. em
US$
Subtotal em US$
c/ impostos (1)
Fonte
1 FPGA
EP1K50FC256-3
55,60 Acumula Abaixo
1 Disp. conf.
EPC1PC8
14,80 78,85 (2) www.picompone
ntes.com.br (SP)
32 Módulos
USBMOD1
22,85 (fob) Acumula Abaixo
1 Módulo
USBMOD2
22,85 (fob) 1215,52 (3) www.gigatechnol
ogy.com.br (AU)
33 soquetes gold
p/ módulos
CPT 032 BA (4)
0,65 21,45 (2) www.blupel.com.
br (SC)
Total em US$ c/ impostos 1.315,82
Notas:(1) Custo total pelo dólar comercial com a carga tributária máxima já incluída sem considerar nenhuma
lei de redução de impostos sobre material destinado a instituições de ensino.(2) Frete não incluso. O ICMS incluído é de 12%(3) Cotação original em Dólares Australianos (AU$ 1330,00) incluindo transporte (AU$ 10,00).
Importação por correio aéreo (isento de ICMS) sob Regime de Importação Simplificada que é isenta de IPI(aliquota única de 60% sobre (bens + transporte) até US$ 3000,00).
(4) O soquete possui contatos com 12 microns de ouro (150 inserções). Qualquer soquete tipo “dip”para CI de 32 pinos semelhante (.600 x .100”) pode ser utilizado.
(5) As cotações da Tabela 2 e Tabela 3 foram finalizadas em 10 de junho de 2002.
55
6.2 – Estrutura da Placa Mãe
A Figura 27 esboça um “layout” de como os componentes poderiam ser posicionados
e roteados na placa mãe, onde os retângulos hachuriados representam conectores. Observe
que o conversor USB/Paralelo associado ao canal de configuração é posicionado em um
soquete muito próximo ao FPGA. Por outro lado, os conversores USB/Serial são distribuídos
em 4 placas com 8 conversores cada. Estas placas estarão superpostas formando um banco de
conectores que deve estar posicionado muito próximo à placa mãe. Os cabos entre a placa
mãe e o banco de conectores não devem ultrapassar 30 cm de comprimento, que é o limite de
transmissão de um sinal TTL.
Figura 27 – “Layout” da estrutura da placa mãe do “crossbar”.
56
7 – CONCLUSÕESEsta dissertação apresentou o projeto de um "crossbar" 32 x 32 a ser utilizado como
rede de trabalho para o Multicomputador Crux. O Capítulo 1 apresentou uma breve
introdução sobre o contexto desta dissertação. No Capítulo 2 foi apresentada a arquitetura,
trabalhos correlatos e a contribuição deste trabalho. No Capítulo 3 foram analisadas as
propriedades gerais do “crossbar”, a especificação das características físicas e de suas funções
de controle. O Capítulo 4 descreveu a estrutura do “crossbar” e seu mapeamento para um
dispositivo lógico programável. No Capítulo 5 abordou-se a validação experimental do
projeto, através de simulação. No Capítulo 6 foram feitas estimativas de custo e uma proposta
de "layout" para o sistema. Neste capítulo serão apresentadas nossas conclusões e
perspectivas de continuidade do trabalho aqui iniciado.
7.1 – Contribuições desta Dissertação
Uma primeira contribuição foi o projeto lógico e mapeamento físico de um
“crossbar” com 32 entradas e 32 saídas que foram realizados com sucesso. Os resultados
obtidos da simulação temporal permitiram validar o projeto lógico, uma vez que foram
avaliadas com sucesso as características do “crossbar” após mapeamento físico para um
FPGA específico.
Uma segunda contribuição importante foi a de se ter descoberto componentes
disponíveis no mercado que permitiram o uso do padrão USB para a comunicação entre nós
trabalhadores. Esta descoberta, além de manter a simplicidade da interface entre os nós do
multicomputador e o "crossbar", possibilitou um aumento de velocidade de cerca de 26
vezes na comunicação em relação à alternativa mais simples anteriormente visualizada (RS-
232), com um aumento de apenas 8% no custo.
Uma decorrência dessa contribuição foi a obtenção de uma interface bem definida
entre os nós do multicomputador e o “crossbar”. Isto permitiu visualizar e antecipar a
resolução, com o auxílio de simulação, de alguns problemas que surgiriam em um protótipo
real, como por exemplo os “hazards” que ocorrem entre os canais de entrada e de saída do
“crossbar”, como descrito na Seção C.1. Ademais, as soluções para tais problemas podem ser
estendidas para outros projetos que utilizem um “crossbar” com outras interfaces padrão
diferentes do padrão USB.
Uma outra decorrência dessa contribuição é a viabilidade de prototipação rápida e
confiável do "crossbar". Os conversores USB/Paralelo e USB/Serial apresentam-se prontos
58
para conexão com o FPGA, não sendo necessária a confecção de circuitos que muitas vezes é
crítica, sendo que a única soldagem necessária é para os respectivos soquetes.
7.2 – Escalabilidade e Limitações da Implementação
Apesar da ausência de controle ou detecção de erros no projeto para fazer face à
possível degradação de sinais elétricos entre a origem da mensagem e sua recepção final pelo
FPGA, um tal mecanismo parece dispensável. Como o ponto crítico da transmissão é a
interface entre o conversor USB e o FPGA e ambos estarão na mesma placa operando em
níveis TTL, é provável que um mecanismo de controle de erros possa ser omitido em um
primeiro protótipo, como sugerido na Seção B.2.
Uma limitação da utilização dos conversores USB, como descrito na Seção B.1.3, é
que o barramento USB utiliza “frames” fixos de 1 milisegundo em suas transmissões, o que
pode afetar particularmente o canal de configuração que utiliza mensagens curtas em suas
transmissões. Esta limitação é praticamente irrelevante quando pacotes contendo conjuntos de
diversas operações forem enviados pelo canal de configuração durante o mesmo “frame” USB
como está descrito na Seção E.1. Os “frames” portanto tornam-se uma limitação apenas no
caso do envio de mensagens isoladas.
Se os “frames” na transmissão USB mostrarem impacto inaceitável no desempenho do
multicomputador é sugerido como alternativa na Seção B.1.3 a utilização de uma PIC-UART
no canal de configuração (sem nenhuma alteração na arquitetura do “crossbar” apresentada
nesta dissertação). Com uma PIC-UART, em conjunto com um meio de transmissão RS-422,
é possível receber dados à velocidade de 1,25 Mbps do canal de configuração.
A taxa de transmissão suportada pelos conversores USB/Serial e USB/Paralelo é de
3Mbps e 8Mbps, respectivamente. O fabricante [Ftd02] está em fase de lançamento de novos
CIs que podem operar no padrão USB 2.0, mas à freqüência de 12 MHz (padrão “full-
speed”). No entanto em longo prazo, há ainda a possibilidade de lançamento de novos
módulos operando à freqüência de 480 MHz (padrão “high-speed”). Portanto, a escalabilidade
deste projeto, em termos de velocidade, depende em parte da disponibilização no mercado de
conversores operando em velocidades mais altas. Além da velocidade 40 vezes maior,
conversores com CIs operando no padrão “high-speed” teriam também a vantagem de um
frame 8 vezes menor. O micro-frame do padrão USB 2.0 “high-speed” tem apenas 125 µs, o
que reduziria o impacto do tamanho fixo de “frame” particularmente em relação ao canal de
configuração.
59
Uma limitação adicional associada ao padrão USB é a transmissão “half-duplex”
bidirecional. A transmissão “dual-simplex” seria mais adequada às características de
transmissão dos canais de comunicação do Multicomputador Crux. Caso esta limitação
mostre-se crítica, os conversores USB/Serial poderiam ser substituídos pelos transceptores
RS-232 ou RS-422 sugeridos na Seção B.1.1, sem nenhuma alteração na arquitetura do
“crossbar” apresentada nesta dissertação.
Apesar deste projeto estar limitado a 32 portas de E/S ele pode ser expandido para
comportar um número maior de portas. Infelizmente, isto requereria a substituição do FPGA
ora adotado por um de maior capacidade e com um custo um pouco mais elevado. No entanto
seria preciso também levar em conta o aumento na complexidade para confecção da placa
mãe com o aumento do número de portas de E/S do “crossbar”.
Embora a integração com o sistema operacional não seja o foco desta dissertação,
convém registrar uma deficiência no desempenho do driver associado aos conversores USB
disponível até o momento. Conforme mostra a Seção B.1.4, na comunicação dos processos
com ambos os módulos USB é utilizado um único driver de dispositivo. O driver disponível
até o presente para Linux se chama Virtual COM Port e foi desenvolvido por Bill Ryder
[Ryd02]. Um experimento com este driver para ambos os conversores utilizando um
programa em Pearl [Ryd02] resultou em velocidades de transmissão de 512 Kbps e 2,16Mbps
para escrita e leitura, respectivamente. Isto fica bem aquém da verdadeira potencialidade dos
módulos. Comentários sobre como contornar a deficiência do atual driver e considerações
sobre a determinação do tempo de atraso para a configuração do “crossbar” podem ser
encontrados no Apêndice E.
7.3 – Perspectivas e Trabalhos Futuros
Devido à limitação de tempo imposta à execução do trabalho aqui descrito, não foram
feitos experimentos para avaliar se a transmissão de pacotes limitada por "frames" através do
barramento USB adequa-se aos requisitos para a rede de trabalho do Multicomputador Crux.
É razoável supor que algumas adaptações tenham de ser feitas na modelagem da comunicação
do sistema operacional com a rede de trabalho, sobretudo para levar em conta o “throughput”
com um sistema de frames e o “overhead” devido ao padrão USB. Estes problemas bem como
medidas de desempenho e outras características relativas a uma rede de trabalho USB são
deixados para trabalhos futuros.
Esta dissertação restringiu-se ao projeto e validação de um sistema digital para um
protótipo do “crossbar” e à determinação de componentes fundamentais bem como dos cabos
60
e placas necessários nos PCs. Este trabalho é portanto o ponto de partida para a efetiva
implementação de um protótipo para o “crossbar”, que venha a ser usado na rede de trabalho
do Multicomputador Crux.
Embora a forma de transmissão aqui proposta não seja uma solução definitiva como
alternativa aos “links transputer”, ela poderá contribuir para o futuro desenvolvimento de uma
rede de trabalho mais eficiente para o multicomputador. Novos padrões comerciais estão
surgindo como o padrão IEEE 1394b, que substitui o barrramento serial bidirecional “half-
duplex” do padrão IEEE 1394 por um barramento “dual-simplex”. Esta característica poderia
ser explorada em um trabalho futuro.
Outra alternativa factível é a utilização do meio Ethernet compondo com o “crossbar”
a rede de trabalho. Após uma pesquisa extensiva na Web foram encontrados transceptores
ECL independentes da camada física [DP897] tão somente para o padrão IEEE 802.3u
(100BaseTX) embora tais CIs possam existir para os outros padrões. Portanto o “crossbar”
poderia interfacear com o meio Ethernet também de forma direta, pois o cabeamento
100BaseTX é “full-duplex”. Existem duas possibilidades para interfacear os transceptores
ECL com o “crossbar”: utilizar um FPGA ECL ou utilizar conversores ECL/TTL para que
possa ser utilizada a família de dispositivos da Altera [Alt01]. Eis, portanto, mais uma
oportunidade de trabalho futuro.
Por outro lado, caso venham a ser produzidos CIs USB 2.0 “high-speed”, a
escalabilidade para o circuito digital apresentado neste trabalho irá se concretizar,
possibilitando a implementação de um “crossbar” de alta velocidade, com um menor tempo
de “frame”, desde que sejam feitas alterações no projeto para permitir que opere na freqüência
apropriada. Com esta perspectiva o projeto de um “crossbar” com conversores USB “high-
speed” poderia ser posto em prática em um trabalho futuro possivelmente com as mesmas
vantagens oferecidas pela atual versão dos módulos USB.
Em particular o atual driver de dispositivo para os conversores, por necessitar
provavelmente de adaptações, poderia também dar margem para a realização de outro
trabalho que contemple todas as modificações necessárias.
Em suma, embora haja várias perspectivas para futuras investigações, esta dissertação
além de lançar as bases para a prototipação rápida de uma rede de trabalho provavelmente
lançará luz para a futura solução das limitações aqui relatadas.
APÊNDICE A - Diagramas Esquemáticos do "Crossbar"
A.1 – Diagramas Esquemáticos:
Os diagramas esquemáticos apresentados aqui foram retirados diretamente do pacote
de CAD MAX+PLUS II.
Figura 28 – Diagrama esquemático do “crossbar”
62
Figura 29 – Diagrama esquemático do “datapath”
. . . . . . . .
63
Figura 30 – Diagrama esquemático da célula de conexão
Figura 31 – Diagrama esquemático do controlador (CONTROL).
64
Figura 32 – Diagrama do módulo CTRL do controlador (FSM e DEMUX_MSG_REG)
Figura 33 – Diagrama esquemático da estrutura do circuito FSM
65
Figura 34 – Diagrama do circuito DEMUX_MSG_REG.
Figura 35 – Diagrama esquemático do circuito REG_DEMUX
66
Figura 36 – Diagrama esquemático de DECODER.
Figura 37 – Diagrama esquemático de OP_DECODER.
Figura 38 – Diagrama esquemático de DEST_DECODER.
67
A.2 – Minimização das Funções das Máquinas de Estado
A Tabela 4 é a representação tabular das funções de transição e de saída para
FSM_READ sincronizada ilustrada na Figura 18.
Tabela 4 – TTES correspondente ao DTE da Figura 18.
Estado Presente Entradas Próximo Estado Saída
Mintermo Q2, Q1, Q0 usb_sleep, rxf D2, D1, D0 rd, ren, cf
0 0, 0, 0 0, 0 0, 0, 0 1, 0, 0
1 0, 1 0, 0, 0
2 1, 0 0, 0, 1
3 1, 1 0, 0, 0
4 0, 0, 1 0, 0 0, 1, 0 0, 0, 0
5 0, 1 0, 1, 0
6 1, 0 0, 1, 0
7 1, 1 0, 1, 0
8 0, 1, 0 0, 0 0, 1, 1 0, 0, 0
9 0, 1 0, 1, 1
10 1, 0 0, 1, 1
11 1, 1 0, 1, 1
12 0, 1, 1 0, 0 1, 0, 0 1, 1, 1
13 0, 1 1, 0, 0
14 1, 0 1, 0, 0
15 1, 1 1, 0, 0
16 1, 0, 0 0, 0 0, 0, 0 1, 0, 0
17 0, 1 0, 0, 0
18 1, 0 0, 0, 0
19 1, 1 0, 0, 0
68
A partir da Tabela 2, as funções de transição e de saída podem ser expressas,
respectivamente, através das seguintes equações Booleanas:
D2= ∑ 12, 13, 14, 15 + ∑X 20 ... 31
D1= ∑ 4, 5, 6, 7, 8, 9, 10, 11, + ∑X 20 ... 31
D2= ∑ 12, 13, 14, 15 + ∑X 20 ... 31
D0= ∑ 2, 8, 9, 10, 11 + ∑X 20 ... 31
rd = ∑ 0, 1, 2, 3, 12, 13, 14, 15, 16, 17, 18, 19 + ∑X 20 ... 31
ren= ∑ 12, 13, 14, 15 + ∑X 20 ... 31
cf = ∑ 12, 13, 14, 15 + ∑X 20 ... 31
onde os números representam os mintermos. Note que a primeira somatória reúne os
mintermos para os quais a saída é necessariamente 1 e a segunda somatória os mintermos para
os quais a saída pode ser 1, já que seu valor é irrelevante (X).
Essas equações Booleanas podem então ser minimizadas, como segue:
(o simbolo ^ indica a operação lógica “ou exclusivo” (XOR))
D2= Q1 * Q0 [Equação 1]
D1= Q1 ^ Q0 [Equação 2]
D0= (Q1 * Q0’) + (Q2’ * Q0’ * usb_sleep * rxf’) [Equação 3]
rd= (Q1 ^ Q0)’ [Equação 4]
ren= Q1 * Q0 [Equação 5]
cf = Q1 * Q0 [Equação 6]
As minimizações foram obtidas com minimizador lógico descrito em [Soa93].
69
A Tabela 5 é a representação tabular das funções de transição e de saída para
FSM_CFG ilustrada na Figura 17.
Tabela 5 – TTES correspondente ao DTE da Figura 17.
Estado Presente Entradas Próximo Estado Saídas
Mintermo Q1, Q0 cf D1, D0 sel2, en, dec_en
0 0, 0 0 0, 0 0, 0, 0
1 1 0, 1
2 0, 1 0 0, 1 1, 0, 0
3 1 1, 0
4 1, 0 0 1, 1 0, 1, 0
5 1 1, 1
6 1, 1 0 0, 0 0, 0, 1
7 1 0, 0
De forma similar à apresentada anteriormente, as equações Booleanas abaixo, podem
ser obtidas a partir da Tabela 3:
D1= ∑ 3, 4, 5
D0= ∑ 1, 2, 4, 5
sel2= ∑ 2, 3
en= ∑ 4, 5
dec_en= ∑ 6, 7
Essas equações Booleanas podem então ser minimizadas, como segue:
D1= (Q1 ^ Q0) * (Q1 + cf) [Equação 7]
D0= (Q1’ + Q0’) * (Q0’ + cf’) * (Q1 + Q0 + cf) [Equação 8]
sel2= Q1’ * Q0 [Equação 9]
en= Q1 * Q0’ [Equação 10]
dec_en= Q1 * Q0’. [Equação 11]
A Figura 33 da Seção A.1 mostra a estrutura do circuito FSM que corresponde ao
diagrama em blocos da Figura 14 da Seção 4.4.4. Os diagramas da Figura 39 e Figura 40
ilustram os circuitos detalhados de FSM obtidos pela minimização acima para FSM_READ e
FSM_CFG
70
Figura 39 – Diagrama esquemático da máquina de leitura (FSM_READ).
Figura 40 – Diagrama esquemático da máquina de configuração (FSM_CFG).
APÊNDICE B – Módulos Conversores USB
B.1 – Informações Adicionais sobre os Conversores USB
B.1.1 – Conversor USB/Serial
O módulo conversor USB/Serial utilizado neste projeto é o USBMOD1 [G3201] e
utiliza o CI FT8U232AM [F3200].
O nível dos pinos do conversor USB/serial durante os dois estados de inicialização
possíveis e o modo “sleep” (reset, configuração e “sleep”) é descrito a seguir [Ftd02]:
TX:
• Estado de reset: “tri-state”, mas “puxado” para VCC por resistor interno de 200k.
• Estado de configuração: nível 1
• Em modo “sleep”: nível 1
RX:
• Estado de reset: ignorado pelo módulo
• Estado de configuração: Ativo (9600 baud) – reset dos “buffers”.
• Em modo “sleep”: ignorado pelo módulo
RTS#:
• Estado de reset: “tri-state”, mas “puxado” para VCC por resistor interno de 200k.
• Estado de configuração: nível 1
• Em modo “sleep”: nível 1
CTS#:
• Estado de reset: ignorado pelo módulo
• Estado de configuração: ignorado pelo módulo
• Em modo sleep: ignorado pelo módulo
RI#:
• Em modo sleep: recebendo nível 0 “acorda” o módulo do estado “sleep”.
72
Como pode ser observado pela descrição acima, quando o conversor USB/Serial entra
em um de seus dois estados de inicialização possíveis ou modo “sleep” (reset, configuração e
“sleep”) ele desabilita o fluxo de entrada para RX vindo do canal correspondente pois, nos três
estados, RTS# permanece em nível 1. Além disso, o nível recebido em CTS# é ignorado
interrompendo a transmissão na saída TX. Desta forma é assegurado o correto fluxo de dados
entre os nós trabalhadores e que nenhum bit espúrio será escrito (lido) para (de) nenhum nó
tranbalhador.
Parte-se ainda do pressuposto de que na inicialização cada nó trabalhador deverá
“avisar” o nó de controle que está em estado de pronto e configurado para transmitir. Só
então, após receber a mensagem inicial de todos os nós trabalhadores, o nó de controle
enviará a primeira operação, garantindo assim que não seja realizada uma operação, pelo nó
de controle, com nenhum conversor USB/Serial não inicializado por algum nó trabalhador.
A opção “remote wake-up” dos descritores do dispositivo USB [F2300] deve ser
habilitada via driver de dispositivo [Ryd02] para que o pino RI# seja monitorado.
Caso os bytes do final de uma mensagem transmitida por um canal de comunicação
não formem um pacote eles ficarão na fila de transmissão do conversor USB/Serial até que o
tempo de “timeout” de 16ms seja atingido quando então serão finalmente enviados a seu
destino. Para evitar este atraso é necessário enviar um “event character” anexo ao final de
cada mensagem transmitida pelos canais de comunicação [FA301]. Na nova geração dos
conversores USB [Ftd02] o tempo de “timeout’ é ajustável entre 1 e 255 ms. Para o conversor
USB/Paralelo este detalhe não é relevante pois ele só recebe dados do canal de configuração,
utilizando apenas a fila de recepção.
Para obter a velocidade de 3 Mbps nos conversores USB/Serial (velocidade máxima) é
preciso ajustar o “prescaler divisor” para zero através do driver de dispositivo [FA101]
[Ryd02].
Caso convenha como alternativa, os conversores USB/Serial podem ainda ser
substituídos por conversores de nível (MAX233CPP para 115kbps) para funcionarem com o
padrão RS-232 como meio de transmissão. Pode-se ainda utilizar o transceptor MAX3086
para o meio RS-422 até 2 Mbps.
73
B.1.2 – Conversor USB/Paralelo
O módulo conversor USB/Paralelo utilizado neste projeto é o USBMOD2 [G4501] e
utiliza o CI FT8U245AM [F4500].
O diagrama de temporização do ciclo de leitura da fila do conversor USB/Paralelo está
ilustrado na Figura 41 [F4500].
Figura 41 – Diagrama de temporização do ciclo de leitura do conversor USB/Paralelo
Como observação, os tempos T3, T5 e T6 da Figura 41 estão associados ao
funcionamento do conversor USB/Paralelo. No traçado de osciloscópio [FA401], para uma
freqüência de 12MHz, o tempo T3 na prática é de 50 ns, o tempo T5 é de 25 ns, e o tempo T6
é de 333,3 ns (4 períodos de relógio para sincronização interna).
Para o sinal RD, que provém da unidade de controle, o projeto das máquinas de
estados finitos do “crossbar” determinou um tempo T1 de 166,6 ns (dois períodos de relógio)
e um tempo T2 de no mínimo 250 ns (três períodos de relógio), estando portanto ambos os
tempos acima do mínimo especificado que é de 50 ns tanto para T1 como para T2.
74
O nível dos pinos do módulo conversor USB/Paralelo durante os dois estados de
inicialização possíveis e modo “sleep” (reset, configuração e “sleep”) é descrito a seguir
[Ftd02]:
RCCLK: (usb_sleep)
• Quando o módulo entra em modo “sleep” esta saída entra em nível 0.
RXF#:
• Estado de reset: Em reset, RXF# vai para “tri-state” mas é posto em nível 1 por
um resistor “pull up” de 200k no CI. Resumindo: nível 1.
• Estado de configuração: nível 1.
• Em modo “sleep”: Durante “suspend mode” o estado de RXF# não muda. De
onde se faz necessário monitorar o pino RCCLK para evitar a leitura do módulo
durante “suspend mode”.
RD#:
• Estado de reset: ignorado pelo módulo.
• Estado de configuração: ignorado pelo módulo
• Em modo “sleep”: ignorado pelo módulo.
Pela descrição acima, nota-se que a saída RXF# do conversor USB/Paralelo fica
desabilitada em nível 1 durante todo o período de inicialização, assegurando que nenhum
dado espúrio seja lido pela unidade de controle.
Embora não ilustradas, o conversor USB/Paralelo possui duas linhas (WR e TXE#) que
permitem o envio de bytes da unidade de controle para o PC “host”.
As oito linhas de dat[7..0] que chegam ao FPGA, ilustradas na Figura 7 da Seção
4.2.2, ficam em estado de alta impedância (“Z”) durante todo o tempo em que não estão ativas
e portanto cada uma delas deverá ser conectada a um resistor “pull-down” para prevenir
oscilações durante sua inatividade.
75
B.1.3 – Alternativa ao Conversor USB/Paralelo
O conversor USB/Paralelo oferece uma velocidade de transmissão para o canal de
coniguração de até 8 Mbps. No entanto é preciso mencionar que o barramento USB transfere
dados em pacotes. Quando dados são enviados a partir do PC, um pacote de dados é montado
pelo driver de dispositivo e enviado para o escalonador de tarefas USB que põe a requisição
numa lista de tarefas a serem realizadas pelo “USB host controller”. Este utiliza “frames” de 1
milisegundo para transmissão de qualquer pacote de dados pelo barramento [FA301][USB00].
Isto significa que se uma mensagem isolada de 2 bytes for enviada, o “throughput” será de 2
bytes / 1 milisegundo (16 kbps); uma mensagem de 40 bytes, 40 bytes / 1 milisegundo (320
kbps); ...; para 128 bytes, 128 bytes / 1 milisegundo (1024 kbps); para 256 bytes, 256 bytes / 1
milisegundo (2048 kbps); ... Logo a velocidade do canal de configuração irá variar com a
quantidade de mensagens enviadas de uma só vez.
Se as características acima não se adequarem aos requisitos para rede de trabalho do
multicomputador, pode-se utilizar uma segunda opção para interface do canal de configuração
com a unidade de controle. A alternativa é utilizar a “PIC16F877 Development Board” da
Futurlec [Fut02] ilustrada na Figura 42 ou similar. Este é um módulo (pronto para usar) com
uma PIC UART que pode ser conectado diretamente ao FPGA sem componentes adicionais
(da mesma forma que o conversor USB/Paralelo) e que com seu cristal de 4 MHz recebe
dados à velocidade de 57,6 Kbps. Este módulo PIC UART pode ser programado “in system”
para oferecer a mesma interface 8-bit paralelo TTL exposta acima, com a diferença de que o
meio de transmissão será RS-232/422 ao invés de USB. A Gigatechnology [Gig02] provê o
“firmware” para tal interface por um custo razoável, conforme informado na Seção D.1. No
entanto este “firmware” pode ser programado localmente (em MPLAB-C, MPASM ou
mesmo PIC-BASIC), pois é de baixa complexidade. O software MPLAB (além de outras
ferramentas) está disponível “royalty free” para emulação e simulação deste microcontrolador
(www.microchip.com). O diagrama da interface está ilustrado na Figura 43.
Figura 42 – PIC16F877 Development Board” da Futurlec
76
Figura 43 – Conversor RS-232 / 8-bit paralelo TTL ligado ao FPGA.
Aqui também, embora não ilustradas na figura, a PIC-UART possuirá duas linhas
semelhantes (WR e TXE#) que permitem o envio de bytes da unidade de controle para o PC
“host”. Caso a mesma não possua uma saída para “modo sleep” então o pino usb_sleep do
FPGA poderá ser “amarrado” a VCC.
É importante ressaltar que, caso seja utilizado um cristal de 20MHz com o
microcontrolador PIC16F877 em conjunto com um meio de transmissão RS-422, o “crossbar”
pode receber dados à velocidade de 1,25 Mbps (www.microchip.com). A limitação da
velocidade a 57,6 Kbps está restrita ao módulo da Futurlec mencionado nesta seção.
77
B.1.4 – Software e Hardware para os Conversores USB
Quanto ao software, ambos os conversores USB serão vistos pela interface dos
processos, tanto do nó de controle quanto dos nós trabalhadores como uma porta COM serial
comum devido ao driver “Virtual COM Port” para Linux [Ryd02][Ftd02]. Este driver faz
parte do S.O. Linux a partir do Kernel 2.4.14 e foi desenvolvido pelo engenheiro de sistemas
Bill Ryder [Ryd02], sua documentação e código são abertos, e podem ser alterados sob
licença GPL (ou seja, publicação do código). A Documentação da API do “Virtual COM
Port” pode ser obtida sob “Non-Disclosure Agreement” por solicitação a FTDI [Ftd02].
Quanto ao hardware de comunicação necessário nos nós do multicomputador, em boa
parte das máquinas comerciais há uma função USB “onboard” e “ATX form cards”, porém
estas placas só possuem 2 portas. No entanto placas PCI/USB de 4 portas são bastante
comuns e econômicas.
Os meios de conexão utilizados entre as máquinas do multicomputador e os
conversores USB que realizam a interface com o “crossbar” serão cabos USB do tipo A-B
com dimensões variando entre 1,80, 3,00, 4,80 e 5,00 metros de comprimento.
Os CIs da FTDI mencionados aqui são compatíveis com o padrão USB 1.1. E todos os
cabos e placas mencionados acima devem ser compatíveis com este padrão.
É preciso ressaltar que já estão em fase de lançamento pela FTDI [Ftd02] novos CIs
que podem operar tanto na versão USB 1.1 como na versão USB 2.0 (12MHz). Os novos
módulos conversores serão fabricados pela Dlp Design [Dlp02] e pela Gigatechnology
[Gig02].
78
B.2 – Principais Vantagens da Utilização dos Conversores USB.
Uma vez que os conversores USB possuem soquetes específicos, a substituição de
qualquer conversor avariado consiste simplesmente em retirá-lo do soquete substituindo-o por
um novo. Conclui-se que isto confere um grau de simplicidade de manutenção para o
“crossbar” visto que os conversores individualmente são de baixo custo e descartáveis.
Uma característica importante é que utilizando-se resistores “pull-up” em todas as
entradas para o FPGA provindas dos soquetes dos conversores USB/Serial (canais de
comunicação) será possível utilizar qualquer número de conversores/portas desejado entre 2 e
32 conversores. Os resistores “pull-up” têm por finalidade evitar que as entradas não
utilizadas fiquem desconectadas e fazer com que as mesmas fiquem em seu estado “default”
adequado (nível 1).
Isto confere modularidade à dimensão do “crossbar”, permitindo que sejam adquiridos
poucos conversores (e.g. 4) para testes iniciais e incrementar os mesmos gradualmente com o
andamento dos experimentos. O protótipo conterá efetivamente apenas um banco de 32
soquetes. Desta forma os custos dos experimentos com o protótipo podem ser reduzidos
substancialmente adquirindo-se apenas os módulos conversores USB/Serial necessários.
Outra característica física de grande vantagem oferecida pelos módulos conversores é
a confiabilidade oferecida na transmissão USB (diferencial) dos dados que vão dos
computadores até os conversores de interface com o FPGA. Além da transmissão ser
diferencial, neste caminho dos dados são realizados CRC16 e CRC5 além de “Packet Retry”,
conferindo na prática 100% de confiabilidade entre o computador e o dispositivo
[Ftd02][F4500] (a utilização direta de uma interface RS-232 precisaria levar em conta a
presença de erros no meio físico).
Após este primeiro caminho dos dados eles estarão disponíveis em nível TTL para
serem conectados diretamente ao FPGA. Ora, em condições ideais a conexão entre o
conversor USB/Paralelo (configuração) e o FPGA (“crossbar”) pode também ser considerada
praticamente 100% livre de erros devido ao mecanismo de transmissão entre ambos, que é
bastante preciso, e ao fato de todos os sinais estarem em nível TTL e na mesma placa. Pode-se
então, a princípio, dispensar para um primeiro protótipo, qualquer controle de erro como
CRC, CheckSum ou mesmo Paridade no canal de configuração. Isto considerando-se, por
hipótese, a transmissão entre o conversor USB/Paralelo e o FPGA sob condições ideais de
desacoplamento, blindagem, fonte externa, etc., em que nenhum byte será perdido ou
corrompido por problemas de implementação ou ruído elétrico externo.
79
Pelo fato de o mecanismo de interface do conversor USB/Paralelo ser assíncrono, a
freqüência de operação do FPGA (“crossbar”) não é crítica, basta que ela esteja “em torno” de
12MHz, freqüência escolhida. Esta última é uma característica desejável, pois torna a
implementação de um futuro protótipo mais viável, simples e flexível em relação a
freqüência.
Com relação ao cabeamento o padrão USB suporta cabos de 5 metros de comprimento
com segurança [USB00] o que confere uma boa flexibilidade na composição de uma rede de
trabalho para o multicomputador se comparado ao padrão RS-232 que pode chegar a atingir a
velocidade de 115Kbps com um cabo de no máximo 3 metros de comprimento e de boa
qualidade (http://www.vutrax.co.uk/vbook2.htm) mas que no entanto continua não sendo um
barramento diferencial como no padrão USB.
Mais uma característica relevante com relação aos conversores de interface é o seu
tamanho reduzido, com a dimensão de 1,88 cm de largura por 4,19 cm de comprimento,
constituindo-se de um conector USB tipo B, um CI da FTDI, um cristal e componentes
auxiliares, como está ilustrado em tamanho natural na Figura 44 [Gig02].
Figura 44 – Módulos conversores USB em tamanho natural
Alguns Links importantes para futura continuação do projeto do “crossbar” em
conjunto com os módulos conversores USB são listados a seguir:
1. http://www.dlpdesign.com;
2. www.gigatechnology.com;
3. www.ftdichip.com;
4. http://www.usbman.com/index.html;
5. www.usb.org;
6. http://www.beyondlogic.org/serial/serial.htm;
7. http://www.beyondlogic.org e
8. http://www.lammertbies.nl/comm/index.html.
80
APÊNDICE C – Melhorias e Cuidados Operacionais.
C.1 – Melhorias Introduzidas
O modelo da célula de conexão apresentado anteriormente [Soa01] era conceitual e
sua validação limitava-se à simulação funcional. Para operação em um protótipo real, algumas
adaptações foram realizadas com a finalidade de filtrar os “hazards” que ocorrem entre as
entradas e saídas assíncronas dos canais de comunicação do “crossbar” durante a conexão,
desconexão e reset de uma dada célula de conexão, e são válidas para qualquer meio de
comunicação que venha a ser adotado no futuro. Estas adaptações podem ser acompanhadas
pelo esquemático do decodificador na Figura 45 e pela ilustração da célula de conexão na
Figura 46, as quais foram repetidas por praticidade. O detalhamento do problema é descrito a
seguir. Uma revisão bastante sucinta da teoria sobre “static hazards”, sua detecção e
prevenção pode ser encontrada em [Woo97] e uma explanação mais abrangente pode ser
encontrada em [Koh78].
Figura 45 – Diagrama esquemático de DECODER.
82
Figura 46 – Diagrama de blocos da célula de conexão.
• Ocorrem “hazards” na lógica dos dois MUXes da célula de conexão ilustrada na
Figura 46 somente quando estes são atualizados pelas saídas dos registradores da
célula (REG1 e REG2).
• Os “hazards” ocorrem nos MUXes em determinadas trocas de estado dos
registradores, dependendo ainda do valor das entradas para os MUXes neste
momento.
• Os “hazards” atingem isoladamente só aquela célula de conexão que está trocando
de estado, sem afetar as demais.
Baseado nos padrões de operação normais do “crossbar”, que estão de acordo com a
transmissão serial assíncrona padrão, são descritas abaixo algumas considerações sobre o
problema e proposta uma solução.
83
MUX2 (reponsável pela conexão/desconexão com a saída out j da célula):
As conexões e desconexões só ocorrem respectivamente antes e depois das
transmissões, portanto em estado “idle” (nível lógico 1). Assim, no momento em que o
registrador REG2 provoca uma mudança no seletor do MUX2, como visto na Figura 46, os
dois níveis envolvidos nas entradas deste MUX são nível 1 (um é o canal de entrada
selecionado, que está em “idle” e o outro é VCC). Este é exatamente o único caso onde ocorre
um “static-1 hazard” em um MUX de 2 entradas como o MUX2. Na verdade um MUX de
duas entradas se enquadra exatamente na definição mais simples de “static-1 hazard” como
pode ser observado em [Woo97]. Isto significa que haveria um pequeno intervalo de tempo
onde a saída do MUX2 iria para nível zero quando as duas entradas deste MUX estivessem em
nível 1 e o seletor do mesmo fosse alterado pelo registrador REG2 . No entanto, após a síntese
lógica de um MUX de duas entradas onde uma delas está “amarrada” a VCC, realizada
automaticamente pelo MAX+PLUS II, esta única situação de “hazard” é eliminada. O MUX2,
portanto, fica livre de “hazards” em todas as situações (Neste projeto foram utilizadas as
opções “default” de síntese lógica para o mapeamento do dispositivo ACEX1K50).
Observe que uma operação de reset também ocorre quando as transmissões estão em
estado “idle” (nível 1), no entanto, não haverá “hazard” no MUX2 também para esta operação
pelo mesmo motivo exposto acima.
MUX1 (responsável pela seleção do canal de entrada na célula de conexão):
Quando REG1 atualiza a seleção de novo canal de entrada no MUX1, como pode ser
visto na Figura 46, há muitas portas lógicas com situações de atraso que geram “hazards”,
pois se trata de um MUX 32 x 1, e seria muito complexo eliminar os “hazards” neste caso.
• conexão: Relembrando, quando uma operação de conexão é realizada sobre uma
dada célula de conexão ela está sempre previamente desconectada (saída do MUX2
em VCC). Consideremos inicialmente, por hipótese, que os dois MUXes sejam
atualizados no mesmo período de relógio pelos registradores REG1 e REG2. O
MUX1 então troca de estado quando há uma conexão (connect x, y) causando
“static hazards” em sua saída, o que é inevitável. Ao mesmo tempo o MUX2 vai de
VCC para conectado. Desta forma os “hazards” gerados na saída do MUX1
passariam diretamente para a saída out j através do MUX2. SOLUÇÃO: retirando
o MUX2 de VCC um período de relógio após o MUX1, como visto no
decodificador da Figura 45 onde os sinais cd e load_cd estão sincronizados por um
flip-flop, evita-se que os “hazards” se propaguem através do MUX2 pois, no
84
período de relógio seguinte, os “glitches” causados pela troca de estado na saída do
MUX1 terão desaparecido e sua saída poderá então ser conectada pelo MUX2 com
segurança . O MUX2 por sua vez é livre de “hazard”, como já foi explicado.
• desconexão: O MUX1 da célula não troca de estado quando há uma desconexão
pois no comando “disconnect x, y” os operandos x e y são os mesmos que foram
utilizados na operação de conexão. Como o operando x, responsável pela ativação
do sinal src, é o mesmo, o registrador REG1, seletor do MUX1, não é alterado, não
causando “hazards” como pode ser observado na Figura 46.
• reset: A solução aqui é não utilizar reset em REG1 que atualiza o MUX1 (como
visto em [Soa01]) para que não hajam “hazards” no mesmo (vide Figura 46). Além
disto é necessário desativar todas as linhas do sinal load_src durante a operação de
reset, como visto no decodificador da Figura 45, com o mesmo propósito pois, na
operação “reset x,y”, o operando “x” que ativa o sinal src causaria uma mudança
no registrador REG1 da célula y caso o sinal load_src estivesse ativado
provocando um “hazard” nesta célula (Como os operandos x e y da operação reset
têm valor zero eles causariam uma alteração na célula zero da unidade operativa).
Os “hazards” no MUX1 estão condicionados antes de mais nada a uma mudança de
seleção causada pelo registrador REG1, e, como visto aqui, para uma operação de
reset, esta mudança de seleção foi eliminada. E no MUX2, como visto acima, não
há “hazards”.
Caso no futuro se utilize um terceiro sistema de CAD que não elimine em particular a
situação de “hazard” do MUX2 mencionada acima durante a síntese lógica, pode-se
facilmente substituir a “megafunction” utilizada para este MUX pelo circuito ilustrado na
Figura 47, garantindo assim a eliminação do “hazard” mesmo antes da síntese lógica. Uma
explicação da teoria para o circuito lógico da figura pode ser encontrada em [Woo97]. De
forma sucinta pode-se dizer que, considerando a função booleana f (sel, A, B) que representa o
circuito da figura, o produto A*B foi adicionado para cobrir os mintermos 3 e 7
correspondentes a esta função, eliminando desta forma o “hazard” causado pela variável sel.
85
Figura 47 – Mux de 2 entradas livre de “hazard”
É preciso ressaltar que tão somente o bloco de circuito ilustrado na Figura 47 precisa
ser compilado como “What You See Is What You Get” para que a redundância A*B não seja
eliminada na síntese lógica.
Estas soluções utilizadas para eliminação dos “hazards” entre entradas e saídas do
“crossbar” não estão restritas apenas ao meio de transmissão USB/RS-232 ora adotado neste
projeto do “crossbar”. Os mesmos esquemas podem vir a ser utilizados para qualquer meio de
comunicação adotado no futuro, como por exemplo: Ethernet, IEEE 1394b, LVDS, etc.
86
C.2 – Melhorias Sugeridas
Considerando-se a hipótese, mencionada na Seção B.2, de que nenhum byte seja
perdido no canal de configuração, é sugerido a seguir um possível controle de erro dos bits da
palavra recebida pelo “crossbar”.
Os quatro bits menos significativos da palavra de 16 bits descrita na Seção 3.3 podem
ser reservados para futura implementação de CRC4, que pode utilizar, por exemplo, o
polinômio gerador x4 + x + 1 da ITU-T. Seria necessário para isto um somador deslocador
modular de apenas 4 flip-flops de acordo com a Figura 48 [Rit86].
Neste caso, devido ao formato binário do opcode da mensagem que nunca assume o
valor (11)2 e ao formato do código CRC que nunca assume o valor Fh, o byte FFh não
ocorreria na palavra e poderia ser utilizado como caractere de resincronização.
Figura 48 – Circuito verificador de CRC4 ITU-T
87
C.3 – Cuidados Operacionais
C.3.1 – Conectividade
O conversor USB/Serial suporta em sua interface todas as linhas de “handshaking”
para o padrão RS-232. Porém, devido ao fato de que apenas as linhas de transmissão e
recepção de dados TX e RX e as linhas de controle de fluxo RTS#, CTS# e RI# serão utilizadas
no projeto, se faz necessário a utilização de um esquema de cabo “Null Modem”.
Na Figura 49 é ilustrada a configuração de cabo “Null Modem” que deve ser utilizada
entre o conjunto de pinos de dois conversores USB/Serial quaisquer, utilizados
respectivamente na comunicação entre dois nós trabalhadores quaisquer através do
“crossbar”.
Figura 49 – Diagrama de Null-Modem para os conversores USB/Serial
Os pinos TXDEN, USBEN e SLEEP do conversor USB/Serial permanecerão
desconectados e o pino PCTL deve ser “amarrado” a VCC indicando ao módulo conversor
que há uma fonte própria de alimentação [G3201]. A opção “bus powered” dos descritores do
dispositivo USB [F2300] deve ser desabilitada via driver de dispositivo [Ryd02] para que a
fonte própria seja utilizada.
Para alimentar ambos os módulos conversores USB com uma fonte própria deverá ser
removido o resistor “R4” (VCC USB) de cada módulo [GE101], concectando-se o terminal
+5V da fonte própria ao pino 6 do módulo conversor (Power Supply pin) [G3201]. Além
disso, é necessário um pequeno circuito adicional, com uma porta lógica AND e um
transistor [FA201]. A segunda geração dos módulos conversores USB incorporará todos os
componentes necessários para alimentação externa.
88
C.3.2 – Inicialização do Sistema
A seguir será descrito o esquema de sincronização entre a inicialização do conversor
USB/Paralelo e a inicialização do FPGA.
O FPGA escolhido é baseado em elementos de RAM síncrona CMOS reconfigurável.
Isto requer a utilização de um dispositivo de configuração, contendo uma EPROM a ser
programada com os dados compilados a partir do projeto no ambiente de CAD. Este
dispositivo é o EPC1 [Epc02], que configura o FPGA através de uma linha serial. O CI
utilizado pode ser o EPC1PC8.
O tempo de “PowerOnReset” do EPC1, que serve para permitir que as tensões na
fonte estabilizem, é de 200 ms [Epc02]. E o tempo de configuração do FPGA a partir do
dispositivo é de 40 ms no máximo [Ace01]. Isto significa que o tempo entre o instante em que
o sistema é ligado e o instante em que o "crossbar" está “pronto para utilização” fica em torno
de 240 ms (ta).
O período de reset do conversor USB/Paralelo é de 350 ms (tb) como ajustado pelo CI
de reset “on board” MCP100T-315/TT da Microchip [Gig02]. Após isto o conversor leva em
torno de 150 ms em modo de configuração. Isto significa que o tempo entre o instante em que
o sistema é ligado e o instante em que o conversor USB/Paralelo está “pronto para utilização”
é de 500 ms [Gig02].
Basta então conectar a linha de reset do módulo conversor com a entrada de reset do
“crossbar” para que ambos saiam simultaneamente do estado de reset após 350 ms. Assim, o
"cossbar" dispõe de cerca de 110 ms (350 ms (tb) – 240 ms (ta)) para inicialização, garantindo
a correta ordem de precedência de inicialização do conversor USB/Paralelo e do FPGA o que
é indispensável à sua operação. Ademais isto dispensa um circuito de reset adicional.
No momento em que o “crossbar” sai do estado de reset após tb, o conversor
USB/Paralelo ainda permanecerá em modo de configuração por 150ms até o estado em que
está pronto para enviar o primeiro byte. Isto garante que o “crossbar” já estará pronto na
chegada do primeiro byte, evitando que o módulo conversor entre em modo “sleep” com
bytes não lidos na fila (o módulo entra em modo “sleep” após 3ms de inatividade segundo a
especificação USB [USB00]).
Como não há um pino de saída para reset no conversor USB/Paralelo [G4501], os
pinos 4 (reset) do CI FT8U245AM e rst do “crossbar” deverão ser fisicamente conectados
[GE101]. A segunda geração dos conversores USB contará com uma saída de reset específica
para este fim.
89
Caso a configuração do FPGA, em fase experimental, seja feita diretamente a partir do
PC via cabo de download paralelo ou serial [Ace01], então um esquema alternativo de
sincronização entre a inicialização do módulo conversor e a inicialização do FPGA poderá ser
providenciado.
De forma similar, como não há um pino de saída no conversor USB/Paralelo para
RCCLK., para monitorar o modo “sleep” [G3201], os pinos 31 (RCCLK) do CI FT8U245AM
e usb_sleep do “crossbar” deverão ser fisicamente conectados [GE101] (A segunda geração
dos conversores USB virá com um pino de saída específico para o modo “sleep”).
Recomenda-se utilizar a segunda geração dos conversores USB [Dlp02][Gig02], pois
estes facilitam consideravelmente o projeto de interface e inicialização do sistema e não terão
aumento significativo em seu custo segundo a FTDI [Ftd02].
Quanto à inicialização dos conversores USB/Serial (canais de comunicação) não há
problemas críticos. Uma vez que estes possuem o mesmo CI MCP100T-315/TT do conversor
USB/Paralelo mencionado acima, todos eles sairão de reset em torno de 350 ms após o
instante em que o sistema é ligado. Pode-se concluir, a partir da Seção B.1.1, que os
conversores USB/Serial podem sair do estado de reset antes ou depois do “crossbar” sem
nenhum problema.
Informações importantes para depuração dos módulos conversores USB com o
“crossbar”, como solução de problemas com os sinais dos conversores, descrição detalhada de
todos os sinais e traçado de osciloscópio da dinâmica de todas as entradas e saídas podem ser
encontrados em [FA401].
90
APÊNDICE D – “Crossbar” com Interfaces RS-232 (115,2 Kpbs)
D.1 - Componentes da Placa Mãe, Placas,Cabos e Custo do Sistema
Nesta seção são detalhados os componentes necessários juntamente com o custo
individual de cada componente para um “crossbar” com interfaces RS-232 a 57,6 Kbps no
canal de configuração e até 115,2 Kbps nos canais de comunicação. Todos os componentes
são encontrados no mercado nacional, com exceção da placa de desenvolvimento PIC16F877
e dos transceptores MAX233CPP. A Tabela 6 mostra os cabos necessários e placas
adaptadoras e seu custo. A Tabela 7 mostra os componentes fundamentais que integram a
placa mãe e respectivos custos.
Tabela 6 – Cabos e placas adaptadoras e seu custo para interfaces RS-232 (115,2 Kbps).
Quant. Componentes Custo unit. em
US$
Subtotal em US$
c/ impostos (1)
Fonte
32 Cabos 3 metros
RJ-45/RJ45
RS-232
3,16 101,12 (2) www.senhor.com
.br (MG)
8 Placas RS-232
115Kbps – ISA
4 saídas RJ-45 (3)
105,70 845,60 (2) www.integral.co
m.br (SP)
Total em US$ c/ impostos 946,72
Notas:(1) Custo total pelo dólar comercial com a carga tributária máxima já incluída sem considerar nenhuma
lei de redução de impostos sobre material destinado a instituições de ensino.(2) Frete não incluso. O ICMS incluído é de 12%.(3) Placas Naxos ISA RS-232 da Integral Sistemas com conectores RJ-45. Garantia de 5 anos.
92
Tabela 7 – Componentes da placa mãe e seu custo para interfaces RS-232 (115,2Kbps).
Quant. Componentes Custo unit. em
US$
Subtotal em US$
c/ impostos (1)
Fonte
1 FPGA
EP1K50FC256-3
55,60 Acumula Abaixo
1 Disp. conf.
EPC1PC8
14,80 78,85 (2) www.picompone
ntes.com.br (SP)
32 (36 mín.) Transceptores
MAX233CPP
4,32 (fob) 338,43 (3) (4) www.avnet.com
(EUA)
32 Soquetes gold
p/ transceptores
0,50 16,00 (2) www.blupel.com.
br (SC)
32 Conectores
RJ-45 fêmea
3,30 105,60 (2) http://www.ditell.
com.br (ES)
1 Placa
PIC16F877
27,90 (fob) Acumula Abaixo
1 Cabo
RS-232 / 4 pinos
Polarizado
2,50 (fob) 58,24 (4) www.futurlec.co
m (AU)
Total em US$ c/ impostos 597,12
Notas:(1) Custo total pelo dólar comercial com a carga tributária máxima já incluída sem considerar nenhuma
lei de redução de impostos sobre material destinado a instituições de ensino.(2) Frete não incluso. O ICMS incluído é de 12%.(3) Inclui taxa de manuseio da Avnet Inc. de US$ 50,00.(4) Cotação incluindo transporte (US$ 6,00). Importação por correio aéreo (isento de ICMS) sob
Regime de Importação Simplificada que é isenta de IPI (aliquota única de 60% sobre (bens + transporte) até US$3000,00).
(5) As cotações da Tabela 6 e Tabela 7 foram finalizadas em 10 de junho de 2002
O custo total para uma rede de trabalho com meio de transmissão RS-232 é portanto
de US$ 1.543,84.
Se o “firmware” da placa PIC16F877 não for programado localmente isto pode ser
feito pela empresa Gigatechnology [Gig02] a um custo de US$ 91,39 (AU$ 160,00). Isto
levaria o custo total a US$ 1.635,23.
93
D.2 – Estrutura da Placa Mãe
No caso de serem usados a PIC-UART no canal de configuração e transceptores RS-
232 nos canais de comunicação, a disposição da placa em tudo se assemelha ao esboço
mostrado na Figura 27 da Seção 6.2. Os conversores USB/Serial serão substituídos pelos
transceptores e conectores RJ-45 no banco de conectores, e ao invés do conversor
USB/Paralelo interno à placa mãe, será utilizada a PIC-UART externamente à placa mãe para
o canal de configuração.
94
APÊNDICE E – Discussão Sobre a Integração com o SistemaOperacional
E.1 – Desempenho do Driver de Dispositivo
Conforme visto na Seção B.1.4, na comunicação dos processos com os módulos
conversores USB pode ser utilizado o driver Virtual COM Port para Linux que foi
desenvolvido por Bill Ryder [Ryd02]. Um teste com um programa em Pearl [Ryd02] da
velocidade de transmissão com este driver em ambos os módulos conversores USB resultou
no seguinte:
• Escrita: 512 Kbps
• Leitura: 2,16 Mbps.
Embora a interface da aplicação Pearl não seja muito rápida, isto fica bem aquém da
verdadeira potencialidade dos módulos. Ocorre que Bill Ryder escreveu este driver
originalmente para fazer a comunicação entre um PalmPilot e um PC. Portanto ele não se
preocupou em aprimorar o mesmo para desempenho. Para conseguir o máximo desempenho
dos conversores (3Mbps para USB/Serial e 8Mbps para USB/Paralelo) é provável que seja
preciso aprimorar o driver. Este driver opera sob a camada tty do Linux que de qualquer
maneira não foi criada para ser um transporte de alta velocidade mas tem a vantagem de
operar como uma porta COM serial da seguinte forma:
1. A aplicação entrega os dados para a camada do driver tty
2. O driver tty faz algum processamento nos dados (dependendo das opções seriais) e
passa-os para o topo da camada USB (o driver da FTDI).
3. O driver da FTDI então envia os pacotes formatados para a camada USB
propriamente dita (esta camada “conversa” com o software do “host controller”
que então envia os pacotes para o módulo conversor através do barramento)
Existe a possibilidade de que para obter o máximo desempenho seja preciso retirar a
camada tty e aí neste caso o driver não se comportaria mais como uma porta COM. Isto
poderia ser considerado como uma desvantagem em termos de simplicidade de interface com
as aplicações (que normalmente já têm esta interface pronta), no entanto é razoável supor que
um driver sem a camada tty ficaria mais simples do ponto de vista do Sistema Operacional.
Aparentemente a velocidade do computador que abriga o nó de controle e o S.O.
Linux também têm influência sobre o desempenho do driver Virtual COM Port. O maior
pacote USB de E/S que pode ser recebido/enviado para o módulo conversor é de 64bytes com
96
as transferências em modo “Bulk” utilizadas pelo driver [USB00][FA301]. A questão é quão
rápido a pilha usb/tty pode enviar estes pacotes para o barramento USB. Se considerarmos um
sistema que pode fazer isto duas vezes por milisegundo (um “frame” USB é um por
milisegundo) então a velocidade máxima que teríamos seria de 1024 Kbps (64 x 8 x 2 x
1000). Note que em um “frame” de 1 milisegundo é possível realizar no máximo 19
transferências de pacotes de 64bytes no modo de transferência “Bulk” segundo a
especificação USB [USB00].
Observe que as operações de configuração que forem enviadas pelo nó de controle em
pacotes durante o mesmo “frame” serão todas transmitidas pelo barramento em 1
milisegundo. Portanto, com a utilização de “buffering” em conjuntos de operações, o tempo
para envio ao “crossbar” de todo o conjunto será o mesmo: 1 milisegundo. Com a velocidade
de 512 Kbps (64 bytes / milisegundo) apresentada no teste em Pearl mencionado acima seria
possível, por exemplo, enviar 17 desconexões e 12 conexões sucessivas em 1 milisegundo.
Seria igualmente possível enviar no tempo de um “frame” as 32 operações iniciais de conexão
para o “crossbar”.
E.2 – Tempo de Atraso para Configuração do “Crossbar”
Com o atual driver, uma vez que não serão utilizados “acknowledgements” das
mensagens enviadas pelo canal de configuração para o conversor USB/Paralelo, se faz
necessário determinar o tempo entre o envio de uma operação pela aplicação do nó de
controle e sua efetiva realização no "crossbar". Isto para que se possa saber com segurança,
por exemplo, em que instante após ter enviado uma operação de “conexão entre os nós N3 e
N4” já é possível iniciar a transmissão de dados entre estes nós.
Considerando-se que
1. no protótipo do “crossbar” haverá apenas o conversor USB/Paralelo conectado ao
barramento USB do nó de controle, não havendo concorrência pelo barramento e
que
2. o canal de configuração será na prática um canal “Simplex” (apenas envia pacotes
para o módulo conversor),
pode-se considerar a hipótese de que um conjunto de operações levaria no máximo 1
milisegundo para chegar ao módulo conversor. Porém de acordo com o autor do driver
[Ryd02] seria mais seguro considerar um tempo de 2 milisegundos, isto no pior caso. Mesmo
assim, a menos que se utilize um sistema operacional em tempo real ou outra forma de fixar
este tempo, aparentemente não há garantia absoluta de que o conjunto de operações estará
97
entregue ao conversor USB/Paralelo em 2 milisegundos. Pode-se imaginar algo como receber
uma notificação do software do “host controller” quando o pacote enviado pela aplicação
finalmente foi colocado no barramento, mas para isto seria necessário escrever um driver
específico e trabalhar sobre o kernel. Além desta última, podem haver outras abordagens para
solucionar este problema.
Como visto, existe a possibilidade de que algumas adaptações tenham de ser feitas no
driver de dispositivo dos módulos conversores para contornar os problemas mencionados
nesta seção. Segue uma lista com sites importantes para o estudo do driver em questão:
1. www.linux-usb.org
2. www.linux-usb.org/USB-guide/book1.html
3. www.kernel.org/pub/linux/kernel/v2.4 (A documentação do driver está como parte
do kernel do Linux. Quando o arquivo é descompactado ela se encontra em
linux/drivers/usb/serial/ftdi*. Muito da infra-estrutura USB é utilizada incluindo
usbserial.c)
4. http://ftdi-usb-sio.sourceforge.net/ (página do driver de dispositivo para Linux)
98
REFERÊNCIAS BIBLIOGRÁFICAS
[Ace01] “Acex 1K Programmable Logic Device Family Data Sheet v. 3.3”, Altera
Corporation, EUA, 2001. URL: www.altera.com.
[Alt01] Altera Corporation, 101 Innovation Drive, San Jose, California 95134, EUA. URL:
www.altera.com.
[Ash98] Ashenden, Peter J., “The Student’s Guide to VHDL”, Morgan Kaufmann
Publishers, San Francisco, California, EUA., 1998.
[Boi96] Boing, Hamilcar, “Um Simulador para Multicomputador Implementado como
Núcleo de Sistema Operacional Multiprogramado”, Dissertação de Mestrado, Curso
de Pós-Graduação em Ciência da Computação, Universidade Federal de Santa Catarina,
Florianópolis, SC, 1996.
[Can00] Cancian, Rafael Luiz, “Avaliação de Desempenho de Algoritmos de
Escalonamento de Tempo Real para Ambiente Multicomputador”, Dissertação de
Mestrado, Curso de Pós-Graduação em Ciência da Computação, Universidade Federal de
Santa Catarina, Florianópolis, SC, 2000.
[Cor98] Corso, Thadeu B. & Fraga, Joni da S. & Freitas Filho, Paulo J. de, “A Demand-
Driven Configurable Multicomputer: Design And Evaluation”, Conference on
Comunication Networks and Distributed Systems Modeling and Simulation, San Diego,
Estados Unidos, janeiro de 1998.
[Cor99] Corso Thadeu B., “Crux: Ambiente Multicomputador Configurável por
Demanda”, Tese de Doutorado, Curso de Pós-Graduação em Engenharia Elétrica,
Universidade Federal de Santa Catarina, Florianópolis, SC, 1999.
[Dlp02] “DLP Design”. PO Box 503762, San Diego, CA 92150-3762. EUA. E-mail:
[email protected]. URL: http://www.dlpdesign.com.
[DP897] “DP83223 TWISTER High Speed Networking Transceiver Device”. Datasheet.
National Semiconductor Corporation. Japão, Abril, 1997.
[Epc02] “Configuration Devices for SRAM-Based LUT Devices Data Sheet ver. 12.1”,
Altera Corporation, EUA, Fevereiro de 2002. URL: www.altera.com.
[F3200] “FT8U232AM Data Sheet. Rev. 0.8”, FTDI, UK, 2000. URL.: www.ftdichip.com.
[F4500] “FT8U245AM Data Sheet. Rev. 0.9”, FTDI, UK, 2000. URL.: www.ftdichip.com.
[FA101] “Setting Baud Rates for the FT8U232AM”, Application Note AN232-01, FTDI,
UK, 2001. URL.: www.ftdichip.com.
100
[FA201] “Bus Powered / Self Powered Interface Circuits”, Application Note AN232-08,
FTDI, UK, 2001. URL.: www.ftdichip.com.
[FA301] “Data Rates and Flow Control Considerations for USB to RS232”, Application
Note AN232-04, FTDI, UK, 2001. URL.: www.ftdichip.com.
[FA401] “Debug Information for FT8U232/245 devices”, Application Note AN232-02,
FTDI, UK, 2001. URL.: www.ftdichip.com.
[Ftd02] “Future Technology Devices Intl. Limited (FTDI)”, St. George’s Studios, 93/97 St.
George’s Road Glasgow G3 6JA, UK, 2002. URL.: www.ftdichip.com. Suporte:
[email protected] e [email protected]
[Fut02] “Futurlec”, 24 William St, Paterson, NSW 2421, AU,2002. URL: www.futurlec.com
[G3201] “USBMOD1 Module Data Sheet”, (chip FT8U232AM), Gigatechnology.com Pty
Ltd, AU, 2001. URL.: www.gigatechnology.com
[G4501] “USBMOD2 Module Data Sheet”, (chip FT8U245AM), Gigatechnology.com Pty
Ltd, AU, 2001. URL.: www.gigatechnology.com
[Gav00] Gavilan, Júlio Cesar, “Síntese em Alto Nível de uma Rede de Interconexão
Dinâmica para Multicomputador”, Dissertação de Mestrado, Curso de Pós-Graduação
em Ciência da Computação, Universidade Federal de Santa Catarina, Florianópolis, SC,
2000.
[GE101] “USBMOD1 & USBMOD2 Schematics by B. EDE”, Gigatechnology.com Pty
Ltd, AU, Outubro, 2001. URL.: www.gigatechnology.com
[Gig02] Gigatechnology.com Pty Ltd. 1/126 Scarborough Street Southport, Queensland
4215 AU, 2002. URL:www.gigatechnology.com. Suporte: [email protected]
[Gla85] Lance A. Glasser and Daniel W. Dobberpuhl, "The Design and Analysis of VLSI
Circuits", Addison-Wesley, 1985.
[Hen98] Hennessy, John L. & Patterson, David A., “Computer Organization and Design:
The Hardware, Software Interface”, M. Kaufmann, San Francisco, 1998.
[Inm88] INMOS. IMSC004: Programable Link Switch, In: INMOS Engineering Data.,1988.
[Kat94] Kate, Randy H., “Contemporary Logic Design”, Benjamin / Cummines Publishing,
1994
[Koh78] Kohavi, Zvi. “Switching and Finite Automata Theory”. Ed. McGraw-Hill, 2.ed.
1978.
[Man88] Mano, M. Morris, “Computer Engineering Hardware Design”, California State
University, Los Angeles, E.U.A.
101
[Mer96] Merkle, Carla, “Ambiente para a Execução de Programas Paralelos Escritos na
Linguagem Superpascal em um Multicomputador com Rede de Interconexão
Dinâmica”, Dissertação de Mestrado, Curso de Pós-Graduação em Ciência da
Computação, Universidade Federal de Santa Catarina, Florianópolis, SC, 1996.
[Mic94] Micheli, Giovanni De, “Synthesis and Optimization of Digital Circuits”,
McGraw-Hill International Editions, 1994.
[Ree87] Reed D. A. and R. M. Fujimoto, “Multicomputer Networks: Message-Based
Parallel Processing”. MIT Press. 1987.
[Rit86] Ritter, Terry. “The Great CRC Mystery”. Dr. Dobb's Journal of Software Tools.
February. 11(2): 26-34, 76-83. EUA, 1986. URL: http://www.ciphersbyritter.com/
[Ryd02] Ryder, Bill, Engenheiro de Sistemas da SGI, Ph: (+64 4) 494 6326, Mobile: (+64 21
67 9507), e-mail: [email protected], icq: 16285091, Nova Zelândia, 2002. URL: http://ftdi-
usb-sio.sourceforge.net/.
[Sil00] Silveira, Cláudia Heusi, “GeCRUX: Um Mecanismo de Comunicação em Grupo
para o Ambiente Paralelo CRUX”, Dissertação de Mestrado, Curso de Pós Graduação
em Ciência da Computação, Universidade Federal de Santa Catarina, Florianópolis, SC,
2000.
[Soa01] Soares, Egeu Eduardo B., “Suporte de Hardware para Interconexão entre
Elementos de um Multicomputador”, Trabalho Individual, Curso de Pós-Graduação em
Ciência da Computação, Universidade Federal de Santa Catarina, Florianópolis, SC,
2001.
[Soa93] Soares , Egeu Eduardo B., “Minimizador de Redes de Portas Lógicas de Múltiplas
Saídas (Uma Ferramenta para Projeto de Circuitos Digitais)”,Trabalho de Graduação,
Curso de Informática, Universidade Federal de Santa Maria, Santa Maria, RS, 1993.
[USB00] “Universal Serial Bus Specification Revision 2.0”, Abril, 2000. URL:
www.usb.org
[Woo97] Wood, Sally L. “Static Hazards”, Supplemental Material for ELEN 021, Logic
Design. Electrical Engeneering at Santa Clara University, Califórnia, EUA, 1997. URL:
(http://www.ee.scu.edu/classes/2000fall/elen021/supp/stathaz.html)
[Zef96] Zeferino, Cesar A., “Projeto do Sistema de Comunicação de um
Multicomputador”, Dissertação de Mestrado, Curso de Pós-Graduação em Ciência da
Computação, Universidade Federal de Santa Catarina, Florianópolis, SC, 1996.