RELATÓRIO INTERCALAR DE ACTIVIDADES DO PROJECTO...
Transcript of RELATÓRIO INTERCALAR DE ACTIVIDADES DO PROJECTO...
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
2 Teste Concorrente para Sistemas Electrónicos Reconfiguráveis
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
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
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
6 Teste Concorrente para Sistemas Electrónicos Reconfiguráveis
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.
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,
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
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.
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.
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
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
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.
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
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
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.
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
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
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
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;
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
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
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.
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 é
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
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.
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.
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
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
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
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.
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;
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
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
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.
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
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
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
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.
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
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
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.
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
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.
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
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
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.
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
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
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
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
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
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.
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.
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
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
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
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.
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
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.
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.
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
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).
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
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
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:
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.
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
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.
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
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
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
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
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.
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.
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
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
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.
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
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.
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.
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.
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
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
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
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
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.
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.
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/
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/
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.
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
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.
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.
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.
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.
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.