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
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
À 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.
À 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.
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, baresolveu-seada 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).
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).
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.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
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
v
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
vi
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
vii
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...4ix
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”
Um 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.
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.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 de comunicação e controle Nó traba-lhador Nó traba-lhador Nó traba-lhador Nó de controle Canal de configuração Canais de comuni-cação
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 ();
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; }
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á
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.
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;
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 Rx Tx 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
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
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.
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].
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).
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.
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
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
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.
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).
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.
• 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).
4.3 – Descrição do “Datapath”
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.
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
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.
• 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.
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
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;
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.
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.
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.
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.
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.
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.
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 neutro habilita rd (0) 000 001 reset Entradas: usb_sleep: desabilita
nova leitura do módulo.
rxf: sinaliza presença de
dados na fila.
Saídas:
rd: habilita byte da fila
para ser lido.
ren: habilita leitura do
byte para o registrador.
cf: causa transição na máq. de configuração. entradas / saídas: usb_sleep, rxf / (rd, ren, cf) habilita ren e cf desabi-lita rd, ren e cf 011 100 x, x / (0, 1, 1)
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 leitura e comanda as transições na máq. de configuração. Saídas:
sel2: habilita a leitura de cada
byte em 2 registradores distintos.
en: habilita a carga do
registrador de mensagens com os 2 bytes distintos.
dec_en: habilita o
decodificador. entradas / saídas:
cf / (sel2, en, dec_en) ativa dec_en (1) 11 0 / (1, 0, 0) x / (0, 0, 1)
![Referências técnicas para atuação de psicólogas(os) em Programas de Atenção à Mulher em situação de Violência [2013] - CREPOP CREPOP](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACH5BAEAAAAALAAAAAABAAEAAAICRAEAOw==)