RELATÓRIO INTERCALAR DE ACTIVIDADES DO PROJECTO...

98
RELATÓRIO INTERCALAR DE ACTIVIDADES PROJECTO POCTI/33842/ESE/2000 TESTE CONCORRENTE PARA SISTEMAS ELECTRÓNICOS RECONFIGURÁVEIS (BASEADOS EM FPGAS COM CAPACIDADE DE RECONFIGURAÇÃO PARCIAL DINÂMICA) PERÍODO DE 1 DE NOVEMBRO DE 2000 A 28 DE FEVEREIRO DE 2002 PROF. DR. JOSÉ M. FERREIRA PROF. DR. GUSTAVO R. ALVES MESTRE MANUEL G. GERICOTA ENG. MIGUEL L. SILVA PORTO E FEUP, ABRIL DE 2002

Transcript of RELATÓRIO INTERCALAR DE ACTIVIDADES DO PROJECTO...

Page 1: RELATÓRIO INTERCALAR DE ACTIVIDADES DO PROJECTO …purl.pt/281/1/projecto_maria/relatorio_intercalar.pdf · relatÓrio intercalar de actividades projecto pocti/33842/ese/2000 teste

RELATÓRIO INTERCALAR DE ACTIVIDADES

PROJECTO POCTI/33842/ESE/2000

TESTE CONCORRENTE PARA SISTEMAS ELECTRÓNICOS

RECONFIGURÁVEIS

(BASEADOS EM FPGAS COM CAPACIDADE DE RECONFIGURAÇÃO

PARCIAL DINÂMICA)

PERÍODO DE 1 DE NOVEMBRO DE 2000 A 28 DE FEVEREIRO DE 2002

• PROF. DR. JOSÉ M. FERREIRA

• PROF. DR. GUSTAVO R. ALVES

• MESTRE MANUEL G. GERICOTA

• ENG. MIGUEL L. SILVA

PORTO E FEUP, ABRIL DE 2002

Page 2: RELATÓRIO INTERCALAR DE ACTIVIDADES DO PROJECTO …purl.pt/281/1/projecto_maria/relatorio_intercalar.pdf · relatÓrio intercalar de actividades projecto pocti/33842/ese/2000 teste

2 Teste Concorrente para Sistemas Electrónicos Reconfiguráveis

Page 3: RELATÓRIO INTERCALAR DE ACTIVIDADES DO PROJECTO …purl.pt/281/1/projecto_maria/relatorio_intercalar.pdf · relatÓrio intercalar de actividades projecto pocti/33842/ese/2000 teste

Relatório intercalar de actividades - Projecto POCTI/33842/ESE/2000 3

ÍNDICE

1. INTRODUÇÃO...................................................................................................... 7

2. DESENVOLVIMENTO TEÓRICO........................................................................ 8

2.1.MOTIVAÇÃO E PROPOSTA DE SOLUÇÃO ......................................................... 8

2.2.ABORDAGENS ANTERIORES............................................................................... 11

2.3.DEFINIÇÃO DA ESTRATÉGIA.............................................................................. 14

2.4.REPLICAÇÃO DE BLOCOS ACTIVOS ................................................................. 14

2.4.1.RECUPERAÇÃO DE ERROS............................................................................... 19

2.4.2.COMPORTAMENTO DOS RECURSOS DE CONFIGURAÇÃO ...................... 20

2.5.O MECANISMO DE ROTAÇÃO DINÂMICA ...................................................... 21

2.6.A ESTRATÉGIA DE TESTE .................................................................................... 25

3. DESENVOLVIMENTO PRÁTICO E LABORATORIAL.................................... 30

3.1.CONFIGURAÇÃO DUMA FPGA........................................................................... 30

3.1.1.MODOS DE CONFIGURAÇÃO.......................................................................... 31

3.2.A INFRA-ESTRUTURA BOUNDARY-SCAN ........................................................ 40

3.2.1.O TEST ACCESS PORT – TAP ........................................................................... 42

3.2.2.O CONTROLADOR DO TAP ............................................................................. 42

3.2.3.O REGISTO DE INSTRUÇÃO ............................................................................ 45

3.2.4.O REGISTO DE VARRIMENTO PELA PERIFERIA (BOUNDARY-SCAN – BS)..

......................................................................................................................... 45

3.2.5.O REGISTO DE BYPASS ..................................................................................... 47

3.2.6.O REGISTO DE IDENTIFICAÇÃO..................................................................... 47

3.2.7.O REGISTO DE IDENTIFICAÇÃO DO UTILIZADOR...................................... 48

3.2.8.O REGISTO DE CONFIGURAÇÃO.................................................................... 49

3.2.9.OS REGISTOS DO UTILIZADOR....................................................................... 49

3.2.10. O CONJUNTO DE INSTRUÇÕES................................................................. 49

3.3.A MEMÓRIA DE CONFIGURAÇÃO ..................................................................... 51

3.4.VECTORES DE DADOS .......................................................................................... 52

3.5.REGISTOS DE CONFIGURAÇÃO ......................................................................... 52

3.5.1.REGISTO DE COMANDOS (CMD).................................................................... 54

3.5.2.REGISTO DO COMPRIMENTO DO VECTOR (FLR) ....................................... 54

3.5.3.REGISTO DE OPÇÕES DE CONFIGURAÇÃO (COR)...................................... 55

Page 4: RELATÓRIO INTERCALAR DE ACTIVIDADES DO PROJECTO …purl.pt/281/1/projecto_maria/relatorio_intercalar.pdf · relatÓrio intercalar de actividades projecto pocti/33842/ese/2000 teste

4 Teste Concorrente para Sistemas Electrónicos Reconfiguráveis

3.5.4.REGISTO DE CONTROLO (CTL)...................................................................... 56

3.5.5.REGISTO DE MÁSCARA (MASK) ..................................................................... 58

3.5.6.REGISTO DE ENDEREÇO DO VECTOR (FAR)................................................ 58

3.5.7.REGISTO DE ENTRADA DE VECTORES DE DADOS (FDRI) ........................ 58

3.5.8.REGISTO DE SAÍDA DE VECTORES DE DADOS (FDRO).............................. 59

3.5.9.REGISTO DE SAÍDA DE DADOS PARA CONFIGURAÇÃO EM CADEIA

(LOUT) ................................................................................................................ 59

3.5.10. REGISTO DE VERIFICAÇÃO POR REDUNDÂNCIA CÍCLICA (CRC)..... 59

3.5.11. REGISTO DE ESTADO (STAT) .................................................................... 60

3.6.O PROCESSO DE CONFIGURAÇÃO E LEITURA .............................................. 60

3.6.1.ORGANIZAÇÃO DUM PACOTE DE CONFIGURAÇÃO................................. 64

3.7.ENDEREÇAMENTO E CONTEÚDO DO ESPAÇO DE CONFIGURAÇÃO...... 65

3.7.1.ORGANIZAÇÃO DA MEMÓRIA DE CONFIGURAÇÃO................................. 66

3.7.2.VECTORES.......................................................................................................... 68

3.7.3.ORGANIZAÇÃO DOS VECTORES.................................................................... 69

3.7.4.LOCALIZAÇÃO DOS BITS DAS TABELAS DE CONSULTA.......................... 70

3.7.5.LEITURA DOS DADOS DE CONFIGURAÇÃO ................................................ 70

3.7.6.ESCRITA DOS DADOS DE CONFIGURAÇÃO ................................................ 71

3.7.7.ALTERAÇÃO DOS DADOS DE CONFIGURAÇÃO ......................................... 71

3.7.8.LOCALIZAÇÃO DOS BITS NO FICHEIRO DE CONFIGURAÇÃO................. 72

3.8.REQUISITOS DO SOFTWARE DESENVOLVIDO .............................................. 79

3.9.DESENVOLVIMENTO DO SOFTWARE DE PROGRAMAÇÃO ....................... 79

3.10. INTERFACE COM O HARDWARE................................................................. 80

3.10.1. DESCRIÇÃO DA PLACA............................................................................... 81

3.10.2. MÉTODOS NATIVOS DE XHWIF................................................................ 82

3.10.3. IMPLEMENTAÇÃO DOS MÉTODOS NATIVOS......................................... 83

3.11. GERAÇÃO DO FICHEIRO DE CONFIGURAÇÃO........................................ 84

3.12. INTERFACE COM O UTILIZADOR ................................................................ 85

3.12.1. SELECÇÃO DO HARDWARE....................................................................... 85

3.12.2. CONFIGURAÇÃO INICIAL.......................................................................... 86

3.12.3. RECONFIGURAÇÕES PARCIAIS................................................................. 88

3.12.4. LEITURA DA CONFIGURAÇÃO. ................................................................ 89

4. ACÇÕES DE FORMAÇÃO E DE DISSEMINAÇÃO DE RESULTADOS...........91

4.1.ACÇÕES DE FORMAÇÃO ..................................................................................... 91

Page 5: RELATÓRIO INTERCALAR DE ACTIVIDADES DO PROJECTO …purl.pt/281/1/projecto_maria/relatorio_intercalar.pdf · relatÓrio intercalar de actividades projecto pocti/33842/ese/2000 teste

Relatório intercalar de actividades - Projecto POCTI/33842/ESE/2000 5

4.2.DISSEMINAÇÃO DE RESULTADOS..................................................................... 93

5. PERSPECTIVAS FUTURAS................................................................................ 95

6. CONCLUSÕES..................................................................................................... 96

7. ANEXOS............................................................................................................... 97

Page 6: RELATÓRIO INTERCALAR DE ACTIVIDADES DO PROJECTO …purl.pt/281/1/projecto_maria/relatorio_intercalar.pdf · relatÓrio intercalar de actividades projecto pocti/33842/ese/2000 teste

6 Teste Concorrente para Sistemas Electrónicos Reconfiguráveis

Page 7: RELATÓRIO INTERCALAR DE ACTIVIDADES DO PROJECTO …purl.pt/281/1/projecto_maria/relatorio_intercalar.pdf · relatÓrio intercalar de actividades projecto pocti/33842/ese/2000 teste

Relatório intercalar de actividades - Projecto POCTI/33842/ESE/2000 7

1.INTRODUÇÃO

Um ano e quatro meses após o início do Projecto POCTI/33842/ESE/2000, denominado

Teste Concorrente para Sistemas Electrónicos Reconfiguráveis (baseados em FPGAs com

capacidade de reconfiguração parcial dinâmica), é altura de se fazer um primeiro balanço do

trabalho desenvolvido e dos objectivos entretanto alcançados e perspectivar, a partir dessa

avaliação, o seu desenvolvimento futuro.

Na fase de arranque do projecto procedeu-se à aquisição de algum material necessário para a

execução prática da investigação que nos proponhamos realizar, nomeadamente de ferramentas de

hardware e software indispensáveis para a validação das soluções teóricas que seriam desenvolvidas

como proposta de abordagem ao teste dos dispositivos lógicos programáveis, do tipo vulgarmente

conhecido pelo acrónimo FPGA (Field Programmable Gate Arrays), dotados de capacidade de

reconfiguração parcial dinâmica.

Também nesta fase se procedeu à contratação dum bolseiro para cooperar neste projecto, conforme

tinha sido proposto e aceite aquando da sua submissão à Fundação para a Ciência e Tecnologia

(FCT). Ao concurso concorreram dois engenheiros habilitados com o grau de licenciatura, tendo a

escolha recaído sobre o Engenheiro Miguel L. Silva, licenciado pela Faculdade de Engenharia da

Universidade do Porto no ano lectivo de 1999/2000, dado ser aquele cujo perfil académico mais se

adequava às necessidades de complementaridade que identificávamos para a equipa que se iria

dedicar à prossecução dos objectivos inicialmente definidos.

Este relatório intercalar encontra-se basicamente dividido em duas partes: uma primeira onde é

abordado o desenvolvimento teórico e prático do trabalho, e uma segunda mais centrada nos

aspectos envolventes e nas perspectivas futuras.

A primeira parte divide-se por sua vez em dois capítulos: um em que é referido o desenvolvimento

teórico da ideia inicial e aduzidos os resultados obtidos na validação prática, enquanto o outro

apresenta os aspectos relacionados com o estudo das capacidades dos dispositivos lógicos do tipo já

referido e do mecanismo de configuração dos seus recursos, base sobre a qual se construiu o

desenvolvimento de ferramentas computacionais que permitiram a validação das propostas teóricas.

Na segunda parte são apresentadas as actividades envolventes ao projecto, nomeadamente de

formação e de disseminação dos resultados, perspectivada a evolução futura do trabalho e retiradas

algumas conclusões.

Page 8: RELATÓRIO INTERCALAR DE ACTIVIDADES DO PROJECTO …purl.pt/281/1/projecto_maria/relatorio_intercalar.pdf · relatÓrio intercalar de actividades projecto pocti/33842/ese/2000 teste

8 Teste Concorrente para Sistemas Electrónicos Reconfiguráveis

2.DESENVOLVIMENTO TEÓRICO

Este capítulo trata sobretudo da abordagem teórica ao problema do teste dos novos tipos de

dispositivos lógicos programáveis com reconfiguração parcial dinâmica. Primeiramente é

identificado o problema e definidos os contornos que se propõem para a sua solução, seguindo-se-

-lhe uma resenha dos principais trabalhos produzidos nesta área do teste de FPGAs. Posteriormente

é definida a metodologia de abordagem ao problema e analisados pormenorizadamente cada um dos

aspectos que a constituem, acompanhados de alguns resultados práticos, com particular relevo para

a replicação dinâmica de blocos lógicos, aspecto em que este trabalho é percursor.

2.1. MOTIVAÇÃO E PROPOSTA DE SOLUÇÃO

O uso de dispositivos lógicos reconfiguráveis experimentou uma considerável expansão nos

últimos anos, fruto do aparecimento no mercado de FPGAs de grande tamanho e de elevada

complexidade. Este tipo de dispositivos lógicos, cuja funcionalidade é configurável pelos

utilizadores, apresentam menores requisitos em termos de espaço, possibilitam menores prazos de

introdução no mercado de novos produtos e oferecem maior flexibilidade, relativamente aos

componentes tradicionais com funcionalidade pré-definida, tendo em termos de preço vindo a

tornar-se cada vez mais competitivos. O aparecimento de FPGAs parcialmente reconfiguráveis,

baseadas em tecnologia de memória volátil de leitura/escrita do tipo SRAM (Static Random Access

Memory), abriu, por sua vez, um novo mundo de possibilidades, ao permitir o desenvolvimento de

circuitos cuja funcionalidade pode ser alterada total ou parcialmente, adaptando-se a novos

requisitos aplicacionais de forma dinâmica e praticamente instantânea.

Conceptualmente, uma FPGA pode ser descrita como uma matriz de blocos lógicos configuráveis

(vulgo CLBs, do inglês Configurable Logic Blocks), rodeada na sua periferia por blocos de

entrada/saída (IOBs, Input/Output Blocks), os quais são interligáveis por recursos de

encaminhamento configuráveis. A configuração de todos estes recursos é controlada por um

conjunto de células de memória do tipo SRAM, conforme ilustrado na Figura 2.1.

A constituição dos blocos lógicos configuráveis, CLBs, tem por base as células lógicas, as quais

incluem, cada uma, um gerador de funções de 4 entradas, implementado sob a forma duma tabela

de consulta (LUTs, Look-Up Table), lógica de controlo e transporte (control and carry logic) e um

elemento de retenção configurável como flip-flop ou latch. A saída do gerador de funções de cada

célula lógica opera a saída do CLB, directamente ou através do elemento de retenção, de forma

independente. Cada CLB, cuja organização interna se encontra esquematizada na Figura 2.2,

Page 9: RELATÓRIO INTERCALAR DE ACTIVIDADES DO PROJECTO …purl.pt/281/1/projecto_maria/relatorio_intercalar.pdf · relatÓrio intercalar de actividades projecto pocti/33842/ese/2000 teste

Relatório intercalar de actividades - Projecto POCTI/33842/ESE/2000 9

contém quatro destas células lógicas, organizadas em duas partes similares, designadas slice. Para

além destas quatro células lógicas básicas, cada CLB possui igualmente lógica que permite combinar

os vários geradores de funções, por forma a proporcionar funções de cinco e seis entradas.

CLBCLBCLBCLBCLB

CLBCLBCLBCLBCLB

CLBCLBCLB

CLBCLBCLB

CLBCLBCLBCLBCLB

Figura 2.1: Representação esquemática duma FPGA.

LUT

LUT

Controlo &Transferência

Controlo &Transferência

G4G3G2G1

F4F3F2F1

D

D

BX

CIN

COUT

BY

YB

Y

YQ

XBX

XQ

LUT

LUT

Controlo &Transferência

Controlo &Transferência

G4G3G2G1

F4F3F2F1

D

D

BX

CIN

COUT

BY

YB

Y

YQ

XBX

XQ

Slice 1 Slice 0

Célula lógica

Figura 2.2: Arquitectura interna dum CLB

No entanto, as tendências tecnológicas actuais na indústria de fabrico de semicondutores,

conquanto tornem as novas FPGAs mais apelativas em termos de capacidade e de custo, tendem a

diminuir a sua fiabilidade. As escalas submicrométricas empregues hoje no fabrico de

semicondutores aumentam os riscos de migração eléctrica devido às elevadas densidades de

corrente que percorrem as pistas metálicas. De igual modo, a correspondente diminuição da tensão

de limiar aumenta a sua susceptibilidade às radiações do tipo Gama, com consequente indução de

Page 10: RELATÓRIO INTERCALAR DE ACTIVIDADES DO PROJECTO …purl.pt/281/1/projecto_maria/relatorio_intercalar.pdf · relatÓrio intercalar de actividades projecto pocti/33842/ese/2000 teste

10 Teste Concorrente para Sistemas Electrónicos Reconfiguráveis

transitórios e alteração dos valores guardados em células de memória. Mais susceptíveis a essas

interferências, as FPGAs de grande tamanho vêem aumentada a probabilidade de aparecimento de

falhas [1, 2]. Após longos períodos de operação, alguns defeitos relacionados com imperfeições de

fabrico, indetectáveis nos testes de produção, manifestam-se emergindo quer como faltas

permanentes quer transitórias [3].

Tornava-se pois premente o estudo de novos procedimentos e metodologias de teste, capazes de

assegurar uma elevada dependabilidade1 dos sistemas em que as FPGAs estivessem inseridas,

baseados em modelos de faltas que garantissem níveis aceitáveis de cobertura de defeitos, quando a

redefinição da funcionalidade ocorre com o sistema em funcionamento e por reutilização constante

dos mesmos recursos reprogramáveis.

Na concepção desses novos procedimentos e metodologias de teste procurou-se tirar partido das

mesmas características que deram origem a este novo desafio (a reconfiguração dinâmica e parcial)

para o desenvolvimento de procedimentos eficientes de teste da estrutura interna, optimizados para

a especificidade arquitectónica desses dispositivos, executados sem perturbação da funcionalidade

actual e da operação do(s) circuito(s).

A metodologia de teste a implementar deve detectar não só as faltas estruturais permanentes, mas

também as faltas transitórias, em paralelo com a operação do sistema e sem a perturbar. As

metodologias de teste que apresentam estas características denominam-se metodologias de teste on-

-line, por oposição às metodologias off-line, as quais implicam uma paragem no normal

funcionamento do sistema.

No caso das faltas permanentes, e após os elementos com defeito terem sido localizados, a FPGA

deve-se auto-reconfigurar para excluir o seu uso. Recursos da FPGA que não estiverem a ser usados

podem substituir os recursos com defeito, aumentando a dependabilidade do sistema. No caso de

faltas transitórias, a reconfiguração parcial on-line permite a recuperação de erros nas células da

memória de configuração da FPGA, os quais, visto modificarem a lógica funcional, se manifestam

eles próprios como faltas permanentes, nomeadamente os denominados Single Event Upsets (SEU),

embora a causa da falha seja efectivamente transitória [4].

Devido aos factos expostos, nos sistemas reconfiguráveis, um elevado nível de dependabilidade só

pode ser alcançado através do teste contínuo de todos os componentes da FPGA ao longo de toda a

sua vida útil, e através da introdução de mecanismos de correcção de erros / tolerância a faltas.

Tendo como base a utilização das mesmas características de reconfiguração parcial dinâmica que

1 Termo que compreende a disponibilidade, a fiabilidade, a testabilidade, a facilidade de manutenção e a tolerância a faltas

dum sistema.

Page 11: RELATÓRIO INTERCALAR DE ACTIVIDADES DO PROJECTO …purl.pt/281/1/projecto_maria/relatorio_intercalar.pdf · relatÓrio intercalar de actividades projecto pocti/33842/ese/2000 teste

Relatório intercalar de actividades - Projecto POCTI/33842/ESE/2000 11

deram origem a este desafio, concebeu-se uma nova metodologia de teste on-line, baseada numa

estratégia de varrimento, com as seguintes características principais:

1. é a primeira metodologia de teste verdadeiramente não-intrusiva que é proposta na literatura;

2. é capaz de detectar qualquer falta estrutural permanente, ao nível dos blocos lógicos

configuráveis, que se manifeste durante a operação normal do sistema;

3. é capaz de corrigir qualquer falta transitória que afecte a funcionalidade dos blocos lógicos

configuráveis;

4. as funções de teste e reconfiguração não ocupam nenhum pino de Entrada / Saída da FPGA,

uma vez que toda a implementação é baseada na reutilização da infra-estrutura de teste por

varrimento periférico, definida na norma IEEE 1149.1 − IEEE Standard Test Access Port and

Boundary-Scan Architecture (porto de acesso ao teste e arquitectura de varrimento periférico

normalizados) [5].

A norma IEEE 1149.1, conhecida normalmente por JTAG2, amplamente em uso na indústria para o

teste estrutural de cartas de circuito impresso digitais, foi desenvolvida inicialmente com o objectivo

de permitir um fácil acesso lógico aos pinos de entrada/saída dos componentes, ultrapassando as

dificuldades experimentadas pelas tecnologias de teste funcional e em-circuito. Desde o início

deixou-se aberta a porta para a inclusão de funções opcionais, definidas pelo utilizador, possibilidade

que foi aproveitada pelos fabricantes de dispositivos lógicos programáveis para a implantação de

mecanismos de configuração e leitura em-circuito através da sua infra-estrutura. Daí igualmente a

proposta de aproveitamento desta infra-estrutura neste trabalho, quer para controlar a aplicação

dos testes e a captura das respostas, quer para assegurar a necessária reconfiguração parcial e

dinâmica da própria FPGA, possibilitando o seu teste estrutural completo, sem perturbar o

funcionamento do sistema, de forma dinâmica e totalmente transparente para o utilizador,

permitindo a detecção e identificação de faltas e conduzindo a uma operação mais robusta,

eventualmente tolerante a faltas.

2.2. ABORDAGENS ANTERIORES

Diferentes abordagens ao teste e diagnóstico de FPGAs, baseadas em estratégias on-line ou off-line,

foram propostas na literatura por vários autores, nomeadamente estratégias baseadas em

mecanismos de auto-teste interno (BIST, Built-In Self-Test), como as apresentadas em [67−8]. Estas

2 JTAG é um acrónimo de Joint Test Action Group, o grupo de trabalho que inicialmente foi responsável pelo

desenvolvimento desta norma.

Page 12: RELATÓRIO INTERCALAR DE ACTIVIDADES DO PROJECTO …purl.pt/281/1/projecto_maria/relatorio_intercalar.pdf · relatÓrio intercalar de actividades projecto pocti/33842/ese/2000 teste

12 Teste Concorrente para Sistemas Electrónicos Reconfiguráveis

estratégias exploram as capacidades de reprogramação da FPGA para implantarem a lógica de

auto—teste, sendo alguns dos blocos lógicos configurados como geradores de vectores de teste, ou

como analisadores de resposta, enquanto outros blocos são testados, e vice-versa. Uma vez que as

sequências de teste são função da arquitectura da FPGA e independentes da sua funcionalidade,

esta abordagem é aplicável aos diferentes níveis de teste (bolacha de silício, dispositivo encapsulado,

placa e sistema). Esta técnica requer um número fixo de sessões e não apresenta qualquer

penalização em termos de área ou desempenho, uma vez que a lógica de auto-teste é eliminada

assim que o circuito é reconfigurado para a sua operação normal.

Uma técnica de auto-teste ligeiramente diferente, a qual implica a modificação estrutural da

memória de configuração original, é apresentada em [9]. Em comparação com técnicas similares,

este método tem a vantagem de reduzir o tempo de teste e a memória externa necessária e de

permitir a completa automação do processo de teste. No entanto, a modificação requerida ao nível

da estrutura interna do dispositivo, é uma das suas maiores desvantagens, inviabilizando a

universalidade da solução.

Metodologias baseadas em abordagens off-line, destinadas a testar os blocos lógicos da FPGA, são

apresentadas em [10, 11]. Após a implantação de uma configuração de teste específica, as entradas

e saídas da FPGA são usadas para suportar a aplicação externa de vectores de teste e para capturar

as respectivas respostas. Devido às características de configurabilidade da FPGA, só é possível

alcançar uma total cobertura de faltas sob o modelo considerado, se for usado um conjunto de

diferentes configurações de teste, que possibilitem a controlabilidade e observabilidade de todos os

nós da estrutura do CLB, e a aplicação em cada caso de grupos específicos de vectores. Com base

nos mesmos princípios é apresentado em [12] um método para o diagnóstico de faltas. Alicerçado

numa estratégia clássica de “dividir para reinar” é apresentado em [13, 14] um extenso trabalho ao

nível do teste estrutural das tabelas de consulta e dos recursos de interligação.

A utilização prática das abordagens anteriores está, no entanto, restrita aos testes de produção, por

implicarem que o dispositivo a testar esteja em modo de teste, interrompendo o seu funcionamento

normal, e com todos os seus pinos acessíveis, aumentando a latência na detecção das faltas, o que

pode não ser admissível em aplicações críticas ou muito sensíveis a defeitos. Para se ultrapassarem

essas limitações é necessário o emprego de metodologias de teste e diagnóstico on-line baseadas em

estratégias de varrimento, tais como as apresentadas em [3, 15]. A ideia subjacente a estes métodos

é a de colocar apenas uma parte da FPGA a ser testada off-line (em vez da totalidade, como é

assumido nas propostas anteriores), enquanto a restante parte continua a sua operação normal. O

teste da totalidade da FPGA é alcançado pela troca das funções de teste com as funções

implementadas, cobrindo-se todo o dispositivo. Se a funcionalidade dum pequeno número de

Page 13: RELATÓRIO INTERCALAR DE ACTIVIDADES DO PROJECTO …purl.pt/281/1/projecto_maria/relatorio_intercalar.pdf · relatÓrio intercalar de actividades projecto pocti/33842/ese/2000 teste

Relatório intercalar de actividades - Projecto POCTI/33842/ESE/2000 13

elementos da FPGA puder ser relocada numa outra parte do dispositivo, então esses elementos

podem ser retirados de operação e testados duma forma completamente transparente para o sistema

(isto é, sem interromper a funcionalidade do dispositivo). Este procedimento de detecção de faltas

por varrimento desloca-se então para outra zona do componente, de forma a testar outro conjunto

de elementos, estendendo-se ao longo de toda a FPGA, procurando sistematicamente faltas

emergentes. No entanto, na abordagem apresentada em [3], são requeridas alterações estruturais

nos blocos lógicos da FPGA para implementação do procedimento de replicação. Por outro lado, na

segunda abordagem [15], conhecida por Roving STARs (Self-Testing AReas), a operação do sistema

tem de ser interrompida para se proceder à relocação duma coluna inteira de blocos lógicos. Uma

vez que a reconfiguração é efectuada através da infra-estrutura de teste IEEE 1149.1, já referida

anteriormente, o tempo de reconfiguração é longo e parece claro que a paragem do sistema

provocará perturbações no seu funcionamento normal.

O conjunto de regras de projecto para a testabilidade que são propostas em [16] implementam um

procedimento de teste on-line concorrente, por incorporação de redundância dupla, em vez de

proporcionarem a implementação de funções de teste estrutural ou funcional (a estrutura da FPGA

não é tida em conta). O objectivo principal consiste na detecção da presença de faltas na aplicação

actual, durante o seu funcionamento, pelo que um defeito pode não ser activado por ela e assim não

ser detectado. Se o sistema está constantemente a ser reconfigurado, este método pode resultar

numa falta intermitente, dependendo de a função implementada ocupar ou não o recurso lógico

defeituoso.

Um novo método orientado à aplicação, capaz de gerar testes funcionais para o circuito

configurado, tendo em consideração a estrutura lógica da FPGA onde está implementado, foi

proposto em [17]. Trata-se de um método off-line, orientado ao teste no terreno, a ser usado com

uma dada aplicação, logo apresentando as mesmas desvantagens dos métodos referidos

anteriormente.

O método proposto neste projecto reutiliza algumas das ideias referidas, mas elimina parte das suas

desvantagens ao usar um novo conceito, o da replicação activa, que permite a relocação da

funcionalidade da cada bloco lógico, mesmo se esse bloco lógico está activo, isto é, se é parte

integrante de uma função que está actualmente a ser usada pelo sistema [18]. Um mecanismo de

rotação dinâmica assegura que todos os blocos lógicos da FPGA são libertados e testados dentro

dum determinado intervalo de latência.

Adicionalmente, a reutilização exclusiva da infra-estrutura de teste IEEE 1149.1 para libertar e

testar os blocos lógicos, reduz o dispêndio extra de recursos ao nível da carta, uma vez que só os

Page 14: RELATÓRIO INTERCALAR DE ACTIVIDADES DO PROJECTO …purl.pt/281/1/projecto_maria/relatorio_intercalar.pdf · relatÓrio intercalar de actividades projecto pocti/33842/ese/2000 teste

14 Teste Concorrente para Sistemas Electrónicos Reconfiguráveis

recursos físicos da própria FPGA são usados. Sendo independente da aplicação e orientado para o

teste estrutural, a estratégia proposta garante a fiabilidade da FPGA após muitas reconfigurações,

assegurando uma correcta operação ao longo de toda a sua vida útil.

2.3. DEFINIÇÃO DA ESTRATÉGIA

A definição da estratégia a seguir para o teste on-line da FPGA teve como base a análise das

condições de utilização, em situações reais, deste tipo de dispositivos. Constata-se que um índice de

ocupação de recursos de 100% é praticamente inatingível, mesmo que a FPGA seja dinamicamente

partilhada por blocos de hardware independentes, ou seja, que várias aplicações, interdependentes

ou não, sejam implementadas num único dispositivo. Por essa razão, haverá sempre blocos lógicos

livres e como tal, passíveis de serem testados sem que isso perturbe o normal funcionamento das

aplicações que correm nos restantes blocos. Trata-se tão somente, afinal, de implementar nos blocos

livres uma aplicação móvel de teste, tirando partido das possibilidades oferecidas pela

reconfiguração parcial dinâmica.

Os blocos lógicos que sejam testados com sucesso ficam disponíveis como blocos sobresselentes,

aptos a substituir quaisquer outros que sejam encontrados com defeito. Através dum mecanismo de

rotação dinâmica, os blocos lógicos onde se encontram actualmente implementadas aplicações são

relocados em blocos já testados, sendo eles próprios libertados para serem testados. Por simplicidade

de análise, dividimos a estratégia proposta em três partes:

1. o procedimento de replicação;

2. o mecanismo de rotação dinâmico;

3. a estratégia de teste.

Nas três secções seguintes cada uma destas fases é analisada em detalhe.

2.4. REPLICAÇÃO DE BLOCOS ACTIVOS

A libertação para o teste de blocos lógicos activos requer a sua replicação em blocos previamente

testados e livres, duma forma completamente transparente para as aplicações neles implementadas.

Esta não é, no entanto, uma tarefa trivial, por dois motivos:

1. a organização interna da memória de configuração;

2. a informação interna de estado.

Page 15: RELATÓRIO INTERCALAR DE ACTIVIDADES DO PROJECTO …purl.pt/281/1/projecto_maria/relatorio_intercalar.pdf · relatÓrio intercalar de actividades projecto pocti/33842/ese/2000 teste

Relatório intercalar de actividades - Projecto POCTI/33842/ESE/2000 15

A memória de configuração pode ser vista como uma matriz rectangular de bits, os quais estão

agrupados em vectores verticais de um bit de largura, que se estendem desde o topo até à base da

matriz. Um vector é a unidade atómica de configuração da matriz − é a mais pequena porção da

memória de configuração que pode ser escrita ou lida. Estes vectores agrupam-se em unidades

maiores chamadas colunas. A cada coluna de CLBs corresponde uma coluna de configuração,

constituída por múltiplos vectores, os quais contêm informação sobre a configuração interna do

CLB e informação de estado, definindo as interligações dentro da coluna e dessa coluna para outras

colunas. A divisão da memória de configuração (em vectores de configuração) permite a

reconfiguração parcial dinâmica da definição funcional do(s) circuito(s). A Figura 2.3 ilustra a

partição da memória de configuração.

Col

una

de IO

Bs d

o la

do e

sque

rdo

(54

vect

ores

)

Bloc

os d

e m

emór

ia R

AM

\con

teúd

o(6

4 ve

ctor

es)

Bloc

os d

e m

emór

ia R

AM

\inte

rlig.

(27

vect

ores

)

Col

una

de IO

Bs d

o la

do d

ireito

(54

vect

ores

)

Col

una

de C

LBs

(48

vect

ores

)

2IOBs

2IOBs

Col

una

de C

LBs

(48

vect

ores

)2

IOBs

2IOBs

Col

una

cent

ral

(8 v

ecto

res)

2GCLK

2GCLK

Col

una

de C

LBs

(48

vect

ores

)

2IOBs

2IOBs

Col

una

de C

LBs

(48

vect

ores

)

2IOBs

2IOBs Bl

ocos

de

mem

ória

RA

M\c

onte

údo

(64

vect

ores

)

Bloc

os d

e m

emór

ia R

AM

\inte

rlig.

(27

vect

ores

)C0 C1C2CnCn+4Cn+2 Cn-1RAM0 Cn+3 RAM1 Cn+1

n - nº de colunas de CLBs

Figura 2.3: Partição da memória de configuração

Cabe aqui definir um pormenor de ordem linguística, por forma a dissipar possíveis dúvidas ao longo

da leitura deste documento. Ao bloco (CLB, slice ou célula lógica) cujo conteúdo se pretende

copiar, chamaremos de ora em diante replicado, e àquele para onde é efectuada a cópia, réplica.

O processo de configuração é um mecanismo sequencial que se estende ao longo de algumas (ou

eventualmente todas) as colunas de configuração, sendo que a nova configuração poderá tornar-se

activa à medida que os vectores vão sendo escritos na memória, ou apenas no final, caso em que a

funcionalidade implementada na FPGA é interrompida desde o início e até à conclusão da

configuração e reactivação da nova funcionalidade. Aquando da replicação de um CLB activo, mais

do que uma coluna pode ser afectada pela reconfiguração, uma vez que os seus sinais de entrada e

saída (bem como aqueles na sua réplica) podem atravessar várias colunas, antes de atingirem a sua

origem ou destino. Qualquer reconfiguração parcial deve ter em isso em conta e assegurar que os

sinais do CLB replicado não são interrompidos antes de serem totalmente restabelecidos a partir da

Page 16: RELATÓRIO INTERCALAR DE ACTIVIDADES DO PROJECTO …purl.pt/281/1/projecto_maria/relatorio_intercalar.pdf · relatÓrio intercalar de actividades projecto pocti/33842/ese/2000 teste

16 Teste Concorrente para Sistemas Electrónicos Reconfiguráveis

sua réplica. De notar igualmente que antes de serem ligadas ao resto do circuito, as saídas do CLB

réplica devem estar perfeitamente definidas, para evitar o aparecimento de transitórios nas saídas.

Um conjunto de experiências práticas realizadas sobre um protótipo ilustrado na Figura 2.4,

contendo uma FPGA da família Virtex da Xilinx, demonstrou que a única solução viável era a de

dividir o processo de replicação em duas fases, conforme representado na Figura 2.5.

Figura 2.4: Placa protótipo contendo uma FPGA XCV200 da Xilinx

1ª fase 2ª fase- Matriz de encaminhamento

CLBreplicado

CLBréplica

CLBreplicado

CLBréplica

Entradas Saídas Entradas Saídas

Figura 2.5: As duas fases do processo de replicação

Na primeira fase, a configuração interna do CLB a replicar é copiada e as entradas de ambos os

CLBs são colocadas em paralelo. Devido à baixa velocidade da interface de configuração usada (a

infra-estrutura IEEE 1149.1), o intervalo de reconfiguração será em geral relativamente longo,

quando comparado com a velocidade de operação do sistema, pelo que as saídas do CLB réplica

estarão perfeitamente estáveis quando forem ligadas ao resto do circuito, no decorrer da segunda

fase. O paralelo das saídas deve manter-se pelo menos durante um ciclo de relógio, por forma a

Page 17: RELATÓRIO INTERCALAR DE ACTIVIDADES DO PROJECTO …purl.pt/281/1/projecto_maria/relatorio_intercalar.pdf · relatÓrio intercalar de actividades projecto pocti/33842/ese/2000 teste

Relatório intercalar de actividades - Projecto POCTI/33842/ESE/2000 17

evitar o aparecimento de transitórios. De notar que a rescrita dos mesmos dados de configuração

não gera quaisquer sinais transitórios, pelo que os restantes recursos cobertos durante o processo de

rescrita dos vectores de configuração não são afectados.

Outro requisito necessário para o sucesso da replicação é a correcta transferência da informação

interna de estado. Se a funcionalidade implementada num CLB é puramente combinatória, uma

simples sequência de leitura-alteração-reconfiguração é suficiente para se alcançar a replicação. No

entanto, no caso de circuitos sequenciais, a informação interna de estado deve ser preservada e

qualquer alteração a essa informação durante o processo de replicação deve ser reflectida

correctamente em ambos os CLBs, replicado e réplica, de modo a evitar problemas de coerência na

informação. Embora seja possível, através da memória de configuração, ler o valor interno presente

em cada um dos elementos de retenção, não é possível alterar esse conteúdo directamente. A

solução para este problema depende do tipo de implementação, tendo sido consideradas três tipos

de implementações diferentes durante este trabalho:

1. circuitos síncronos com sinal de relógio livre;

2. circuitos síncronos com sinal de relógio bloqueável;

3. circuitos assíncronos.

Quando em presença de circuitos síncronos com sinal de relógio livre, isto é, em que o sinal de

relógio está sempre aplicado aos flip-flops, a replicação em duas fases, vista anteriormente, resolve

eficazmente o problema da transferência de estado. Entre a primeira e a segunda fase, o CLB

replicado possui as mesmas entradas que o CLB réplica e, como tal, todos os seus quatro flip-flops

recebem a mesma informação de estado. Foram efectuados vários ensaios utilizando esta técnica,

sem que se verificasse perda da informação de estado ou o aparecimento de transitórios nas saídas.

De notar que esta técnica é válida mesmo no caso da replicação de blocos que façam parte de

circuitos assíncronos, desde que o valor máximo do intervalo entre actualizações consecutivas, de

qualquer um dos seus elementos de retenção, seja inferior ao intervalo entre as duas fases da

replicação.

Apesar desta ser uma boa solução, o seu uso é muito restrito, uma vez que a grande maioria das

aplicações usa circuitos com relógio bloqueável, onde a aquisição da entrada por parte dos flip-flops

depende do estado do sinal de controlo. Uma vez que não se pode assegurar que esse sinal estará

activo, ou será activado, durante a replicação, não se pode garantir que os flip-flops do CLB réplica

capturem o valor de entrada. A sua simples activação durante o processo de replicação não é viável,

pois nada garante que os valores actualmente presentes nas entradas dos flip-flops são aqueles que

foram anteriormente capturados pelos flip-flops do CLB replicado.

Page 18: RELATÓRIO INTERCALAR DE ACTIVIDADES DO PROJECTO …purl.pt/281/1/projecto_maria/relatorio_intercalar.pdf · relatÓrio intercalar de actividades projecto pocti/33842/ese/2000 teste

18 Teste Concorrente para Sistemas Electrónicos Reconfiguráveis

Para resolver este problema recorreu-se a um bloco auxiliar, denominado bloco auxiliar de

replicação, que, consoante o valor do sinal de habilitação, efectua a transferência do valor presente

nos flip-flops do CLB replicado para os do CLB réplica, ou captura os valores para ambos

directamente das entradas. Garante-se desta forma a coerência dos dados, mesmo que exista uma

operação de escrita no decorrer do processo de replicação. A representação esquemática desta

implementação é mostrada na Figura 2.6.

D Q

CE

R

D Q

CE

R

Entradas

Saída

Blocoauxiliar

dereplicação

Controlo

Figura 2.6: Representação esquemática da replicação de circuitos síncronos com relógio bloqueável

Após a transferência do estado, os sinais de entrada envolvidos são colocados em paralelo e todos os

sinais do bloco de replicação são desligados. As saídas são posteriormente também colocadas em

paralelo, completando-se o processo de replicação. Um conjunto de ensaios experimentais

efectuados sobre implementações de circuitos pertencentes ao conjunto dos ITC’99 Benchmark

Circuits do Politécnico di Torino [19] demonstraram a eficácia da solução encontrada.

Embora aplicado a circuitos puramente síncronos com um só sinal de relógio presente, este

procedimento é igualmente eficaz em circuitos com múltiplos sinais de relógio, com uma ou mais

fases, desde que o mais longo período de relógio tenha uma duração inferior à do processo de

replicação, visto este processo envolver apenas um sinal de relógio de cada vez.

Este método é igualmente aplicável a circuitos assíncronos, onde latches do tipo D substituem os

flip-flops. Neste caso, o sinal de controlo corresponde ao sinal de controlo de entrada da latch.

Aquando duma transição desse sinal entre ‘1’ e ‘0’, o valor presente na sua entrada é armazenado.

A replicação e libertação para o teste de recursos de interligação local e global segue as mesmas

duas fases, embora com maior simplicidade. Na primeira fase as linhas a libertar são duplicadas, de

Page 19: RELATÓRIO INTERCALAR DE ACTIVIDADES DO PROJECTO …purl.pt/281/1/projecto_maria/relatorio_intercalar.pdf · relatÓrio intercalar de actividades projecto pocti/33842/ese/2000 teste

Relatório intercalar de actividades - Projecto POCTI/33842/ESE/2000 19

modo a estabelecer-se um caminho alternativo, e desligadas na segunda fase, ficando disponíveis

para serem testadas.

As tabelas de consulta presentes em cada CLB podem igualmente ser configuradas como módulos

de memória distribuída, usados pelas aplicações implementadas. No entanto, a extensão deste

conceito de replicação activa às tabelas de consulta configuradas como blocos de memória não é

possível, embora se possa ler e escrever directamente nas células através da memória de

configuração, visto não existir nenhum mecanismo (a não ser a paragem do sistema), capaz de

garantir a coerência dos valores presentes nas tabelas, no caso de ocorrer uma operação de escrita

durante o intervalo de replicação [4]. Por outro lado, a alteração dos dados em uma ou mais tabelas

obriga a que todos os dados de configuração presentes nos vectores sejam válidos, sendo que a

melhor forma de garantir esta condição é alterando configurações válidas retiradas de ficheiros de

configuração, ou resultantes da leitura de componentes devidamente configurados. Note-se que um

vector cobre uma coluna inteira de slices das CLBs ou IOBs, pelo que a alteração de um bit, por

exemplo o bit 0 de uma única slice 1 dum CLB, implica que todas as posições correspondentes ao bit

0 de todas as slice 1 dessa coluna, sejam escritas com o mesmo comando. Como tal ter-se-ia que

assegurar que, ou os dados nas slices afectadas permaneciam constantes durante o processo de

leitura-alteração-reconfiguração, ou eram alterados pelo próprio processo. Com o objectivo de

salvaguardar tais situações, devem as tabelas de consulta configuradas como memória RAM (e

como tal passíveis de serem alteradas a qualquer instante), ocupar, dentro duma mesma coluna,

slices com índice diferente daquelas em que se situem tabelas de consulta, cujo conteúdo deva ser

reconfigurado externamente durante a operação do sistema ou a aplicação da estratégia de teste

aqui descrita.

O método proposto pode ser usado para replicar um ou mais CLBs de cada vez, diminuindo a

latência do teste. No entanto, o escasso número de recursos de interligação disponíveis limita o

número de CLBs replicáveis duma só vez.

2.4.1. RECUPERAÇÃO DE ERROS

No processo de replicação empregue com circuitos síncronos com sinal de relógio livre não existe

uma verdadeira transferência do valor presente nos flip-flops do CLB replicado para o CLB réplica,

uma vez que estes últimos adquirem o valor de estado directamente das suas entradas. Deste modo,

qualquer erro que afecte o valor presente nos flip-flops do CLB replicado não é propagado para os

flip-flops do CLB réplica, pelo que, após o processo de replicação, as saídas do CLB réplica exibem

sempre o valor correcto, corrigindo automaticamente qualquer falta. Por outro lado, aquando da

replicação de circuitos com sinal de relógio bloqueável ou de circuitos assíncronos, é executada uma

Page 20: RELATÓRIO INTERCALAR DE ACTIVIDADES DO PROJECTO …purl.pt/281/1/projecto_maria/relatorio_intercalar.pdf · relatÓrio intercalar de actividades projecto pocti/33842/ese/2000 teste

20 Teste Concorrente para Sistemas Electrónicos Reconfiguráveis

verdadeira acção de transferência dos valores de estado, pelo que uma falta que altere o valor

armazenado nos flip-flops ou latches do CLB replicado, será propagada para os do CLB réplica,

mantendo-se activa até que os valores sejam actualizados pela aplicação implementada. A falta no

CLB replicado será detectada durante a subsequente fase de teste, sendo o CLB marcado como

defeituoso, não voltando a ser utilizado em reconfigurações posteriores.

A recuperação de erros causados por faltas transitórias do tipo SEU, que afectam a memória de

configuração, pode igualmente ocorrer durante o processo de replicação, dependendo do método

usado para criar os ficheiros de reconfiguração. Se os ficheiros de reconfiguração forem criados a

partir da modificação dum ficheiro que resulte duma operação de leitura da memória de

configuração, qualquer erro que a afecte será propagado durante a replicação. Por outro lado, se se

recorrer ao ficheiro de configuração original para criar os ficheiros de reconfiguração, esses erros

serão imediatamente corrigidos.

2.4.2. COMPORTAMENTO DOS RECURSOS DE CONFIGURAÇÃO

O teste prévio dum CLB, que seja usado para replicar a funcionalidade daquele que se pretende

libertar para o teste, assegura a sua correcta funcionalidade. Repare-se, no entanto, que o CLB

replicado pode estar com defeito. Aquando do paralelo das entradas e saídas de ambos os CLBs,

podem ser interligados pontos que, como consequência desse defeito, se encontrem a níveis lógicos

(e consequentemente de tensão) diferentes. Devido à impedância dos pontos de interligação

programáveis, este aparente curto-circuito comporta-se efectivamente como um divisor de tensão,

limitando a corrente na interligação, não resultando do facto qualquer dano para o circuito.

Cada CLB compreende, para além dos seus recursos lógicos, três matrizes de encaminhamento: duas

locais e uma global. Os recursos de encaminhamento dessas matrizes podem ser unidireccionais ou

bidireccionais, conforme indicado na Figura 2.7. Para além de um par de interligações dedicadas

para uso como linhas de transporte, nenhum outro recurso de interligação está disponível nas

matrizes locais para interligar directamente dois CLBs. Como tal, todas as interligações requeridas

pelo processo de replicação passam obrigatoriamente pela matriz de encaminhamento global.

Entre as matrizes de encaminhamento local e a matriz de encaminhamento global apenas estão

disponíveis ligações unidireccionais. Como tal, ao se estabelecer o paralelo, por exemplo, entre uma

entrada do CLB replicado e a respectiva entrada do CLB réplica, uma falta que afecte a entrada do

CLB replicado não será propagada para a entrada do CLB réplica, devido à unidireccionalidade da

interligação (a falta não pode ser propagada para trás). Desta forma, os valores presentes à entrada

Page 21: RELATÓRIO INTERCALAR DE ACTIVIDADES DO PROJECTO …purl.pt/281/1/projecto_maria/relatorio_intercalar.pdf · relatÓrio intercalar de actividades projecto pocti/33842/ese/2000 teste

Relatório intercalar de actividades - Projecto POCTI/33842/ESE/2000 21

do CLB réplica serão sempre os valores correctos, independentemente de qualquer falta que possa

afectar as entradas do CLB replicado.

Matriz deencaminhamento deentrada

Matriz de encaminhamentode saída

Slice 1 Slice 0CLB

Matriz global deencaminhamento

Figura 2.7: Recursos de encaminhamento dum CLB

O mesmo sucede quando se replicam interligações activas, onde as faltas que afectam as

interligações replicadas são automaticamente corrigidas quando tem lugar a substituição.

2.5. O MECANISMO DE ROTAÇÃO DINÂMICA

Para ser possível libertar para o teste todos os CLBs é necessário usar um mecanismo de varrimento

que, cobrindo toda a FPGA, permita a sua replicação de forma transparente, isto é, não

perturbando a operação normal do sistema, e com um dispêndio mínimo em termos de recursos. Na

análise efectuada foram considerados dois tipos de custo. Por um lado, o custo da reconfiguração em

termos do tamanho dos ficheiros necessários para a replicação e libertação de cada CLB, uma vez

que ficheiros de reconfiguração muito grandes implicam um tempo de teste demasiado longo. Por

outro, o impacto que a reconfiguração dos recursos de encaminhamento tem sobre o atraso na

propagação dos sinais, uma vez que pode originar caminhos mais longos, com consequente

diminuição da frequência máxima de funcionamento (numa FPGA o caminho mais longo em

termos de atraso na propagação do sinal determina a frequência máxima de operação).

Supondo apenas a replicação dum CLB de cada vez, foram consideradas três possibilidades para o

estabelecimento duma sequência de varrimento:

1. aleatória;

Page 22: RELATÓRIO INTERCALAR DE ACTIVIDADES DO PROJECTO …purl.pt/281/1/projecto_maria/relatorio_intercalar.pdf · relatÓrio intercalar de actividades projecto pocti/33842/ese/2000 teste

22 Teste Concorrente para Sistemas Electrónicos Reconfiguráveis

2. horizontal;

3. vertical.

O algoritmo de distribuição, responsável pela atribuição de recursos físicos a cada aplicação, agrupa

os componentes duma mesma aplicação, tentando reduzir o atraso na propagação dos sinais, por

forma a possibilitar uma elevada frequência de operação. A aplicação duma estratégia aleatória

conduziria à dispersão desses componentes, criando caminhos mais longos e aumentando os tempos

de propagação (e consequentemente reduzindo a sua frequência máxima de operação), e exigiria

uma abundância não disponível de recursos de encaminhamento, inviabilizando o processo ao fim

de poucas replicações, pelo que esta estratégia foi rejeitada à partida. Para além do mais, uma

estratégia aleatória conduziria a um tempo de latência de cobertura de defeitos imprevisível, o que

não é aceitável.

Ao contrário, na estratégia de rotação horizontal, ilustrada na Figura 2.8-a), o CLB livre desloca-se

ao longo de um percurso horizontal perfeitamente definido e que cobre a totalidade da matriz,

permitindo calcular de antemão o tempo de latência de teste. A replicação é efectuada entre CLBs

contíguos devido à escassez de recursos e no sentido de evitar aumentos nos atrasos de propagação

dos sinais envolvidos. O mesmo princípio aplica-se à estratégia de rotação vertical, ilustrada na

Figura 2.8-b), onde o CLB livre é deslocado ao longo de um percurso vertical.

CLB CLB CLB CLB

CLBCLBCLBCLB

CLB

CLBCLB CLB

CLBCLB

CLB

CLB

CLB CLB CLB CLB

CLBCLBCLBCLB

CLB

CLBCLB CLB

CLBCLB

CLB

CLB

a) Estratégia horizontal b) Estratégia vertical

Figura 2.8: Rotação dinâmica do CLB livre

Um conjunto de ensaios experimentais efectuados sobre implementações de circuitos pertencentes

ao conjunto dos ITC’99 Benchmark Circuits do Politécnico di Torino [19], usando as duas últimas

estratégias, cujos resultados estão representados na Tabela 2.1, mostraram que o tamanho dos

ficheiros de reconfiguração para implementação da estratégia horizontal era, em média, 20% maior

que o tamanho dos necessários para a aplicação da estratégia de rotação vertical. No entanto, a

influência das duas estratégias sobre a frequência máxima de operação era bastante distinta,

principalmente devido à existência de um par de interligações dedicadas, que liga verticalmente

CLBs adjacentes e que permite a rápida propagação de sinais de transporte. Quando o processo de

rotação quebra uma destas ligações, devido à interposição do CLB livre entre os dois CLBs

verticalmente adjacentes, o seu restabelecimento é efectuado através de linhas de encaminhamento

Page 23: RELATÓRIO INTERCALAR DE ACTIVIDADES DO PROJECTO …purl.pt/281/1/projecto_maria/relatorio_intercalar.pdf · relatÓrio intercalar de actividades projecto pocti/33842/ese/2000 teste

Relatório intercalar de actividades - Projecto POCTI/33842/ESE/2000 23

genéricas, que passam obrigatoriamente através das matrizes de encaminhamento locais e globais, o

que vai aumentar grandemente o tempo de propagação. Se o circuito implementado possuir um ou

mais destes sinais de transporte, a rotação horizontal, ao deslocar em direcções diferentes os CLBs

de linhas contíguas, quebra todas essas ligações. O aumento do tempo de propagação na linha vai

ser igual ao somatório dos aumentos dos tempos de propagação de cada um dos segmentos que

interligavam CLBs contíguos, o que provoca uma diminuição drástica da frequência máxima de

funcionamento do circuito. A rotação vertical, por seu lado, quebrará apenas os segmentos que se

situem no topo ou na base da matriz da coluna de CLBs. Como tal, neste caso, a estratégia vertical

torna-se preferível.

Variação da freq. máxima(%)

Tamanho global dosficheiros de

reconfiguração parcial(bytes)Circuito

Vertical Horizontal Vertical Horizontal

Relação entre otamanho global dos

ficheiros dereconfiguração

parcial (horizontalsuperior em x % ao

vertical)

B01 -5,5 0,0 48.350 56.102 16,0

B02 0,0 0,0 7.016 10.623 51,4

B03 -1,9 -4,9 120.705 138.484 14,7

B04 -6,1 -29,3 548.595 665.419 21,3

B05 -17,3 -36,9 1.130.985 1.286.031 13,7

B06 -2,7 0,0 45.291 53.503 18,1

B07 -23,6 -37,8 354.367 425.214 20,0

B08 -5,8 -5,8 150.093 178.339 18,8

B09 -1,8 -4,9 112.107 129.855 15,8

B10 -7,5 -7,6 195.571 245.455 25,5

B11 -10,5 -36,0 500.261 614.093 22,8

B12 0,0 -1,2 1.275.804 1.631.953 27,9

B13 -4,3 -42,8 258.827 332.954 28,6

B14 -13,5 -47,8 5.195.444 6.070.485 16,8

Tabela 2.1: Custo da aplicação das estratégias de rotação horizontal e vertical

Page 24: RELATÓRIO INTERCALAR DE ACTIVIDADES DO PROJECTO …purl.pt/281/1/projecto_maria/relatorio_intercalar.pdf · relatÓrio intercalar de actividades projecto pocti/33842/ese/2000 teste

24 Teste Concorrente para Sistemas Electrónicos Reconfiguráveis

No caso da não existência de sinais de transporte nas aplicações implementadas, dois outros

aspectos devem ser tidos em conta: i) o número de sinais com grande número de derivações (fanout

elevado), e ii) a forma da distribuição (rectangular, quadrada, circular) e a sua orientação

(horizontal ou vertical, se aplicável) dos circuitos implementados na FPGA. Em implementações

com uma distribuição rectangular orientada verticalmente, e onde um elevado número de sinais

apresenta grande número de derivações, a estratégia horizontal é menos penalizadora em termos da

degradação da frequência máxima de funcionamento, o que pode ser, consoante os casos, um factor

mais importante do que o tamanho dos ficheiros de reconfiguração.

Na generalidade, nos 14 circuitos considerados, a estratégia vertical apresenta melhores resultados,

com um valor médio de redução na frequência máxima de 7% em relação ao seu valor inicial,

contra 18% de redução com a estratégia horizontal.

O percurso de ida e volta do CLB livre ao longo da matriz implica um tempo de latência de teste

variável. O tempo que demora a alcançar de novo o mesmo CLB alterna de acordo com o sentido

de rotação, entre um valor máximo e um valor mínimo, dependendo do tamanho do dispositivo

(número de linhas e colunas de CLBs). O tempo máximo de latência do teste é dado por:

Equação 2.1

)(2)2)#((# testereconfcolunaslinhasmáx ttCLBCLB +××−×=τ

O tempo mínimo de latência do teste é por seu lado dado por:

Equação 2.2

)(2 testereconfmin tt +×=τ

onde:

# CLBlinhas: número de linhas da matriz de CLBs da FPGA

# CLBcolunas: número de colunas da matriz de CLBs da FPGA

treconf: tempo necessário para completar a replicação dum CLB

tteste: tempo necessário para testar um CLB livre

Quando este percurso de ida e volta estiver completo, o esquema de interligações inicial é

restaurado, pelo que a aplicação sucessiva desta estratégia de teste não gera atrasos cumulativos na

propagação dos sinais.

Page 25: RELATÓRIO INTERCALAR DE ACTIVIDADES DO PROJECTO …purl.pt/281/1/projecto_maria/relatorio_intercalar.pdf · relatÓrio intercalar de actividades projecto pocti/33842/ese/2000 teste

Relatório intercalar de actividades - Projecto POCTI/33842/ESE/2000 25

2.6. A ESTRATÉGIA DE TESTE

A infra-estrutura de teste IEEE 1149.1 é igualmente reutilizada para a aplicação dos vectores de

teste e para a captura das respostas, com as saídas do CLB(s) sob teste a serem encaminhadas para

células de Boundary Scan associadas a IOBs que se encontrem desocupados. No entanto, não é

possível a aplicação de vectores de teste através deste registo, uma vez que tal iria afectar também

os valores presentes em cada uma das entradas da FPGA, pelo que se recorre a um registo

alternativo, denominado Registo de Teste, criado pelo utilizador (a família Virtex permite a

definição de dois registos pelo utilizador, controlados através da infra-estrutura 1149.1). A Figura

2.9 ilustra a implementação do mecanismo de teste requerido para levar a cabo este procedimento.

MUX

Registo de BypassRegisto de Instruções TDOTDI

...

CLBsob teste

CLBsob teste

CLBsob teste

Entrada Saída

Registo de Teste

Registo de Configuração

Figura 2.9: Teste dos CLBs através da infra-estrutura 1149.1

Cada CLB é composto por duas slices exactamente iguais. No total, cada CLB possui 13 entradas (os

vectores de teste são aplicados a cada parte do CLB em simultâneo) e 12 saídas (6 em cada slice).

Uma vez que as saídas de cada slice são capturadas independentemente, a resolução na localização

da falta é de uma slice.

Uma vez que o CLB possui uma estrutura configurável, o seu teste integral implica o uso de várias

configurações de teste e a aplicação de um conjunto de vectores por cada uma. Visto a

implementação estrutural dos elementos constituintes do CLB não ser conhecida (tabelas de

consulta, multiplexadores, flip-flops) foi adoptado um modelo de faltas do tipo híbrido [10] (ver

também [13, 14] para um estudo alargado no que diz respeito aos modelos de faltas em FPGAs).

Para se alcançar uma cobertura de 100% de faltas ao nível do CLB, sob o modelo considerado, é

necessário igualmente testar a lógica de transporte associada a cada CLB. Uma vez que não é

Page 26: RELATÓRIO INTERCALAR DE ACTIVIDADES DO PROJECTO …purl.pt/281/1/projecto_maria/relatorio_intercalar.pdf · relatÓrio intercalar de actividades projecto pocti/33842/ese/2000 teste

26 Teste Concorrente para Sistemas Electrónicos Reconfiguráveis

possível aceder directamente à entrada e à saída das linhas de transporte do CLB (estas linhas não

passam pelas matrizes de encaminhamento), a não ser através dos CLBs que lhe são verticalmente

adjacentes, pelo menos dois CLBs nestas condições devem ser libertados e testados em simultâneo.

Para testar os elementos de memória da tabela de consulta, cada bit é colocado a ‘0’ e a ‘1’.

Programando as tabelas de consulta (quatro em cada CLB) para implementar funções do tipo OU-

-exclusivo ou Não-OU-Exclusivo − o que requer no mínimo duas fases de teste −, é fácil propagar

para uma saída primária do CLB qualquer falta que tenha sido activada. Igualmente devido à

implementação dessas funções, são activadas todas as faltas do tipo stuck-at nas entradas das tabelas

de consulta, bem como possíveis faltas nas linhas de endereçamento. Os multiplexadores presentes

em cada CLB podem ser divididos em dois grupos: i) convencionais, e ii) programáveis. Por

programáveis entendem-se aqueles cujas linhas de selecção são controladas através de bits da

memória de configuração). Pelo menos três configurações de teste são necessárias para testar os

multiplexadores programáveis, pelo que um total de quatro configurações de teste são suficientes

para testar toda a parte combinatória dos CLBs. Todos os flip-flops são funcionalmente testados

durante as quatro fases.

Uma vez que a reconfiguração é mais lenta que a aplicação dos vectores, o pequeno número de fasesde teste é uma boa medida do reduzido tempo que é necessário para testar o CLB. De notar,

igualmente, que o tempo de reconfiguração não é constante ao longo das quatro fases, uma vez que

na primeira é necessário implementar toda a configuração de teste, enquanto que nas subsequentesapenas um reduzido número de bits de configuração é alterado, relacionados com a funcionalidade

das tabelas de consulta e com os multiplexadores programáveis, pelo que o tempo de reconfiguração

é substancialmente mais pequeno. A Tabela 2.2 detalha o conteúdo de cada sessão de testeestrutural do CLB.

Sessão de teste

1ª fase do teste 18 vectores deteste

2ª fase do teste 3 vectores de teste

3ª fase do teste 2 vectores de teste

4ª fase do teste 16 vectores deteste

Tabela 2.2: Conteúdo duma sessão de teste

O Registo de Teste definido compreende 13 células, correspondendo ao número máximo de

entradas que é possível definir num CLB. O número de CLBs ocupados por este registo (13) e osdois CLBs ocupados pelo bloco auxiliar de replicação, associados ao CLB necessário para

Page 27: RELATÓRIO INTERCALAR DE ACTIVIDADES DO PROJECTO …purl.pt/281/1/projecto_maria/relatorio_intercalar.pdf · relatÓrio intercalar de actividades projecto pocti/33842/ese/2000 teste

Relatório intercalar de actividades - Projecto POCTI/33842/ESE/2000 27

implementar a rotação, são o único hardware necessário para implementar toda a metodologia de

teste. Isto significa uma ocupação de menos de 1% dos recursos em termos de blocos lógicos de uma

FPGA Xilinx XCV200, usada na placa de protótipo, que possui uma matriz de 28x42 CLBs.

A replicação de tabelas de consulta configuradas como memória distribuída não é possível, como

vimos anteriormente, sem a interrupção do funcionamento do dispositivo. No entanto, nada

impede o teste estrutural da lógica associada a esse modo de funcionamento. O teste dasinterligações pode também ser alcançado usando a mesma estratégia, com os blocos lógicos sob teste

a serem substituídos por conjuntos de segmentos de interligação sob teste.

No próximo capítulo abordam-se os aspectos práticos que permitiram sustentar esta estratégia,dando-se conta das ferramentas de software criadas para suportar a sua implementação.

Page 28: RELATÓRIO INTERCALAR DE ACTIVIDADES DO PROJECTO …purl.pt/281/1/projecto_maria/relatorio_intercalar.pdf · relatÓrio intercalar de actividades projecto pocti/33842/ese/2000 teste

28 Teste Concorrente para Sistemas Electrónicos Reconfiguráveis

Referências bibliográficas:

[1] F. Hanchek, S. Dutt, “Methodologies for Toleranting Cell and Interconnect Faults in FPGAs”,IEEE Transactions on Computers, Vol. 47, Nº 1, pp. 15-33, Janeiro de 1998.

[2] J. Lach, H. W. Mangione-Smith, M. Potkonjak, “Low Overhead Fault-Tolerant FPGASystems”, IEEE Transactions on Very Large Scale Integration Systems, Vol. 6, Nº 2, pp. 212-221,Junho de 1998.

[3] N. R. Shnidman, H. Mangione-Smith, M. Potkonjak, “On-Line Fault Detection for Bus-BasedField Programmable Gate Arrays”, IEEE Transactions on Very Large Scale Integration Systems,Vol. 6, Nº 4, pp. 656-666, Dezembro de 1998.

[4] W. Huang, E. J. McCluskey, “A Memory Coherence Technique for Online Transient ErrorRecovery of FPGA Configurations”, Proc. of the 9th ACM Int. Symposium on Field-ProgrammableGate Arrays, pp. 183-192, Fevereiro de 2001.

[5] IEEE Standard Test Access Port and Boundary Scan Architecture (IEEE Std 1149.1), IEEEStd. Board, Maio de 1990.

[6] C. Stroud., S. Konala, P. Chen, M. Abramovici, “Built-In Self-Test of Logic Blocks in FPGAs(Finally, A Free Lunch: BIST Without Overhead!)”, Proc. of the 14th IEEE VLSI TestSymposium, pp. 387-392, Abril de 1996.

[7] C. Stroud, E. Lee, M. Abramovici, “BIST-Based Diagnostic of FPGA Logic Blocks”, Proc. of theInternational Test Conference, pp. 539-547, Novembro de 1997.

[8] C. Stroud, S. Wijesuriya, C. Hamilton, M. Abramovici, “Built-In Self-Test of FPGAInterconnect”, Proc. of the International Test Conference, pp. 404-411, Novembro de 1998.

[9] A. Doumar, T. Ohmameuda, H. Ito, “Design of an automatic testing for FPGAs”, IEEEEuropean Test Workshop Compendium of Papers, Maio de 1999.

[10] W. K. Huang, F. J. Meyer, X. Chen, F. Lombardi, “Testing Configurable LUT-Based FPGA's”,IEEE Trans. on VLSI Systems, Vol. 6, Nº 2, pp. 276-283, Junho de 1998.

[11] W. K. Huang, F. J. Meyer, F. Lombardi, “An approach for detecting multiple faulty FPGAlogic blocks”, IEEE Trans. on Computers, Vol. 49, Nº 1, pp. 48-54, Janeiro de 2000.

[12] T. Inoue, S. Miyazaki, H. Fujiwara, “Universal Fault Diagnosis for Look-up Table FPGAs”,IEEE Design and Test of Computers, Vol. 15, Nº 1, pp. 39-44, Janeiro-Março de 1998.

[13] M. Renovell, J. M. Portal, J. Figueras, Y. Zorian, “RAM-Based FPGA's: A Test Approach forthe Configurable Logic”, Proc. of the IEEE Int. Conference on Design, Automation and Test inEurope, pp. 82-88, Fevereiro de 1998.

[14] M. Renovell, J. M. Portal, J. Figueras, Y. Zorian, “Testing the interconnect of RAM-basedFPGAs”, IEEE Design and Test of Computers, Vol. 15, Nº 1, pp. 45-50, Janeiro-Março de 1998.

[15] M. Abramovici, C. Stroud, S. Wijesuriya, C. Hamilton, V. Verma, “On-Line Testing andDiagnosis of FPGAs with Roving STARs”, Proc. of the 5th IEEE Int. On-Line Testing Workshop,pp. 2-7, Julho de 1999.

Page 29: RELATÓRIO INTERCALAR DE ACTIVIDADES DO PROJECTO …purl.pt/281/1/projecto_maria/relatorio_intercalar.pdf · relatÓrio intercalar de actividades projecto pocti/33842/ese/2000 teste

Relatório intercalar de actividades - Projecto POCTI/33842/ESE/2000 29

[16] A. L. Burress, P. K. Lala, “On-Line Testable Logic Design for FPGA Implementation”, Proc. ofthe International Test Conference, pp. 471-478, Novembro de 1997.

[17] M. Renovell, J. M. Portal, P. Faure, J. Figueras, Y. Zorian, “Test Generation Optimization for aFPGA Application-Oriented Test Procedure”, Proc. of the 15th Design of Circuits and IntegratedSystems Conference, pp. 330-336, November 2000.

[18] M. G. Gericota, G. R. Alves, M. L. Silva, J. M. Ferreira, “Dynamic Replication: The Core of aTruly Non-Intrusive SRAM-based FPGA Structural Concurrent Test Methodology”, 3nd IEEELatin-American Test Workshop Digest of Papers, pp. 70-75, Fevereiro de 2002.

[19] Politécnico di Torino ITC’99 benchmarks. Disponível emhttp://www.cad.polito.it/tools/itc99.html

Page 30: RELATÓRIO INTERCALAR DE ACTIVIDADES DO PROJECTO …purl.pt/281/1/projecto_maria/relatorio_intercalar.pdf · relatÓrio intercalar de actividades projecto pocti/33842/ese/2000 teste

30 Teste Concorrente para Sistemas Electrónicos Reconfiguráveis

3.DESENVOLVIMENTO PRÁTICO E LABORATORIAL

A componente prática desenvolvida neste projecto está sobretudo ligada à produção de software de

controlo dos mecanismos de geração de ficheiros de configuração parciais e de reconfiguração

parcial dinâmica da FPGA e a sua transferência, usando como interface de configuração ao nível do

componente o porto de acesso ao teste (TAP, Test Access Port) da infra-estrutura IEEE 1149.1,

respondendo ao objectivo inicial de não ocupar pinos extra com a implantação da metodologia de

teste proposta, nem que tal implicasse alterações a nível da concepção inicial do projecto ou mesmo

a nível do próprio componente, assumindo-se pois como uma solução de teste universal.

Embora as FPGAs utilizadas no projecto permitam reconfiguração parcial dinâmica, não existem no

mercado aplicações de software que suportem a concepção de sistemas que possam tirar partido

dessa característica, apenas se encontrando disponível um pacote de software, denominado Jbits [1],

constituído por um conjunto de classes em linguagem Java, que proporcionam uma interface entre

as aplicações produzidas pelo utilizador e o ficheiro de configuração.

Ao longo deste capítulo analisaremos os vários aspectos relacionados com a configuração duma

FPGA, nomeadamente o formato e a organização da memória de configuração e o protocolo usado

para a transferência dos dados, cujo conhecimento é fundamental como base para o

desenvolvimento de aplicações que permitam manipular directamente os ficheiros de configuração.

Por último é apresentada a aplicação de software desenvolvida, discutindo-se o seu modo de

funcionamento, as suas potencialidades e a sua utilização.

3.1. CONFIGURAÇÃO DUMA FPGA

Nas aplicações típicas das FPGAs não é necessária uma compreensão aprofundada dos mecanismos

de configuração, nem o entendimento ao nível do bit do formato dos ficheiros de configuração. No

entanto, para operações de depuração, de leitura, de reconfiguração parcial ou outras, este

conhecimento é fundamental. Entende-se por configuração duma FPGA o processo de

transferência da informação (presente num ficheiro) para a sua memória interna de configuração. É

este ficheiro que vai definir a funcionalidade lógica a implementar na FPGA. A leitura da

configuração será o processo inverso, isto é, o conjunto de procedimentos que permite transcrever

para um ficheiro o conteúdo actual da memória interna de configuração. As FPGAs da família

Virtex da Xilinx [2], usadas neste projecto, permitem que a configuração da sua funcionalidade seja

efectuada de forma total ou parcial, isto é, que apenas uma parte dos recursos lógicos seja

reconfigurado, mantendo-se a funcionalidade dos restantes recursos. De notar que essa

Page 31: RELATÓRIO INTERCALAR DE ACTIVIDADES DO PROJECTO …purl.pt/281/1/projecto_maria/relatorio_intercalar.pdf · relatÓrio intercalar de actividades projecto pocti/33842/ese/2000 teste

Relatório intercalar de actividades - Projecto POCTI/33842/ESE/2000 31

reconfiguração parcial tanto pode ocorrer de forma dinâmica, ou seja, sem perturbar a operação da

parte não afectada pela reconfiguração, como com o sistema parado, sendo neste caso activado

imediatamente após o final da reconfiguração.

3.1.1. MODOS DE CONFIGURAÇÃO

As Virtex suportam quatro modos de configuração [3]:

• Modo mestre-série;

• Modo escravo-série;

• Modo SelectMAP;

• Modo boundary-scan.

Os pinos de modo da FPGA determinam qual o modo de configuração seleccionado e a

configuração das saídas dos IOBs, com resistência de pull-up interna ou em alta impedância, antes

da configuração se tornar activa. Após a activação da configuração as saídas não usadas passam ao

estado de alta impedância, enquanto as outras assumem o estado determinado na configuração. Os

códigos de selecção do modo de configuração encontram-se listados na Tabela 3.1.

A configuração através do TAP, isto é, via boundary-scan, é sempre possível, independentemente do

modo seleccionado. A selecção deste modo simplesmente desactiva os outros modos. Os pinos de

modo possuem resistências de pull-up internas, pelo que, por omissão (i. e., se não ligados), se

encontram em nível lógico ‘1’ (modo escravo-série). Embora neste trabalho seja apenas usado o

modo boundary-scan, os restantes são apresentados a título informativo e constrastivo.

3.1.1.1. O MODO DE CONFIGURAÇÃO MESTRE-SÉRIE

No modo mestre-série o componente é interligado ao seguinte ou seguintes, caso existam, através

de uma cadeia-série, tornando possível a configuração em série de vários componentes. No caso de

ser componente único ou de ser o primeiro elemento duma cadeia, deve estar neste modo de

configuração, enquanto os restantes, se existirem, se devem encontrar em modo de configuração

escravo-série. O relógio de configuração é gerado internamente e fornecido para o exterior através

do pino CCLK, sendo aplicado quer aos possíveis restantes elementos da cadeia, quer a uma

memória externa, não volátil, de acesso série, que alimenta com os dados de configuração a entrada

DIN da FPGA (os dados são aceites por esta entrada na transição ascendente de CCLK). Uma vez

transferida a totalidade dos dados para a primeira FPGA, os dados para o próximo componente

Page 32: RELATÓRIO INTERCALAR DE ACTIVIDADES DO PROJECTO …purl.pt/281/1/projecto_maria/relatorio_intercalar.pdf · relatÓrio intercalar de actividades projecto pocti/33842/ese/2000 teste

32 Teste Concorrente para Sistemas Electrónicos Reconfiguráveis

tornam-se válidos no seu pino DOUT, aquando da transição descendente seguinte de CCLK. A

Figura 3.1 exemplifica este modo de configuração.

Modo deconfiguração M2 M1 M0

Sentidode

CCLK

Comprimentoda palavra de

dados

DOUT

sérieResistência de pull-

-up nas saídas

Modo mestre-série 0 0 0 Saída 1 Sim Não

Modo boundary-scan

1 0 1 - 1 Não Não

Modo SelectMAP 1 1 0 Entrada 8 Não Não

Modo escravo-série

1 1 1 Entrada 1 Sim Não

Modo mestre-série 1 0 0 Saída 1 Sim Sim

Modo boundary-scan

0 0 1 - 1 Não Sim

Modo SelectMAP 0 1 0 Entrada 8 Não Sim

Modo escravo-série

0 1 1 Entrada 1 Sim Sim

Tabela 3.1: Códigos de selecção do modo de configuração

3.1.1.2. O MODO DE CONFIGURAÇÃO ESCRAVO-SÉRIE

Neste modo os dados de configuração que se apresentam na entrada DIN do componente são

provenientes da saída DOUT da FPGA que actua como mestre no sistema de configuração, sendo

este componente que fornece igualmente o sinal à entrada de relógio CCLK. Note-se que não é

obrigatório que o componente que precede uma FPGA em modo de configuração escravo-série seja

uma FPGA em modo de configuração mestre-série, como representado na Figura 3.1. Basta que

exista uma fonte de sinal de relógio de configuração exterior e que este seja aplicado quer à

memória de porta série, que contém os dados de configuração, quer ao(s) componente(s) a ser

configurado(s) neste modo. Todas as restantes FPGAs a configurar são ligadas em cadeia, com o

pino DOUT de uma ligado ao pino DIN da seguinte.

Page 33: RELATÓRIO INTERCALAR DE ACTIVIDADES DO PROJECTO …purl.pt/281/1/projecto_maria/relatorio_intercalar.pdf · relatÓrio intercalar de actividades projecto pocti/33842/ese/2000 teste

Relatório intercalar de actividades - Projecto POCTI/33842/ESE/2000 33

1 Se nenhuma das Virtex for seleccionada para controlar a linha DONE,

M2M1M0

DOUT

CCLK

INITDONE

VIRTEXESCRAVO

SÉRIE

DIN

VIRTEXMESTRE

SÉRIE

M2M1M0

DOUT

CCLKDIN

INITDONE

VCC

CLKDATACERESET/OE

CEO

3,3V

4,7K

PROGRAM

Resistência depull-up opcional1

Memória(ex: XC1701L)

PROG PROG

VCC

é necessário o uso de uma resistência de pull-up de 330Ω nesta linha.

Figura 3.1: Modo de configuração mestre/escravo série

A frequência de CCLK é, por omissão, de 2,5 MHz no arranque. Esta frequência é usada até que a

sequência de bits de configuração, que contém o campo ConfigRate, seja carregada. A menos que

outro valor seja especificado no projecto, o valor desse campo é de 4 MHz. A frequência máxima

permitida é de 60 MHz, devendo-se no entanto assegurar que todos os componentes envolvidos,

memória e restantes FPGAs na cadeia, são suficientemente rápidos para suportarem este valor.

A Figura 3.2 apresenta o diagrama de fluxo do modo série de configuração. A entrada PROG

permite a limpeza assíncrona da memória de configuração, pelo que a FPGA limpa ciclicamente

essa memória, enquanto esta linha estiver forçada a zero. Depois de libertada a linha PROG, a

memória de configuração é limpa mais uma vez antes de libertar a linha INIT. A sequência de

configuração só tem início quando todos os pinos INIT de todos os componentes da cadeia

estiverem a nível lógico ‘1’.

O pino INIT possui duas funções distintas: indica se a memória de configuração da FPGA já está

limpa e como tal se se pode dar início à configuração; e se existe erro na transmissão dos bits de

configuração. Neste último caso INIT passa automaticamente a nível lógico ‘0’, abortando a

configuração. O valor de INIT pode ser forçado exteriormente a nível lógico ‘0’, de modo a atrasar

o início da configuração. Como veremos mais adiante, este procedimento não se aplica aos casos em

que a reconfiguração é apenas parcial e efectuada de forma dinâmica.

Após a configuração a FPGA entra numa sequência de arranque, que a conduz do seu estado de

configuração para o estado de operação, compreendendo uma série de oito estados onde são

efectuadas as seguintes tarefas:

1. Libertação do pino DONE;

Page 34: RELATÓRIO INTERCALAR DE ACTIVIDADES DO PROJECTO …purl.pt/281/1/projecto_maria/relatorio_intercalar.pdf · relatÓrio intercalar de actividades projecto pocti/33842/ese/2000 teste

34 Teste Concorrente para Sistemas Electrónicos Reconfiguráveis

2. Negação do sinal GTS (Global TriState), conduzindo à activação de todas as E/S;

3. Activação do sinal GWE (GlobalWriteEnable), permitindo que as memórias e os flip-flops mudem

de estado (o seu estado só mudará aquando da activação do sinal GSR);

4. Negação do sinal GSR (GlobalSetReset), conduzindo à mudança de estado dos flip-flops;

5. Activação da flag interna EOS (End-Of-Start).

Recebealimentação

INIT?

Coloca PROG= 1

Liberta INIT

0

1

Carrega um bit deconfiguração

Fim dos bits deconfiguração

Não

Sim

Configuraçãocompleta

A FPGA inicia a limpeza dasua memória de configuração

A FPGA efectua uma últimapassagem de limpeza,libertando no final INIT

Uma vez por pacote de bits, aFPGA verifica os dados,colocando INIT=0 em casode erro

Se não forem encontradoserros, a FPGA entra na fasede arranque (DONE=1)

Se usado para atrasar aconfiguração

Figura 3.2: Diagrama de fluxo do modo série de configuração

Por omissão, a libertação do pino DONE ocorre no quarto estado da sequência de arranque. No

entanto, tal é configurável pelo utilizador, podendo definir-se a sua ocorrência entre o primeiro e o

sexto estado. De igual forma, o estado em que ocorre a activação das E/S, bem como dos blocos

internos de memória e a inicialização de cada flip-flop no estado pré-definido pela configuração

(alteração dos sinais GTS, GWE e GSR), pode ser configurada, quer especificando um estado fixo

para essa ocorrência (entre o primeiro e o sexto), quer tornando-a dependente da transição do sinal

DONE, situação em que a alteração dos sinais ocorre sincronamente com a primeira transição

Page 35: RELATÓRIO INTERCALAR DE ACTIVIDADES DO PROJECTO …purl.pt/281/1/projecto_maria/relatorio_intercalar.pdf · relatÓrio intercalar de actividades projecto pocti/33842/ese/2000 teste

Relatório intercalar de actividades - Projecto POCTI/33842/ESE/2000 35

ascendente do sinal do relógio de arranque após a transição do sinal DONE. Ambas as

possibilidades estão representadas na Figura 3.3. A sequência de arranque pode ainda ser atrasada,

forçando exteriormente a linha DONE a nível lógico ‘0’.

Relógio de arranque

Estado

DONE

GTS

GSR

GWE

0 1 2 3 4 5 6 7

Relógio de arranque

Estado

DONE

GTS

GSR

GWE

0 1 2 3 4 5 6 7

Por omissão

Síncrono com DONE

DONE=1

Figura 3.3: Sequência de arranque

3.1.1.3. O MODO DE CONFIGURAÇÃO SELECTMAP

O modo SelectMAP é o mais rápido, uma vez que é o único em que a transmissão dos dados para a

memória de configuração do componente é efectuada de forma paralela, através de um barramento

de oito bits. O fluxo dos dados é controlado através de uma flag (BUSY), podendo a frequência do

relógio de configuração atingir os 60MHz. Vários componentes podem ser colocados em paralelo,

sendo o componente a configurar seleccionado através de uma linha única de selecção (CS),

conforme se ilustra na Figura 3.4, devendo os restantes sinais (DATA[0:7], CCLK, WRITE, BUSY,

PROG, DONE e INIT) de todos os componentes da cadeia ser ligados em paralelo. Se o ficheiro de

configuração for o mesmo para todos os componentes, ou parte deles, e a opção de leitura não for

usada, a linha CS desses componentes pode ser interligada, sendo configurados em simultâneo.

Embora não representado na Figura 3.4, este modo de configuração exige um módulo de controlo

que pode ser um microprocessador ou outro dispositivo capaz de desempenhar esta tarefa.

Após a configuração os pinos de dados comportam-se como pinos de E/S normais. Note-se no

entanto que a sua funcionalidade deve ser retida, o que pode ser especificado aquando da geração

Page 36: RELATÓRIO INTERCALAR DE ACTIVIDADES DO PROJECTO …purl.pt/281/1/projecto_maria/relatorio_intercalar.pdf · relatÓrio intercalar de actividades projecto pocti/33842/ese/2000 teste

36 Teste Concorrente para Sistemas Electrónicos Reconfiguráveis

do ficheiro de configuração, se se pretender realizar operações de leitura da memória de

configuração usando este modo. A Figura 3.5 apresenta o diagrama de fluxo do modo de

configuração SelectMAP.

VIRTEXSelectMAP

M0M2M1

BUSY

INITPROGDONE

PROG

Resistência depull-up opcional

VCC

D[0:7]CCLKWRITE

CSCS(0)

VIRTEXSelectMAP

M0M2M1

BUSY

INITDONE

VCC

D[0:7]CCLKWRITE

CSCS(1)

INITDONE

BUSY

DATA[0:7]CCLK

WRITE

VCC

PROG

Figura 3.4: Modo de configuração SelectMAP

3.1.1.4. O MODO DE CONFIGURAÇÃO BOUNDARY-SCAN

Este modo sobrepõe-se a todos os outros e pode ser usado mesmo que esteja outro modo

seleccionado através dos pinos de modo [M2:M0]. Uma vez que toda a configuração é efectuada

usando apenas os pinos do TAP, este modo não requer a existência de pinos dedicados.

A configuração através do TAP usa a instrução CFG_IN, que converte os dados entrados por TDI

em pacotes para o barramento interno de configuração. A Figura 3.6 ilustra o fluxo de configuração

neste modo.

O componente a ser configurado pode ser único na cadeia BS ou fazer parte de uma cadeia com

múltiplos componentes, configuráveis ou não. Quando se configura um único componente através

da cadeia BS, deve-se assegurar que na geração do ficheiro de configuração é indicado TCK como

relógio de configuração. A Tabela 3.2 descreve a sequência de comandos de controlo do TAP,

necessários para se proceder à configuração de um único componente.

Page 37: RELATÓRIO INTERCALAR DE ACTIVIDADES DO PROJECTO …purl.pt/281/1/projecto_maria/relatorio_intercalar.pdf · relatÓrio intercalar de actividades projecto pocti/33842/ese/2000 teste

Relatório intercalar de actividades - Projecto POCTI/33842/ESE/2000 37

Recebealimentação

INIT?

Coloca PROG= 1

Liberta INIT

0

1

A FPGA inicia a limpeza dasua memória de configuração

A FPGA efectua uma últimapassagem de limpeza,libertando no final INIT

Se usado para atrasar aconfiguração

ColocaWRITE= 0

ColocaCS= 0

Coloca o byte deconfiguração

BUSY?1

0

Fim dos dados?Não

Sim

Na primeira FPGA

Na primeira FPGAColocaCS= 1

Repete asequência A Para outra qualquer FPGA

ColocaWRITE= 1

Configuraçãocompleta

Verifica os dados colocandoINIT=0 em caso de erro

Sequência A

Não havendo erros a primeiraFPGA entra na fase dearranque, libertando DONE

Quando todos os pinosDONE forem libertados,DONE=1 e a sequência dearranque finaliza

Figura 3.5: Diagrama de fluxo do modo de configuração SelectMAP

Page 38: RELATÓRIO INTERCALAR DE ACTIVIDADES DO PROJECTO …purl.pt/281/1/projecto_maria/relatorio_intercalar.pdf · relatÓrio intercalar de actividades projecto pocti/33842/ese/2000 teste

38 Teste Concorrente para Sistemas Electrónicos Reconfiguráveis

Recebealimentação

INIT?0

1

Carrega ainstrução CFG_IN

Carrega a cadeiade dados deconfiguração

Dadoscorrectos?

Não

Sim

Sequência dearranque

Operacional

Infra-estrutura BS disponível

Aborta arranque

Carrega ainstrução JSTART

Reconfigurar?Sim

Limpa mais umavez a memória de

configuração

Limpa a memóriade configuração PROG=0?

Sequência deshutdown

Sim

Carrega ainstrução CFG_IN

Carrega a cadeiade dados de

reconfiguração

Reconfiguraçãoparcial dinâmica

Figura 3.6: Diagrama de fluxo do modo boundary-scan de configuração

Page 39: RELATÓRIO INTERCALAR DE ACTIVIDADES DO PROJECTO …purl.pt/281/1/projecto_maria/relatorio_intercalar.pdf · relatÓrio intercalar de actividades projecto pocti/33842/ese/2000 teste

Relatório intercalar de actividades - Projecto POCTI/33842/ESE/2000 39

Aplica e mantémDescrição da sequência de passos do controlador do TAP

TDI TMS

# impulsosde TCK

1Ao receber a alimentação, com TMS a ‘1’, cinco impulsosde relógio em TCK asseguram que o estado Test-Logic-Reseté alcançado

X 1 5

2 Passa ao estado Run-Test/Idle X 0 1

3 Passa ao estado Select-IR X 1 2

4 Entra no estado Shift-IR X 0 2

5 Começa a deslocar a instrução CFG_IN3 0101 0 4

6 Desloca o último bit da instrução CFG_IN quando deixaShift-IR

0 1 1

7 Entra no estado Select-DR X 1 2

8 Entra no estado Shift-DR X 0 2

9 Desloca o ficheiro de configuração (bitn (mais significativo)é o primeiro bit do ficheiro de configuração)

bit1...bitn 0 (# bits noficheiro)-1

10 Desloca o último bit do ficheiro de configuração bit0 1 1

11 Entra no estado Update-DR X 1 1

12 Entra no estado Select-DR X 1 2

13 Passa para o estado Shift-DR X 0 2

14 Começa a deslocar a instrução JSTART, que inicializa asequência de arranque 1100 0 4

15 Carrega o último bit da instrução JSTART, quando deixaShift-IR

0 1 1

16 Passa para o estado Select-DR X 1 2

17 Passa para o estado Shift-DR e aplica um mínimo de dozeciclos de relógio para executar a sequência de arranque

X 0 ≥14

18 Passa ao estado Update-DR X 1 2

19 Retorna ao estado Run-Test-Idle X 0 1

Tabela 3.2: Sequência de configuração de um único componente

Page 40: RELATÓRIO INTERCALAR DE ACTIVIDADES DO PROJECTO …purl.pt/281/1/projecto_maria/relatorio_intercalar.pdf · relatÓrio intercalar de actividades projecto pocti/33842/ese/2000 teste

40 Teste Concorrente para Sistemas Electrónicos Reconfiguráveis

É igualmente possível a configuração de múltiplos componentes numa mesma cadeia BS, um de

cada vez. A instrução CFG_IN deve ser carregada no componente que se pretende configurar,

colocando todos os outros da cadeia em Bypass. Para a configuração de vários componentes numa

cadeia pode ser necessário o deslocamento de alguns zeros (N) antes do início do ficheiro de

configuração. A Equação 3.1 permite determinar o número de zeros a acrescentar, em função da

posição na cadeia (M) do componente a configurar. Note-se que à primeira posição corresponde o

componente zero.

Equação 3.1

32)(M paraM32N

32)(M para32M

mod32N

≤−=

>

−=

Depois de ter deslocado os ficheiros de configuração, um a um, para cada componente da cadeia,

carrega-se a instrução JSTART em todos eles, aplicando de seguida, enquanto no estado Shift-DR,

doze impulsos em TCK, após o que ficarão todos operacionais. A Figura 3.7 ilustra as ligações dos

componentes para o modo de configuração boundary-scan.

VIRTEXFPGA

PROG 1

TDITMSTCK

TDO

VIRTEXFPGA

TDITMSTCK

TDO

VIRTEXFPGA

TDITMSTCK

TDOTDO

TMSTCK

TDI

ControladorBS

Componente 0 Componente 1 Componente 2

1 PROG='1' durante a configuração através da cadeia BS

PROG 1 PROG 1

Figura 3.7: Modo de configuração boundary-scan

3.2. A INFRA-ESTRUTURA BOUNDARY-SCAN

A família Virtex é totalmente conforme à norma IEEE 1149.1, incluindo a sua arquitectura todos os

elementos obrigatórios definidos na norma. Esses elementos incluem:

• TAP (Test Access Port);

3 Na coluna TDI, o bit mais à direita é deslocado em primeiro lugar.

Page 41: RELATÓRIO INTERCALAR DE ACTIVIDADES DO PROJECTO …purl.pt/281/1/projecto_maria/relatorio_intercalar.pdf · relatÓrio intercalar de actividades projecto pocti/33842/ese/2000 teste

Relatório intercalar de actividades - Projecto POCTI/33842/ESE/2000 41

• controlador do TAP;

• registo de instrução;

• registo de varrimento pela periferia (Boundary-Scan – BS);

• registo de bypass.

São igualmente suportados alguns elementos adicionais totalmente compatíveis com a norma:

• um registo de identificação com 32 bits;

• um registo de identificação programável pelo utilizador;

• um registo de configuração com 32 bits.

Ao utilizador é permitida a configuração de dois registos por si definidos, os quais podem ser

acedidos, através dos pinos do TAP.

A Figura 3.8 ilustra a implementação interna dos registos presentes na infra-estrutura de teste

Boundary Scan das Virtex.

IOB IOB IOB IOB IOB

IOB IOB

IOB IOB

IOB

IOBIOB

IOB

IOB IOB

Registo de instrução

Registo deBypass

TDI TDO

Registo de configuração

Registo de identificação

Versão Identificaçãodo componente

Código dofabricante

Reg. de identif. programável

2 registos opcionais

Figura 3.8: Registos internos da infra-estrutura de teste

Page 42: RELATÓRIO INTERCALAR DE ACTIVIDADES DO PROJECTO …purl.pt/281/1/projecto_maria/relatorio_intercalar.pdf · relatÓrio intercalar de actividades projecto pocti/33842/ese/2000 teste

42 Teste Concorrente para Sistemas Electrónicos Reconfiguráveis

3.2.1. O TEST ACCESS PORT – TAP

O TAP nas Virtex é constituído por quatro pinos dedicados, três de entrada e um de saída, que

controlam o funcionamento desta infra-estrutura de teste, gerida por uma máquina de estados cujo

diagrama de transição está ilustrado na Figura 3.9.

Os quatro pinos dedicados são:

• TMS – Test Mode Select: a sequência de estados percorrida pelo controlador do TAP é

determinada pelo estado do pino TMS aquando da transição ascendente do relógio de teste

(Test Clock – TCK). O pino TMS possui uma resistência de pull-up interna, que assegura um

valor lógico alto no caso de o pino não ser usado.

• TCK – Test Clock: relógio de teste, sequencia o controlador do TAP e os registos associados a

esta infra-estrutura de teste. O valor máximo da frequência do relógio de teste na família Virtex

é de 33 MHz, independente da velocidade do componente (entre 180 e 200 MHz, no máximo).

• TDI – Test Data In: entrada série de todas as instruções e dados para a infra-estrutura de teste.

O estado do controlador do TAP e a instrução guardada no registo de instrução, que indica a

operação a executar, determinam o registo que será atravessado pela sequência de bits injectada

neste pino. O deslocamento dos bits ocorre aquando da transição ascendente do relógio de teste

(TCK). O pino TDI possui uma resistência de pull-up interna que assegura um valor lógico alto

no caso de o pino não ser usado.

• TDO – Test Data Out: saída série de todos os registos internos, instrução e dados. O estado do

controlador do TAP e a instrução guardada no registo de instrução, que indica a operação a

executar, determinam qual o registo que alimenta esta saída. O valor de TDO é alterado na

transição descendente do relógio de teste, encontrando-se activo somente durante o

deslocamento de instruções ou dados (estados Shift-XR) através do componente e em alta

impedância durante o resto do tempo.

3.2.2. O CONTROLADOR DO TAP

O controlador do TAP é uma máquina de estados finita com 16 estados, cujo diagrama está

representado na Figura 3.9. As três entradas do TAP controlam a forma como os dados são

deslocados dentro dos vários registos, sendo o estado do pino TMS, na altura da transição

ascendente de TCK, que determina a sequência de transição dos estados. Distinguem-se claramente

no diagrama duas sequências principais idênticas, uma para deslocar dados para o registo de dados

Page 43: RELATÓRIO INTERCALAR DE ACTIVIDADES DO PROJECTO …purl.pt/281/1/projecto_maria/relatorio_intercalar.pdf · relatÓrio intercalar de actividades projecto pocti/33842/ese/2000 teste

Relatório intercalar de actividades - Projecto POCTI/33842/ESE/2000 43

seleccionado (ao centro na figura) e a outra para deslocar uma instrução para o registo de instrução

(à direita na figura).

Shift-DR

Select-DR-Scan

Test-LogicReset1

Run-Test/Idle0

0

1

Capture-DR

0

0

Exit1-DR

Pause-DR

Exit2-DR

Update-DR

0

1

0

1

1

0

1

1

0

Shift-IR

Select-IR-Scan

Capture-IR

0

0

Exit1-IR

Pause-IR

Exit2-IR

Update-IR

0

1

0

1

1

0

1

1

0

1

01 01

1

Figura 3.9: Diagrama de estados do controlador do TAP4

A cada estado corresponde um comportamento bem definido, que sumariamente se descreve a

seguir [4, 5]:

• Test-Logic-Reset Neste estado toda a lógica de teste é inicializada, sem que de tal resulte qualquer

interferência para a operação normal do circuito integrado. Independentemente do estado

inicial do controlador do TAP, o estado Test-Logic-Reset é alcançado ao fim de cinco transições

ascendentes no relógio de teste, com o sinal TMS em nível lógico ‘1’.

• Run-Test/Idle A instrução presente no registo de instrução determina o comportamento da lógica

de teste neste estado. Por exemplo, no caso de uma instrução de auto-teste interno, as

respectivas operações serão realizadas neste estado. Se, por outro lado, a instrução presente não

4 O valor adjacente a cada transição de estado representa o sinal presente em TMS aquando da transição ascendente de

TCK.

Page 44: RELATÓRIO INTERCALAR DE ACTIVIDADES DO PROJECTO …purl.pt/281/1/projecto_maria/relatorio_intercalar.pdf · relatÓrio intercalar de actividades projecto pocti/33842/ese/2000 teste

44 Teste Concorrente para Sistemas Electrónicos Reconfiguráveis

implicar a execução de qualquer função, todos os registos de dados por ela seleccionados devem

conservar o seu estado.

• Capture-DR Neste estado os dados presentes nas entradas paralelas do registo ou registos de

dados seleccionados pela presente instrução, são transferidos para o andar de

captura/deslocamento das respectivas células.

• Shift-DR O registo de dados seleccionado pela instrução actual desloca o conteúdo do seu andar

de captura/deslocamento. A operação de deslocamento permite que os dados previamente

capturados sejam examinados no exterior e que novos dados sejam deslocados para o interior

para serem aplicados.

• Update-DR Os andares de retenção serão actualizados neste estado, com os novos valores

presentes no andar de captura/deslocamento das respectivas células.

• Capture-IR, Shift-IR e Update-IR Estes estados são análogos respectivamente aos estados Capture-

-DR, Shift-DR e Update-DR, mas dizem neste caso respeito ao registo de instrução. Estes estados

são usados para deslocar uma nova instrução que se torna activa no estado Update-IR.

É importante referir que a acção descrita nos estados Update-IR e Update-DR tem lugar à transição

descendente de TCK. Em todos os outros as acções descritas acontecem aquando da transição

ascendente de TCK, na altura da mudança de estado (ver Figura 3.10). Conforme já foi referido

anteriormente, TDO encontra-se activo somente durante o deslocamento de instruções ou dados

através do componente, isto é, nos estados Shift-DR e Shift-IR, e em alta impedância em todos os

outros. Nos restantes oito estados a lógica de teste está inactiva. Os estados Pause-DR e Pause-IR

possibilitam uma paragem temporária do processo de deslocamento, permitindo, por exemplo, que o

equipamento exterior que controla o teste aceda à sua memória para carregar novos dados a serem

deslocados. Os estados Select-DR-Scan, Select-IR-Scan, Exit1-DR, Exit1-IR, Exit2-DR e Exit2-IR são

estados de decisão quanto ao caminho a seguir no diagrama de estados.

TCK

Estado

Transiçãode estado

Acções que ocorrem na transiçãodescendente de TCK

(Update-DR e Update-IR)

Acções que ocorrem natransição ascendente de TCK

(todas as restantes)

Figura 3.10: Diagrama temporal das acções que ocorrem nas transições de TCK

Page 45: RELATÓRIO INTERCALAR DE ACTIVIDADES DO PROJECTO …purl.pt/281/1/projecto_maria/relatorio_intercalar.pdf · relatÓrio intercalar de actividades projecto pocti/33842/ese/2000 teste

Relatório intercalar de actividades - Projecto POCTI/33842/ESE/2000 45

3.2.3. O REGISTO DE INSTRUÇÃO

O registo de instrução apresenta-se na família Virtex como um registo de deslocamento de 5 bits

com entradas e saídas paralelas. A instrução deslocada para o seu interior é carregada, tornando-se

activa, aquando da passagem pelo estado Update-IR, sendo simultaneamente capturada informação

sobre o estado interno do componente, que por sua vez pode ser deslocada para o exterior para

posterior análise.

3.2.4. O REGISTO DE VARRIMENTO PELA PERIFERIA (BOUNDARY-SCAN – BS)

O registo principal de dados é o registo de varrimento pela periferia (BS). A operação deste registo é

independente da configuração individual de cada IOB, ligado ou não a um pino do componente,

que assim contribuem para este registo sempre com três bits. A Figura 3.11 apresenta o esquema

completo de um IOB, incluindo toda a lógica associada à implementação da respectiva célula BS.

Quando, em virtude da instrução presente no registo de instrução, é este o registo seleccionado, a

captura paralela dos dados para o andar de captura/deslocamento ocorre à transição ascendente de

TCK, estando o controlador do TAP no estado Capture-DR. Esses dados são deslocados para o

exterior e substituídos por dados novos durante o estado Shift-DR. O andar de retenção existente

em cada célula deste registo assegura a estabilidade do valor presente na sua saída paralela, durante

o processo de deslocamento, de acordo com o especificado na norma IEEE 1149.1. A actualização

dos valores nas saídas paralelas dar-se-à durante o estado Update-DR, à transição descendente de

TCK.

Os bits da cadeia de varrimento periférico (BS), dentro de cada IOB, apresentam-se pela seguinte

ordem: entrada, saída, controlo do 3º estado. Os pinos de entrada dedicados5 contribuem com

somente um bit para a cadeia, enquanto que os pinos de saída dedicados contribuem com três [2].

A Tabela 3.3 mostra a sequência dos bits na cadeia de varrimento periférico, iniciando-se em TDO

e seguindo em sentido directo, visto do lado dos pinos, até atingir TDI, conforme se ilustra na

Figura 3.12. Numa sequência de deslocamento do conteúdo da cadeia de varrimento periférico o

primeiro bit a aparecer em TDO será o correspondente ao controlo do 3º estado do IOB mais

próximo de TDO. A sequência dos portos na cadeia BS é descrita para cada componente através

dum ficheiro BSDL (Boundary-Scan Description Language).

5 Pinos não associados a IOBs configuráveis, excluindo, conforme definido na norma, os pinos do TAP.

Page 46: RELATÓRIO INTERCALAR DE ACTIVIDADES DO PROJECTO …purl.pt/281/1/projecto_maria/relatorio_intercalar.pdf · relatÓrio intercalar de actividades projecto pocti/33842/ese/2000 teste

46 Teste Concorrente para Sistemas Electrónicos Reconfiguráveis

Atraso

Programável

VR

EF

Weak

Keeper

OBU

FT

IBUF

T

TC

EO

OC

EI

IQSRC

LKIC

E

Controlo doterceiro estadoSaída

EntradaA

ssíncrona

EntradaSíncrona

SR CE D

Q

SR

CE

DQ

SR

CE

DQ

Porto

VC

CO

Pull upPull dow

n

para o buffer global de relógio(som

ente nos portos de relógio)

10

Disjunção lógica

entre INT

EST e

EXT

EST

sd

LE DQ

TEST

LOG

ICR

ESET

DQ

UPD

AT

E

1X0100 1X0100

TD

I

INT

ESTSHIFT

CLO

CK

DA

TA

REG

ISTER

10 10

sd

LE DQ

DQ

EXT

EST

DQ

sd

LE DQ

1X0100

TD

O

Lógica BS presenteem

cada IOB

Andar de captura/deslocam

entoA

ndar de retenção

Figura 3.11: IOB com a respectiva célula BS

Page 47: RELATÓRIO INTERCALAR DE ACTIVIDADES DO PROJECTO …purl.pt/281/1/projecto_maria/relatorio_intercalar.pdf · relatÓrio intercalar de actividades projecto pocti/33842/ese/2000 teste

Relatório intercalar de actividades - Projecto POCTI/33842/ESE/2000 47

Bit 0 (junto a TDO)

Bit 1

Bit 2

Bit n (junto a TDI)

Metade direita do conjunto de IOBs do topo(direita para a esquerda)

GCLK3

GCLK2

Metade esquerda do conjunto de IOBs dotopo (direita para a esquerda)

IOBs do lado esquerdo (de cima para baixo)

M1

M0

M2

Metade esquerda do conjunto de IOBs dofundo (Esquerda para a direita)

GCLK1

GCLK0

Metade direita do conjunto de IOBs do fundo(Esquerda para a direita)

DONE

PROG

IOBs do lado direito (de baixo para cima)

CCLK

Tabela 3.3: Sequência de bits na cadeia BS

3.2.5. O REGISTO DE BYPASS

O registo de Bypass é um registo de dados constituído por um único flip-flop inserido entre TDI e

TDO, permitindo um percurso de comprimento mínimo entre estes dois pinos. Este registo é

inicializado a zero aquando da transição ascendente de TCK, na passagem do controlador do TAP

pelo estado UPDATE-DR [6].

3.2.6. O REGISTO DE IDENTIFICAÇÃO

As Virtex possuem um registo de identificação com 32 bits (IDCODE), que permite a fácil

identificação do componente a ser testado ou programado através da cadeia BS. O formato dos

Page 48: RELATÓRIO INTERCALAR DE ACTIVIDADES DO PROJECTO …purl.pt/281/1/projecto_maria/relatorio_intercalar.pdf · relatÓrio intercalar de actividades projecto pocti/33842/ese/2000 teste

48 Teste Concorrente para Sistemas Electrónicos Reconfiguráveis

dados neste registo, pré-definido pelo fabricante, está representado na Tabela 3.4. O componente é

identificado pelo código da família, 03h no caso das Virtex, e pelo número de linhas que constituem

a matriz de CLBs do componente. O código de fabricante da Xilinx é 49h.

Vista inferiordo componente

TDITDO

GCLK2GCLK3

M1M0 M2

GCLK1 GCLK0

PROGDONE

CCLK

Porto

(de TDI)

(para TDO)

Vista superiordo

componente

TDI TDO

Figura 3.12: Identificação do sentido da cadeia BS dentro do componente

Identificação do componente

VersãoCódigo da família Nº linhas de

CLBs

Código dofabricante LSB

31...28 27...21 20...12 11...1 0

xxxx 0000 011 y yyyy yyyy 0000 1001 001 1

Tabela 3.4: Conteúdo do registo de identificação na família Virtex

3.2.7. O REGISTO DE IDENTIFICAÇÃO DO UTILIZADOR

As Virtex suportam igualmente um registo de identificação adicional (USERCODE) com o

comprimento de 32 bits, o qual permite que o utilizador especifique um código de identificação

próprio para cada implementação. O conteúdo é definido pelo utilizador aquando da geração do

ficheiro de configuração, pelo que este só se torna válido após a configuração da FPGA, podendo a

partir daí ser acedido em qualquer altura para verificação.

Page 49: RELATÓRIO INTERCALAR DE ACTIVIDADES DO PROJECTO …purl.pt/281/1/projecto_maria/relatorio_intercalar.pdf · relatÓrio intercalar de actividades projecto pocti/33842/ese/2000 teste

Relatório intercalar de actividades - Projecto POCTI/33842/ESE/2000 49

3.2.8. O REGISTO DE CONFIGURAÇÃO

O registo de configuração através da infra-estrutura BS possui 32 bits e permite o acesso ao

barramento de configuração do componente para operações de escrita (configuração) e leitura.

3.2.9. OS REGISTOS DO UTILIZADOR

O utilizador pode igualmente definir até dois registos de dados adicionais (USER1 e USER2), que

serão válidos apenas após a configuração. Estes registos, uma vez criados, podem ser acedidos

através dos pinos do TAP, da mesma forma que os restantes registos de dados, através das

instruções opcionais USER1 e USER2. Uma vez que os pinos e a lógica de teste associados à infra-

-estrutura BS são dedicados, não é necessária a adição ao projecto de qualquer elemento para

possibilitar o seu uso. No entanto, se se pretender definir registos próprios, será necessário declará-lo

explicitamente através do uso de uma macro para esse fim, cujo símbolo se encontra representado

na Figura 3.13.

A macro BSCAN_VIRTEX possui dois pinos, SEL1 e SEL2, que determinam qual o registo a

aceder, dois pinos de relógio independentes para cada registo, DRCK1 e DRCK2, e pinos de saída

partilhados que representam o estado do controlador do TAP: Reset, Shift e Update.

Figura 3.13: Representação simbólica da macro BSCAN_VIRTEX

3.2.10. O CONJUNTO DE INSTRUÇÕES

O modo de operação da infra-estrutura Boundary-Scan é determinado pelo conjunto de instruções

suportado pela família Virtex, conjunto esse apresentado na Tabela 3.5. A cada instrução

corresponde um comportamento bem definido, que a seguir se detalha:

• EXTEST Esta instrução permite o teste das ligações na carta de circuito impresso (CCI),

seleccionando para este efeito o registo de varrimento pela periferia (BS). O conteúdo dos

Page 50: RELATÓRIO INTERCALAR DE ACTIVIDADES DO PROJECTO …purl.pt/281/1/projecto_maria/relatorio_intercalar.pdf · relatÓrio intercalar de actividades projecto pocti/33842/ese/2000 teste

50 Teste Concorrente para Sistemas Electrónicos Reconfiguráveis

respectivos andares de retenção define o estado dos pinos de saída, aquando da transição

descendente de TCK, no estado Update-DR, enquanto que os sinais recebidos nos pinos de

entrada são carregados para os andares de captura/deslocamento das mesmas células, aquando

da transição ascendente de TCK, no estado Capture-DR.

Instrução Código (4:0) Descrição

EXTEST 00000 Selecciona o registo BS em modo teste

SAMPLE/PRELOAD 00001 Selecciona o registo BS em modotransparente

USER1 00010 Acede ao registo 1, definido peloutilizador

USER2 00011 Acede ao registo 2, definido peloutilizador

CFG_OUT 00100 Acede ao barramento de configuraçãopara leitura

CFG_IN 00101 Acede ao barramento de configuraçãopara escrita

INTEST 00111 Habilita a operação INTEST

USERCODE 01000Permite deslocar para o exterior oconteúdo do registo de identificação doutilizador

IDCODE 01001Permite deslocar para o exterior oconteúdo do registo de identificação docomponente

HIGHZ 01010 Coloca os pinos de saída em 3º estado eselecciona o registo de Bypass

JSTART 01100 Permite que TCK seja o relógio quesequencia o arranque após a configuração

BYPASS 11111 Selecciona o registo de Bypass

RESERVED Todos osoutros

Códigos reservados

Tabela 3.5: Instruções suportadas pela infra-estrutura Boundary-Scan das Virtex

• SAMPLE/PRELOAD Esta instrução, que selecciona igualmente o registo de varrimento pela

periferia (BS), permite que uma amostra dos sinais presentes nos pinos do componente seja

capturada e examinada, sem que esse funcionamento seja perturbado. A mesma instrução

Page 51: RELATÓRIO INTERCALAR DE ACTIVIDADES DO PROJECTO …purl.pt/281/1/projecto_maria/relatorio_intercalar.pdf · relatÓrio intercalar de actividades projecto pocti/33842/ese/2000 teste

Relatório intercalar de actividades - Projecto POCTI/33842/ESE/2000 51

permite que em simultâneo se carreguem valores, previamente deslocados, nos elementos de

retenção de cada célula BS.

• USER1 e USER2 Estas instruções permitem o acesso aos registos do utilizador.

• CFG_OUT Esta instrução permite a leitura da configuração do dispositivo e, opcionalmente, do

estado actual dos registos internos dos CLBs e IOBs, e dos valores presentes nas tabelas de

consulta dos CLBs e nos blocos de memória, quer na sua totalidade, quer parcialmente.

• CFG_IN Esta instrução permite realizar a configuração do dispositivo, quer total quer

parcialmente.

• INTEST Esta instrução, que selecciona o registo de varrimento pela periferia (BS), permite o

teste da lógica interna do componente. Os estímulos de teste são deslocados e aplicados nas

entradas da lógica interna aquando da transição descendente de TCK, no estado Update-DR,

sendo os resultados presentes nas suas saídas capturados aquando da transição ascendente de

TCK, no estado Capture-DR, e posteriormente deslocados para o exterior.

• USERCODE Esta instrução selecciona o registo de identificação, cujo conteúdo é definido pelo

utilizador, permitindo o seu deslocamento para o exterior.

• IDCODE Esta instrução selecciona o registo de identificação do componente, cujo conteúdo é

definido pelo fabricante (vide Tabela 3.4), permitindo o seu deslocamento para o exterior.

• HIGHZ Esta instrução selecciona o registo de Bypass e coloca todos os pinos de saída em terceiro

estado.

• JSTART Após o deslocamento dos bits de configuração, a FPGA passa por uma sequência de

arranque antes de ficar operacional. Na configuração através da infra-estrutura BS, esta

instrução torna TCK o relógio que sequencia essa etapa. O número mínimo de períodos de

TCK requeridos pela sequência de arranque é de doze.

• BYPASS Esta instrução selecciona o registo de Bypass e coloca todas as células do registo BS em

modo transparente.

Todas as instruções estão disponíveis antes e após a configuração, com excepção de USER1 e

USER2, disponíveis apenas após a configuração e só se o seu uso tiver sido explicitamente definido.

3.3. A MEMÓRIA DE CONFIGURAÇÃO

A memória de configuração das Virtex, do tipo SRAM, permite um número infinito de

reconfigurações do componente, tendo no entanto a desvantagem da sua volatilidade, o que obriga

Page 52: RELATÓRIO INTERCALAR DE ACTIVIDADES DO PROJECTO …purl.pt/281/1/projecto_maria/relatorio_intercalar.pdf · relatÓrio intercalar de actividades projecto pocti/33842/ese/2000 teste

52 Teste Concorrente para Sistemas Electrónicos Reconfiguráveis

à existência de uma memória ou processador externo que armazene de forma permanentemente a

ou as configurações. A configuração das FPGAs da família Virtex desenrola-se ao longo de três

fases:

1. limpeza da memória de configuração;

2. transferência dos dados de configuração para a memória de configuração do componente;

3. activação da lógica por intermédio duma sequência de arranque.

Alguns dos pinos usados para a configuração são dedicados, enquanto outros são reutilizáveis como

pinos de entrada, saída ou bidireccionais de uso geral, uma vez terminada a configuração. A

Tabela 3.6 lista esses pinos, indicando resumidamente a sua função e qual a sua funcionalidade apósa configuração.

Dependendo do modo seleccionado, o relógio de configuração terá uma das seguintes origens: ser

gerado internamente na própria FPGA; provir de uma fonte externa (actuando neste caso o pinoCCLK como um pino de saída ou de entrada, respectivamente); ou ainda provir da entrada TCK do

TAP.

3.4. VECTORES DE DADOS

A memória interna de configuração está dividida em segmentos, designados por vectores, sendo as

porções do ficheiro de dados de configuração que são escritos nesta memória designados por

vectores de dados. O número e comprimento desses vectores depende do tamanho, em termos delógica, da FPGA. A título de exemplo, o componente XCV200 da família Virtex possui 2317

vectores, tendo cada um o comprimento de 576 bits (correspondentes a 18 palavras de 32 bits), num

total de 1.335.872 bits de configuração. O número total é obtido pelo produto entre o número devectores e o seu comprimento, a que se acrescenta o número de bits necessários para configurar os

registos internos que controlam a operação de configuração.

3.5. REGISTOS DE CONFIGURAÇÃO

A lógica de configuração das Virtex foi concebida de tal forma que é possível a partir do exterior ter

um controlo completo sobre todas as funções de configuração. Os registos internos que controlam

essas funções, listados na Tabela 3.7, são endereçáveis directamente através de um barramento deconfiguração comum, podendo o seu valor ser lido e alterado do exterior. Todos os dados de

configuração, com excepção das palavras de sincronização e mudas6, são escritas em registos

internos de configuração.

6 A lógica interna de configuração das Virtex necessita de alguns ciclos de relógio para se inicializar. Por esse motivo são

acrescentados no início do ficheiro de configuração algumas palavras que não contêm informação válida (mudas). Nacontinuação deste documento o termo “mudo” será usado sempre que a informação não tenha valor relevante

Page 53: RELATÓRIO INTERCALAR DE ACTIVIDADES DO PROJECTO …purl.pt/281/1/projecto_maria/relatorio_intercalar.pdf · relatÓrio intercalar de actividades projecto pocti/33842/ese/2000 teste

Relatório intercalar de actividades - Projecto POCTI/33842/ESE/2000 53

Nome Direcção Tipo Descrição Funcionalidadeapós configuração

Pinos dedicados

CCLK E/S Activa Relógio de configuração(saída no modo mestre-série) Entrada

PROG Entrada - Reset assíncrono da lógica deconfiguração

DONE E/S Activa/Colector--aberto

Estado da configuração econtrolo da sequência dearranque

M2, M1, M0 Entrada - Selecção do modo deconfiguração

TMS Entrada - Modo do TAP

TCK Entrada - Relógio do TAP

TDI Entrada - Entrada de dados do TAP

TDO Saída Activa Saída de dados do TAP

-

Pinos não dedicados

DIN(D0) Entrada - Entrada de dados nasconfigurações série E/S

[D1:D7] E/S Activabidireccional

Entrada de dados deconfiguração e saída de dadosde leitura no modoSelectMAP

CS Entrada - Selecção do componente

WRITE Entrada -Escrita (0) ou leitura (1) damemória de configuração nomodo SelectMAP

E/S a menos que sejaretido pelo modo

SelectMAP

BUSY/DOUT Saída Colector-aberto/

activa

Estado BUSY/READY nomodo SelectMAP; saída sériedos dados nos modos série deconfiguração

INIT E/S Colector-aberto Atrasa a configuração, indicaerro de configuração

E/S

Tabela 3.6: Pinos de configuração

Page 54: RELATÓRIO INTERCALAR DE ACTIVIDADES DO PROJECTO …purl.pt/281/1/projecto_maria/relatorio_intercalar.pdf · relatÓrio intercalar de actividades projecto pocti/33842/ese/2000 teste

54 Teste Concorrente para Sistemas Electrónicos Reconfiguráveis

Símbolo Nome do registo Leitura/Escrita Endereço

CRC Verificação por redundância cíclica L/E 0000b

FAR Endereço do vector L/E 0001b

FDRI Entrada de vectores de dados E 0010b

FDRO Saída de vectores de dados L 0011b

CMD Comandos L/E 0100b

CTL Controlo L/E 0101b

MASK Máscara do registo de controlo L/E 0110b

STAT Estado L 0111b

LOUT Saída de dados para configuração em cadeia E 1000b

COR Opções de configuração L/E 1001b

Reservado - - 1010b

FLR Comprimento do vector L/E 1011b

Reservado - - 11xxb

Tabela 3.7: Registos internos de configuração

3.5.1. REGISTO DE COMANDOS (CMD)

Os comandos carregados no registo CMD controlam o funcionamento da máquina de estados que

rege a configuração, os registos de vectores de dados e alguns sinais globais. O comando presente no

registo de comandos é executado sempre que o registo de endereço do vector (FAR) é carregado

com um novo valor, sendo suportados os comandos apresentados na Tabela 3.8.

3.5.2. REGISTO DO COMPRIMENTO DO VECTOR (FLR)

O registo FLR é escrito no início da configuração com o valor do comprimento do vector, indicado

pelo número de palavras de 32 bit. Recorde-se que esse comprimento é variável, dependendo do

tamanho, em termos de lógica, do componente. Se o número total de bits não for divisível por 32, o

valor é arredondado para o primeiro inteiro acima. Note-se que o valor presente em FLR é sempre

inferior em um ao número de palavras realmente lidas ou escritas por vector, dada a necessidade de

se incluir uma palavra muda no fim do vector, no caso de uma operação de escrita, ou à sua

existência no início, no caso de uma operação de leitura.

Page 55: RELATÓRIO INTERCALAR DE ACTIVIDADES DO PROJECTO …purl.pt/281/1/projecto_maria/relatorio_intercalar.pdf · relatÓrio intercalar de actividades projecto pocti/33842/ese/2000 teste

Relatório intercalar de actividades - Projecto POCTI/33842/ESE/2000 55

Símbolo Comando Código

Reservado - 0000b

WCFG Escrita de dados de configuração - usado antes da escritade dados em FDRI

0001b

Reservado - 0010b

LFRM

Último vector escrito – carregado antes da escrita doúltimo vector de dados (vector mudo), se o sinalGHIGH_B estiver activo; este comando não é necessáriose GHIGH_B estiver inactivo, o que permite asobreposição do último vector escrito com a libertação dosinal GHIGH_B

0011b

RCFG Leitura de dados de configuração – usado antes da leiturade dados de FDRO

0100b

START

Inicia sequência de arranque – este comando é tambémusado para iniciar uma sequência de shutdown antes deuma reconfiguração parcial; a sequência de arranque teminício após a próxima verificação com sucesso do códigode redundância cíclica

0101b

RCAPColoca o sinal CAPTURE a zero – este comando deve serusado quando se realiza uma operação de captura emmodo de amostragem única

0110b

RCRC Limpa o registo CRC 0111b

AGHIGH

Coloca o sinal GHIGH_B a nível lógico 1 – usado antesda reconfiguração para prevenir conflitos enquanto osnovos dados de configuração são escritos; todos os sinais esaídas dos CLBs são forçados a 1

1000b

SWITCH Altera a frequência de CCLK – usado quando em modode configuração mestre-série

1001b

Reservado - 101xb

Reservado - 11xxb

Tabela 3.8: Comandos do registo CMD

3.5.3. REGISTO DE OPÇÕES DE CONFIGURAÇÃO (COR)

O registo COR é usado para definir as opções de configuração ilustradas na Figura 3.14 e definidas

na Tabela 3.9.

Page 56: RELATÓRIO INTERCALAR DE ACTIVIDADES DO PROJECTO …purl.pt/281/1/projecto_maria/relatorio_intercalar.pdf · relatÓrio intercalar de actividades projecto pocti/33842/ese/2000 teste

56 Teste Concorrente para Sistemas Electrónicos Reconfiguráveis

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

DO

NE_

PIPE

DR

IVE_

DO

NE

SIN

GLE

OSC

FSEL

SSC

LKSR

C

LOC

K_W

AIT

SHU

TD

OW

N

DO

NE_

CYC

LE

LCK

_CYC

LE

GT

S_C

YCLE

GW

E_C

YCLE

GSR

_CYC

LE

xxx xxxx xxxx xxxx xxxx xxxx xxxx xxx0 x

Figura 3.14: Campos do registo de opções de configuração

3.5.4. REGISTO DE CONTROLO (CTL)

O registo CTL controla as seguintes funções internas, associadas aos campos representados na

Figura 3.15:

• Persist Se ‘0’, valor por omissão, todos os pinos de configuração passam a E/S genéricas após a

configuração, com as excepções de CCLK, PROG e DONE. Caso contrário, os pinos de

configuração retêm a sua função, mesmo após a configuração ter terminado. Esta função não

afecta o TAP.

• Security (SBITS) Os níveis de segurança restringem o acesso às operações de leitura e

configuração. No nível 0, o nível por omissão, todas as operações de leitura e escrita são

permitidas. No nível 1 todas as funções de leitura, quer na configuração SelectMAP, quer

através do TAP, são interditadas. Nos níveis 2 e 3 todas as funções de configuração e leitura são

interditadas, independentemente do modo. A única forma de remover um nível de segurança é

desconfigurando o componente, por colocação da linha PROG a nível lógico 1, ou retirando-

-lhe a alimentação.

• GTS_USR_B Se 0 coloca todos as E/S em alta impedância. Desabilita as resistências de pull-up

se GTS_CFG_B também estiver activo.

As restantes posições contém obrigatoriamente o valor lógico ‘0’.

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

GT

S_U

SR_B

x00 00xx 0x00 0000 0000 0000 0000 0000 0

Pers

ist

SBIT

S

Figura 3.15: Campos do registo de controlo

Page 57: RELATÓRIO INTERCALAR DE ACTIVIDADES DO PROJECTO …purl.pt/281/1/projecto_maria/relatorio_intercalar.pdf · relatÓrio intercalar de actividades projecto pocti/33842/ese/2000 teste

Relatório intercalar de actividades - Projecto POCTI/33842/ESE/2000 57

Campo Descrição Valor poromissão

DONE_PIPE

A FPGA atrasa ou não em um ciclo de relógio a transição para oestado seguinte, após a passagem de DONE ao valor lógico 1

0: sem atraso

1: com atraso

0

DRIVE_DONE0: pino DONE em configuração colector-aberto

1: pino DONE activo (não necessita de pull-up externo)

0

SINGLE A leitura é efectuada numa única amostragem 0

OSCFSEL Estabelece a frequência de CCLK na configuração em modo mestre--série

2

SSCLKSRC

Fonte de relógio para a sequência de arranque:

00: CCLK

01: UserClk

1X: JTAGClk (TCK)

0

LOCK_WAIT Máscara de 4 bits que indica qual a DLL (Delay Looked Loop)pelaqual a sequência de arranque deve esperar durante um LCK_CYCLE

0

SHUTDOWN

Indica se se trata de uma sequência de arranque ou de paragem

0: arranque

1: paragem

0

DONE_CYCLE Especifica em que estado da sequência de arranque o pino DONE élibertado

3

LCK_CYCLE Especifica qual o estado em que a sequência de arranque deve pararquando espera por um lock da DLL

7

GTS_CYCLEEspecifica em que estado da sequência de arranque as E/Sabandonam o terceiro estado e assumem a configuração definida peloutilizador

4

GWE_CYCLE Especifica em que estado da sequência de arranque a habilitaçãoglobal de escrita é activada

5

GSR_CYCLE Especifica em que estado da sequência de arranque os flip-flopsassumem o estado inicial definido pelo utilizador

5

Tabela 3.9: Descrição das opções de configuração

Page 58: RELATÓRIO INTERCALAR DE ACTIVIDADES DO PROJECTO …purl.pt/281/1/projecto_maria/relatorio_intercalar.pdf · relatÓrio intercalar de actividades projecto pocti/33842/ese/2000 teste

58 Teste Concorrente para Sistemas Electrónicos Reconfiguráveis

3.5.5. REGISTO DE MÁSCARA (MASK)

O registo MASK actua como um mecanismo de segurança, que controla quais os bits do registo

CTL que podem ser alterados. Um ‘1’ no bit n da máscara permite a sua escrita no registo CTL. O

valor por omissão da máscara é ‘0’.

3.5.6. REGISTO DE ENDEREÇO DO VECTOR (FAR)

O registo FAR especifica o endereço onde o próximo vector de dados de configuração deve ser

escrito. Este endereço está dividido em três partes, o tipo de bloco, a parte alta do endereço e a

respectiva parte baixa, conforme se ilustra na Figura 3.16.

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

Tip

o de

blo

co

Part

e al

ta d

oen

dere

ço(C

olun

a de

CLB

s ou

RA

M)

000 0000 00xx xxxx xxxx xxxx xxx0 x000 0

Part

e ba

ixa

doen

dere

ço(e

nder

eço

dove

ctor

)

Figura 3.16: Campos do registo de endereço do vector

O tipo de bloco indica qual o espaço de endereçamento a ser usado, CLB (00) ou bloco de memória

RAM (01). A parte alta do endereço selecciona qual a coluna de CLBs ou RAM, enquanto a parte

baixa indica qual o vector, dentro da coluna, a ser acedido. A parte baixa do endereço é

incrementada de cada vez que um vector completo é escrito ou lido, de ou para o registo de entrada

ou saída de vectores de dados. Se o último vector de uma coluna de CLBs for o seleccionado, esta

operação conduz ao incremento da parte alta do endereço e à colocação em zero da parte baixa. No

caso do endereçamento de um bloco de RAM, a parte alta não é, neste caso, incrementada

automaticamente.

3.5.7. REGISTO DE ENTRADA DE VECTORES DE DADOS (FDRI)

O registo FDRI é usado para carregar vectores de dados de configuração. Trata-se de um registo de

deslocamento, no qual os dados são carregados antes de serem transferidos para a memória de

configuração.

A operação de escrita é realizada de modo a que enquanto um vector de dados é escrito na memória

de configuração, um segundo vector está já a ser deslocado. O último vector é sempre um vector

Page 59: RELATÓRIO INTERCALAR DE ACTIVIDADES DO PROJECTO …purl.pt/281/1/projecto_maria/relatorio_intercalar.pdf · relatÓrio intercalar de actividades projecto pocti/33842/ese/2000 teste

Relatório intercalar de actividades - Projecto POCTI/33842/ESE/2000 59

mudo, que não é escrito na memória de configuração, servindo apenas para “empurrar”7 o vector

anterior.

Para uma operação de escrita, o registo de comandos deve ser carregado com o comando WCFG e

posteriormente o registo FDRI com pelo menos dois vectores, um vector de dados válidos (para

serem escritos na memória de configuração) e o outro mudo.

3.5.8. REGISTO DE SAÍDA DE VECTORES DE DADOS (FDRO)

O registo FDRO é usado para ler vectores de dados de configuração, ou dados capturados nos flip-

-flops e blocos de memória RAM. O registo actua da forma descrita anteriormente para o FDRI, mas

agora em sentido contrário, como área temporária de transferência de dados. Para uma operação de

leitura, o registo de comandos deve ser carregado com o comando RCFG e posteriormente

endereçado o FDRO com um comando de leitura.

3.5.9. REGISTO DE SAÍDA DE DADOS PARA CONFIGURAÇÃO EM CADEIA (LOUT)

O registo LOUT é usado nos modos de configuração série para permitir a transferência de dados

através da cadeia de configuração. Os dados escritos em LOUT são serializados e aparecem no pino

de saída DOUT.

3.5.10. REGISTO DE VERIFICAÇÃO POR REDUNDÂNCIA CÍCLICA (CRC)

O registo CRC, cuja estrutura interna está representada na Figura 3.17, proporciona um mecanismo

de detecção de erros. Aquando da escrita de qualquer registo de configuração (com excepção do

registo LOUT), é calculado e guardado no registo CRC, um valor de verificação de 16 bit, cobrindo

quer o registo de dados quer o de endereços. No final de uma série de operações de escrita, um valor

de verificação pré-calculado pode ser escrito no registo CRC. A lógica de configuração é colocada

em modo ERRO (configuração abortada e sinal de INIT a nível lógico 0) se o valor resultante for

diferente de zero, sendo o bit CRC_ERROR acessível através do registo de estado.

7 O deslocamento de um vector mudo para o registo obriga a que o vector anterior seja transferido para a memória de

configuração. Se esta operação não tivesse lugar, o último vector permaneceria armazenado no registo, não sendotransferido para a memória. Este vector mudo serve assim apenas para “empurrar” o anterior, limpando o registo dedados válidos.

Page 60: RELATÓRIO INTERCALAR DE ACTIVIDADES DO PROJECTO …purl.pt/281/1/projecto_maria/relatorio_intercalar.pdf · relatÓrio intercalar de actividades projecto pocti/33842/ese/2000 teste

60 Teste Concorrente para Sistemas Electrónicos Reconfiguráveis

0000 0000 0000 0000 CRC 16 bit

31:16 15:0

Registo CRC [31:0]

0 12 3 4 5 6 7 8 9 10 11 12 13 14

15

29 28 27 5 4 3 2 1 0

Palavra de dados de 32 bit

3 2 1 0 2631 30

Endereço

Desloca

Registo de cálculo

Registo de entrada de dados Entrada de dados

Figura 3.17: Estrutura interna do registo CRC

3.5.11. REGISTO DE ESTADO (STAT)

No registo STAT são mantidos os valores actuais de alguns dos sinais de controlo e de estado,

podendo este registo ser lido através de uma operação de leitura. A Figura 3.18 ilustra os diferentes

campos do registo de estado, estando a funcionalidade de cada um descrita na Tabela 3.10. As

restantes posições contém obrigatoriamente o valor lógico ‘0’.

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

LOC

K

INIT

DO

NE

MO

DE

GT

S_C

FGIN

_ER

RO

R

CR

C_E

RR

OR

xxx xxxx xxxx xxx0 x000 0000 0000 0000 0

GSR

_BG

WE_

B

GH

IGH

_B

Figura 3.18: Campos do registo de estado

3.6. O PROCESSO DE CONFIGURAÇÃO E LEITURA

O processo de configuração interna de uma Virtex segue o diagrama de fluxo ilustrado na

Figura 3.19, sendo a respectiva sequência de comandos listada na Tabela 3.11.

O primeiro conjunto de comandos prepara a lógica interna de configuração para a carga dos

vectores de configuração. Alguns ciclos do relógio de configuração, representados por palavras

mudas, conduzem à inicialização da lógica interna de configuração, enquanto que a palavra de

sincronismo permite o reconhecimento dos limites da palavra de 32 bit, sincronizando a

transferência dos dados. Este procedimento apenas é necessário no caso de uso do modo de

configuração SelectMAP. O registo de verificação por redundância cíclica é inicializado através da

escrita do comando RCRC no registo de comandos. O tamanho do vector de dados para o

Page 61: RELATÓRIO INTERCALAR DE ACTIVIDADES DO PROJECTO …purl.pt/281/1/projecto_maria/relatorio_intercalar.pdf · relatÓrio intercalar de actividades projecto pocti/33842/ese/2000 teste

Relatório intercalar de actividades - Projecto POCTI/33842/ESE/2000 61

dispositivo é carregado no registo FLR e as opções de configuração no registo COR, seguidas por

dados para o registo CTL, se existirem. Embora a frequência de CCLK seja especificada no registo

COR, esta nova frequência só será assumida após o envio do comando SWITCH para o registo de

comandos. O envio deste comando é necessário apenas quando se usa o modo de configuração

mestre-série.

Nome Bit Descrição

DONE 14 Valor no pino DONE

INIT 13 Valor de INIT

MODE 12:10 Valor dos pinos de modo M2, M1 e M0

GHIGH_B 9 0: Todas as interligações estão forçadas a nívellógico ‘1’

GSR_B 8 0: Todos os flip-flops estão forçados ao seu estadoinicial

GWE_B 7 1: Escrita nos flip-flops e blocos de memóriabloqueada

GTS_CFG 6 0: Todas as E/S se encontram em alta impedância

IN_ERROR 5 Assinala erro na entrada série de dados

LOCK 4:1 Indica se alguma DLL se encontra locked

CRC_ERROR 0 Indica ocorrência de erro na configuração

Tabela 3.10: Descrição dos bits do registo de estado

A escrita na memória de configuração dos vectores de dados de configuração é efectuada no

segundo conjunto de comandos. A activação do circuito que vai efectuar a transferência dos dados

escritos em FDRI para as células da memória de configuração é efectivada carregando no registo

CMD o comando WCFG. Para se iniciar a carga dos vectores é necessário primeiro carregar o

endereço de destino no registo FAR, seguido do comando de escrita, que contém igualmente o

número de palavras que vão ser enviadas, e posteriormente dos vectores de dados para FDRI. O

número de conjuntos de vectores é variável, sendo na Tabela 3.11 exemplificado o caso de serem

três conjuntos. Quando todos, à excepção do último vector, se encontram carregados, o valor

inicial de verificação é transferido para o registo CRC, após o que o comando LFRM é carregado no

registo CMD, seguido por um último comando de escrita e pelo último vector para FDRI.

Page 62: RELATÓRIO INTERCALAR DE ACTIVIDADES DO PROJECTO …purl.pt/281/1/projecto_maria/relatorio_intercalar.pdf · relatÓrio intercalar de actividades projecto pocti/33842/ese/2000 teste

62 Teste Concorrente para Sistemas Electrónicos Reconfiguráveis

Inicialização

Sincronização

Limpa CRC

Define tamanhodo vector

Inicializa opções

Inicializaparâmetros de

controlo

Inicializafrequência de

CCLK

Escreve vectoresna memória

Fim

Invocasequência de

arranque

Carrega CRC

Máximo de três ciclos deCCLK

Define os limites da palavrade 32 bit

Inicializa o cálculo do CRC

Uso interno

Assume opções e ConfigRateiniciais

Uso interno

Os vectores de dados sãoescritos na memória deconfiguração

Após o cálculo do CRC éinvocada a sequência dearranque

Se a verificação do CRCfalha, o arranque é abortado

A FPGA está operacional

Quando em modo mestre--série, o CCLK assumeo valor de configuração

Figura 3.19: Diagrama de fluxo do processo interno de configuração

Por último, o terceiro conjunto de comandos inicializa a sequência de arranque, por intermédio do

comando START, e termina o cálculo da palavra de verificação. As quatro palavras mudas finais

são fornecidas ao sistema, para proporcionarem o número de ciclos de CCLK necessários à

activação da FPGA.

Page 63: RELATÓRIO INTERCALAR DE ACTIVIDADES DO PROJECTO …purl.pt/281/1/projecto_maria/relatorio_intercalar.pdf · relatÓrio intercalar de actividades projecto pocti/33842/ese/2000 teste

Relatório intercalar de actividades - Projecto POCTI/33842/ESE/2000 63

Tipo Nº de palavras

1º conjunto de comandos

Palavras mudas (somente no modo SelectMAP) 2

Palavra de sincronização (somente no modo SelectMAP) 1

Envia CMD (RCRC) 2

Define FLR 2

Define COR 2

Define MASK 2

Define CTL 2

Envia CMD (SWITCH) (somente no modo mestre-série) 2

2º conjunto de comandos

Escreve CMD (WCFG) 2

Escreve FAR 2

Escreve FDRI 2

Escreve FAR 2

Escreve FDRI 1

Escreve FAR 2

Escreve FDRI 1

Escreve CRC 2

Escreve CMD (LFRM) 2

Escreve FDRI 1

3º conjunto de comandos

Escreve CMD (START) 2

Escreve CRC 2

Palavras mudas 4

Total 40

Tabela 3.11: Sequência de escrita nos registos de configuração

Page 64: RELATÓRIO INTERCALAR DE ACTIVIDADES DO PROJECTO …purl.pt/281/1/projecto_maria/relatorio_intercalar.pdf · relatÓrio intercalar de actividades projecto pocti/33842/ese/2000 teste

64 Teste Concorrente para Sistemas Electrónicos Reconfiguráveis

A sequência descrita aplica-se na configuração inicial e completa da FPGA. No caso de

reconfigurações posteriores, totais ou parciais, a sequência é idêntica mas apresenta algumas

cambiantes. Assim:

• Se existir a possibilidade dos vectores de dados a ser escritos causarem conflitos, o sinal

GHIGH_B deve ser colocado a nível lógico ‘1’, através do envio do respectivo comando para o

registo CMD;

• Envio do comando WCFG;

• Definição do endereço de início através dum comando FAR;

• Definição do número de palavras de configuração a ser escritas no registo FDRI;

• Envio dos vectores de dados;

• Desactivação do sinal GHIGH_B através do envio do comando LFRM, caso tenha sido colocado

a nível lógico ‘1’;

• Envio de um vector mudo.

Para se proceder a uma operação de leitura da configuração interna a sequência de comandos é a

seguinte:

• Envio do comando RCFG para o registo de comandos;

• Definição do endereço de início através dum comando FAR;

• Definição do número de palavras de configuração a ser lidas para o registo FDRO;

• Envio de um vector mudo;

• Leitura dos vectores de dados.

3.6.1. ORGANIZAÇÃO DUM PACOTE DE CONFIGURAÇÃO

A troca de informação entre a FPGA e o exterior, quer para envio de comandos, quer para a leitura

ou escrita de vectores de dados, pressupõe a definição de um protocolo que torne compreensível

essa troca. Os dados de configuração são organizados em palavras de 32 bit, contendo sempre dois

comandos principais: Leitura e Escrita, cujos códigos de operação (OP) se encontram listados na

Tabela 3.12. A execução de um comando de configuração ocorre sempre que o comando é lido ou

escrito no registo de comandos apropriado (ver Tabela 3.8).

Page 65: RELATÓRIO INTERCALAR DE ACTIVIDADES DO PROJECTO …purl.pt/281/1/projecto_maria/relatorio_intercalar.pdf · relatÓrio intercalar de actividades projecto pocti/33842/ese/2000 teste

Relatório intercalar de actividades - Projecto POCTI/33842/ESE/2000 65

Operação Código

Leitura 01

Escrita 10

Tabela 3.12: Códigos de operação para Leitura e Escrita

Um comando é organizado como um pacote, com uma palavra de cabeçalho e, em opção, uma ou

mais palavras de dados. O cabeçalho é dividido em vários campos conforme ilustrado na Figura

3.20, sendo a primeira palavra a ser escrita no registo de comandos apropriado, definindo à partida,

através do seu campo ‘OP’, se se trata de uma operação de leitura ou de escrita.

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0Tipo

xxx xxxx xxx0 x0xx xx00 0000 000x 0x00 1

OP Endereço do registo RSV Número de palavras

Nota: Os valores lógicos '0' ou '1' indicados em alguns campos são obrigatórios.Um x indica que o valor é variável e deve ser definido.

Figura 3.20: Formato da palavra de cabeçalho dum pacote de comando

O campo ‘Endereço de registo’ define o registo interno de configuração a que se destina o comando,

os quais se encontram listados na Tabela 3.7. O campo ‘Número de palavras’ contém um inteiro

entre 0 e 2.047, indicando o número de palavras subsequentes à palavra de cabeçalho. No caso de o

número de palavras subsequentes se situar entre 2.048 e 1.048.575, o campo ‘Número de palavras’

da palavra de cabeçalho deve conter ‘0’, sendo essa palavra seguida de uma palavra de extensão de

cabeçalho, cujo formato se ilustra na Figura 3.21. O campo ‘OP’ é igual em ambas as palavras,

enquanto o campo ‘Tipo’ é diferente para as duas, sendo ‘001’ no primeiro caso e ‘010’ no segundo.

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0Tipo

xxx xxxx xxxx xxxx xxxx x000 000x 0x10 0

OP Número de palavras

Nota: Os valores lógicos '0' ou '1' indicados em alguns campos são obrigatórios.Um x indica que o valor é variável e deve ser definido.

Figura 3.21: Formato da palavra de extensão de cabeçalho

3.7. ENDEREÇAMENTO E CONTEÚDO DO ESPAÇO DE CONFIGURAÇÃO

As FPGAs da família Virtex apresentam a possibilidade de serem escritas e lidas apenas

parcialmente, o que obriga ao conhecimento preciso da forma de endereçamento e da localização

dos bits de configuração de CLBs e blocos de RAM, bem como dos bits de estado, no caso de uma

Page 66: RELATÓRIO INTERCALAR DE ACTIVIDADES DO PROJECTO …purl.pt/281/1/projecto_maria/relatorio_intercalar.pdf · relatÓrio intercalar de actividades projecto pocti/33842/ese/2000 teste

66 Teste Concorrente para Sistemas Electrónicos Reconfiguráveis

leitura em que se pretenda capturar o estado dos flip-flops e os valores contidos nas células das

memórias RAM, quer nos blocos quer nas LUT.

Os dados de configuração estão organizados em colunas de CLBs, que contêm, como visto

anteriormente, duas slices, contendo cada uma duas células lógicas. Cada coluna de CLBs possui

dois IOBs em cima e em baixo, que fazem parte do mesmo vector de configuração dos CLBs. Nos

extremos esquerdo e direito existem três IOBs por linha de CLBs, cujos dados de configuração estão

organizados em colunas que percorrem o componente de alto a baixo. De igual forma, os blocos de

memória situam-se em duas colunas, uma de cada lado da matriz de CLBs, sendo o número de

blocos em cada coluna igual a ¼ do número de CLBs por coluna. A Figura 3.22 apresenta de forma

esquemática esta distribuição.

RAM

RAM

CLB

CLB

CLB

CLB

CLB

CLB

CLB

CLB

IOB IOB

IOB IOB

CLB

CLB

CLB

CLB

CLB

CLB

CLB

CLB

IOB IOB

IOB IOB

CLB

CLB

CLB

CLB

CLB

CLB

CLB

CLB

IOB IOB

IOB IOB

CLB

CLB

CLB

CLB

CLB

CLB

CLB

CLB

IOB IOB

IOB IOB

CLB

CLB

CLB

CLB

CLB

CLB

CLB

CLB

IOB IOB

IOB IOB

CLB

CLB

CLB

CLB

CLB

CLB

CLB

CLB

IOB IOB

IOB IOB

CLB

CLB

CLB

CLB

CLB

CLB

CLB

CLB

IOB IOB

IOB IOB

CLB

CLB

CLB

CLB

CLB

CLB

CLB

CLB

IOB IOB

IOB IOB

CLB

CLB

CLB

CLB

CLB

CLB

CLB

CLB

IOB IOB

IOB IOB

RAM

RAM

IOB

IOB

IOB

IOB

IOB

IOB

IOB

IOB

IOB

IOB

IOB

IOB

IOB

IOB

IOB

IOB

IOB

IOB

IOB

IOB

IOB

IOB

IOB

IOB

IOB

IOB

IOB

IOB

IOB

IOB

IOB

IOB

IOB

IOB

IOB

IOB

IOB

IOB

IOB

IOB

IOB

IOB

IOB

IOB

IOB

IOB

IOB

IOB

Figura 3.22: Esquema da organização interna das Virtex

3.7.1. ORGANIZAÇÃO DA MEMÓRIA DE CONFIGURAÇÃO

A memória de configuração pode ser visualizada como uma matriz rectangular de bits, agrupados em

vectores verticais, com um bit de largura, os quais se estendem do topo ao fundo da matriz. O vector

é a unidade atómica de configuração, a mais pequena porção da memória de configuração que pode

Page 67: RELATÓRIO INTERCALAR DE ACTIVIDADES DO PROJECTO …purl.pt/281/1/projecto_maria/relatorio_intercalar.pdf · relatÓrio intercalar de actividades projecto pocti/33842/ese/2000 teste

Relatório intercalar de actividades - Projecto POCTI/33842/ESE/2000 67

ser escrita e/ou lida. Os vectores agrupam-se paralelamente em unidades maiores designadas

colunas de configuração, constituídas por um número de vectores variável consoante o seu tipo. A

Tabela 3.13 lista os diferentes tipos de colunas de configuração, o número de vectores que integra

cada tipo e o número de colunas por tipo num componente. Na Figura 3.23 é possível visualizar a

forma como as colunas de configuração são atribuídas aos diferentes recursos configuráveis,

salientando-se a coluna central que inclui a configuração dos quatro pinos de relógio global

(GCLK), rodeada pelo conjunto formado pelas colunas de configuração de cada uma das colunas de

CLBs, e respectivos dois IOBs no topo e dois IOBs em baixo. Nos extremos, de ambos os lados, mais

três colunas de configuração, duas referentes à configuração dos blocos de RAM (uma para a

configuração das interligações e a outra relativa ao conteúdo de cada célula de memória) e uma à

configuração das coluna laterais de IOBs.

Tipo de coluna de configuração # de vectores dacoluna de configuração

# colunas de configuraçãopor componente

Central 8 1

CLB 48 # de colunas de CLBs

IOB 54 2

Interligações dos blocos de memóriaRAM

27

Conteúdo dos blocos de memória RAM 64

2

Tabela 3.13: Tipos de colunas de configuração

Col

una

de IO

Bs d

o la

do e

sque

rdo

(54

vect

ores

)

Bloc

os d

e m

emór

ia R

AM

\con

teúd

o(6

4 ve

ctor

es)

Bloc

os d

e m

emór

ia R

AM

\inte

rlig.

(27

vect

ores

)

Col

una

de IO

Bs d

o la

do d

ireito

(54

vect

ores

)

Col

una

de C

LBs

(48

vect

ores

)

2IOBs

2IOBs

Col

una

de C

LBs

(48

vect

ores

)

2IOBs

2IOBs

Col

una

cent

ral

(8 v

ecto

res)

2GCLK

2GCLK

Col

una

de C

LBs

(48

vect

ores

)

2IOBs

2IOBs

Col

una

de C

LBs

(48

vect

ores

)

2IOBs

2IOBs Bl

ocos

de

mem

ória

RA

M\c

onte

údo

(64

vect

ores

)

Bloc

os d

e m

emór

ia R

AM

\inte

rlig.

(27

vect

ores

)

C0 C1C2CnCn+4Cn+2 Cn-1RAM0 Cn+3 RAM1 Cn+1

n - nº de colunas de CLBs

Figura 3.23: Locação dos vectores aos recursos configuráveis

O espaço total endereçável está dividido em blocos de dois tipos:

Page 68: RELATÓRIO INTERCALAR DE ACTIVIDADES DO PROJECTO …purl.pt/281/1/projecto_maria/relatorio_intercalar.pdf · relatÓrio intercalar de actividades projecto pocti/33842/ese/2000 teste

68 Teste Concorrente para Sistemas Electrónicos Reconfiguráveis

• Tipo RAM, correspondente às colunas que contêm os dados constantes dos blocos de memória

RAM (exclui as de interligação);

• Tipo CLB, correspondente às colunas que contêm todos os dados de configuração de todos os

elementos programáveis dentro da FPGA (valores das LUT, elementos de controlo dos CLBs,

IOBs e Blocos de RAM e a totalidade do controlo das interligações).

Ambos os espaços de endereçamento se encontram subdivididos em parte alta e parte baixa,

designados respectivamente por endereço maior e endereço menor. A cada coluna de cada tipo

corresponde um único endereço maior e a cada vector dentro de cada coluna um único endereço

menor.

O espaço de endereçamento dos CLBs inicia-se com zero (endereço maior) na coluna central e

alterna entre a metade direita e esquerda do componente, para todas as colunas do tipo CLB. No

espaço de endereçamento da RAM, um 0 corresponde à coluna da esquerda e um 1 à da direita. Na

Figura 3.24 encontram-se indicados os endereços maiores para o caso da Virtex XCV50, que

apresenta 24 colunas de CLBs.

Coluna de IO

Bs do lado direito(54 vectores)

Blocos de mem

ória RA

M/conteúdo

(64 vectores)

Blocos de mem

ória RA

M/interlig.

(27 vectores)

Coluna de IO

Bs do lado esquerdo(54 vectores)

Coluna de C

LBs(48 vectores)

2IOBs

2IOBs

Coluna de C

LBs(48 vectores)

2IOBs

2IOBs

Coluna central(8 vectores)

2GCLK

2GCLK

Coluna de C

LBs(48 vectores)

2IOBs

2IOBs

Coluna de C

LBs(48 vectores)

2IOBs

2IOBs

Blocos de mem

ória RA

M/conteúdo

(64 vectores)

Blocos de mem

ória RA

M/interlig.

(27 vectores)

C0 C1C2C24BI0IOesq. C23RAM0 BI1 RAM1 IOdir.

0 12242826 230 27 1 25End. maior

Figura 3.24: Endereços maiores da Virtex XCV50

3.7.2. VECTORES

Os vectores são, em cada operação, escritos ou lidos sequencialmente por ordem ascendente dos

seus endereços. Múltiplos vectores consecutivos são lidos com um único comando de configuração,

sendo um vector a mais pequena quantidade de dados que pode ser lida ou escrita. A totalidade da

matriz de CLBs, mais os IOBs e as colunas que definem as interligações dos blocos de memória,

podem ser escritos ou lidos com um único comando. O conteúdo de cada coluna de memória tem

de ser escrito ou lido separadamente.

Page 69: RELATÓRIO INTERCALAR DE ACTIVIDADES DO PROJECTO …purl.pt/281/1/projecto_maria/relatorio_intercalar.pdf · relatÓrio intercalar de actividades projecto pocti/33842/ese/2000 teste

Relatório intercalar de actividades - Projecto POCTI/33842/ESE/2000 69

Cada vector é constituído por um conjunto de bits agrupados em palavras de 32 bit, sendo os bits do

topo da coluna escritos ou lidos primeiro. O tamanho do vector depende do número de linhas de

CLBs do componente, sendo dado pela Equação 3.2.

Equação 3.22)CLBs de linhas (# 18 vector do# +×=bits

A este resultado são acrescentados zeros no final, até perfazer um número inteiro de palavras. Uma

palavra muda adicional é acrescentada no final de cada vector, pelas mesmas razões que as

apontadas para o caso dos vectores mudos. A título de exemplo teríamos que para a Virtex

XCV200, com 28 linhas, o número de palavras por vector seria:

Equação 3.3( )

( )

vector por palavras18117

x a inferior não inteiro menor x 1732

540

54022818

=+

=

=+×

3.7.3. ORGANIZAÇÃO DOS VECTORES

Embora em cada coluna o vector se desenvolva verticalmente do topo para o fundo, por

conveniência de visualização, os vectores são apresentados na horizontal, correspondendo ao lado

esquerdo o topo da coluna e ao direito o fundo. A Figura 3.25 mostra a atribuição de bits de cada

vector aos elementos de cada coluna de CLBs, 18 bits por cada dois IOBs, no topo e no fundo, e 18

por cada CLB, completados com o número de bits mudos necessários para perfazer um número

inteiro de palavras, mais uma palavra muda. A Figura 3.26 mostra a atribuição de bits de cada

vector aos elementos de cada coluna de IOBs, 18 bits por cada três linhas de IOBs, completados

com o número de bits mudos necessários para perfazer um número inteiro de palavras, mais uma

palavra muda.

2 IOBs dotopo

18

CLB L1

18

CLB L2

18

CLB Ln

18

2 IOBs dofundo

18

Palavramuda

32

bitsmudos

x

Figura 3.25: Organização do vector duma coluna de CLBs

3 IOBs

18

3 IOBs

18

3 IOBs

18

3 IOBs

18

3 IOBs

18

Palavramuda

32

bitsmudos

x

de cima para baixo

Figura 3.26: Organização do vector duma coluna de IOBs

Page 70: RELATÓRIO INTERCALAR DE ACTIVIDADES DO PROJECTO …purl.pt/281/1/projecto_maria/relatorio_intercalar.pdf · relatÓrio intercalar de actividades projecto pocti/33842/ese/2000 teste

70 Teste Concorrente para Sistemas Electrónicos Reconfiguráveis

A Figura 3.27 mostra a atribuição de bits de cada vector aos blocos de memória, 18 bits mudos

iniciais, seguidos por grupos de 72 bits atribuídos a cada linha de RAM8, mais 18 bits mudos finais,

completados com o número de bits mudos necessários para perfazer um número inteiro de palavras,

mais uma palavra muda.

bits mudos

18

RAM L0

72

RAM L1

72

RAM Ln

72

Palavramuda

3218

bits mudos

x

Figura 3.27: Organização do vector duma coluna de memória

3.7.4. LOCALIZAÇÃO DOS BITS DAS TABELAS DE CONSULTA

Relativamente ao início de cada vector, as posições relativas dos bits das tabelas de consulta no

ficheiro de configuração são as mesmas para cada slice de cada CLB. Estes bits encontram-se

espalhados por 16 vectores com endereços menores consecutivos, isto é, para uma dada tabela de

consulta, cada bit dessa tabela faz parte de um vector diferente. Esses 16 vectores contêm todos os

16 bits de uma coluna de slices de uma CLB. É pois necessário escrever ou ler os 16 vectores que

contêm esses bits, para aceder à totalidade da tabela de consulta.

Note-se que os bits nas tabelas de consulta são guardados invertidos, ao contrário do que se passa

com o valor armazenado nos flip-flops. Aquando de uma operação de escrita ou leitura numa tabela

de consulta, os dados estão negados. Por exemplo, uma porta E (conjunção lógica) de quatro

entradas tem como tabela de verdade LUT[15:0]=1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0, que será

armazenada internamente como /LUT[15:0]=0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1. Esta organização é

obviamente transparente para o funcionamento da lógica implementada pelo utilizador, que lerá o

valor lógico correcto.

3.7.5. LEITURA DOS DADOS DE CONFIGURAÇÃO

Os dados de configuração do dispositivo podem ser lidos a qualquer instante sem comprometer o

seu funcionamento, desde que tal seja permitido pela configuração presente no registo CTL. Sempre

que se processa uma operação de leitura, um vector mudo é lido primeiro que qualquer outro, como

se ilustra na Figura 3.28, pelo que deve ser incluído no número de palavras a ler do componente.

8 De recordar que cada bloco de memória se estende por quatro CLBs, pelo que o número de linhas de memória RAM em

cada coluna é igual ao número de linhas de CLBs a dividir por quatro.

Page 71: RELATÓRIO INTERCALAR DE ACTIVIDADES DO PROJECTO …purl.pt/281/1/projecto_maria/relatorio_intercalar.pdf · relatÓrio intercalar de actividades projecto pocti/33842/ese/2000 teste

Relatório intercalar de actividades - Projecto POCTI/33842/ESE/2000 71

Vector mudo (n palavras)

Vector de dados 1 (n-1 palavras)Palavramuda

Vector de dados 2 (n-1 palavras)Palavramuda

Vector de dados x (n-1 palavras)Palavramuda

Figura 3.28: Leitura de vários vectores de configuração

3.7.6. ESCRITA DOS DADOS DE CONFIGURAÇÃO

Para além da configuração inicial, as Virtex podem igualmente ser reconfiguradas, no todo ou em

parte, enquanto o dispositivo estiver em operação, desde que tal seja permitido pela configuração

presente no registo CTL. A reescrita dos mesmos dados de configuração não gera sinais transitórios,

mas a reescrita de novos dados pode conduzir ao seu aparecimento, especialmente se os valores

presentes nas tabelas de consulta, ou o encaminhamento dos sinais, forem alterados. Neste caso

todas as células lógicas, bem como as que definem o encaminhamento, podem ser colocadas num

estado de contenção, pela colocação em nível lógico 1 do sinal GHIGH_B. Aquando da escrita de

dados de configuração na memória, cada vector de dados é sempre seguido por uma palavra muda,

terminando esta operação sempre com um vector mudo, conforme se ilustra na Figura 3.29.

Vector mudo (n palavras)

Vector de dados x (n-1 palavras) Palavramuda

Vector de dados 2 (n-1 palavras) Palavramuda

Vector de dados 1 (n-1 palavras) Palavramuda

Figura 3.29: Escrita de vários vectores de configuração

3.7.7. ALTERAÇÃO DOS DADOS DE CONFIGURAÇÃO

As Virtex permitem que os dados armazenados nas células de memória das tabelas de consulta

sejam alterados através da infra-estrutura BS ou da interface do modo SelectMAP, no caso de esta

ter sido retida. A alteração dos dados em uma ou mais tabelas obriga a que todos os dados de

configuração presentes nos vectores sejam válidos, sendo que a melhor forma de garantir esta

condição é alterando configurações válidas retiradas de ficheiros de configuração, ou resultado da

leitura de componentes devidamente configurados. Note-se que um vector cobre uma coluna

inteira de slices das CLBs ou IOBs, pelo que a alteração de um bit, por exemplo o bit 0 de uma única

slice 1 de uma CLB, implica que todas as posições correspondentes ao bit 0 de todas as slice 1 dessa

coluna, sejam escritas com o mesmo comando. Como tal deve assegurar-se que, ou os dados nas

Page 72: RELATÓRIO INTERCALAR DE ACTIVIDADES DO PROJECTO …purl.pt/281/1/projecto_maria/relatorio_intercalar.pdf · relatÓrio intercalar de actividades projecto pocti/33842/ese/2000 teste

72 Teste Concorrente para Sistemas Electrónicos Reconfiguráveis

slices afectadas permanecem constantes durante o processo de leitura-alteração-reconfiguração, ou

são alterados pelo próprio processo. Um exemplo de incoerência dos dados é apresentado na

Figura 3.30. Neste caso pretendia-se alterar o valor guardado na tabela de consulta da linha 2,

coluna 3, slice 1 (L2C3.S1), de 34h para D5h. No intervalo de tempo que decorre entre a leitura e a

reescrita dos 16 vectores, o número mínimo de vectores, não contando com os vectores mudos (que

é necessário ler e reescrever para alterar a totalidade do conteúdo de uma tabela de consulta) a

tabela de consulta situada na linha 14, coluna 3, slice 1 (L14C3.S1), configurada como memória

RAM, vê o seu conteúdo alterado de C3h para 14h. Aquando da reescrita de L2C3.S1, L14C3.S1 é

igualmente reposto o valor original, C3h, perdendo-se o valor entretanto escrito. Com o objectivo

de salvaguardar tais situações, devem as tabelas de consulta configuradas como memória RAM, e

como tal passíveis de serem alteradas a qualquer instante, ocupar, dentro de uma mesma coluna,

slices com índice diferente daquelas em que se situem tabelas de consulta cujo conteúdo deva ser

reconfigurado externamente durante a operação do sistema.

Tabela de consultaL2C3.S1

34h

LUT RAML14C3.S1

C3h

Tabela de consultaL2C3.S1

34h

LUT RAML14C3.S1

14h

Tabela de consultaL2C3.S1

D5h

LUT RAML14C3.S1

C3h

Aquando da operaçãode leitura

Antes dareconfiguração Após a reconfiguração

Figura 3.30: Exemplo de conflito devido a reconfiguração parcial

3.7.8. LOCALIZAÇÃO DOS BITS NO FICHEIRO DE CONFIGURAÇÃO

A determinação da localização de um dado bit num ficheiro de configuração de uma FPGA da

família Virtex implica a definição de dois conjuntos de variáveis: um conjunto de variáveis

independentes, ou atributos do projecto, tais como o tamanho do componente e qual a CLB e,

dentro desta, o bit a localizar, ou a linha e a coluna do bloco RAM pretendido e o índice do bit

dentro do bloco; e um conjunto de variáveis dependentes, ou variáveis do projecto, nomeadamente

valores que devem ser calculados para encontrar o bit pretendido. O conjunto das variáveis

independentes encontra-se listado na Tabela 3.14 e o das variáveis dependentes na Tabela 3.15. A

Page 73: RELATÓRIO INTERCALAR DE ACTIVIDADES DO PROJECTO …purl.pt/281/1/projecto_maria/relatorio_intercalar.pdf · relatÓrio intercalar de actividades projecto pocti/33842/ese/2000 teste

Relatório intercalar de actividades - Projecto POCTI/33842/ESE/2000 73

Tabela 3.16 apresenta a definição de três funções usadas nas equações de determinação da

localização dos bits.

Termo Definição

Chip_Cols Número de colunas de CLBs do componente

Chip_Rows Número de linhas de CLBs do componente

FL Número de palavras de 32 bits num vector

RW 1 para leitura, 0 para escrita

CLB_Col Número da coluna do CLB pretendido

CLB_Row Número da linha do CLB pretendido

Slice 0 ou 1

FG 0 para a F-LUT, 1 para a G-LUT

lut_bit Bit pretendido dentro da LUT (nas LUTs os bits têm índices de 0 a 15)

XY 0 para o flip-flop X, 1 para o flip-flop Y

RAM_Col Número da coluna do bloco RAM pretendido

RAM_Row Número da linha do bloco RAM pretendido

ram_bit Bit pretendido dentro do bloco de RAM (os bits têm índices de 0 a 4095)

Tabela 3.14: Variáveis independentes

As equações que permitem calcular os valores das variáveis dependentes variam consoante se

pretenda localizar um bit situado numa tabela de consulta dum CLB, o estado dum flip-flop dum

CLB ou dum IOB, o valor actual duma porta ou um bit num bloco de memória RAM. A

Tabela 3.17 apresenta as equações para o cálculo das variáveis dependentes que permitem localizar,

num ficheiro de configuração, o bit pretendido duma tabela de consulta. As equações que permitem

localizar num ficheiro de configuração o valor correspondente ao estado dum flip-flop dum CLB são

apresentadas na Tabela 3.18.

Cada IOB possui quatro valores que podem ser capturados numa operação de leitura. Esses valores

são:

• E – Estado do flip-flop de entrada

• S – Estado do flip-flop de saída

• T – Estado do flip-flop de terceiro estado

Page 74: RELATÓRIO INTERCALAR DE ACTIVIDADES DO PROJECTO …purl.pt/281/1/projecto_maria/relatorio_intercalar.pdf · relatÓrio intercalar de actividades projecto pocti/33842/ese/2000 teste

74 Teste Concorrente para Sistemas Electrónicos Reconfiguráveis

• P – Valor actual no porto de E/S

Termo Definição

MJA Endereço maior

MNA Endereço menor

fm_st_wd Índice da palavra dentro dum ficheiro de configuração quecorresponde à palavra de início do vector desejado. Um ficheirocompleto de configuração é definido como: i) para CLB/IOB, todos osCLBs, IOBs e vectores de definição das interligações dos blocos RAMcom início em MJA=0, MNA=0 e; ii) para os blocos RAM, todo osvectores de conteúdo para uma dada coluna de RAM.

fm_wd Índice da palavra de 32 bits dentro do vector que contém o bitpretendido. A numeração das palavras dentro do vector começa emzero.

fm_wd_bit_idx Índice do bit pretendido dentro da palavra fm_wd. Ao bit mais àesquerda dentro da palavra corresponde o índice 31 e ao mais à direitao índice 0.

fm_bit_idx Índice do bit pretendido dentro do vector. A numeração dos bitscomeça em zero, correspondendo ao bit mais à esquerda, e continua aolongo de todas as palavras dentro de um vector.

Tabela 3.15: Variáveis dependentes

Função Definição

floor(x) Maior inteiro não superior a x (ex: floor(3,7)=3)

ceiling(x) Menor inteiro não inferior a x (ex: ceiling(3,7)=4)

¥ Resto da divisão (ex: 5¥2=1)

Tabela 3.16: Definição de funções

Uma vez que os IOBs do topo e do fundo do componente são parte integrante da coluna de CLBs

do ponto de vista dos vectores de configuração, a localização de bits nestes IOBs obedece a regras

diferentes das aplicáveis aos dos IOBs da esquerda e da direita, que só por si constituem colunas

autónomas. Os IOBs são numerados no sentido dos ponteiros do relógio, partindo do porto 1

situado no topo, à esquerda, por cima da coluna de CLBs mais à esquerda, conforme se ilustra na

Figura 3.31. As equações para determinação da localização no ficheiro dos bits de estado dos flip-

-flops dos IOBs são baseadas no número do porto, o qual, para um dado tamanho da FPGA, é

independente dos números dos pinos, os quais variam com o tipo de encapsulamento, e na sua

localização relativa dentro do componente. A Tabela 3.19 apresenta as equações que permitem

Page 75: RELATÓRIO INTERCALAR DE ACTIVIDADES DO PROJECTO …purl.pt/281/1/projecto_maria/relatorio_intercalar.pdf · relatÓrio intercalar de actividades projecto pocti/33842/ese/2000 teste

Relatório intercalar de actividades - Projecto POCTI/33842/ESE/2000 75

determinar qual a posição relativa do porto, enquanto a Tabela 3.20 lista as equações que permitem

obter as variáveis dependentes para os flip-flops dos IOBs. A variável n refere-se, nesta tabela, ao

número do porto.

Termo Definição

MJA

Se (CLB_Col ≤ Chip_Cols / 2),

então Chip_Cols − CLB_Col × 2 + 2

senão 2 × CLB_Col − Chip_Cols − 1

MNA lut_bit + 32 − Slice × (2 × lut_bit + 17)

fm_bit_idx 3 + 18 × CLB_Row − FG + RW × 32

fm_st_wd FL × (8 + (MJA − 1) × 48 + MNA ) + RW × FL9

fm_wd floor (fm_bit_idx / 32)

fm_wd_bit_idx 31 + 32 × fm_wd − fm_bit_idx

Tabela 3.17: Equações para a localização de bits nas tabelas de consulta

Termo Definição

MJA

Se (CLB_Col ≤ Chip_Cols / 2),

então Chip_Cols − CLB_Col × 2 + 2

senão 2 × CLB_Col − Chip_Cols − 1

MNA Slice × (12 × XY − 43) − 6 × XY + 45

fm_bit_idx (18 × CLB_Row) + 1 + (32 × RW)

fm_st_wd FL × (8 + (MJA − 1) × 48 + MNA) + RW × FL

fm_wd floor (fm_bit_idx / 32)

fm_wd_bit_idx 31 + 32 × fm_wd − fm_bit_idx

Tabela 3.18: Equações para a localização dos bits de estado dos flip-flops dos CLBs

9 A diferença na posição relativa da palavra entre leitura e escrita deve-se ao facto de que o vector mudo e a palavra muda

aparecem, respectivamente, no início e fim do ficheiro de configuração.

Page 76: RELATÓRIO INTERCALAR DE ACTIVIDADES DO PROJECTO …purl.pt/281/1/projecto_maria/relatorio_intercalar.pdf · relatÓrio intercalar de actividades projecto pocti/33842/ese/2000 teste

76 Teste Concorrente para Sistemas Electrónicos Reconfiguráveis

RAM

CLB

CLB

CLB

IOB IOB

CLB

CLB

IOB IOB IOB

IOB

IOB

IOB

IOB

IOB

IOB

IOB

IOB

IOB

Porto 1

Figura 3.31: Numeração dos portos dos IOBs

Localização do porto Índice do porto

Topo 1 ≤ n ≤ Chip_Cols × 2

Direita Chip_Cols × 2 + 1 ≤ n ≤ Chip_Cols × 2 + Chip_Rows × 3

Fundo Chip_Cols × 2 + Chip_Rows × 3 + 1 ≤ n ≤ Chip_Cols × 4 ++ Chip_Rows × 3

Esquerda Chip_Cols × 4 + Chip_Rows × 3 + 1 ≤ n ≤ Chip_Cols × 4 ++ Chip_Rows × 6

Tabela 3.19: Intervalo de localização dos portos dos IOBs em função do seu índice

As equações para localização no ficheiro dos bits correspondentes aos valores presentes nas célulasdos blocos de memória RAM encontram-se listadas na tabela Tabela 3.21.

Aplicando sobre o ficheiro resultante da leitura da configuração de uma Virtex as várias equaçõesapresentadas é possível conhecer, para o instante de amostragem, os valores presentes em cadacélula de armazenamento, independentemente de se tratar de flip-flops ou células de memória.

O desenvolvimento de software que permitisse a manipulação a um nível muito baixo dos recursosde configuração da FPGA obrigou ao estudo aturado e à realização dum conjunto de experiênciaspráticas, uma vez que por razões comerciais os fabricantes se recusam a revelar informação precisasobre a correspondência entre os bits do ficheiro de configuração e os referidos recursos. Somenteapós esse estudo foi possível partir para a construção de software que possibilitasse a automatização,senão do todo pelo menos de parte da implementação da estratégia de teste definida.

Page 77: RELATÓRIO INTERCALAR DE ACTIVIDADES DO PROJECTO …purl.pt/281/1/projecto_maria/relatorio_intercalar.pdf · relatÓrio intercalar de actividades projecto pocti/33842/ese/2000 teste

Relatório intercalar de actividades - Projecto POCTI/33842/ESE/2000 77

Termo Definição

Topo

Se (n≤Chip_Cols),

então Chip_Cols-ceiling(n/2)×2+2

senão 2×ceiling(n/2) −Chip_Cols−1

Direita Chip_Cols+1

Fundo

Se (n>3×(Chip_Cols+Chip_Rows)),

então 2×ceiling((n−3×Chip_Cols−3×Chip_Rows)/2)

senãoChip_Cols−2×floor((n−2×Chip_Cols−3×Chip_Rows−1)/2)−1

MJA

Esquerda Chip_Cols+2

E −25×(n¥2)+45

S −13×(n¥2)+39

T −5×(n¥2)+35Topo

P −4×(n¥2)+25

E t=(n−2×Chip_Cols)¥3; MNA=27,5×t2−57,5×t+32

S t=(n−2×Chip_Cols)¥3; MNA=21,5×t2−51,5×t+38

T t=(n−2×Chip_Cols)¥3; MNA=17,5×t2−47,5×t+42Direita

P 50

E 25×((n−2×Chip_ Cols −3×Chip_Rows)¥2)+20

S 13×((n−2×Chip_ Cols −3×Chip_Rows)¥2)+26

T 5×((n−2×Chip_ Cols −3×Chip_Rows)¥2)+30Fundo

P 4×((n−2×Chip_ Cols −3×Chip_Rows)¥2)+21

E t=(n−4×Chip_Cols−3×Chip_Rows)¥3;MNA=17,5×t2−47,5×t+45

S t=(n−4×Chip_Cols−3×Chip_Rows)¥3;MNA=23,5×t2−53,5×t+39

T t=(n−4×Chip_Cols−3×Chip_Rows)¥3;MNA=27,5×t2−57,5×t+35

MNA

Esquerda

P 50

fm_bit_idx Topo 32×RW

Page 78: RELATÓRIO INTERCALAR DE ACTIVIDADES DO PROJECTO …purl.pt/281/1/projecto_maria/relatorio_intercalar.pdf · relatÓrio intercalar de actividades projecto pocti/33842/ese/2000 teste

78 Teste Concorrente para Sistemas Electrónicos Reconfiguráveis

E, S eT 18×(1+floor((n−2×Chip_Cols−1)/3))+32×RW

Direita

P

t=(n−2×Chip_Cols)¥3;

fm_bit_idx=18×(1+floor((n−2×Chip_Cols−1)/3))+6×t2--17×t+15+32×RW

Fundo 18×(Chip_Rows+1)+32×RW

E, S eT

18×(Chip_Rows−floor((n−4×Chip_Cols-- 3×Chip_Rows−1)/3))+32×RW

Esquerda

P

t=(n−4×Chip_Cols−3×Chip_Rows)¥3;

fm_bit_idx=18×(Chip_Rows−floor((n−4×Chip_Cols−3×× Chip_Rows−1)/3)) −10,5×t2+21,5×t+4+32×RW

fm_st_wd

Se (MJA>Chip_Cols+1),

entãoFL×(54×MJA−46+MNA−6×Chip_Cols)+RW×FL

senão FL×(8+(MJA−1)×48+MNA)+RW×FL

fm_wd floor(fm_bit_idx/32)

fm_wd_bit_idx 31+32×fm_wd−fm_bit_idx

Tabela 3.20: Equações para a localização dos bits de estado dos flip-flops dos IOBs

Termo Definição

MJA RAM_Col

MNA

1×floor(((ram_bit/64)¥64)/32)++2×floor(((ram_bit/64)¥32)/16)++4×floor(((ram_bit/64)¥16)/8)++8×floor(((ram_bit/64)¥8)/4)++16×floor(((ram_bit/64)¥4)/2)++32×floor(((ram_bit/64)¥2)/1)

fm_bit_idx 18+72×RAM_Row+bitpos (ver bitpos na Tabela 3.22)

fm_st_wd FL×MNA+RW×FL

fm_wd floor(fm_bit_idx/32)

fm_wd_bit_idx 31+32×fm_wd−fm_bit_idx

Tabela 3.21: Equações para a localização dos valores presentes nas células dos blocos de memória

Page 79: RELATÓRIO INTERCALAR DE ACTIVIDADES DO PROJECTO …purl.pt/281/1/projecto_maria/relatorio_intercalar.pdf · relatÓrio intercalar de actividades projecto pocti/33842/ese/2000 teste

Relatório intercalar de actividades - Projecto POCTI/33842/ESE/2000 79

3.8. REQUISITOS DO SOFTWARE DESENVOLVIDO

O programa desenvolvido, denominado Device Programmer, permite a programação sequencial de

vários ficheiros de reconfiguração parcial ou total de forma dinâmica, isto é, sem que a operação da

FPGA seja interrompida, usando o modo boundary-scan de configuração. A execução deste

programa, que foi implementado em linguagem Java, necessita do ambiente Java 2 Runtime

Environment (JRE) [7], versão 1.3. O Device Programmer é baseado em classes da API (Application

Program Interface) JBits, versão 2.7, que possibilita o desenvolvimento de aplicações baseadas em linguagem

Java capazes de manipular directamente os ficheiros de configuração, em formato binário, das FPGAs da

família Virtex da Xilinx, quer estes tenham sido gerados pelas ferramentas de apoio ao projecto da Xilinx,

através do programa Bitgen, quer tenham sido modificados por ferramentas baseadas no próprio JBits. O JBits

faz parte do pacote de software JBits Software Development Kit da Xilinx.

ram

_bit¥

64

bitp

os

ram

_bit¥

64

bitp

os

ram

_bit¥

64

bitp

os

ram

_bit¥

64

bitp

os

ram

_bit¥

64

bitp

os

ram

_bit¥

64

bitp

os

ram

_bit¥

64

bitp

os

ram

_bit¥

64

bitp

os

0 42 8 45 16 29 24 26 32 43 40 44 48 28 56 27

1 58 9 61 17 13 25 10 33 59 41 60 49 12 57 11

2 41 10 46 18 30 26 25 34 40 42 47 50 31 58 24

3 57 11 62 19 14 27 9 35 56 43 63 51 15 59 8

4 50 12 53 20 21 28 18 36 51 44 52 52 20 60 19

5 49 13 54 21 22 29 17 37 48 45 55 53 23 61 16

6 66 14 69 22 5 30 2 38 67 46 68 54 4 62 3

7 65 15 70 23 6 31 1 39 64 47 71 55 7 63 0

Tabela 3.22: Posição do bit dentro de um dado bloco de memória

3.9. DESENVOLVIMENTO DO SOFTWARE DE PROGRAMAÇÃO

A aplicação Device Programmer foi dividida em duas partes, correspondentes a duas componentes

distintas mas interligáveis:

1. A componente de interface com o hardware;

2. A componente de interface com o utilizador.

Page 80: RELATÓRIO INTERCALAR DE ACTIVIDADES DO PROJECTO …purl.pt/281/1/projecto_maria/relatorio_intercalar.pdf · relatÓrio intercalar de actividades projecto pocti/33842/ese/2000 teste

80 Teste Concorrente para Sistemas Electrónicos Reconfiguráveis

Estas duas componentes foram desenvolvidas de forma independente, tendo como base de

interligação uma série de funções normalizadas. É pois possível a construção duma vasta variedade

de componentes de ambos os tipos, interligados posteriormente de forma a possibilitar que vários

tipos de programas interajam com diferentes géneros de hardware e vice-versa.

No caso especifico desta aplicação, foi construído um interface com o utilizador que permite

programar uma Virtex com um ficheiro de configuração total ou parcial, e ler a actual configuração

da Virtex, transcrevendo-a para um ficheiro. De igual forma desenvolveram-se dois interfaces com o

hardware, permitindo programação da FPGA usando recursos distintos − a porta paralela dum

computador pessoal e uma placa de interface entre um barramento de instrumentação PXI (PCI −

Peripheral Component Interconnect − eXtensions for Instrumentation) e uma porta de teste IEEE

1149.1. Cada um dos recursos é seleccionável a partir do interface com o utilizador.

3.10. INTERFACE COM O HARDWARE

O interface com o hardware foi desenvolvido tendo por base uma interface normalizada XHWIF

(Xilinx standard HardWare InterFace) desenvolvida especificamente para a comunicação com

FPGAs da Xilinx. Esta escolha pretende garantir a portabilidade do software, que será executável

em qualquer sistema que implemente este interface. Desta forma, ferramentas como o JBits podem

ser utilizadas com qualquer sistema sem que para tal seja necessário proceder a alterações, pelo que

mover esta ferramenta, ou outras aplicações semelhantes, para um novo hardware, torna-se uma

tarefa bastante simplificada. Outra das características desta interface é a sua flexibilidade e o

elevado nível de abstracção relativamente à camada de hardware, fornecendo o suporte para o

acesso dinâmico a interfaces de hardware. Isto significa que para que novo hardware possa ser

suportado, basta adicionar uma interface XHWIF para esse hardware, passando as aplicações

existentes a poderem usar o novo hardware sem modificação ou recompilação. Esta interface inclui

métodos para ler e escrever dados de configuração numa FPGA, e para descrição da carta, incluindo

número e referência da FPGA(s) presente(s) no hardware reconfigurável ligado ao sistema. Estão

igualmente disponíveis métodos para o envio de impulsos de relógio e para ler e escrever em

circuitos de memória eventualmente presentes na mesma placa, os quais possuam infra-estrutura de

teste IEEE 1149.1 e possibilidade de configuração no circuito através dessa interface.

O interface XHWIF normaliza a forma como a aplicação comunica com o hardware, de modo que

uma única aplicação possa controlar uma variedade de cartas. Toda a informação específica do

Page 81: RELATÓRIO INTERCALAR DE ACTIVIDADES DO PROJECTO …purl.pt/281/1/projecto_maria/relatorio_intercalar.pdf · relatÓrio intercalar de actividades projecto pocti/33842/ese/2000 teste

Relatório intercalar de actividades - Projecto POCTI/33842/ESE/2000 81

hardware está embebida dentro da classe que implementa o interface XHWIF. Utilizando o JNI10,

que permite que programas desenvolvidos em Java interajam com programas em C, chamadas ao

interface são convertidas em chamadas ao controlador da placa. Esta metodologia liberta a

aplicação de comunicar directamente com o controlador ou com o barramento. Desta forma, ao

esconder-se a informação específica sobre o controlador e o barramento na classe que implementa o

interface XHWIF, permite-se que as aplicações comuniquem com as placas ligadas por qualquer

barramento ou porta de comunicação, sejam eles PCI, ISA ou outra qualquer norma. O controlador

implementa as operações de interacção com o barramento, sendo apenas necessário criar um novo

interface XHWIF, para se poder ligar uma nova placa à aplicação.

O interface XHWIF é constituído por dois blocos distintos que requerem a definição de alguns

parâmetros. O primeiro é o código de descrição da placa, que indica ao XHWIF quais são os

dispositivos e o seu tipo de encapsulamento. O segundo bloco é um conjunto de métodos nativos,

funções descritas em Java implementadas por funções escritas em linguagem C, disponíveis em

bibliotecas externas. A comunicação entre a classe de Java do XHWIF e as bibliotecas externas é

efectuada através do JNI. A implementação dos métodos nativos na biblioteca externa corresponde

à maior parte do trabalho na implementação de um interface XHWIF.

3.10.1. DESCRIÇÃO DA PLACA

A descrição da placa no XHWIF requer apenas alguma informação básica, como o número de

FPGAs presentes, a sua sequência, a referência e o tipo de encapsulamento de cada uma. As FPGAs

serão posteriormente referenciadas internamente pelo XHWIF por uma ordem numérica,

começando no valor zero. Na construção da classe de Java do XHWIF, onde é efectuada a descrição

do hardware, utiliza-se uma classe modelo presente no JBits, sendo apenas necessário definir os

parâmetros especificados anteriormente, bem como alterar o seu nome de forma a melhor

identificar esse hardware. O restante conteúdo está normalizado, sendo desaconselhado que se

proceda a alterações profundas, sob pena de perda de portabilidade.Com base nestes pressupostos

foi criada uma classe Java, denominada XCV200, onde foram definidos os seguintes parâmetros

respeitantes ao hardware do protótipo referido no capítulo anterior:

• Número de FPGAs − 1

• Referência da FPGA − Virtex XCV200

10 O JNI (Java Native Interface) é um interface de programação nativo. Permite que código em Java, que corre dentro da

Java Virtual Machine, se interligue com aplicações e bibliotecas escritas noutras linguagens de programação, como C,C++ e Assembly.

Page 82: RELATÓRIO INTERCALAR DE ACTIVIDADES DO PROJECTO …purl.pt/281/1/projecto_maria/relatorio_intercalar.pdf · relatÓrio intercalar de actividades projecto pocti/33842/ese/2000 teste

82 Teste Concorrente para Sistemas Electrónicos Reconfiguráveis

• Tipo de encapsulamento − BG352 (Ball Grid array).

3.10.2. MÉTODOS NATIVOS DE XHWIF

Após a descrição da carta procede-se à implementação dos métodos nativos descritos na classe

construída. Estes métodos são funções de baixo nível, dependentes do sistema em que são

definidos, as quais fornecem acesso ao hardware. Os métodos nativos a implementar, tal como estão

definidos na classe Java modelo que acompanha o JBits, são os seguintes:

• public native int customConnect(); − activa a ligação do sistema anfitrião ao hardware;

• public native int customDisconnect(); − desactiva a ligação do sistema anfitrião ao hardware;

• public native int customGetSystemInfo(int data[], int length); − retorna informação sobre a

placa de hardware; esta informação encontra-se na DLL e não no hardware e é colocada pelo

programador11;

• public native int customReset(); − efectua uma inicialização da memória de configuração (este

método não se encontra implementado, pois não é possível efectuar a inicialização dos

componentes através do TAP);

• public native int customSetClockFrequency(float frequency); − permite ajustar a frequência do

relógio da FPGA (este método não se encontra implementado, pois não é possível efectuar este

ajuste através da infra-estrutura de teste, pelo que a frequência é fixa);

• public native int customClockOn(); − activa o relógio da FPGA;

• public native int customClockOff(); − desactiva o relógio da FPGA;

• public native int customClockStep(int count); − gera n impulsos de relógio da FPGA (este

método não se encontra implementado, pois não é possível efectuar este controlo através da

infra-estrutura de teste, pelo que a frequência é fixa);

• public native int customGetConfiguration(int device, byte data[], int length); − retorna a

configuração actual da FPGA, total ou parcial;

• public native int customSetConfiguration(int device, byte data[], int length); − permite o envio

da configuração para a FPGA, total ou parcial;

11 Refere-se ao conteúdo do registo de identificação do componente, programado pelo utilizador, acessível através da

infra-estrutura de teste.

Page 83: RELATÓRIO INTERCALAR DE ACTIVIDADES DO PROJECTO …purl.pt/281/1/projecto_maria/relatorio_intercalar.pdf · relatÓrio intercalar de actividades projecto pocti/33842/ese/2000 teste

Relatório intercalar de actividades - Projecto POCTI/33842/ESE/2000 83

• public native int customGetRAM(int address, byte data[], int length); − retorna o conteúdo dos

blocos de RAM interna da FPGA (este método não se encontra implementado);

• public native int customSetRAM(int address, byte data[], int length); − permite a programação

dos blocos de RAM interna da FPGA (este método não se encontra implementado).

A implementação da totalidade dos métodos nativos descritos é obrigatória, embora, por

condicionalismos de hardware ou por falta de interesse no seu uso numa determinada situação,

possam simplesmente invocar uma função que retorne um código de erro, caso sejam executados.

Outro parâmetro de definição obrigatória na classe XCV200, é o nome da biblioteca externa que

implementa os métodos nativos. Designou-se esta biblioteca XCV200.dll, nome idêntico ao da

classe, para facilitar a associação dos ficheiros.

3.10.3. IMPLEMENTAÇÃO DOS MÉTODOS NATIVOS

O sistema operativo sobre o qual a aplicação foi desenvolvida é o Windows da Microsoft, pelo que a

implementação dos métodos nativos descritos anteriormente foi efectuada através de uma DLL12.

Esta DLL é desenvolvida usando as linguagens de programação C e C++, sendo a interligação

entre ela e a classe de Java desenvolvida anteriormente assegurada pelo uso do JNI. Mais

pormenores sobre a implementação duma interface XHWIF podem ser encontrados na

documentação que acompanha o JBits.

As DLLs são implementações de baixo nível intimamente dependentes do hardware, pelo que, para

as duas interfaces com o hardware desenvolvidas, criam-se DLLs específicas. As interfaces

desenvolvidas são:

• ligação através da porta paralela dum computador;

• ligação através dum controlador de Boundary Scan para barramento PXI da Goepel [8].

No primeiro caso, a comunicação com a placa de protótipo é efectuada através da porta paralela do

computador, utilizando um cabo de interface, o Parallel Download Cable III da Xilinx. Do lado da

placa a porta de entrada é o TAP da infra-estrutura Boundary Scan. O acesso directo da aplicação

desenvolvida em C/C++ à porta paralela, possibilitando a escrita e leitura de dados na porta, é

12 Uma biblioteca de ligação dinâmica, DLL, do inglês Dynamic Link Library, é uma colecção de pequenos programas, em

que qualquer um deles pode ser chamado quando necessário por outro programa que esteja a ser executado. FicheirosDLL que suportam operações específicas com dispositivos são conhecidos por controladores de dispositivos (devicedrivers). Uma vez que estes ficheiros só são carregados na memória do computador quando o programa a que estãoassociados os invoca, não ocupam espaço permanente em memória.

Page 84: RELATÓRIO INTERCALAR DE ACTIVIDADES DO PROJECTO …purl.pt/281/1/projecto_maria/relatorio_intercalar.pdf · relatÓrio intercalar de actividades projecto pocti/33842/ese/2000 teste

84 Teste Concorrente para Sistemas Electrónicos Reconfiguráveis

efectuado com recurso a um programa específico, o DriverLINX Port I/O da Scientific Software

Tools, Inc. .

No segundo caso, a comunicação é efectuada através dum controlador de Boundary Scan para

barramento PXI da Goepel, que se interliga directamente ao TAP da FPGA, possibilitando

velocidades de transmissão mais elevadas que as possíveis no caso do uso da porta paralela dum

computador. A Figura 3.32 ilustra o fluxo da comunicação entre a aplicação desenvolvida e o

hardware. Os dois ramos correspondem aos dois tipos de interface com o hardware − a porta

paralela e a placa de interface com o barramento de instrumentação PXI.

DLL(XCV200.dll)

DLLPorta paralela

(DriverLINX Port I/O )

Porta paralela PXI

XHWIF(XCV200_Goepel)

XHWIF(XCV200)

DLL(XCV200_goepel.dll)

DLLPXI (Goepel)

Device Programmer(Aplicação em JAVA)

JNIJNI

Figura 3.32: Diagrama de fluxo da comunicação entre a aplicação e o hardware

3.11. GERAÇÃO DO FICHEIRO DE CONFIGURAÇÃO

O programa Bitgen do pacote de ferramentas de desenvolvimento Foundation da Xilinx [9] permite a

geração de ficheiros de configuração total para os dispositivos da família Virtex. Das várias opções

permitidas para a criação desse ficheiro as que obrigatoriamente têm de ser seleccionadas para o

correcto funcionamento do Device Programmer são a escolha do modo de configuração, boundary

scan, e a opção de permissão de leitura. Desta forma o comando de invocação do programa Bitgen

deve incluir as opções:

Bitgen -g StartUpClk:JTAGCLK -g persist:yes - g Readback

Page 85: RELATÓRIO INTERCALAR DE ACTIVIDADES DO PROJECTO …purl.pt/281/1/projecto_maria/relatorio_intercalar.pdf · relatÓrio intercalar de actividades projecto pocti/33842/ese/2000 teste

Relatório intercalar de actividades - Projecto POCTI/33842/ESE/2000 85

Está fora do âmbito deste relatório uma explicação mais aprofundada sobre o processo de criação

dum ficheiro de configuração (para tal consultar [3]. Desde que as opções referidas estejam activas

o ficheiro gerado é compatível com o funcionamento do Device Programmer.

3.12. INTERFACE COM O UTILIZADOR

A ferramenta Device Programmer disponibiliza um meio simples de configurar uma Virtex através da

infra-estrutura Boundary Scan, sendo possível carregar sequencialmente várias configurações

parciais diferentes de forma dinâmica, isto é, sem interromper o funcionamento da FPGA. O

programa permite igualmente ler, a qualquer instante, a configuração actualmente presente na

FPGA, transcrevendo o seu conteúdo para um ficheiro. O programa pode ser dividido em quatro

módulos:

1. selecção do hardware;

2. envio da configuração inicial;

3. envio de reconfigurações parciais;

4. leitura da configuração.

3.12.1. SELECÇÃO DO HARDWARE

No primeiro módulo, o de selecção do hardware, o utilizador é interrogado sobre qual as

características do sistema a programar. A Figura 3.33 mostra a janela inicial do programa, onde é

efectuada a selecção da interface de configuração, e a Figura 3.34 a janela de selecção do dispositivo

presente na placa.

Uma vez seleccionada a interface e o dispositivo a programar, o programa carrega a respectiva

interface XHWIF e a DLL correspondente na memória, ficando apto a transmitir dados para a

memória de configuração da FPGA. A verificação do correcto funcionamento do canal usado para a

transmissão da informação entre o computador e o sistema a configurar será efectuado de forma

automática pelo interface XHWIF, encontrando-se neste momento em desenvolvimento a sua

implementação.

A detecção de erros é um dos problemas que se levanta na ligação do programa com o interface,

uma vez que o código de sucesso na transmissão é normalizado, mas o significado dos códigos de

erros não. Desta forma, o programa apresentará eventualmente mensagens de erro incorrectas no

caso de se usarem interfaces XHWIF não desenvolvidas tendo como base os códigos de erro

definidos durante o seu desenvolvimento, o que é um entrave na portabilidade dos programas. Este

Page 86: RELATÓRIO INTERCALAR DE ACTIVIDADES DO PROJECTO …purl.pt/281/1/projecto_maria/relatorio_intercalar.pdf · relatÓrio intercalar de actividades projecto pocti/33842/ese/2000 teste

86 Teste Concorrente para Sistemas Electrónicos Reconfiguráveis

facto não impede a utilização de outros XHWIFs que não foram criados especificamente para este

programa, devendo o utilizador estar consciente que a mensagem de erro poderá não corresponder

ao tipo de erro ocorrido. A classe Virtexprogrammer é responsável pela implementação deste e dos

restantes módulos da interface com o utilizador. Esta classe contém todos os métodos responsáveis

pela execução das ordens que o utilizador tem à sua disposição no interface gráfico. Estes métodos

irão por sua vez chamar os métodos presentes no interface XHWIF de modo a executar a função

pretendida.

Figura 3.33: Janela de selecção da interface de configuração

3.12.2. CONFIGURAÇÃO INICIAL

O segundo módulo, envio da configuração inicial, é responsável por, após estabelecida a ligação

com o hardware, carregar um ficheiro de configuração, que obrigatoriamente é um ficheiro de

configuração total, na memória de configuração da FPGA. Para executar esta operação é necessário

seleccionar primeiro o ficheiro a usar, iniciando o programa automaticamente o seu carregamento,

conforme ilustrado na Figura 3.35. A aplicação começa por inicializar três objectos da classe JBits,

correspondentes à referência escolhida anteriormente segundo a informação fornecida pela

interface XHWIF, que implementam as três possibilidades indicadas anteriormente: configuração

total, configuração parcial e leitura da configuração actual. A classe JBits define um interface de

programação com uma dada FPGA, providenciando um modelo para controlar todos os seus

Page 87: RELATÓRIO INTERCALAR DE ACTIVIDADES DO PROJECTO …purl.pt/281/1/projecto_maria/relatorio_intercalar.pdf · relatÓrio intercalar de actividades projecto pocti/33842/ese/2000 teste

Relatório intercalar de actividades - Projecto POCTI/33842/ESE/2000 87

recursos. O ficheiro de configuração seleccionado é então carregado para esses objectos que,

posteriormente, usando as funções do XHWIF, configuram essa informação na FPGA.

Figura 3.34: Janela de selecção da referência do dispositivo a configurar

Figura 3.35: Carga do programa inicial de configuração

Page 88: RELATÓRIO INTERCALAR DE ACTIVIDADES DO PROJECTO …purl.pt/281/1/projecto_maria/relatorio_intercalar.pdf · relatÓrio intercalar de actividades projecto pocti/33842/ese/2000 teste

88 Teste Concorrente para Sistemas Electrónicos Reconfiguráveis

3.12.3. RECONFIGURAÇÕES PARCIAIS

Após a configuração inicial ter sido concluída com sucesso pode-se proceder à reconfiguração de

partes da FPGA de forma dinâmica, isto é, sem interromper o seu funcionamento. Para tal,

seleccionam-se os ficheiros de configuração que se pretendem carregar, inserindo-os numa lista, e

colocando-os pela ordem pretendida. Os ficheiros de configuração podem ser totais ou parciais,

embora o que é transferido para a memória de configuração da FPGA seja sempre o ficheiro

diferença entre o que se pretende carregar e a configuração actualmente implementada, cuja versão

actualizada é mantida pelo programa, isto partindo do princípio de que todas as alterações de

configuração foram efectuadas pelo programa e que não ocorreu qualquer erro.

O ficheiro de configuração seleccionado, da lista de ficheiros carregados, é comparado com o

ficheiro existente em memória, sendo gerada uma matriz diferença, residente em memória,

contendo os vectores que sofrem alteração, os quais são transferidos para a FPGA, segundo o

formato visto no sub-capítulo dedicado ao endereçamento e conteúdo do espaço de configuração.

Durante a sequência da matriz diferença o programa recorre a dois objectos JBits inicializados

previamente, um com a configuração actual e outro com o ficheiro de configuração seleccionado,

efectuando-se depois a comparação entre as configurações presentes nos dois objectos. Todos os

vectores que diferirem entre as duas configurações são marcados e posteriormente configurados na

FPGA através da função de configuração da interface XHWIF. Por fim, é actualizado, em função

das alterações detectadas, o objecto que preserva a configuração actual, ficando disponível para a

próxima reconfiguração.

As reconfigurações podem efectuar-se segundo três modos:

• passo−a−passo;

• em ciclo;

• contínuo.

No modo passo−a−passo, sempre que o botão “Next” na interface gráfica com o utilizador é

pressionado, o ficheiro seguinte na lista de configuração é carregado, sendo que quando o fim da

lista é atingido a sequência retorna ao início. A Figura 3.36 ilustra o aspecto da interface gráfica

com o modo passo−a−passo seleccionado. No modo ciclo a lista é percorrida um determinado

número de vezes, enquanto que no modo contínuo é percorrida repetidamente até que o utilizador

interrompa o processo.

Page 89: RELATÓRIO INTERCALAR DE ACTIVIDADES DO PROJECTO …purl.pt/281/1/projecto_maria/relatorio_intercalar.pdf · relatÓrio intercalar de actividades projecto pocti/33842/ese/2000 teste

Relatório intercalar de actividades - Projecto POCTI/33842/ESE/2000 89

Figura 3.36: Interface gráfica com o modo de reconfiguração passo−a−passo seleccionado

3.12.4. LEITURA DA CONFIGURAÇÃO

Em qualquer momento, após a configuração inicial ter sido efectuada, pode-se ler a configuração

actual da FPGA e guardá-la num ficheiro. Usando a função de leitura da interface XHWIF, é

efectuada uma leitura da configuração actual da FPGA, a qual é armazenada num terceiro objecto

JBits inicializado anteriormente. A partir desse momento é possível salvar essa configuração para

um ficheiro de configuração total, ou então comparar essa informação com a que foi previamente

carregada. Esta última funcionalidade ainda não se encontra implementada.

Este capítulo abordou sobretudo os aspectos ligados à implementação prática da solução proposta

no capítulo anterior, permitindo a sua validação. No próximo capítulo dar-se-á conta das acções de

formação e de disseminação de resultados empreendidas no âmbito do projecto.

Page 90: RELATÓRIO INTERCALAR DE ACTIVIDADES DO PROJECTO …purl.pt/281/1/projecto_maria/relatorio_intercalar.pdf · relatÓrio intercalar de actividades projecto pocti/33842/ese/2000 teste

90 Teste Concorrente para Sistemas Electrónicos Reconfiguráveis

Referências bibliográficas:

[1] The Xilinx JBits SDK para as Virtex está disponível como Limited Distribution Release. Paracolocar questões ou obter uma cópia do programa: [email protected]

[2] Virtex 2.5V Field Programmable Gate Arrays, Product Specification, Xilinx The ProgrammableLogic Data Book, versão 2.5, 2 de Abril de 2001. Disponível em http://www.xilinx.com/

[3] Virtex FPGA Series Configuration and Readback, Xilinx Application Note 138, versão 2.3, 4 deOutubro de 2000. Disponível em http://www.xilinx.com/

[4] Colin M. Maunder, Rodham E. Tulloss, “An Introduction to the Boundary Scan Standard:ANSI/IEEE Std. 1149.1”, Journal of Electronic Testing: Theory and Applications (JETTA), Vol. 2,Kluwer Academic Publishers, Boston, 1991, pp. 27-42.

[5] IEEE Standard Test Access Port and Boundary Scan Architecture (IEEE Std 1149.1), IEEEStd. Board, Maio de 1990.

[6] Configuration and Readback of Virtex FPGAs Using (JTAG) Boundary-Scan, XilinxApplication Note 139, versão 1.2, 18 de Fevereiro de 2000. Disponível emhttp://www.xilinx.com/

[7] “The Source for Java(TM) Technology”. Disponível em http://java.sun.com/

[8] PXI 1149.1 Boundary Scan Controller da GOEPEL electronic GmbH. Mais nformaçãodisponível em http://www.goepel.com/eng/bsc/bscanfr.html

[9] Foundation Series Software, Xilinx Development System. Xilinx The Programmable Logic DataBook. Disponível em http://www.xilinx.com/

Page 91: RELATÓRIO INTERCALAR DE ACTIVIDADES DO PROJECTO …purl.pt/281/1/projecto_maria/relatorio_intercalar.pdf · relatÓrio intercalar de actividades projecto pocti/33842/ese/2000 teste

Relatório intercalar de actividades - Projecto POCTI/33842/ESE/2000 91

4.ACÇÕES DE FORMAÇÃO E DE DISSEMINAÇÃO DE RESULTADOS

Uma das partes importantes de qualquer projecto de investigação é, sem dúvida, o impacto que esse

projecto tem, quer a nível dos conhecimentos gerados, quer da sua divulgação. Desta forma,

reveste-se de carácter essencial não só as acções de formação resultantes do desenrolar do projecto

e servindo de apoio a este, mas também as actividades de divulgação dos resultados alcançados no

próprio projecto. Daí a maior importância da interacção entre os membros do projecto e outros

especialistas de renome na área, quer como forma de colher experiências que possam

proveitosamente ser integradas no projecto, quer como meio para vislumbrar novas áreas de

aplicação ou áreas em aberto que o desenvolvimento do projecto possa cobrir, quer também como

modo de validar os próprios resultados do projecto. Por tal, paralelamente ao projecto, foram

realizadas várias acções de formação e divulgação, de que a seguir se dá conta.

4.1. ACÇÕES DE FORMAÇÃO

No âmbito deste projecto foi convidado para proferir um seminário na Faculdade de Engenharia da

Universidade do Porto, subordinada ao tema “Metodologias de Teste para FPGAs”, o Professor

Charles Eugene Stroud do Dept. of Electrical & Computer Engineering da University of North Carolina

at Charlotte, Estados Unidos da América13. O contacto e posterior convite ao Prof. Charles Stroud

surgiu depois dum primeiro encontro ocorrido aquando da apresentação do trabalho desenvolvido

neste projecto, e de que se dá conta na secção seguinte, no decorrer da 7th IEEE On-Line Testing

Workshop (IOLTW'01), que se realizou em Giardini Naxos - Taormina, Itália, em Julho de 2001.

O Prof. Charles Stroud é detentor dum extenso currículo com raízes na investigação a nível

industrial e posterior continuação em actividades de docência, do qual se transcreve um breve

resumo enviado pelo próprio.

Charles E. Stroud received his B.S. and M.S. degrees in Electrical Engineering from the University of

Kentucky in 1976 and 1977, respectively. He then joined AT&T Bell Laboratories in Naperville, IL,

where he worked for 15 years. His primary areas of experience were in digital circuit board and VLSI

design, CAD tool development, and digital VLSI testing and diagnosis. He designed 21 VLSI devices

and 3 printed circuit boards (which incorporated many VLSI devices and FPGAs) for telephone

switching systems and computers. He developed CAD tools for behavioral model synthesis of VLSI

13 A página do Professor Charles Stroud, na qual se pode encontrar uma descrição detalhada da sua actividade, encontra-

-se disponível no endereço http://www.coe.uncc.edu/~cestroud/

Page 92: RELATÓRIO INTERCALAR DE ACTIVIDADES DO PROJECTO …purl.pt/281/1/projecto_maria/relatorio_intercalar.pdf · relatÓrio intercalar de actividades projecto pocti/33842/ese/2000 teste

92 Teste Concorrente para Sistemas Electrónicos Reconfiguráveis

devices and PLD/FPGA based circuit boards, automatic implementation of BIST approaches in VLSI

devices, and timing and fault simulation and analysis. He received the AT&T Bell Laboratories

Distinguished Member of Technical Staff Award in 1987, Best Technical Paper Award at the 1988

ACM/IEEE Design Automation Conference, and 9 U.S. patents for various BIST techniques for VLSI

and FPGAs. While working at Bell Labs, he received his Ph.D. in Electrical Engineering & Computer

Science from the University of Illinois at Chicago in 1991 (dissertation topic: Majority Voting Based

Fault and Defect Tolerance in VLSI and WSI). He left Bell Labs in 1993 to join the faculty in the

Dept. of Electrical Engineering at the University of Kentucky where he developed a VLSI design and

testing curriculum and research program which included FPGA design and testing. In July of 2000, he

joined the Department of Electrical & Computer Engineering at the University of North Carolina at

Charlotte where he is director of the VLSI-FPGA Design and Test Laboratory. Charles is a member of

Eta Kappa Nu, Tau Beta Pi, and a Senior Member of IEEE. He has served on the Technical Program

Committees for IEEE International Test Conference (3 years as BIST topic coordinator), ACM/IEEE

International Workshop for Hardware-Software Co-Design (2 years as Publications Chair), IEEE

International Application Specific Integrated Circuits Conference (3 years), IEEE International On-

Line Test Workshop (4 years), ACM International Field Programmable Gate Array Symposium (1

year), the Design for Testability Editor of IEEE Design and Test of Computers (for 4 years) and

Associate Editor for IEEE Transactions on VLSI Ssytems (for 2 years). He has authored/co-authored

over 100 journal and conference papers, primarily in the area of design and testing of VLSI and FPGA

devices and systems. He has received 6 teaching awards and has been awarded at total of over $3.5

million in 15 research grants in the area of design and testing of VLSI and FPGA devices from NSF,

DARPA, US Air Force, US Army, AT&T, Lucent Technologies, Agere Systems, and Cypress

Semiconductor.

A permanência do Prof. Charles Stroud em Portugal estendeu-se por quatro dias, durante os quais,

para além do dia dedicado ao seminário, este investigador contribuiu com os seus valiosos

conhecimentos para uma enriquecedora troca de experiências, que permitiu abrir novos horizontes

para o desenvolvimento deste projecto.

O seminário, que contou com a participação dum público bastante interessado, proveniente não só

do meio académico mas também científico e industrial, estendeu-se por quatro horas, incluindo

uma interessante exposição teórica, acompanhada de duas demonstrações práticas do trabalho

desenvolvido pelo Prof. Charles Stroud nos últimos anos. A Figura 4.1 ilustra um dos momentos

iniciais do seminário, vendo-se sobre a mesa a placa de demonstração.

Page 93: RELATÓRIO INTERCALAR DE ACTIVIDADES DO PROJECTO …purl.pt/281/1/projecto_maria/relatorio_intercalar.pdf · relatÓrio intercalar de actividades projecto pocti/33842/ese/2000 teste

Relatório intercalar de actividades - Projecto POCTI/33842/ESE/2000 93

O cartaz de divulgação do seminário, de que se junta um exemplar em anexo, foi difundido pelas

escolas de ensino superior e centros de investigação, bem como por algumas empresas industriais da

área da electrónica e das telecomunicações.

4.2. DISSEMINAÇÃO DE RESULTADOS

O sucesso que o trabalho realizado tem obtido junto da comunidade científica da área em que se

insere, traduz-se na sua aceitação para apresentação em conferências internacionais bem

conhecidas, com comité de avaliação prévio, e no convite para apresentação nas Jornadas

Científicas do Instituto Superior de Engenharia do Instituto Politécnico do Porto. As cópias dos

artigos listados são apresentadas em anexo.

Figura 4.1: Um dos momentos da palestra proferida pelo Prof. Charles Stroud

• Manuel G. Gericota, Gustavo R. Alves, José M. Ferreira, “Dynamically Rotate And Free for

Test: The Path for FPGA Concurrent Test”, 2nd IEEE Latin-American Test Workshop

(LATW’2001) Digest of Papers, Cancun, México, Fevereiro de 2001, pp. 180-185

• Manuel G. Gericota, Gustavo R. Alves, Miguel L. Silva, José M. Ferreira, “Testando...”, 2ª

Jornadas Científicas do ISEP, Porto, Portugal, Maio de 2001

Page 94: RELATÓRIO INTERCALAR DE ACTIVIDADES DO PROJECTO …purl.pt/281/1/projecto_maria/relatorio_intercalar.pdf · relatÓrio intercalar de actividades projecto pocti/33842/ese/2000 teste

94 Teste Concorrente para Sistemas Electrónicos Reconfiguráveis

• Manuel G. Gericota, Gustavo R. Alves, Miguel L. Silva, José M. Ferreira, “DRAFT: A Scanning

Test Methodology for Dynamic and Partially Reconfigurable FPGAs”, IEEE European Test

Workshop (ETW’2001) Informal Digest, Saltsjöbaden, Stockolm, Suécia, Maio-Junho de 2001,

pp. 113-115

• Manuel G. Gericota, Gustavo R. Alves, Miguel L. Silva, José M. Ferreira, “DRAFT: An On-Line

Fault Detection Method for Dynamic and Partially Reconfigurable FPGAs”, Proceedings of the

7th IEEE On-Line Testing Workshop (IOLTW'01), Giardini Naxos - Taormina, Itália, Julho de

2001, pp. 34-36

• Manuel G. Gericota, Gustavo R. Alves, Miguel L. Silva, José M. Ferreira, “DRAFT: An On-line

Concurrent Test for Partial and Dynamically Reconfigurable FPGAs”, Proceedings of the 16th

Conference on Design of Circuits and Integrated Systems (DCIS’2001), Porto, Portugal, Novembro

de 2001, pp. 553-558

• Manuel G. Gericota, Gustavo R. Alves, Miguel L. Silva, José M. Ferreira, “Dynamic Replication:

The Core of a Truly Non-Intrusive SRAM-based FPGA Structural Concurrent Test

Methodology”, 3nd IEEE Latin-American Test Workshop (LATW’2002) Digest of Papers,

Montevideo, Uruguay, Fevereiro de 2002, pp. 70-75

Neste capítulo traçou-se um breve historial das acções de disseminação realizadas no âmbito do

projecto e cujo acolhimento demonstra o sucesso que este tem alcançado.

Page 95: RELATÓRIO INTERCALAR DE ACTIVIDADES DO PROJECTO …purl.pt/281/1/projecto_maria/relatorio_intercalar.pdf · relatÓrio intercalar de actividades projecto pocti/33842/ese/2000 teste

Relatório intercalar de actividades - Projecto POCTI/33842/ESE/2000 95

5.PERSPECTIVAS FUTURAS

Encontrando-se a parte de exploração teórica praticamente concluída, os trabalhos em curso no

projecto centram-se sobretudo na implementação prática dos procedimentos teóricos, de forma a se

conseguir uma completa automação de todo o procedimento de teste. Neste sentido, a continuação

do desenvolvimento e melhoria da componente de software constituem os pontos de progressão

centrais deste projecto.

De igual forma, tenta-se já perspectivar outras áreas de aplicação para os procedimentos teóricos

desenvolvidos, salientando-se a utilização dos mecanismos de replicação na reorganização e

desfragmentação do espaço de configuração quando a FPGA é partilhada por múltiplas aplicações,

área em que já apresentamos uma submissão a uma conferência especializada, aguardando

presentemente resposta do painel de avaliadores.

O bolseiro contratado, Eng. Miguel L. Silva, encontra-se actualmente, em paralelo com a sua

actividade no projecto, a frequentar a parte lectiva do Mestrado em Inteligência Artificial, que

decorre na Faculdade de Engenharia, em parceria com a Faculdade de Ciências da Universidade do

Porto, devendo a sua Tese de Mestrado ter como base o trabalho que desenvolveu neste projecto,

mais-valia não prevista inicialmente na proposta submetida à FCT. Por outro lado, a Tese de

Doutoramento do Mestre Manuel G. Gericota, subordinada ao tema “Metodologias de teste para

FPGA’s (field-programmable gate arrays) integradas em sistemas reconfiguráveis”, apontada na

proposta como parte integrante dos resultados que se previam alcançar neste projecto, decorre a

bom ritmo, acompanhando o êxito do próprio projecto, devendo estar concluída até ao final da sua

execução.

Page 96: RELATÓRIO INTERCALAR DE ACTIVIDADES DO PROJECTO …purl.pt/281/1/projecto_maria/relatorio_intercalar.pdf · relatÓrio intercalar de actividades projecto pocti/33842/ese/2000 teste

96 Teste Concorrente para Sistemas Electrónicos Reconfiguráveis

6.CONCLUSÕES

Dos três objectivos propostos inicialmente, considerados como centrais dentro da proposta de

projecto apresentada, o desenvolvimento de procedimentos de teste que, explorando a regularidade

das FPGAs e o mecanismo de acesso proporcionado pela infra-estrutura IEEE 1149.1, permitissem

implementar um mecanismo de detecção e diagnóstico eficiente de faltas estruturais, em

concorrência com e sem afectar o normal funcionamento do sistema de que fazem parte, foi já

plenamente conseguido. Da mesma forma, o desenvolvimento de algoritmos que suportassem a

reconfiguração parcial dinâmica da FPGA, permitindo a libertação faseada de recursos para serem

testados, foi já alcançado, procedendo-se actualmente à sua integração e à expansão das suas

potencialidades, bem como ao desenvolvimento de interfaces gráficas que tornem mais amigável e

menos exigente, do ponto de vista da especialização do utilizador, o seu uso.

Em fase não tão avançada, em parte devido à não divulgação de informação pelos fabricantes sobre

a implementação dos circuitos dentro da FPGA, a análise do espectro de defeitos e a avaliação do

índice de cobertura proporcionado pelos modelos de faltas tradicionais, encontra-se ainda em fase

de estudo, tendo-se optado nos testes práticos pela utilização de modelos híbridos, sempre que a

implementação estrutural dos diferentes circuitos não é conhecida.

Quanto ao aspecto da divulgação e ao sucesso do trabalho já desenvolvido, prova-se pelo número

de publicações já concretizadas em fóruns internacionais da especialidade e pela reacção do público

aí presente, a elevada apreciação que o trabalho tem merecido. Paralelamente, foram já

desenvolvidas ideias e contactos no sentido de se aproveitar o trabalho aqui realizado para explorar

novas áreas e novas aplicações em próximos projectos de investigação e desenvolvimento.

Page 97: RELATÓRIO INTERCALAR DE ACTIVIDADES DO PROJECTO …purl.pt/281/1/projecto_maria/relatorio_intercalar.pdf · relatÓrio intercalar de actividades projecto pocti/33842/ese/2000 teste

7.ANEXOS

Cópia do anúncio do seminário proferido pelo Prof. Charles E. Stroud do Dept. of Electrical &

Computer Engineering, University of North Carolina at Charlotte, Estados Unidos da América,

referido no capítulo 4.1.

Page 98: RELATÓRIO INTERCALAR DE ACTIVIDADES DO PROJECTO …purl.pt/281/1/projecto_maria/relatorio_intercalar.pdf · relatÓrio intercalar de actividades projecto pocti/33842/ese/2000 teste

98 Teste Concorrente para Sistemas Electrónicos Reconfiguráveis

Seminário

Metodologias de Teste para FPGAs

pelo Prof. Charles E. Stroud,Dept. of Electrical & Computer Engineering

University of North Carolina at Charlotte

Sexta-feira, 9 de Novembro de 2001

14 Horas - Sala B 233

Faculdade de Engenharia da U. P.

Rua Dr. Roberto Frias - PORTO

Pontos a abordar:

- metodologia de teste e diagnóstico não concorrente de blocos lógicos e interligaçõesem FPGAs usando auto-teste interno

- demonstração prática da aplicação da metodologia ao teste e diagnóstico duma FPGAcomercial

- panorâmica das metodologias de teste concorrente para FPGAs

- metodologia de teste e diagnóstico concorrente de blocos lógicos e interligações emFPGAs usando auto-teste interno

- demonstração prática da aplicação da metodologia ao teste e diagnóstico duma FPGAcomercial

O seminário terá um caracter informal, possibilitando uma desejável interacção entretodos os participantes. A entrada é livre.

Qualquer informação suplementar poderá ser obtida junto da Dra. Maria Inês Cambeiro,pelo tel. 225081748 ou pelo e-mail: [email protected]

Prof. Dr. José Manuel Martins Ferreira, FEUP

Eng. Manuel Gericota, ISEP

Este seminário é promovido no âmbito do projecto POCTI/33842/ESE/2000 financiado pela Fundaçãopara a Ciência e Tecnologia.