pdf (90) - Faculdade de Informática - pucrs

More documents

Recommendations

Info

Esta Seção aborda métodos utilizados no projeto e/ou na implementação de sistemas digitais re- configuráveis. O Item 2.4.1 propõe uma métrica para avaliação de sistemas RTR, a fim de analisar a viabilidade de implementação de um sistema assim perante um estático. Já o Item 2.4.2 traz um framework de uma ferramenta para projeto de planta-baixa temporal, que viabilizaria o projeto de sistemas RTR. Os itens 2.4.3 e 2.4.4 apresentam diferentes enfoques relativos a métodos para projeto de sistemas com características de reconfiguração dinâmica. 2.4.1 Método para projeto de sistemas RTR Pesquisadores do departamento de engenharia elétrica da Brigham Young University desenvol- veram o protótipo de um sistema de rede neural baseada em RTR parcial [HAD95]. O sistema foi chamado de RRANN-2 (Run-time Rreconfigurable Artificial Neural Network). Durante o projeto e implementação do RRANN-2, foi desenvolvido um método de projeto para sistemas RTR. O ponto mais importante deste método é maximizar a lógica que permanecerá inalterada (estática) e minimizar a lógica que precisa ser modificada durante a execução da aplicação (dinâmica). Esta ma- ximização dá-se pelo particionamento da aplicação em blocos funcionais que são, em sua maior parte, comuns a todas configurações utilizadas na implementação da aplicação. Esses blocos representam as partes da configuração que não mudam, e, portanto, podem ser implementadas como um circuito estático. O projeto de recursos para reconfiguração dinâmica só ocorrerá quando não houver unidade funcional correspondente entre a configuração implementada e a que será utilizada. Adicionalmente, a parte estática do circuito é utilizada para reter estados intermediários do dispositivo reconfigurável. Isto elimina circuitos de controle e roteamento que seriam necessários para armazenar valores. O segundo passo no desenvolvimento de um projeto de RTR parcial é mapear fisicamente os blocos no dispositivo. Além das restrições de implementação e localização necessárias, um bloco lógico também é restringido pelo contexto físico que o cerca. Todos os assuntos referentes a interconexão global, localização global, e posicionamento e interconexão com os blocos próximos têm que ser re- solvidos. O problema é que muitas dessas restrições não são conhecidas em tempo de projeto, o que vem a requerer um difícil processo interativo. Os autores deste método ressaltam a necessidade de pesquisa contínua nessa área, para cristalizar conhecimento a respeito de uma metodologia de projeto para sistemas RTR. Também citam a falta de CAD eficiente para suportar definições de restrições, posicionamento e roteamento. 2.4.1.1 Métrica para avaliação de sistemas RTR 24
Os aumentos na eficiência providos através de RTR não são obtidos sem custo [WIR98]. Tempo e largura de banda de memória adicionais são necessários para transferir os bits de configuração do circuito de uma unidade de armazenamento fora do FPGA para dentro da memória de configuração do dispositivo. Em alguns casos esse tempo extra elimina as vantagens de uma especialização em tempo de execução. Para outros casos, contudo, a relação entre custo de reconfiguração e ganhos em desempenho e economia de recursos compensa em muito o tempo de configuração. Foi proposta uma forma de avaliar a validade da utilização de RTR através de um método que cal- cula o equilíbrio entre ganho de eficiência e custo de configuração. A base da análise que realizaram é a densidade funcional [WIR98]. A métrica de densidade funcional é definida nos termos de custo da implementação de uma lógica no hardware. Esse custo (© ) é tradicionalmente medido como o produto entre a área total requerida para implementar a lógica em hardware ( ) e tempo total de operação ( ): © (2.1) E aplica-se àqueles sistemas onde a vazão (número de operações por segundo) é mais importante que a latência. inclui o tempo necessário para execução, controle, inicialização e transferência de dados. Densidade Funcional (D) mede a vazão computacional de uma unidade de hardware, e é definida como o inverso de C: © A métrica densidade funcional em (2.2) será utilizada para comparar circuitos modificados estaticamente contra as alternativas em reconfiguração dinâmica. ( ¤ O incremento ) na densidade funcional de alguns sistemas RTR ( ) sobre as alternativas estaticamente reconfiguráveis ( ) é computada como a diferença normalizada entre e , como segue: ¤ A porcentagem de incremento é medida multiplicando (2.3) por 100. A maior diferença entre sistemas RTR e os estáticos é o custo adicional de reconfiguração. Os dispositivos atuais exigem que a configuração do circuito e a execução ocorram separadamente. Isto força a adição do tempo de configuração ao tempo total de operação de um sistema RTR. Para estes sistemas, o tempo total de operação inclui o tempo total de execução ( ) e o tempo total de configuração ( ), ou: (2.2) (2.3) ¢ (2.4) 25
Page 1: Pontifícia Universidade Católica
Page 5: Agradecimentos Um trabalho extenso
Page 8 and 9: viii
Page 11 and 12: Sumário RESUMO vii ABSTRACT ix LIS
Page 13 and 14: Capítulo 5: Ferramentas para recon
Page 15 and 16: Lista de Figuras 1.1 Gráfico indic
Page 17 and 18: Lista de Tabelas 2.1 Classificaçã
Page 19 and 20: Lista de Abreviaturas FPGA Field-Pr
Page 21 and 22: Capítulo 1 Introdução Este Capí
Page 23 and 24: mais flip-flops. A maioria das arqu
Page 25 and 26: ➢ Compatibilidade em relação a
Page 27 and 28: Essas lacunas motivam a pesquisa no
Page 29 and 30: Capítulo 2 Estado-da-arte em siste
Page 31 and 32: 2.1.1.2 Granularidade Granularidade
Page 33 and 34: ➢ FPGA sem acesso a memória exte
Page 35 and 36: ➢ Sistema dinâmico: Envolve um a
Page 37 and 38: Sistemas PRISM DECPerLe Splash Spyd
Page 39 and 40: do a cada elemento uma pequena cach
Page 41 and 42: Figura 2.4: Exemplo de relocação
Page 43: complicar os programas de roteament
Page 47 and 48: 2.4.1.2 Exemplo de comparação ent
Page 49 and 50: propósito específico para execuç
Page 51 and 52: 2.4.2.2 O framework Dynasty Dynasty
Page 53 and 54: arquivo texto (nos formatos VHDL e
Page 55 and 56: hardware de tamanho arbitrário. Al
Page 57 and 58: Garp é um processador baseado no c
Page 59 and 60: Barramentos Globais n
Page 61 and 62: Figura 2.13: Esquema da estrutura i
Page 63 and 64: 2.6 Interfaces para conexão entre
Page 65: Wishbone utiliza uma arquitetura me
Page 68 and 69: plexidade, este programa de control
Page 70 and 71: aplicação Java escrita pelo usuá
Page 72 and 73: XHWIF, a interface de hardware Xili
Page 75 and 76: Capítulo 4 Hardware que habilita r
Page 77 and 78: A implementação do Cache Logic é
Page 79 and 80: Cada FPGA da família Virtex possui
Page 81 and 82: Figura 4.5: Abstração de um quadr
Page 83 and 84: O bitstream é composto por um flux
Page 85 and 86: A Figura 4.7-V inclui a escrita de
Page 87 and 88: Figura 4.10: Final de um arquivo de
Page 89 and 90: Assim, como mostrado na Figura 4.11
Page 91 and 92: Portanto, para este caso, o bit 14
Page 93 and 94: Capítulo 5 Ferramentas para reconf
Page 95 and 96:
Tabela 5.1: Alguns comandos do JBit
Page 97 and 98:
sas coordenadas foi explicado no it
Page 99 and 100:
Figura 5.5: Interface do reconfigur
Page 101 and 102:
Figura 5.6: Interface do Reconfigur
Page 103 and 104:
linha 11 determina um reset no regi
Page 105 and 106:
Tabela 5.3: Bits configuráveis do
Page 107 and 108:
Figura 5.9: Visualização do core
Page 109 and 110:
Figura 5.11: Seleção de um core n
Page 111 and 112:
A computação reconfigurável pres
Page 113:
➢ Os módulos em questão devem p
Page 116 and 117:
causa de problemas já descritos. A
Page 119 and 120:
Referências Bibliográficas [ALG89
Page 121 and 122:
[IBM99] IBM. The CoreConnect bus ar
Page 123:
[XIL99a] XILINX. XC6200 datasheet.
show all

pdf (90) - Faculdade de Informática - pucrs

Create successful ePaper yourself

Delete template?

Save as template?