Soluções de Auto-teste para Sistemas Electrónicos

UNIVERSIDADE TÉCNICA DE LISBOA
INSTITUTO SUPERIOR TÉCNICO
Soluções de Auto-teste para
Sistemas Electrónicos
Ruben Tagarroso Janeiro Correia nº46687
LICENCIATURA EM ENGENHARIA ELECTROTÉCNICA E DE COMPUTADORES
Relatório de Trabalho Final de Curso
Prof. Orientador: João Paulo Cacho Teixeira
Prof. Co-Orientador: Isabel Maria Silva Nobre Parreira Cacho Teixeira
Lisboa
Outubro de 2006
Agradecimentos
Queria agradecer aos Professores João Paulo Cacho Teixeira e Isabel Maria Silva Nobre
Parreira Cacho Teixeira, que com toda a sua dedicação, orientação e disponibilidade, ajudaram ao
longo deste projecto.
Queria agradecer ainda ao Professor Marcelino Bicho dos Santos e ao Abílio Parreira por
toda a ajuda que me dispensaram e pelos meios técnicos que me disponibilizaram, um obrigado
muito especial ao Marcial Irago pelas ajudas a nível do software, ao Pedro Bento, ao Professor
Fernando Gonçalves e ao Jorge Semião um muito obrigado pela ajuda na compreensão do autoteste integrado (BIST, Built In Self Test) .
Finalmente queria agradecer aos meus amigos pelo apoio, ajuda e motivação e a minha
família por me ter disponibilizado os meios para conseguir fazer o curso e este relatório.
ii
Resumo
O projecto de sistemas digitais complexos torna necessário o desenvolvimento de soluções de
teste economicamente viáveis, para aferição da qualidade do produto, após a produção e durante
a sua vida útil. O auto-teste integrado (BIST, Built-In-Self-Test) pode ser uma solução atraente, já
que permite conter os custos de equipamento automático de teste (ATE, Automatic Test
Equipment) e viabilizar o auto-teste durante a vida útil, mesmo que os circuitos integrados são
embebidos em sistemas mais complexos. A verificação da integridade física de cada componente,
para assegurar a qualidade do produto, requer uma solução BIST estrutural. Usualmente, durante
a vida útil do produto, o que o utilizador pretende é verificar se o componente ainda é capaz de
assegurar a funcionalidade correcta. Tal objectivo requer uma solução BIST funcional. Uma vez
que os objectivos de teste nestas duas aplicações diferem, torna-se necessário analisar e concluir
se uma solução de BIST funcional poderá ser reutilizada para BIST estrutural.
As técnicas de projecto tendo em vista a testabilidade (DfT, Design for Testability) devem ser
integradas no fluxo de projecto do produto, quer seja implementado em tecnologia reconfigurável
(FPGA) quer em circuito integrado de aplicação específica (ASIC). A síntese lógica pode ser
efectuada com recurso a muitas opções (por exemplo, com optimização da área de silício ou da
rapidez de resposta). Assim, torna-se útil avaliar o impacto que as diferentes estruturas lógicas
têm sobre a testabilidade do circuito. Adicionalmente, é necessário avaliar a qualidade da solução
BIST, em função da eficiência do teste (medida pela cobertura de faltas) e da sobrecarga do teste,
especialmente para módulos sequenciais.
O objectivo deste Trabalho Final de Curso é duplo. Primeiro, recorrendo-se a sistemas de
projecto automático comerciais (EDA, Electronic Design Automation), nomeadamente Cadence e
Synopsys, definir o fluxo de projecto para uma inserção eficiente de BIST, tendo em consideração
as vantagens e limitações de cada solução BIST. Segundo, discutir a possibilidade de desenvolver
uma solução unificada de BIST para implementar o auto-teste funcional e estrutural.
O trabalho é realizado utilizando um caso de estudo do mundo real, um controlador de leitura de
um sistema electrónico de aquisição de dados para imagiologia médica (mamografia, com recurso
a tecnologia PET (Positron Emission Tomography). Nesta aplicação, existia previamente uma
solução de BIST funcional numa implementação em FPGA. Neste TFC, desenvolveu-se uma
solução BIST estrutural com varrimento (test-per-scan) baseada em implementação ASIC e
comparam-se as duas soluções. Demonstra-se que a utilização dos estímulos de auto-teste
funcional conduzem a valores reduzidos da cobertura de faltas (62,5%). Contudo, se esses
estímulos forem utilizados para verificar que a funcionalidade é correcta, então as faltas
associadas à estrutura que realiza a funcionalidade-alvo da aplicação são detectadas por este
padrão de teste funcional. Assim, para este objectivo, o teste funcional pode ser reutilizado como
teste estrutural parcial. A sobrecarga do teste da solução proposta para o caso de estudo é
elevada; contudo, isso deve-se ao facto da complexidade do controlador ser limitada. Para
módulos de complexidade compatível com a utilização de BIST estrutural clássico, a sobrecarga
de teste será reduzida.
Palavras Chave
Sistema auto teste integrado, Teste Funcional e Estrutural, Cadeia de varrimento (Scan),
Cobertura de faltas
iii
Abstract
Complex system digital design drives the need to develop cost-effective test solutions, for
product and lifetime quality assessment (production and lifetime test). BIST (Built-In-Self-Test)
is an attractive solution, as it allows constraining ATE (Automatic Test Equipment) costs and
enabling lifetime self-test, even when chips are embedded in a more complex system. Checking
for physical integrity of the component, to guarantee product quality, requires structural BIST.
Often, during product lifetime, users mainly want to make sure the component is still able to
perform the correct functionality. This requires functional BIST. As test objectives differ for
these two applications, work needs to be carried out to understand if functional BIST can be
reused for structural BIST.
Design for Testability (DfT) techniques need to be smoothly integrated in the product design
flow, either for reconfigurable (FPGA) or for ASIC (Application-Specific) implementations. As
logic synthesis can be performed using many options (e.g., for silicon area or speed
optimization), it is worthwhile to evaluate the testability of these different logic structures.
Moreover, BIST quality, in terms of test effectiveness (measured by the fault coverage metrics)
and test overhead, especially for sequential modules, needs to be ascertained.
The purpose of this Final Work Program is twofold. First, using commercial EDA (Electronic
Design Automation) systems, namely Cadence and Synopsys, to define a design flow for costeffective BIST insertion, taking into account the advantages and limitations of each BIST
solution. Second, to discuss the possibility of having a unified BIST solution to accommodate
both structural and functional self-test.
The work is performed using a real-world case study, the readout controller of a data acquisition
electronic system for medical imaging (mammography, using PET (Positron Emission
Tomography) technology). In this application, so far functional BIST has been inserted with an
FPGA-based implementation. In this Final Work, a test-per-scan BIST solution is developed for
structural BIST (ASIC-based implementation), and the two solutions are compared. It is shown
that using functional BIST test stimuli leads to limited fault coverage (62.5%). However, if these
stimuli are used to verify the correctness of the functionality, then we show that faults associated
with the parts of the structure used to implement the target functionality of the device are, in fact,
detected by the functional test. Hence, for this purpose, the functional BIST can be reused as a
partial structural BIST. Due to the limited complexity of the controller, test overhead is high.
However, more complex modules for which usually BIST solutions are devised will lead to low
overhead.
Keywords
Built-in Self test
Functional and Structural test
Scan chain
Fault coverage
iv
Índice
Agradecimentos............................................................................................................................... ii
Resumo........................................................................................................................................... iii
Palavras Chave ............................................................................................................................... iii
Abstract ...........................................................................................................................................iv
Keywords ........................................................................................................................................iv
Lista de Figuras ............................................................................................................................. vii
Lista de Tabelas...............................................................................................................................ix
Lista de Programa............................................................................................................................ix
Acrónimos ........................................................................................................................................1
1. Introdução.................................................................................................................................1
1.1. Motivação.........................................................................................................................1
1.2. Objectivo ..........................................................................................................................2
1.3. Roteiro..............................................................................................................................2
2. Projecto de CI Testáveis...........................................................................................................3
2.1. Necessidade do Teste .......................................................................................................3
2.2. Técnicas de DfT (Design for Testability) ........................................................................4
2.3.
A Metodologia BIST (Built-In Self Test) ........................................................................6
2.4. Indicadores de Qualidade .................................................................................................8
3. Fluxo de Projecto ...................................................................................................................10
3.1. FPGA e ASIC.................................................................................................................10
3.2. Sistemas e Ferramentas de Projecto Automático (EDA) ...............................................11
3.3. Casos de Estudo Elementares (XTRAN & B01) ...........................................................13
3.3.1.
XTRAN ..................................................................................................................13
3.3.2.
B01 .........................................................................................................................15
4. Fluxo de Projecto com BIST e Análise das Soluções ............................................................18
4.1. Caso de Estudo: Controlador RD_ROC.........................................................................18
4.1.1.
Síntese e Optimização ............................................................................................20
4.1.2.
Criação da Test-bench e Teste do Circuito.............................................................21
4.1.3.
Geração de Vectores de Teste ................................................................................23
4.2. Implementação FPGA. BIST Funcional ........................................................................26
4.3. Implementação ASIC. Fluxo de projecto com BIST Estrutural.....................................30
4.3.1.
Gerador de Vectores de Teste Pseudo-aleatório (PR)............................................31
4.3.2.
Multiplexer .............................................................................................................32
4.3.3.
Circuito Sob Teste (CUT) ......................................................................................33
4.3.4.
Compactador ..........................................................................................................33
4.3.5.
Comparador............................................................................................................34
4.3.6.
Registo de Assinatura.............................................................................................34
4.3.7.
Desenvolvimento e Implementação do BIST.........................................................34
4.4. Análise de Resultados ....................................................................................................44
4.4.1.
Cobertura de Faltas do Circuito RD_ROC sem BIST............................................44
4.4.2.
Cobertura de Faltas do Circuito RD_ROC com BIST ...........................................46
5. Conclusões .............................................................................................................................50
6. Referências .............................................................................................................................53
Anexos............................................................................................................................................54
v
RD_ROC Test Bench .................................................................................................................55
PLI..........................................................................................................................................58
Código VHDL dos Diferentes Blocos........................................................................................60
Control....................................................................................................................................60
LFSR ......................................................................................................................................64
MISR ......................................................................................................................................70
MUX.......................................................................................................................................73
Top Level ...............................................................................................................................74
BIST Test Bench ........................................................................................................................77
vi
Lista de Figuras
Figura 2. 1 - Exemplo de aplicação da metodologia BIST ..............................................................6
Figura 2. 2 - MISR ...........................................................................................................................7
Figura 3. 1 - Circuito xtran.............................................................................................................14
Figura 3. 2 - Clock mínimo para xtran (ns)....................................................................................15
Figura 3. 3 – Circuito B01 não optimizado (descrição RTL).........................................................16
Figura 3. 4 – Esquema do B01 optimizado frequência de relógio (nível lógico) ..........................17
Figura 3. 5 – Esquema B01 optimizado área (nível lógico)...........................................................17
Figura 4. 3 – RD_ROC, package....................................................................................................18
Figura 4. 4 – Máquina de Estados do circuito de RD_ROC ..........................................................19
Figura 4. 1 – Contador rd_counter_EvT.vhd .................................................................................20
Figura 4. 2 - Contador rd_counter_EvN.vhd..................................................................................20
Figura 4. 5 – Relatórios de síntese para optimização a) desempenho b) área..... Error! Bookmark
not defined.
Figura 4. 6– Ilustração da sincronização entre os clocks ...............................................................22
Figura 4. 7 – Relatórios de síntese com eliminação de latches para optimização a) desempenho b)
área .................................................................................................Error! Bookmark not defined.
Figura 4. 8 – Relatórios de síntese com eliminação de latches e warnings para optimização a)
desempenho b) área........................................................................................................................21
Figura 4. 9 – Explicação de funcionamento dos três primeiros estados do circuito (ModelSim™)
........................................................................................................................................................24
Figura 4. 10 – Máquina de Estados criada a partir do ficheiro RD_ROC original ........................25
Figura 4. 11 – Agrupamento de módulos do DAE nas FPGA's.....................................................26
Figura 4. 12 – Descrição esquemática da estratégia de teste. ........................................................28
Figura 4. 13 – Arquitectura genérica do controlador local de teste. ..............................................29
Figura 4. 14 - Arquitectura BIST utilizada ....................................................................................30
Figura 4. 15 – Fluxo de projecto BIST estrutural ..........................................................................31
Figura 4. 16 - Gerador de vectores pseudo-aleatórios....................................................................32
Figura 4. 17 - Exemplo de LFSR com N=4 ...................................................................................32
Figura 4. 18 - MUX........................................................................................................................33
Figura 4. 19 - Compactador............................................................................................................33
Figura 4. 20 - Comparador .............................................................................................................34
Figura 4. 21 - Registo de assinatura ...............................................................................................34
Figura 4. 22 - top level, package....................................................................................................35
Figura 4. 23 – Circuito BIST..........................................................................................................36
Figura 4. 24 – LFSR, package........................................................................................................37
Figura 4. 25 – mux, package ..........................................................................................................37
Figura 4. 26 – RD_ROC com scan, package..................................................................................38
Figura 4. 28 – compactador, package ............................................................................................40
Figura 4. 29 – controlador, package...............................................................................................42
Figura 4. 30 – Maquina de estados do controlador ........................................................................43
vii
Figura 4. 31 - Cobertura de faltas de RD_ROC com 10 mil vectores aleatórios ...........................44
Figura 4. 32 – Cobertura de faltas de RD_ROC com vectores usados em FPGA .........................45
Figura 4. 33 – Cobertura de faltas de RD_ROC com vectores usados em FPGA, 10.000 vectores
........................................................................................................................................................46
Figura 4. 34 – Área do circuito com BIST.....................................................................................47
Figura 4. 35 – Área dos diferentes blocos do circuito com BIST ..................................................48
Figura 4. 36 – Cobertura de Faltas com BIST................................................................................49
viii
Lista de Tabelas
Tabela 4. 1:resultados simulação PLI.(caso 1)...............................................................................22
Tabela 4. 2:resultados simulação PLI.(caso 2)...............................Error! Bookmark not defined.
Tabela 4. 3:resultados simulação PLI.(caso 3)...............................Error! Bookmark not defined.
Tabela 4. 4:estados activados por vectores ....................................................................................23
Tabela 4. 5:resumo dos resultados de simulação com PLI ............................................................26
Tabela 4. 6: Resultados de simulação com PLI para diferente número de vectores de entrada ....26
Tabela 4. 7:portos de Top_level.....................................................................................................35
Tabela 4. 8:Portos de lfsr................................................................................................................37
Tabela 4. 9:Portos de Mux .............................................................................................................38
Tabela 4. 10:Portos de RD_ROC com scan ...................................................................................39
Tabela 4. 11: Portos de compactador .............................................................................................40
Tabela 4. 12: Portos de control.......................................................................................................41
Lista de Programas EDA
Verilog™, simulador da Cadence;
PLI™, interface a usar com Verilog;
Design_Vision™, Ferramenta de síntese da Synopsys para ambiente Linux;
ModelSim™, simulador lógico da Mentor Graphics;
ISE Webpack™, utilizado para realização dos ficheiros VHDL, ferramenta da Xilinx para
descrever e programar FPGA’s;
ix
Acrónimos
ASIC – Application-Specific Integrated Circuit
ATE – Automated Test Equipment
BGA – Ball Grid Array
BIST – Built In Self Test
CI – Circuito Integrado
CUT – Circuit Under Test
DAE - Data Acquisition Electronics
EDA – Electronic Design Automation
FPGA – Field Programmable Gate Array
HDL - Hardware Description Language
JTAG – Joint Test Action Group
LFSR – Linear Feadback Shift Register
LSA - Line Stuck-At
LUT – Look Up Table
MISR – Multiple Input Signature Register
MUX – Multiplexer
PCB - Printed Circuit Board
PET - Positron Emission Tomography
PRPG – Pseudo Random Pattern Generator
RTL – Register Transfer Level
SoC - Systems on a Chip
TE - Test Effectiveness
TL - Test Length
TO - Test Overhead
TP - Test Power
TPG – Test Pattern Generator
TPI – Test Point Insertion
VHDL – Very High-level Hardware Description Language
VLSI – Very Large Scale Integration
1
1. Introdução
Com o aumento da complexidade dos circuitos integrados (CI), aumenta também a
possibilidade de ocorrerem falhas nos mesmos, falhas essas que muitas vezes são difíceis de
detectar num teste de produção.
Torna-se ainda mais complicado detectar uma falha numa placa de circuito impresso, isto
é, detectar qual o circuito integrado que está a causar o mau funcionamento da placa. Uma
solução simples seria o próprio circuito integrado indicar se está com mau funcionamento. Para
que tal situação fosse possível, o integrado teria de estar munido de um teste interno, ou auto
teste integrado (BIST, Built In Self Test) [2].
Hoje em dia já se usam essas soluções, em especial em aplicações críticas de segurança,
tais como nos ramos da aviação e ferroviário. Os componentes aqui aplicados têm um sistema de
auto-teste que indica se estão a funcionar correctamente, o que é muito útil, por exemplo, no caso
dos aviões em que os circuitos indicam o seu mau funcionamento antes que estes efeitos
provoquem uma catástrofe.
1.1.
Motivação
A complexidade e a qualidade dos produtos tornam necessário projectar CI digitais
testáveis [1]. Muitos produtos são desenvolvidos e prototipados em tecnologia de hardware
reconfigurável (FPGA, Field Programmable Gate Array). Posteriormente, se a aplicação o tornar
rentável, migram para implementação em ASIC (Application-Specific Integrated Circuit). Para
uma design house, é necessário desenvolver um fluxo de projecto automático, com base em
sistemas de projecto automático EDA (Electronic Design Automation) comerciais, para produzir
soluções testáveis e, muitas vezes, auto-testáveis.
Seria muito interessante poder aplicar auto-teste a todos os sistemas electrónicos,
conseguindo-se assim saber se estão a funcionar correctamente e, deste modo, facilitando
eventuais reparações. Claro que projectar um circuito com auto-teste é mais dispendioso, mas
existem vários tipos de auto-teste com diferentes custos de implementação [3] Entre eles, como
se descreve no capítulo 2, conta-se o auto-teste com varrimento (test-per-scan BIST) [1]-[3]. Este
tipo de teste é uma mais valia para o consumidor que certamente saberá dar valor a esta
funcionalidade para além de aumentar a qualidade dos produtos e facilitar a assistência técnica.
Do ponto de vista empresarial leva-se mais tempo a projectar o produto mas consegue-se lançá-lo
com bastante rapidez, devido a não haver necessidade de fazer muitos testes externos, poupando
assim custos em equipamento de teste externo (ATE, Automated Test Equipment). A assistência
pós-venda vai ter muito menos procura, devido à alta qualidade do produto, e torna-se mais fácil
fazer um diagnóstico de reparação.
1
1.2.
Objectivo
O objectivo deste Trabalho Final de Curso é o desenvolvimento de um fluxo de projecto
de um módulo de CI digital com auto-teste integrado, em ASIC, numa tecnologia BIST estrutural
em test-per-scan, com análise dos custos de inserção do BIST, e sua aplicação a um caso de
estudo, não de um sistema domótico (como inicialmente se previu), mas num sistema de
aquisição e processamento de dados de um sistema de imagiologia médica para mamografia
baseado em tecnologia PET (Positron Emission Tomography) [4][5]. Pretende-se ainda comparar
a solução FPGA com BIST funcional, com a solução ASIC com BIST estrutural e discutir se (e
em que condições) se poderá reutilizar a solução de BIST funcional para auto-teste funcional.
1.3.
Roteiro
Este documento está organizado como se indica em seguida.
No capítulo 2 revêem-se conceitos básicos sobre a necessidade do teste e do projecto
tendo em vista a testabilidade (DfT, Design for Testability). Recordam-se as técnicas DfT mais
comuns (técnica de varrimento (scan) e de auto teste integrado (BIST)). Identificam-se ainda os
indicadores de qualidade de teste, que permitem uma análise de compromissos e de valor relativo
de diversas soluções.
No capítulo 3 identificam-se os fluxos de projecto automático para implementação em
FPGA (em uso) e em ASIC (proposto neste trabalho). Concretiza-se para os sistemas EDA
disponíveis no INESC-ID e apresenta-se a sua aplicação em casos de estudo elementares, um
circuito combinatório industrial (XTRAN, da Tecmic [6]) e um circuito sequencial (circuito de
referência B01 [7]).
O capítulo 4 descreve a aplicação da metodologia e fluxo de projecto propostos num caso
de estudo prático, um módulo de um sistema DAE (Data Acquisition Electronics [8]) de um
sistema de imagiologia médica – um detector de nódulos cancerígenos através de mamografia
com tecnologia PET. O módulo é descrito e colocado em contexto no sistema. A solução FPGA
(desenvolvida pelo Eng.º. Pedro Bento, e apresentada na sua dissertação de Mestrado [9]) é
brevemente descrita. Em seguida, apresenta-se o fluxo de projecto com inserção de BIST
estrutural e a correspondente implementação ASIC testável, e as duas soluções são comparadas.
Finalmente, o capítulo 5 resume as principais conclusões do trabalho e direcções de
trabalho futuro.
2
2. Projecto de CI Testáveis
2.1. Necessidade do Teste
Os circuitos integrados desde o inicio da sua produção estão sujeitos a ter vários tipos de
defeitos físicos, tais como defeitos de processamento, de materiais, de encapsulamento, etc. Estes
defeitos podem ser considerados críticos ou não críticos, ou seja, estas falhas podem influenciar
ou não o funcionamento normal de um circuito. As falhas que influenciam o funcionamento do
circuito são apelidadas de faltas. As faltas são analisadas de uma forma abstracta e não como um
defeito físico, não sendo o mais importante descobrir que tipo de falta foi encontrada
(fisicamente) mas sim descobrir se existem faltas, o que inutiliza o componente. As faltas podem
ser descritas a diversos níveis de abstracção e ser classificadas em diferentes tipos, por exemplo:
linhas fixas a um valor lógico (LSA, Line Stuck-At), duas linhas em curto-circuito, uma linha que
não foi colocada, etc [1].
Sistemas complexos devem em numerosas situações, poder ser testados, desde a sua fase
de produção e ao longo da sua vida útil, de forma a poder monitorizar o seu correcto
funcionamento. Estes testes e eventualmente o diagnóstico de falhas e sua correcção deverão ser
rápidos, ter uma elevada cobertura de faltas e certificar o funcionamento do componente.
Tradicionalmente os circuitos são testados com equipamento de teste automático, onde se
armazenam os vectores de teste, se geram os estímulos a aplicar ao CUT (Circuit Under Test) e
se analisam as respectivas respostas aos estímulos. Durante o decurso do teste, este equipamento
é ligado às entradas e saídas do CUT, procedendo-se à respectiva excitação das entradas e recolha
dos valores das suas saídas. Uma desvantagem séria desta abordagem é o facto destes
equipamentos de teste serem muito dispendiosos. Adicionalmente o processo de teste é caro,
lento e com muitos vectores e limitações de memória por pino, resultando num tempo de
utilização por componente elevado. Igualmente desvantajoso é o facto do teste com ATE
(Automated Test Equipement) não ser completamente automático, uma vez que as pontas de
prova necessitam de ser conectadas manualmente às entradas do circuito. Para além destes
inconvenientes, a electrónica por pino no ATE tem vindo a aumentar com a complexidade dos
sistemas, tornando difícil medir sinais no dispositivo, o que é essencial no processo de teste. Os
sistemas VLSI (Very Large Scale Integration) continuam a tornar-se cada vez mais densos e
rápidos com o desenvolvimento das tecnologias nanométricas. Consequentemente o tempo para a
geração e a aplicação dos vectores de teste torna-se cada vez maior. Finalmente a quantidade de
informação proveniente do teste, a ser armazenada no ATE, tem-se tornado proibitiva. Uma
forma de minorar estes problemas é especificar o teste como mais uma função do sistema, de
modo a tornar o componente auto-testável. Esta ideia motivou o desenvolvimento de métodos de
BIST, providenciando formas de decompor hierarquicamente o sistema em teste, localizando-o
em módulos menos complexos e por conseguinte acelerando o processo de teste. Em BIST
procede-se à inclusão de mais lógica no circuito original, de modo a poder testá-lo. Desta forma,
a maior parte das desvantagens do teste externo são eliminadas pelo BIST, o processo é muito
mais económico e passa a ser completamente automático. Para além disso, outra vantagem é o
facto das capacidades de teste acompanharem a evolução da tecnologia VLSI, algo que não se
verifica com o teste externo. Portas lógicas tornam-se relativamente baratas, em comparação com
3
o esforço para desenvolver programas de teste e com o custo do equipamento de teste automático
necessário.
2.2. Técnicas de DfT (Design for Testability)
Existem diversas técnicas de teste de circuitos integrados, em particular, técnicas Ad-hoc
e estruturadas. Entre as técnicas estruturadas merecem destaque as técnicas de varrimento (scan),
de varrimento periférico (BoundaryScan), de auto-teste integrado (BIST, Built-In-Self-Test), e de
inserção de portos de teste (TPI, Test-Point-Insertion) [1]-[3].
A técnica de scan é uma das mais utilizadas devido a sua simplicidade de implementação,
sendo esta hoje em dia, automaticamente feita por software. Esta técnica consiste em reconfigurar
o circuito, em modo de teste, criando uma cadeia entre todos os elementos de memória do
circuito, designada por cadeia de scan. Trata-se de uma ligação física entre todos os registos de
memoria do circuito, ou seja, a entrada de cada elemento de memoria esta ligada a saída de outro,
excepto a entrada do primeiro elemento e a saída do ultimo elemento de memoria, formando
assim uma cadeia.
A funcionalidade da cadeia de scan é permitir chegar onde as entradas primárias não
chegam. De facto, no circuito em modo normal, nem todos os registos de memória conseguem
ser controlados pelas entradas do circuito. O mesmo acontece com as saídas das várias portas
lógicas, nem todas conseguem ser observáveis nas saídas do circuito.
O modo de funcionamento, em modo de teste, de um circuito com scan é relativamente
simples. Os dados entram em série na cadeia e saem da mesma forma, como se de um registo de
deslocamento (shift register) se tratasse. Quando a cadeia de scan esta preenchida aplica-se um
sinal de relógio ao circuito obtendo assim um resultado.
Imagine-se um circuito com 5 registos de memória (flip-flops) no qual se pretende inserir
uma cadeia de scan. Adicionam-se duas entradas e uma saída (entrada de dados, entrada de
activação da cadeia e saída de dados). Cria-se uma cadeia do tipo shift register entre os registos e
alteram-se os mesmos, de forma a que quando se está a preencher a cadeia de scan estes recebem
os valores da cadeia e não os do circuito. Por outras palavras, as entradas dos registos de memoria
são multiplexadas entre as da cadeia de scan e as que vem do circuito. Este multiplexer é
controlado pela entrada de activação da cadeia. Para testar o circuito activa-se a entrada de
activação da cadeia e aplica-se na entrada de dados os 5 bits com que se quer preencher a cadeia.
Este procedimento leva 5 ciclos de relógio visto a entrada de dados ser série. Em seguida
desactiva-se a entrada de activação de cadeia e aplica-se um ciclo de relógio de forma a obter nos
registos de memória a resposta ao conjunto de bits que estes continham. Finaliza-se procedendo a
activação da entrada de activação da cadeia, e lê-se na saída de dados os 5 bits obtidos. Note-se
que esta operação é em tudo idêntica a operação de inserção de dados na cadeia, o que permite
que as duas sejam realizadas ao mesmo tempo possibilitando a entrada de um novo vector.
Assim, para este exemplo, são necessários 11 ciclos de relógio para obter a primeira resposta e 6
para obter as seguintes.
Resumindo, a técnica de scan é fácil de implementar, conduz a uma boa cobertura de
faltas e é realizada com aumento de área de implantação não muito elevado. Como desvantagens
refira-se o tempo que requer para que seja realizado um teste e a necessidade de vectores do
tamanho da cadeia. Note-se que a cadeia pode ser partida em varias cadeias, de forma a poupar
tempo de teste. Contudo, essa solução obriga a aumentar-se o número de pinos.
4
A técnica de BoundraryScan é no essencial uma técnica similar à apresentada
anteriormente, mas com a diferença de ligar CI (circuitos integrados) e não elementos de
memoria. As placas de circuito impresso (PCB, Printed Circuit Board) hoje em dia contêm
vários circuitos integrados. Devido a tecnologia existente (PCB´s com várias camadas,
encapsulamentos com pinos BGA) não é possível aceder as linhas ou pinos de teste dos CI´s.
Assim criou-se uma cadeia que liga todos os CI´s ao exterior permitindo que estes sejam
configurados, testados, etc. Esta cadeia também é conhecida por cadeia de JTAG.
Este trabalho tem por objectivo o desenvolvimento de uma metodologia de projecto com
BIST (auto-teste integrado) que sequencialmente testa circuitos VLSI, de modo a cobrir o maior
número de faltas possível.
Uma parte significativa do lucro de um produto pode ser perdida devido aos componentes
que são devolvidos, devido ao facto de apresentarem defeitos (field rejects). Uma forma de
minimizar este problema consiste usar um sistema de teste melhor na linha de produção. No
entanto, esta solução é cara e lenta porque é necessário equipamento que analise componentes
complexos e com elevado número de pinos. Com a implementação de BIST num componente,
esta tarefa é facilitada porque o teste já vem total ou parcialmente implementado no chip, e vai
acompanhá-lo para o resto da sua vida útil. As vantagens do uso desta técnica são:
•
Baixo custo de teste: ATE mais baratas que permitem que se realizem testes em
paralelo aumentando a velocidade do teste de produção.
•
Melhor cobertura de faltas: ao permitir testes massivos em paralelo, e dispensando
a necessidade de testes dispendiosos, mais tempo pode ser gasto para testar cada
chip i.e. permite testes mais extensivos a cada componente em particular.
•
Possibilidade de tempos de teste mais curtos: no caso do chip poder ser dividido
em partes, usando múltiplas cadeias de scan, que podem ser testadas em paralelo.
•
Testes podem ser executados durante toda a vida útil do chip: o consumidor pode
testar o seu chip e saber se a funcionalidade do sistema é confiável ou não.
No entanto, convém referir algumas desvantagens desta metodologia de auto teste, sendo
elas:
•
•
•
•
Maior área de implementação: maior área implica mais custos.
Tempo de acesso e consumo de potência: o número de portas lógicas constituintes
aumenta, o que fará com que o circuito fique mais lento e consuma mais energia.
Necessidade de uso de mais pinos em algumas arquitecturas de BIST: existe um
número limitado de pinos de saída em qualquer integrado e o circuito de BIST
necessita de comunicar com o exterior.
Não se garante 100% de cobertura de faltas: não se testa o hardware de teste, e o
tempo de teste dos circuitos maiores é demasiado grande para que se torne viável
testar todos os vectores possíveis.
O auto-teste integrado (BIST) tem sido proposto como um poderoso instrumento para
técnicas de teste por se dirigir especificamente aos problemas de teste dos circuitos VLSI [2]. O
5
projecto da funcionalidade de auto-teste inclui circuitos de teste dentro de circuitos integrados
para gerar vectores de teste e analisar as respostas na saída. Consegue realizar teste interno ao
chip de tal modo que reduz significativamente o uso de equipamento externo de teste, claramente
complexo.
2.3. A Metodologia BIST (Built-In Self Test)
Muitos dos elementos do BIST têm sido desenvolvidos e usados em aplicações práticas
ao longo dos anos. Agora que um crescente número de chips se está a tornar em SoC (Systems on
a Chip), as questões e problemas de engenharia de sistemas associados estão a tornar-se em
problemas a nível industrial e em questões de necessidade comercial ao invés de soluções
construtivas.
A arquitectura de base de um CUT com BIST pode ser observada na Figura 2. 1. Esta
arquitectura é muito eficaz quando o CUT é combinatório. Quando é um circuito sequencial, a
solução usual consiste em reconfigurar o CUT, em modo de auto-teste, por forma a aumentar a
acessibilidade dos nós internos, em particular, dos nós associados aos elementos de memória.
n
PIs
PIs
m
POs
POs
MUX
CUT
MISR
LFSR
BIST Controller
Figura 2. 1 – Arquitectura-base da metodologia BIST
O projecto é realizado utilizando descrições de elevado nível de abstracção (HDL,
Hardware Description Language) especificadas num nível de RTL (Register Transfer Level).
Estas descrições de alto nível permitem que a funcionalidade de teste seja inserida no início do
processo de projecto. Isto trás vantagens, incluindo: independência da tecnologia, melhor
integração do BIST e circuitos funcionais e menos impacto no processo de projecto total.
Dentro do BIST existem alguns tipos, por exemplo logicBIST e MemoryBIST [13]. As
funções desempenhadas pelo logicBIST são baseadas em técnicas de scan design populares. A
ideia base consiste em adicionar um PRPG (Pseudo-Random Pattern Generator) [11], às
entradas primárias e de scan, e um MISR (Multiple Input Signature Register) às saídas das
cadeias de scan e saídas primárias (um esquema exemplificativo do MISR encontra-se na Figura
2. 2). O PRPG é usualmente realizado com um LFSR (Linear Feedback Shift Register).
Um controlador BIST gera as formas de onda necessárias para, repetidamente, carregar os
padrões pseudo aleatórios para as cadeias de scan, iniciando um ciclo funcional (ciclo de captura)
e registando as respostas capturadas no MISR. O MISR comprime as respostas acumuladas num
6
código de detecção de erro, designada por assinatura. Qualquer palavra digital diferente da
assinatura do circuito bom indica a presença de defeitos.
Figura 2. 2 – Analisador de assinuatura (MISR).
Embora os padrões pseudo-aleatórios alcancem uma alta cobertura de teste para a maior
parte do scan, existem, com generalidade, faltas resistentes ao teste com os padrões pseudo
aleatórios. Uma ferramenta de inserção de pontos de teste (TPI, Test Point Insertion) pode ser
utilizada para analisar o circuito à procura desses problemas e automaticamente adicionar portos
de teste para assegurar que o teste é realizado na sua totalidade. Uma solução alternativa consiste
em adicionar alguns vectores determinísticos para detectar essa faltas.
O LogicBIST pode ainda operar a alta velocidade (at-speed), i.e. operando à frequência
máxima do CUT [10], permitindo a detecção de defeitos relacionados com atrasos (delays).
O controlador BIST, no que concerne ao memoryBIST, é implementado com algoritmos
standard determinísticos de teste de memórias. Um “colar” (wrapper) de BIST é colocado em
volta da memória embebida. Este “colar” consiste essencialmente em lógica de multiplexagem
permitindo que a memória seja alimentada pelo controlador, no modo de teste, em lugar da lógica
do utilizador. Tal como no LogicBIST, os padrões de teste podem ser aplicados à velocidade
normal de operação (at-speed).
Devido às estruturas regulares das memórias, o controlador de MemoryBIST pode ser
partilhado por várias memórias. Obviamente, isto reduz a área circundante e a degradação de
desempenho por memória e possibilita uma redução do tempo de teste devido ao facto de ser
possível fazer-se testes em paralelo.
Em BIST podem ser considerados dois tipos, nomeadamente BIST em linha (on-line) e
BIST em separado (off-line) [12]. O teste on-line é aquele que se realiza durante o funcionamento
normal do circuito. O teste off-line desactiva a funcionalidade do circuito durante um curto
período de tampo para poder executar o teste, em modo de teste.
No BIST on-line o teste opera paralelamente com o circuito a ser testado (CUT), ou seja,
o modo normal de funcionamento inclui teste. O teste on-line é o mais complicado de
implementar e tem custos mais elevados (este tipo de teste é utilizado em aplicações críticas de
segurança, tais como em aviónica).
No BIST off-line o CUT é testado enquanto não está a realizar a sua função normal de
funcionamento. No caso de equipamentos de electrónica de consumo, tais como televisores,
computadores, telemóveis, pode usar-se um teste off-line que é mais barato e fácil de
implementar. Neste caso o teste realiza-se, por exemplo, quando se inicia o aparelho (power-on)
ou ciclicamente durante um curto intervalo de tempo em que se encontra em repouso (idle).
7
A maior parte das técnicas de BIST para lógica sequencial envolvem um compromisso
entre tempo de execução e hardware adicional. Pode-se caracterizar este compromisso ao
classificar as técnicas de BIST em duas categorias distintas: at-clock e at-scan.
No at-clock BIST aplica-se um padrão de teste e adquire-se uma resposta em cada período
de relógio, justificando assim um teste bastante rápido, mas complicado de implementar, devido a
necessidade de ter registos com 4 modos de funcionamento, e por sua vez, mais complexos que
os usados na técnica seguinte. Em at-scan BIST, usa-se a capacidade de scan para aplicar um
padrão de teste e capturar uma resposta em cada ciclo de scan. Um ciclo de scan corresponde ao
número de ciclos de relógio necessários para enviar o padrão para uma cadeia de serial scan ou
para mandar a resposta para fora do caminho da cadeia de serial scan (o que for mais extenso),
mais um ou mais modos de relógio para se obter resposta do circuito. Quer dizer, se um chip que
contenha 1 000 edge-triggered flip-flops tem uma única cadeia de scan completa, o at-scan BIST
irá necessitar de 1001 períodos de clock para aplicar um padrão de (grosseiramente 1000 vezes
mais lento do que a aproximação de at-clock). As duas aproximações envolvem estruturas de
hardware e modos de comunicação distintas. A escolha de uma solução envolve uma análise de
compromissos (trade-offs).
De um modo geral, um circuito sequencial síncrono pode ser modelado como uma tabela
iterativa de lógica combinatória. Em qualquer tempo t, o circuito sequencial comporta-se como
um circuito combinatório com elementos de memória que guardam o estado prévio da lógica do
tempo t = t − t0 . Deste modo, a detecção de faltas num circuito sequencial pode ser vista como a
detecção de múltiplas faltas numa rede combinatória. À medida que o circuito se torna mais
complexo, a tarefa de gerar vectores de teste adequados torna-se cada vez mais difícil.
A dificuldade em gerar vectores de teste para circuitos sequenciais cresce devido à
reduzida controlabilidade1 e observabilidade2 dos elementos de memória i.e. flip-flops e latches.
Embora um scan completo com teste de geração combinatório seja visto como uma solução
satisfatória, para o problema de teste sequencial existem muitas desvantagens para esta
aproximação. Estas incluem a dimensão da área devido ao hardware adicionado, o subsequente
alargamento do caminho crítico do circuito e o comprimento dos testes resultantes devido às
mudanças em série extensivas dos padrões e respostas.
O BIST desenvolvido no âmbito deste projecto é um BIST off-line do tipo logicBIST
realizado com técnica at-scan.
2.4. Indicadores de Qualidade
A qualidade do teste é aferida por diversos indicadores e métricas:
•
Eficácia do teste (TE, Test Effectiveness) – a eficácia de um teste depende de:
o A cobertura de faltas (FC, Fault Coverage) – esta medida indica a percentagem de
faltas detectadas;
1
Valor numérico que indica a possibilidade de controlar a colocação de um valor lógico num ponto do circuito a
partir do valor lógico que se coloca na entrada em questão
2
Valor numérico que indica a possibilidade de observar a alteração do valor de um ponto do circuito a partir do
valor lógico que se obtém na saída em questão. A observabilidade também depende da controlabilidade.
8
o Modelos de faltas (FM, Fault Models) – existem diferentes modelos de faltas.
Quantos mais forem usados, melhor eficácia terá o teste. Alguns exemplos de
modelos de faltas em tecnologias CMOS são: Line-Stuck-At-0/1, Bridging, linhas
interrompidas, Gate Oxide Short, Floating Gate, etc [1];
•
Sobrecarga do teste (TO, Test Overhead) – devido a introdução de novo hardware de
teste, aumenta a complexidade (portas lógicas e/ou área de silício) e a degradação do
desempenho de circuito. Assim, o novo hardware de teste, para além de influenciar o
tamanho do circuito, pode diminuir a sua velocidade de funcionamento em modo normal.
•
O tempo do teste (TL, Test Lenght) – é o tempo que se leva a aplicar o número de
vectores de teste suficientes para se atingir o valor de FC necessário. Em realidade, o
tempo de teste é o produto do período de relógio de teste pelo número de vectores do
padrão de teste;
•
Potência do teste (TP, Test Power) – em alguns casos a adição de teste e o consequente
aumento de hardware, junto com a necessidade de activar todo o circuito, implicam que
quando se esteja a fazer o teste haja um maior consumo de energia e potencia
relativamente aos que se observam em modo normal de funcionamento;
Neste trabalho utilizou-se extensivamente o modelo de faltas do tipo LSA (linha fixa a) e
avaliou-se a eficácia do teste (TE) através da cobertura de faltas, FC, correspondente.
Caracterizou-se a sobrecarga de teste (TO) através de duas métricas: o aumento percentual da
área de silício (estimada pelo sistema Synopsys™) e a redução percentual da máxima frequência
de trabalho do sinal de relógio, fMAX, estimada com uma técnica de simulação lógica explicada
adiante (secção 3.3.1). Finalmente, avaliou-se o tempo de teste (TL), através do número de ciclos
de relógio necessários para efectuar o auto-teste com a eficácia pretendida.
9
3. Fluxo de Projecto
3.1. FPGA e ASIC
O primeiro passo a realizar na produção de um projecto em FPGA é descrever a
funcionalidade do circuito a implementar ou obter uma descrição de circuito que se queira
implementar. Normalmente usam-se as ferramentas disponibilizadas pelos construtores das
FPGA’s, nomeadamente a Xilinx™.
Em seguida deve-se simular logicamente o circuito, de forma a verificar se se obtem o
funcionamento pretendido. A ferramenta ModelSim™ é usada neste trabalho para este efeito.
Antes de se poder passar ao próximo nível tem de se especificar qual a FPGA que se pretende
usar. Sem se definir qual a arquitectura da FPGA que se vai usar não faz sentido sintetizar o
circuito. As FPGA’s têm uma geometria fixa e recursos finitos. Assim, é necessário garantir que
uma descrição pode ser mapeada na FPGA em questão. A síntese produz relatórios que nos
informam de tempos de atraso, área ocupada, tempos máximos, etc. Estes relatórios apenas são
validos para a FPGA em questão. Em outra FPGA terá comportamentos/velocidades diferentes
consoante a tecnologia usada na mesma.
Depois do circuito ser mapeado convêm que o mesmo seja simulado antes de ser
programado na FPGA. Por fim, deve-se configurar a FPGA e efectuar os testes que o hardware
que acompanha a FPGA (normalmente uma placa de desenvolvimento) nos permitir.
Para o projecto ASIC usam-se neste trabalho ferramentas comerciais da Synopsys e
Cadence. Antes de trabalhar com as ferramentas tem de se especificar as bibliotecas a usar. As
bibliotecas contêm informação da tecnologia, do fabricante e o design kit. Neste trabalho usa-se
uma tecnologia CMOS 0,35µm da Áustria Micro Systems alimentada a 3.3 V). Note-se que as
bibliotecas são diferentes para cada um das ferramentas (Synopsys e Cadence) embora tentem
simular os mesmos parâmetros. A Figura 3. 1 apresenta os passos do fluxo de projecto de um
sistema digital, até se atingir o nível estrutural (lógico), com indicação das ferramentas utilizadas
neste trabalho, nas duas implementações (FPGA e ASIC). A estes passos segue-se o projecto
físico, até se gerar a implantação (layout) e a verificação ascendente (bottom-up).
O primeiro passo a realizar é obter ou descrever o código de linguagem de descrição de
hardware que define a funcionalidade do circuito. Normalmente este código está descrito em
alto-nivel (comportamental). A verificação da funcionalidade é realizada com a ferramenta
ModelSim™. Um passo importante, de seguida, é fazer a sua síntese lógica, passagem a baixo
nível (estrutural). Este processo é feito automaticamente pelas ferramentas do sistema Synopsys,
em que o utilizador controla os parâmetros através da escolha de opções. Por exemplo, podem ser
especificados tempos de atraso pretendidos ou área máxima pretendida. Depois de realizado este
passo o circuito deve ser simulado, de forma a verificar que a síntese não alterou a sua
funcionalidade. Também podem ser feitos outros testes, como por exemplo, averiguar a
velocidade máxima de funcionamento do circuito.
10
Depois de realizados todos os
testes deve ser inserida a cadeia
scan
(tarefa
realizada
de
automaticamente pelo sistema de
ferramentas). Os módulos de
auto-teste (BIST) são realizados
de forma semelhante à utilizada
para criar o circuito a testar. Os
módulos devem ser criados em
linguagem de alto nível e devem
ser sintetizados em conjunto com
o circuito, por forma a obter-se
um circuito mais compacto e um
ficheiro final que contem todo o
circuito com a funcionalidade de
BIST. Em seguida fazem-se todos
os testes necessários, de forma a
avaliar a qualidade da solução
encontrada, averiguando-se a
eficácia do teste na detecção de
faltas, a sobrecarga de teste e o
seu tempo de execução.
Figura 3. 1 – Fases iniciais do fluxo de projecto (com indicação das ferramentas utilizadas para
implementação FPGA e ASIC)
3.2. Sistemas e Ferramentas de Projecto Automático (EDA)
O software habitualmente usado para produção de documentos e programação de FPGA’s
é o software do fabricante de FPGA’s. Neste trabalho, utilizou-se a Xilinx. Esse programa é
conhecido como ISE Webpack e tem diversas funcionalidades.
A primeira coisa a fazer quando se usa este software é seleccionar a linguagem de
descrição de hardware que se vai usar, Verilog ou VHDL. Este programa permite criar vários
ficheiros que se unem de forma hierárquica e intuitiva. Quando se tem os ficheiros criados devese fazer a simulação lógica. Antes de simular é necessário criar a base à simulação (test-bench).
Esta pode ser criada em modo gráfico ou em modo de texto.
Para fazer a simulação lógica usa-se uma ferramenta da Mentor, o Modelsim™. Esta
ferramenta possibilita fazer 4 níveis de simulação (lógico, sintetizado, mapeado, simula a FPGA
de destino carregada). A simulação lógica é bastante útil porque permite que se aceda a todas as
linhas internas do circuito, possibilitando uma boa análise do que se passa internamente, o que
permite detectar erros de projecto de uma forma muito rápida e precisa. A simulação física é uma
simulação bastante mais pesada porque tem em conta vários aspectos físicos, como por exemplo,
11
atrasos nas linhas, não sendo possível visualizar nós internos, de forma a não tornar a simulação
ainda mais lenta e pesada.
Por ultimo o Webpack contempla ainda uma ferramenta que permite programar as
FPGA’s que estejam ligadas ao PC.
É complicado inserir cadeias de scan num projecto para FPGA porque este é todo feito
em alto nível, logo não é possível ter uma ferramenta que introduza automaticamente a cadeia de
scan. Apenas se consegue introduzir a cadeia após a síntese do circuito. Todavia, como este é
sintetizado para FPGA e a FPGA tem arquitectura fixa, não é possível alterar os elementos de
memória.
As ferramentas da Synopsys e Cadence são usadas para projecto de ASIC’s. A Synopsys
possui uma ferramenta, design_vision, que é utilizada para fazer a síntese lógica em ambientes
Linux. Esta ferramenta tem de ser bem configurada (associada as respectivas bibliotecas, licenças
activas e também associada as bibliotecas). A ferramenta possibilita o uso de diferentes tipos de
linguagem de descrição de hardware e permite passar de um nível RTL para o nível lógico, tendo
em conta diversos parâmetros tais como:
•
•
•
•
•
•
Área máxima que se deseja obter
Potência máxima
“Fanout” máximo
Percentagem mínima de cobertura de faltas
Tempos de subida e de descida de relógio
Frequência de funcionamento
Existem várias opções de optimização de circuito, sendo as mais evidentes, as de
mapeamento que podem ser de baixo, médio e alto nível de “esforço” de síntese. Existem ainda a
possibilidade de activar as opções de dar prioridade a caminhos mais curtos, e mapeamento
incremental. Caso se decida combinar todas estas opções (optimização, prioridade caminhos
curtos e mapeamento incremental) podem-se obter 12 opções possíveis. Depois de feita a síntese,
pode-se introduzir uma cadeia de scan automaticamente.
As ferramentas usadas para simulação pertencem à Cadence. Este software deve ser usado
com ficheiros descritos em Verilog. Por isso, quando se usam as ferramentas de síntese, deve terse o cuidado de guardar o resultado neste tipo de linguagem. Licenças e ficheiros de configuração
têm de ser preparados antes de usar as ferramentas. De modo a simular o funcionamento é
necessária criar uma test-bench. Esta serve para regular o tipo de simulação que é feita, isto é,
especificar as entradas, especificar como devem ser lidas as saídas, quantos estímulos devem ser
aplicados, a frequência de relógio com que se alimenta o circuito, entre outras possibilidades que
não foram usadas neste trabalho. O programa que permite fazer estas simulações é o Verilog™3.
Este programa pode ser associado a um script descrito em linguagem C, que aumentam a sua
versatilidade. Este script conhecido como interface PLI (Programmable Logic Interface)[15]
pode ser criado para executar diversas funções, neste trabalho foi realizado um PLI para avaliar a
frequência máxima de funcionamento do circuito.
Por último utiliza-se a ferramenta Verifault™, da Cadence, . Esta ferramenta possui um
mecanismo de funcionamento idêntico ao da ferramenta Verilog™. Contudo, o seu objectivo é
3
O nome do programa é idêntico ao nome de um tipo de linguagem de descrição de hardware pelo que não devem
ser confundidos.
12
contabilizar a cobertura de faltas, FC. Tal como para a ferramenta anterior, é necessário criar um
test-bench. Caso se pretenda, podem-se utilizar diversos modelos de faltas para avaliar a
cobertura de faltas, FC. Neste trabalho utilizou-se sempre a avaliação por defeito.
3.3. Casos de Estudo Elementares (XTRAN e B01)
Neste passo inicial do trabalho, utilizaram-se dois circuitos de teste com o objectivo de
experimentar e familiarizar o utilizador com as ferramentas computacionais, um circuito
combinatório e um sequencial.
3.3.1. XTRAN
O primeiro circuito a ser utilizado foi o circuito XTRAN, descrito em VHDL, um
circuito combinatório. Este circuito tem 13 entradas, mais uma de relógio, 11 saídas e é
habitualmente usado (no INESC-ID) por quem se inicia na síntese e optimização de circuitos.
Para conseguir optimizar o circuito foi usada a ferramenta “design_vision” da Synopsys. Esta
ferramenta permite visualizar o esquemático a partir do ficheiro VHDL (veja-se Figura 3. 2).
Posteriormente guarda-se o circuito obtido num ficheiro com descrição Verilog. O
circuito X_TRAN foi sintetizado usando todas as combinações possíveis mencionadas no
capítulo 3.2. Geram-se assim 12 circuitos possíveis. Após a obtenção dos 12 circuitos, foi criada
uma test-bench4 em Verilog a fim de se verificar se todos os circuitos tinham o mesmo valor de
saída, quando expostos aos mesmos sinais de entrada. Analisando o hardware e o código obtido
em cada processo de síntese, notou-se que muitos dos circuitos eram estruturalmente idênticos.
Neste caso, concluiu-se que apenas existiam duas estrutruras do circuito. Criou-se um ficheiro
com 10 vectores aleatórios para executar o teste.
Utilizando um compilador de Verilog, o ficheiro test_bench foi executado para cada um
dos circuitos, tendo-se obtido valores idênticos em todos os circuitos, que era o resultado
esperado, confirmando-se assim que cada circuito tinha sido bem gerado e alterado.
Para se poder estimar qual a frequência máxima a que o circuito pode trabalhar
correctamente, é necessário associar a ferramenta PLI à test-bench. Para experimentar este
procedimento foi seleccionado o circuito com uma arquitectura mais simples. A metodologia
usada para a resolução do problema é relativamente fácil. Executa-se o test-bench uma primeira
vez, exactamente da mesma forma que foi feito anteriormente para simular o circuito, com a
diferença das saídas obtidas serem guardadas numa estrutura de dados que irá servir de
referência. De seguida o test-bench reinicia-se5, subtraindo ao período de relógio um valor
predefinido (este valor aumenta a cada vez que se reinicia). O resultado obtido em cada passo da
simulação é comparado com o resultado de referência. Quando, num dado passo de simulação, se
detecta que o resultado difere do de referência, conclui-se que o circuito já excedeu a sua
frequência máxima, fMAX. Esta é então avaliada como a frequência de relógio utilizada no ciclo
anterior.
4
Test-bench é um ficheiro em código Verilog que permite testar circuitos, injectando vectores na entrada dos
mesmos e lendo as saídas.
5
Reiniciar implica repetir o processo mas com uma frequência mais elevada.
13
Figura 3. 2 - Circuito XTRAN
A gravura seguinte apresenta uma impressão do que foi obtido no ecrã do computador. Na
Figura 3. 3 vê-se um erro, para a última frequência de relógio em que a simulação foi efectuada
(parte de baixo da figura), porque a resposta ao quarto vector de entrada não é idêntica às
anteriores. Assim, a frequência anterior é a máxima frequência do sinal de relógio (esta
corresponde ao período mínimo de 6,1 ns).
Os 10 vectores aleatórios utilizados não garantem que se teste o hardware de forma
completa. De facto, com tão poucos vectores de teste, a probabilidade de se activarem todos os
caminhos críticos de sinal (os que conduzem a um maior tempo de propagação dos sinais da
entrada para a saída do bloco combinatório) é reduzida. Assim, prevê-se que com um número
maior de vectores se obtenha períodos de relógio maiores.
14
Figura 3. 3 – Período de relógio mínimo nujma das estruturas do XTRAN (6,1 ns)
3.3.2. B01
O segundo circuito a ser testado foi o circuito de referência B01 [7], um circuito
sequencial. Na Figura 3. 4 pode-se observar a arquitectura deste circuito (ainda num nível RTL).
A estratégia de optimização é diferente da utilizada no circuito anterior (XTRAN). Foram
realizadas duas optimizações, uma para cada circuito:
•
•
Optimização de frequência de relógio
Optimização de área de implantação
O nível de optimização utilizado para ambos os circuitos foi o de máxima optimização,
isto é, utilizando o máximo nível de esforço. No primeiro especifica-se um período de relógio de
0.00001 ns, e no segundo uma área de dimensão zero. Este procedimento assegura que serão
utilizados os valores mínimos. Os circuitos obtidos são apresentados na Figura 3. 5 e Figura 3. 6
para frequência de relógio e área respectivamente. Nestes, distingue-se a área de implantação
(layout) menor no segundo caso. Ao contrário, no primeiro caso encontramos portas lógicas
15
simples, embora em maior número, que tornam o circuito mais rápido. Os resultados obtidos são
os esperados, um funcionamento rápido, para o caso de optimização de frequência de relógio mas
com consequências de aumento de área, e o oposto para o circuito com optimização de área. A
simulação com test-bench deu resultados idênticos de saída para ambos os circuitos.
Figura 3. 4 – Circuito B01 não optimizado (descrição RTL)
16
Figura 3. 5 – Estrutura do B01 com optimização da frequência de relógio (nível lógico)
Figura 3. 6 – Estrutura do B01 com optimização em área (nível lógico)
17
4. Fluxo de Projecto com BIST e Análise das Soluções
4.1. Caso de Estudo: Controlador RD_ROC
Após a familiarização com as ferramentas de trabalho, passou-se à sua aplicação no
circuito RD_ROC (RD_ReadOutControl), que foi disponibilizado para o desenvolvimento deste
projecto [9]. O RD_ROC é uma interface de comunicação aplicável a uma FPGA (Field
Programmable Gate Array) que faz a comunicação da FPGA para um PC (não faz o retorno).
Este módulo faz parte do sistema DAE (em particular do módulo designado por trigger DCC),
logo está inserido na FPGA deste sistema. O RD_ROC é constituído por quatro ficheiros em
formato VHDL, sendo eles:
•
•
•
•
PEM_param.vhd
rd_roc.vhd
rd_counter_EvN.vhd
rd_counter_EvT.vhd
O primeiro ficheiro, PEM_param.vhd, descreve o hardware que serve para armazenar os
parâmetros e as constantes necessários, para parametrização da funcionalidade.
O RD_ROC é o ficheiro de topo e contém a parte maioritária do circuito (Figura 4. 1).
Neste ficheiro é descrita a máquina de estados do circuito (Figura 4. 2). O circuito tem 8 entradas
mais a entrada de relógio. Dessas 8 entradas, duas são de dados (uma com 244 bits, dout_fout, e a
outra com 25 bits, int_errcount). As restantes 6 entradas são de controlo, duas controlam os
contadores (uma faz ENABLE, int_req_onoff, e a outra dá ordem de contar ou parar, onoff), três
controlam a máquina de estados (empty_fout, full_bbus, int_readyerr) e a última é o RESET.
Figura 4. 1 – Diagrama de topo do RD_ROC
18
Figura 4. 2 – Máquina de Estados do circuito de RD_ROC
O circuito contem cinco saídas. A saída dout_bbus possui 64 bits e por elas passam os
dados a enviar para o PC. A saída rd_fout contêm um sinal de controlo que indicará que a FIFO,
onde estão colocados os dados a transferir da FPGA para o PC, está a ser lida pelo circuito
RD_ROC. A saída wr_bbus é um sinal de controlo que indica o envio de dados para escrita no PC
pela saída dout_bbus. Por fim, a saída int_doneerr é um sinal de controlo que indica que os erros
já foram enviados para o PC. A saída dcc_busy indica ao computador que a FPGA está ocupada.
No que concerne à máquina de estados, observa-se que esta contém dez estados. O estado
inicial é o estado IDLE. Existem dois trajectos possíveis, um com o SLAT_SEND_DATA que é
o trajecto caracterizado pelo envio de dados; o outro é o trajecto de envio de erros (ERR). A
passagem do estado SEND_DATA_5 para o estado SEND_DATA_2 dá-se quando existem mais
do que um pacote de dados a ser enviado.
Como se referiu, o ficheiro rd_roc.vhd é o ficheiro de topo que contém a máquina de
estados. Quanto aos ficheiros restantes, rd_counter_EvT.vhd e rd_counter_EvN.vhd, são
contadores de 32 bits, sendo o segundo controlado por mais uma variável (incr) que se comporta
como um ENABLE. Note-se ainda que, com a aplicação do sinal START, os contadores são
reiniciados a zero. Os contadores estão representados na Figura 4. 3 e Figura 4. 4 respectivamente
e são parte integrante da hierarquia do ficheiro RD_ROC.
19
Figura 4. 3 – Contador rd_counter_EvT.vhd
Figura 4. 4 - Contador rd_counter_EvN.vhd
4.1.1. Síntese e Optimização
Usando a ferramenta design_vision agregaram-se os 4 ficheiros do circuito, entidades
VHDL, para posterior síntese. Fizeram-se dois tipos de síntese, uma em desempenho e outra em
área. Este procedimento é idêntico ao usado no capítulo 3.3.2. e Figura 3. 1. Os primeiros
resultados obtidos não eram satisfatórios o que levou a que com a utilização destes
procedimentos fossem encontradas possibilidades de melhoramento do circuito original, que
acabaram por ser realizadas. O circuito obtido é armazenado em linguagem Verilog (num só
ficheiro) para que posteriormente se possa trabalhar com as ferramentas da Cadence6. Na
Figura 4. 5 são apresentados os relatórios obtidos na síntese do circuito
f max
A frequência máxima corresponde ao inverso dos valores a negrito, isto é:
1
=
para cada um dos casos.
data _ arrival _ time(ns )
6
Sendo o Verilog a linguagem mais usada nos EUA, a Cadence, empresa norte americana, desenvolve o seu
software para esta linguagem, enquanto que na Europa utiliza-se mais o VHDL.
20
Desempenho
Área
****************************************
Report : area
Design : rd_roc
Version: 2001.08
Date
: Tue Aug 9 00:55:19 2005
****************************************
****************************************
Report : area
Design : rd_roc
Version: 2001.08
Date
: Tue Aug 9 01:24:40 2005
****************************************
Number
Number
Number
Number
Number
Number
Number
Number
of
of
of
of
ports:
nets:
cells:
references:
344
1411
1067
44
of
of
of
of
ports:
nets:
cells:
references:
344
1117
769
52
Combinational area:
Noncombinational area:
Net Interconnect area:
1110192.500000
1283756.375000
4466.093262
Combinational area:
Noncombinational area:
Net Interconnect area:
470639.562500
1181926.500000
3519.672363
Total cell area:
Total area:
2393949.000000
2398415.000000
Total cell area:
Total area:
1652566.000000
1656085.625000
****************************************
Report : timing
Design : rd_roc
Version: 2001.08
Date
: Tue Aug 9 00:55:19 2005
****************************************
---------------------------------------data required time
-0.45
data arrival time
-5.17
---------------------------------------slack (VIOLATED)
-5.62
****************************************
Report : timing
Design : rd_roc
Version: 2001.08
Date
: Tue Aug 9 01:24:41 2005
****************************************
---------------------------------------data required time
49.53
data arrival time
-34.14
---------------------------------------slack (MET)
15.39
Figura 4. 5 – Relatórios de síntese do circuito de RD_ROC para optimização em a) desempenho e b) área
4.1.2. Criação da Test-bench e Teste do Circuito
Foi criado um ficheiro test-bench para se poder testar o circuito. No ficheiro de vectores
de estímulo, cada linha (que representa um vector) tem o número exacto de bits de entrada, 275
neste caso. Caso não sejam tomados cuidados pode-se ter problemas na sincronização entre o
clock do circuito e o clock de amostragem, os tempos de set e hold têm de ser respeitados. Os
sinais de relógio são idênticos (trabalham à mesma frequência, mas com atraso entre eles).
Contudo, um é injectado directamente no circuito, o outro é utilizado para ler o vector de entrada
no flanco ascendente e disponibilizar as saídas, para o display, no flanco descendente (ver os dois
primeiros sinais na Figura 4. 6). No caso do relógio de amostragem só ser activado nos flancos
ascendentes ter-se-ia de usar uma frequência com o dobro da velocidade (isto é exemplificado na
Figura 4. 6).
21
Figura 4. 6– Ilustração da sincronização entre os clocks
Os dez vectores de teste (padrão de teste T1) deste teste inicial foram gerados
aleatoriamente; apenas se teve o cuidado de aplicar um RESET e forçar a entrada num estado
específico (ERR) para carregar as saídas. Posteriormente, desenvolveram-se vectores de
estímulos mais apropriados. Com o padrão de teste T1 apenas se testam 3 estados, de entre os 10
da máquina. O código de test-bench encontra-se em anexo. De seguida adicionou-se, ao testbench, um ficheiro PLI que permite estimar a frequência máxima de funcionamento de cada uma
das estruturas. O PLI é uma interface em linguagem C que recebe da test-bench o valor das saídas
para cada uma das frequências. Inicialmente é injectado um conjunto de vectores no circuito, e os
primeiros resultados (para a frequência inicial, a mais baixa) são guardados em memória.
Posteriormente aumenta-se a frequência em passos discretos, de tamanho predefinido pelo
projectista, injectam-se os mesmos vectores e, para cada nova simulação, comparam-se os
resultados com os resultados da frequência inicial. Este procedimento repete-se para as
frequências seguintes. Quando um destes resultados for diferente do caso inicial sabe-se que o
circuito já não está a funcionar a 100%. Assim, assume-se que a frequência anterior é a
frequência máxima de funcionamento. Em rigor, é uma estimativa do valor da frequência máxima
para o conjunto de vectores injectado. O erro da estimativa depende do passo de variação da
frequência. Posteriormente testaram-se os circuitos e os resultados obtidos não foram favoráveis
no que diz respeito ao circuito optimizado em desempenho, porque o seu período mínimo era
superior ao do circuito optimizado em área (Tabela 4. 1).
Tabela 4. 1:resultados simulação PLI
Optimizado_desempenho
23.9 ns
Optimizado_área
9.3 ns
22
4.1.3. Geração de Vectores de Teste
A fim de se poder gerar um padrão de teste funcional mais completo, analisou-se em
detalhe a máquina de estados. Isto permitiu a construção de uma tabela (Tabela 4. 2) onde se
ilustram as condições necessárias às passagens em todos os estados.
Tabela 4. 2:Estados activados por vectores
reset int_redyerr Full_bbus empty_fout
STATE
1
X
X
X
IDLE
0
1
0
ERR
0
X
X
X
SLATE_ERR
0
X
X
X
IDLE
0
0
0
0
SLATE_SEND_DATA
0
X
X
X
SLATE_SEND_DATA_1
0
X
X
X
SEND_DATA_1
0
X
X
X
SEND_DATA_2
0
X
X
X
SEND_DATA_3
0
X
X
X
SEND_DATA_4
0
X
X
X
SEND_DATA_5
Com base na tabela de estados criou-se um ficheiro de estímulos com 22 vectores (padrão
de teste T2) que servem para percorrer a máquina de estados duas vezes.
Embora se considerasse toda a máquina de estados, os resultados obtidos em frequência
mostraram poucas melhorias e as saídas pareciam não estar correctas. A fim de se descobrir o
erro, fizeram-se várias alterações a nível de test-bench, e usaram-se vários vectores de estímulo.
Posteriormente, com a utilização da ferramenta ModelSim, entendeu-se o motivo do
problema encontrado. Através dos resultados obtidos, exibidos na Figura 4. 7, pode verificar-se
que a máquina de estados funciona correctamente e que os tempos da test-bench estão correctos.
O problema é que não se teve em consideração que as variáveis de saída de cada estado são
auxiliares, ou seja, só no estado seguinte é que as saídas são actualizadas com os valores que
estão nas variáveis auxiliares.
23
Figura 4. 7 – Explicação de funcionamento dos três primeiros estados do circuito (ModelSim™)
Analisando a Figura 4. 7 reconstruiu-se uma máquina de estados com maior detalhe,
(Figura 4. 8) a fim de melhor entender o funcionamento do circuito.
24
Figura 4. 8 – Máquina de Estados criada a partir do ficheiro RD_ROC original
25
Na Figura 4. 8 verifica-se que a máquina de estados é uma mistura de máquina de Mealy e de
Moore. A máquina é dominantemente de Moore. Todavia, no estado de IDLE, comporta-se como
uma máquina de Mealy (as saídas dependem também das entradas).
O novo ficheiro de estímulos (T2) foi testado. Na Tabela 4. 3 resumem-se os valores
obtidos de períodos mínimos de relógio. (os valores à esquerda foram obtidos com versão 3.5 da
AMS, à direita versão 3.6)
Tabela 4. 3:Resumo dos resultados de simulação com PLI activando todos os estados
Optimizado_desempenho
20.0 ns / 19.9 ns
Optimizado_área
20.0 ns / 19.9 ns
Realizaram-se de saída testes mais longos, com 1 000 vectores aleatórios (padrão de teste T3) e
10 000 vectores aleatórios (padrão de teste T4). Os valores obtidos em desempenho e área para a
versão escolhida estão registados na Tabela 4. 4.
Tabela 4. 4: Resultados de simulação com PLI para diferente número de vectores de entrada
Optimizado_ desempenho
Optimizado_área
1 000 vectores
24.0 ns
22.0 ns
10 000 vectores
24.0 ns
22.0 ns
Por verificação da tabela e observando que a versão optimizada em desempenho piorou em
termos de período, seleccionou-se assim a versão optimizada em área porque embora os tempos
de relógio sejam idênticos para ambas, a área é menor7.
4.2. Implementação FPGA. BIST Funcional
Na
Figura 4. 9, representam-se os módulos do DAE divididos pelas diferentes FPGA's.
FPGA DAQ (x8)
FPGA
DBUS
Trigger TGR/
DCC
UNIDADE
FE
DAQ
FILTRO
DE
MEMORIA
GBUS
DCC
(ROC)
PC
Figura 4. 9 – Agrupamento de módulos do DAE nas FPGA's.
7
Note-se que nos resultados presentes nos relatórios obtidos no capítulo Criação da Test-bench e Teste do Circuito,
os valores baseiam-se em bibliotecas da ferramenta da Synopsyis. Os resultados obtidos neste capítulo baseiam-se em
bibliotecas da Cadence, cujos modelos são diferentes, dai a discrepância de resultados. Como a ferramenta de
simulação é da Cadence, são os valores obtidos pela mesma considerados para efeitos de decisão.
26
Como se pode observar na
Figura 4. 9, a FPGA TGR/DCC contém os módulos Trigger e Concentrador de Dados (DCC). Os
módulos Aquisição de Dados, Filtro e Unidade de Memória estão na segunda FPGA, denominada
FPGA DAQ. Dado o volume de dados de entrada no DAE, foi necessário recorrer a 8 FPGA’s
DAQ.
Toda a comunicação entre o sistema DAE e o computador é realizada através do módulo
denominado Controlador de Saída da Electrónica de Aquisição de Dados (DCC ROC ou
RD_ROC).
O teste deste sistema está longe de constituir uma tarefa trivial. Numa primeira
aproximação, poder-se-ia pensar em utilizar cadeias de varrimento. Contudo, as configurações
das FPGA’s em modo de teste e de funcionalidade normal, neste caso, são diferentes acarretando
comportamentos diferentes, particularmente no que se refere ao cumprimento dos requisitos de
desempenho.
Por outro lado, o teste que faz sentido realizar não é um teste estrutural, na medida em que
os fornecedores da tecnologia, asseguram a ausência (quase total) de defeitos nos componentes.
Assim, o que é necessário, na realidade, é realizar um teste funcional e de desempenho do
sistema.
A necessidade de testar o comportamento, não só do sistema como um todo, mas, para
efeitos de diagnóstico, testar o comportamento dos vários módulos que o constituem, motivou o
desenvolvimento de um teste funcional integrado [9]. Trata-se de um auto-teste, na medida em
que os próprios vectores de teste estão incorporados nas FPGA’s e o teste pode ser despoletado
do exterior ou internamente (por exemplo, na ligação do sistema). Uma vez que, na configuração
da FPGA, nem todos os recursos são atribuídos, é possível implementar a funcionalidade de
BIST funcional sem sobrecarga em área – isto é, no mesmo componente. Verificou-se que a
degradação de desempenho, devido à atribuição de mais recursos na FPGA, é limitada.
O auto-teste funcional (Functional BIST) é realizado cada vez que o sistema é ligado,
cada vez que se faz o reset do sistema, ou a pedido do utilizador. Pode ser realizado num
ambiente de produção para validação do protótipo ou durante a vida útil do sistema.
Adicionalmente, o teste incorporado permite verificar o funcionamento correcto do
sistema, relativo à sua funcionalidade e desempenho, em todos os seus modos de funcionamento,
bem como, verificar o funcionamento correcto dos barramentos que garantem a comunicação
entre as diversas FPGA’s que constituem o sistema.
Como se pode observar na Figura 4. 10, a profundidade do teste é escolhida pelo
projectista. De facto, para cada cenário de operação podem identificar-se processos, módulos,
funções, etc. A cada um destes elementos corresponde uma assinatura, que representa o resultado
correcto da execução funcional desse elemento para um dado padrão de teste. Esta assinatura é
comparada com o resultado do teste, para os diferentes elementos, duma forma hierárquica e é
gerado um bit de verdade. Se as assinaturas correspondentes coincidirem, o bit de verdade é
colocado a um dado valor (0 ou 1 consoante o projectista achar conveniente).
27
Para cada cenário
Identificação do cenário
Para cada processo do cenário
Identificação do processo
Entrada de Dados/Controlo do processo
Para cada módulo no processo
Identicação do módulo
Entrada de Dados/Controlo do módulo
Para cada função do módulo
Identificação da função
Entrada de Dados/Controlo da função
……….
……….
Saída dos Dados/Controlo da função
Geração da assinatura da função
Geração dos bit de verdade da função
Fim da Função
Saída dos Dados/Controlo do módulo
Geração da assinatura do módulo
Geração dos bit de verdade do módulo
Fim do Módulo
Saída dos Dados/Controlo do processo
Geração da assinatura do processo
Geração dos bit de verdade do processo
Fim do Módulo
Geração da assinatura do processo
Geração dos bit de verdade do processo
Fim do cenário
Figura 4. 10 – Descrição esquemática da estratégia de teste.
Se o que se pretende obter com o teste é um resultado correcto/incorrecto (go/no go) então
o resultado final será o bit de verdade. Se se pretende obter um resultado para diagnóstico, então
pode construir-se uma palavra com os bits de verdade. O valor de cada bit indica a correcção ou
incorrecção do funcionamento do elemento em teste que lhe corresponde.
Para se obter um teste eficiente e confiável é necessário dispor de um conjunto de
vectores de teste adequados para o efeito. No caso presente, foram desenvolvidos mecanismos de
geração de vectores de teste funcionais a ser aplicados segundo a estratégia de teste préestabelecida.
Para testar as FPGA’s foram implementados em cada FPGA, controladores locais de
teste, nomeadamente, o controlador local de teste da DAQ, referido como DAQ Test na FPGA
DAQ e o controlador local de teste da TGR/DCC referido como TGR/DCC Test na FPGA
TGR/DCC.
Cada um destes controladores locais de teste realiza as seguintes funções:
• Gera localmente os vectores de teste necessários para o teste de cada módulo da FPGA,
• Indica, através de um sinal de controlo, a um multiplexer de teste que direccione para a
entrada do módulo em teste os vectores de teste, em vez dos dados relativos ao
funcionamento normal do sistema.
• Recebe os resultados do módulo em teste e compara com assinaturas pré-definidas.
Na Figura 4. 11 apresenta-se a arquitectura genérica do controlador local de teste.
28
Controlador Local de Teste
Gerador de
Vectores de
Teste
Controlo
BIST
funcional
Comparador
Módulo em
Teste
(RD_ROC)
Mux
Dados
de
Entrada
Assinatura
Dados
de
Saída
Figura 4. 11 – Arquitectura genérica do controlador local de BIST funcional.
Como se pode observar na Figura 4. 11 o controlador local de teste é constituído por: (1)
um módulo de controlo, (2) um bloco gerador de vectores de teste e (3) um comparador de
assinaturas.
O bloco de controlo é uma máquina de estados que comanda os restantes blocos do
controlador local de teste bem como o multiplexer de teste.
Os vectores de teste podem ser gerados de uma forma pseudo-aleatória, recorrendo à
utilização de circuitos (exemplo de LFSR – Linear Feedback Shift Register), ou podem ser
vectores de teste determinísticos que permitam cobrir o maior número possível de faltas, No
último caso, os vectores e as assinaturas correspondentes são previamente armazenados em
memória. Em qualquer dos casos, os vectores devem permitir uma elevada cobertura de erros
funcionais em todos os modos de funcionamento.
O comparador de assinaturas compara o resultado do teste com a assinatura previamente
carregada em memória. O resultado de uma comparação estabelece o valor do bit de verdade.
Para permitir o diagnóstico, armazenam-se em registos os resultados de cada comparação.
Estes registos são ligados em série, de modo a que seja possível fazer um deslocamento de todos
os bits de verdade para um local observável. Se todos os bits de verdade estiverem activos, podese afirmar que o circuito passou no teste. O controlador local de teste armazena todos os bits de
verdade referente ao teste da sua FPGA.
Placa TGR/DCC
FPGA TGR/DCC
DCC
TGR/DCC
ROC
DCC
ROC
QL 5064
TGR
Falta a legenda
29
PC
4.3. Implementação ASIC. Fluxo de projecto com BIST Estrutural.
Para a realização deste projecto com BIST estrutural idealizou-se uma arquitectura
simples, como se pode visualizar na Figura 4. 12. Os blocos são apresentados em maior pormenor
nos capítulos seguintes.
Figura 4. 12 - Arquitectura BIST utilizada
30
Na Figura 4. 13 apresenta-se o fluxo de
projecto para introdução de BIST
estrutural num CUT sequencial que se
propõe neste trabalho. Note-se que este
diagrama é uma continuação do diagrama
apresentado na Figura 3. 1. Como se
observa, o procedimento para a geração
dos diferentes blocos do hardware de
BIST é idêntico ao realizado para o CUT.
Neste caso usa-se a ferramenta
Verifaul™t da Cadence para verificar a
cobertura de faltas e validar o circuito
com BIST. No passo de simulação lógica
do CUT já com a funcionalidade de autoteste, pode reutilizar-se a metodologia de
estimação da máxima frequência de
relógio, e desse modo avaliar a
degradação de desempenho que a
funcionalidade de BIST introduz no
circuito, quando opera em modo normal
de funcionamento.
Figura 4. 13 – Fluxo de projecto BIST estrutural
4.3.1. Gerador de Vectores de Teste Pseudo-aleatório (PRPG)
O test pattern generator usado pode ser dividido em dois blocos. A Figura 4. 14
representa a arquitectura utilizada.
O primeiro bloco é um LFSR (Linear Feedback ShiftRregister) de tipo 2, tamanho N
igual a 20. A arquitectura de uma LFSR resume-se a um anel de Flip Flop’s com realimentações
em alguns dos FF. Essas realimentações são feitas com portas lógicas XOR e não são escolhidas
ao acaso, têm de respeitar o vector determinístico8. Neste caso (N=20) foi usada a expressão
x 20 + x 3 + 1 = 0 (polinómio primitivo). Um anel de 20 FF tem uma dimensão significativa. A
título de exemplo, apresenta-se na Figura 4. 15 um LFSR com N=4 cujo vector determinístico é
x4 + x3 + 1 = 0 .
8
Garante que são gerados 2N-1 vectores distintos, que se repetem ciclicamente em blocos de N-1
31
Figura 4. 14 - Gerador de vectores pseudo-aleatórios
Figura 4. 15 - Exemplo de LFSR com N=4
Como o número de entradas do circuito (275) é superior ao tamanho do LFSR, criou-se
à saída do mesmo uma cadeia com 254 flip flop's (o reset é controlado pelo controlador BIST) de
forma a garantir que é feita a entrada de 275 bits em paralelo nas entradas principais. O último
Flip Flop também alimenta a entrada da cadeia de scan.
4.3.2. Multiplexer
O Multiplexer de 275 entradas (Figura 4. 16) tem uma função simples, deixar passar os
valores do utilizador, provenientes do exterior, no modo normal, ou deixar passar os valores
pseudo-aleatórios, provenientes do LFSR, no modo de teste.
32
Figura 4. 16 - MUX
4.3.3. Circuito Sob Teste (CUT)
Circuit Under Test, é o circuito que vai ser testado. No presente trabalho esse circuito é o
RD_ROC mas com uma cadeia de scan e é apresentado no capítulo 4.3.7 (Circuito RD_ROC).
4.3.4. Compactador
O compactador (Figura 4. 17) tem um hardware similar ao do LFSR. Contudo, a sua
função é totalmente diferente. A ideia base do compactador é comportar-se como um somador
porque vai “agrupando” a nova resposta com as respostas já obtidas. Desta forma, cria-se uma
chave única. Como a cada teste se garante que os estímulos de entrada são sempre os mesmos, as
respostas a estes também serão sempre as mesmas assim como a chave criada. Esta chave apenas
muda se uma ou mais das respostas for diferente do esperado, ou seja, uma ou mais faltas.
Figura 4. 17 - Compactador
33
4.3.5. Comparador
O comparador é um bloco simples onde se compara a “palavra” obtida no comparador
com a “palavra” esperada. Esta comparação é feita bit a bit, passando os bits do mesmo “peso”
pela mesma porta lógica XOR. O NOR de todos os blocos anteriores, assegura que no caso de
existir pelo menos um bit diferente do esperado, o valor lógico na saída é 0. Na Figura 4. 18 é
apresentado um comparador.
Figura 4. 18 - Comparador
4.3.6. Registo de Assinatura
A palavra (assinatura) é o valor que se espera ter no final do teste no compactador. Para se
conseguir testar se o resultado obtido é o resultado esperado, tem de se ter esse resultado
guardado num registo. Este bloco realiza essa mesma função, guardar a palavra que vai ser
comparada com o resultado obtido no comparador. Na Figura 4. 19 pode-se ver o modelo de um
registo de assinatura.
Figura 4. 19 - Registo de assinatura
4.3.7. Desenvolvimento e Implementação do BIST
Neste capítulo apresenta-se o circuito BIST realizado, ou seja, a evolução do circuito
idealizado nos capítulos anteriores até ao circuito realizado. Os blocos foram todos descritos em
VHDL, com recurso ao Webpack da Xilinx (o código VHDL de cada um dos blocos é
apresentado em anexo, na secção: código VHDL dos diferentes blocos). A simulação lógica do
34
circuito foi feita com Modelsim de forma a verificar o funcionamento correcto do BIST, antes de
se proceder à síntese. O processo de síntese é idêntico ao realizado para o ficheiro RD_ROC no
capítulo 4.1.1. Em seguida são apresentados os blocos obtidos.
A Figura 4. 20 representa a diagrama de topo do BIST. Tem 4 entradas e 3 saídas
Figura 4. 20 - top level, package
Na Tabela 4. 5 é apresentada uma descrição das entradas e saídas do bloco.
Tabela 4. 5:portos de Top_level
Sinal
test_bist
Reset
data_in
Clk
Data_out
Bist_result
Bist_done
Tipo
Bits
entrada 1
entrada 1
entrada 275
entrada 1
saída
68
saída
1
saída
1
Descrição
Quando activo a 1 inicia o modo de test BIST off-line
“reset” aos registos
Entrada de dados equivalente a entrada de dados de RD_ROC
Frequência de relógio
Saída de dados equivalente a saída de dados de RD_ROC
Quando activo a 1 indica que o teste passou, apenas faz quando
bist_done estiver activo
Quando activo a 1 indica que o teste acabou
No modo de funcionamento normal (test_bist desligado) o circuito tem comportamento
idêntico a RD_ROC, sendo as entradas clk, data_in e a saída data_out. Data_in tem 275 pinos e
estes correspondem a:
• Pino 0 – reset
• Pino 1 – onoff
• Pino 2 – int_req_onoff
• Pino 3 – empty_fout
• Pino 4 – int_readyerr
• Pino 5 – full_bbus
• Pino 6 a 249 – dout_fout
• Pino 250 a 274 – int_errcount
35
Data_out tem 68 pinos e estes correspondem a:
• Pino 0 – wr_bbus
• Pino 1 – rd_fout
• Pino 2 – int_doneerr
• Pino 3 a 66 – dout_bbus
• Pino 67 – dcc_busy
A Figura 4. 21, que apresenta os blocos internos do BIST, foi obtida após síntese no
Design_Vision (Synopsys).
Figura 4. 21 – Circuito RD_ROC com BIST estrutural
Todos estes blocos são apresentados em seguida.
Bloco TPG
O test pattern generator criado baseia-se num LFSR de 20 bits do tipo do apresentado no
capítulo 4.3.1. Este é seguido de uma cadeia de 254 registos (Flip-Flop's) que somados aos 20 da
LFSR criam 274 saídas. Estas saídas correspondem as entradas do CUT, excepto CLK e RESET,
a primeira é externa e o reset (em modo de teste) é controlado pelo controlador BIST. A cadeia
de scan do CUT (capítulo 4.3.7 (Circuito RD_ROC)) tem 373 registos e a entrada da mesma é
feita em modo série. Assim, são necessários 373 impulsos de clock até que se preencha a cadeia.
Nessa altura os 274 bits de entrada paralela vão ser utilizados. Na Figura 4. 22 é apresentado o
bloco TPG e na Tabela 4. 6 têm um resumo dos Portos do circuito. O vector inicial da LFSR
(designado por semente) pode influenciar a cobertura de faltas, porque quando se executa o teste
raramente se usam todos os vectores e alguns detectam mais faltas que outros.
36
Esta LFSR é do tipo “galois”, mais conhecido por LFSR modular. É um pouco mais
complicado de implementar, comparativamente a LFSR “fibonacci ”, mais conhecido por LFSR
linear, porque os xor ficam entre os flip-flops e tem que se adicionar mux’s para poder converter o
LFSR em registo de deslocamento. No entanto, geram vectores pseudo-aleatórios menos corelacionados entre si, ou seja, um pouco mais aleatórios, conduzindo normalmente a melhores
resultados para a cobertura de faltas [14].
Figura 4. 22 – LFSR, package
Tabela 4. 6:Portos de LFSR
Sinal
Tipo
bits
Descrição
Clock entrada 1
Frequência de relógio
Reset
entrada 1
“reset” aos registos
Enable entrada 1 Controla o arranque do módulo
data_out saída 274
dados de saída
Bloco MUX 275
Este bloco (Figura 4. 23) descreve um multiplexer com duas entradas de 275 bits e uma
saída de 275 bits comutadas por uma linha de controlo. As saídas representam as entradas de
dados do CUT, como se pode verificar na Tabela 4. 7.
Figura 4. 23 – mux, package
37
Tabela 4. 7:Portos de Mux
Sinal
Tipo
Bits
A
entrada 275
B
entrada 275
Control entrada 1
C
saída 275
Descrição
Dados do exterior
Dados da LFSR(274 bits) e reset(1 bit)
Comuta entre as duas entradas
Dados para as entradas primarias e cadeia de scan
Circuito RD_ROC
O circuito RD_ROC apresentado no capítulo 4.1 foi alterado de forma a ser mais fácil
testar. Essa alteração consistiu na introdução de uma cadeia de scan.
A cadeia de scan do circuito RD_ROC é idêntica à explicada no capítulo 2.2. A única
diferença é o número de registos de memória, que neste caso é de 373. Para introduzir a cadeia de
scan utilizou-se mais uma vez o software da Synopsys, o design_vision. Esta cadeia é inserida
automaticamente. O circuito obtido é apresentado na Figura 4. 24.
Figura 4. 24 – RD_ROC com scan, package
38
Comparando a Figura 4. 24 com a Figura 4. 1 nota-se que foram introduzidas duas
entradas, tal como era esperado, mas não foi inserida uma nova saída. Isso deve-se ao facto do
software não permitir a introdução da mesma, delegando assim esse efeito para uma das saídas
normais do circuito, visto as mesmas não terem à partida interesse quando a cadeia de scan está
activa. A saída wr_bbus foi a escolhida pelo programa para a realização dessa função.
Na Figura 4. 25 é apresentado o relatório de área, que permite verificar o aumento
percentual de área ocasionado pela funcionalidade de BIST. Comparando-se com a
Figura 4. 5 conclui-se que é de cerca 6.7%.
****************************************
Report : area
Design : rd_roc
Version: V-2004.06-SP1
Date
: Wed May 24 00:10:18 2006
****************************************
Number
Number
Number
Number
of
of
of
of
ports:
nets:
cells:
references:
346
1856
1229
55
Combinational area:
Noncombinational area:
Net Interconnect area:
730559.875000
1031803.812500
4638.004883
Total cell area:
Total area:
1762368.000000
1767001.750000
***** End Of Report *****
Figura 4. 25 – Relatorio de area de Rd_roc com cadeia de scan
Na Tabela 4. 8 apresenta-se um resumo dos portos do circuito.
Tabela 4. 8:Portos de RD_ROC com scan
Sinal
Tipo
Bits
Descrição
Clk
Reset
onoff
int_req_onoff
empty_fout
int_readyerr
full_bbus
Dout_fout(243 downto 6)
int_errcount(24 downto 0)
Test_se
test_si
Wr_bbus
Rd_fout
entrada
entrada
entrada
entrada
entrada
entrada
entrada
entrada
entrada
entrada
entrada
saída
saída
1
1
1
1
1
1
1
244
25
1
1
1
1
Frequência de relógio
“reset” aos registos
Ver capítulo 4.1
Ver capítulo 4.1
Ver capítulo 4.1
Ver capítulo 4.1
Ver capítulo 4.1
Ver capítulo 4.1
Ver capítulo 4.1
Activa modo scan
Entrada de dados scan
Saída de dados e scan
Saída de dados
39
Int_doneerr
Dout_bbus
Dcc_busy
saída
saída
saída
1
64
1
Saída de dados
Saída de dados
Saída de dados
Note-se que a entrada test_si pertence ao mesmo nó que a entrada int_errcount(24). Isto
deve-se ao facto de ambas pertencerem ao nó que contem a ultima saída do TPG e a primeira ter
importância quando a cadeia de scan esta activa e a outra nos restantes casos.
Bloco COMPACTADOR (MISR)
O compactador MISR possui 68 entradas de dados, as equivalentes ao número de saídas
do circuito, como se pode constatar na Tabela 4. 9.
.
Tabela 4. 9: Portos de Compactador
Sinal
Tipo bits
Descrição
data_in entrada 68
Entrada de dados
clock
entrada 1 Frequência de relógio
reset
entrada 1
“reset” aos registos
data_out saída
68
Saída de dados
.
Figura 4. 26 – compactador, package
Este compactador tem como função
“acumular” as saídas paralelas do circuito e a
saída da cadeia de scan. O resultado final é
quase único, dependendo de todos os valores
que entraram no compactador. Relembra-se
que a saída de dados da cadeia de scan é a
saída wr_bbus. Como são necessários 373
ciclos de relógio para preencher/esvaziar a
cadeia de scan e apenas um para aplicar o teste,
pode-se dizer que durante os 373 ciclos entra
no compactador o vector da cadeia de scan e
num ciclo as saídas primárias. Isto não é
inteiramente verdade. Neste trabalho optou-se
por se ler sempre as saídas primarias (excepto
wr_bbus por ser multiplexada) com o intuito de
tentar detectar mais faltas, visto que durante o
processo de preenchimento da cadeia de scan,
o CUT vai dar respostas aos estímulos que
estão presentes nos registos de memoria a cada
ciclo de relógio. A
Figura 4. 26
apresenta o compactador depois de sintetizado
40
Bloco CONTROL
O controlador é o bloco coordenador do BIST porque tal como o nome indica, controla
todos os blocos e operações. É necessário que este esteja bem feito de modo a garantir que tudo é
feito no tempo, caso contrario não se obtém uma boa cobertura de faltas. Na Tabela 4. 10.
Tabela 4. 10: Portos de control
Sinal
Tipo
Bits Descrição
Clk
Reset
Test_bist
Data
Scan_en
Reset_tpg
Reset_cut
Reset_misr
Enable_misr
Bist_result
entrada
entrada
entrada
entrada
saída
saída
saída
saída
saída
saída
1
1
1
68
1
1
1
1
1
1
Bist_done
saída
1
Frequência de relógio
“reset” aos registos
Ordem de inicio de test
Resultado do compactador a ser comparado com a chave
Activa o modo de preenchimento da cadeia de scan no CUT
Reset ao TPG
Reset ao CUT
Reset ao compactador
põe o compactador “on-line”
Quando activo a 1 indica que o teste passou, apenas faz quando
bist_done estiver activo
Quando activo a 1 indica que o teste acabou
Repare-se que uma das entradas do controlador é uma entrada de dados de 68 bits. Este
valor é o valor de saída do compactador. Normalmente este resultado deveria seguir para o
comprador de modo a ser comparado com o registo de assinatura. Como estes blocos foram
descritos em VHDL e era muito mais simples fazer a comparação por comandos IF, esta
funcionalidade foi embebida no controlador porque é o único bloco em que se deve aceitar este
tipo de instruções (a instrução IF tem de estar dentro de um procedimentos e por razões de
coerência e organização o único bloco que tem procedimentos é o controlador). Resumindo, os
blocos comparador e registo de assinatura estão incluídos no controlador. Na Figura 4. 27
apresenta-se o bloco do controlador.
41
Figura 4. 27 – controlador, package
O controlador foi realizado recorrendo a uma máquina de estados, idealizada de forma a
ser o mais fiável possível sem que isso levasse a um número de estados exagerado. Assim
chegou-se a uma máquina, apresentada na Figura 4. 28, com apenas 7 estados.
42
A máquina de estados só sai do estado de
INÍCIO no caso de o teste bist ter sido
activado. Se em qualquer altura este for
desactivado, volta-se imediatamente ao
estado inicial. Estes testes são facilmente
perceptíveis no diagrama, visto se
encontrarem em cor amarela.
O primeiro passo do teste é fazer um
reset ao TPG, de forma a assegurar que
este inicia sempre da mesma forma e o
mesmo para o CUT (RESET_TPG). Em
seguida enche-se a cadeia de scan bit a
bit, até completar os 373 bits da cadeia
(FILL_SCAN). Como o reset do CUT
não garante que todos os elementos de
memória tenham sido limpos e estes
sofrem um shift para dentro do
compactador durante o estado anterior,
executa-se um reset ao compactador e
um clock no CUT(RESET_MISR).
No estado seguinte esvazia-se a cadeia de
scan para o compactador. A cadeia de
scan é preenchida ao mesmo tempo que
esvazia. O estado TEST injecta um clock
no CUT de forma a obter resposta ao
vector que se encontra na cadeia de scan,
tal como em RESET_MISR. No caso de
ainda não se terem testados os vectores
estipulados,
recua-se
ao
estado
EMPTY_SCAN de forma a obter um
novo resultado. Caso contrário, passa-se
ao estado BIST_END onde se activa a
saída bist_done e se indica se o teste teve
sucesso ou não.
Note-se que existe um reset assíncrono
prioritario no estado INICIO. A função
deste reset é assegurar que o circuito não
arranca num estado não definido.
Figura 4. 28 – Máquina de estados do controlador
43
4.4. Análise de Resultados
4.4.1. Cobertura de Faltas do Circuito RD_ROC sem BIST Estrutural
No seguimento dos testes efectuados no capítulo 4.1.3, concluiu-se qual o circuito
escolhido (versão 3 / optimizado_área) para implementar a funcionalidade de BIST estrutural
(versão ASIC). Nesta secção apresentam-se resultados de simulação de faltas sobre este circuito,
com vectores pseudo-aleatórios e com vectores utilizados na versão FPGA com BIST funcional.
Pretende-se analisar a cobertura de faltas, FC. Primeiro utilizam-se 10 000 vectores pseudoaleatórios (padrão de teste T4), número escolhido tendo em conta a obtenção de um resultado de
cobertura de faltas aceitável sem que a simulação dure muito tempo. Este teste é feito injectando
um vector de 254 bits a cada ciclo de relógio. Assim, a aplicação do padrão de teste T4 tem a
duração de dez mil ciclos de relógio. Os resultados são apresentados na Figura 4. 29.
L101 "./rd_roc_tb.v": $finish at simulation time 20000000000
statistics
Untestable
Drop_detected
Detected
Potential
Undetected
Drop_potential
All
end_statistics
Total #
720
8056
0
0
3572
1324
12952
Total %
62.2
0.0
0.0
27.6
10.2
Prime #
720
3438
0
0
2138
1145
6721
Prime %
51.2
0.0
0.0
31.8
17.0
Figura 4. 29 - Cobertura de faltas de RD_ROC com 10 mil vectores pseudo-aleatórios (T4)
O valor drop detected indica-nos a percentagem de cobertura de faltas, neste caso 62.2%.
Os 10.000 vectores usados são aleatoriamente gerados pela aplicação rand9. Como é de esperar, a
cobertura de faltas de um circuito sequencial sem cadeia de scan é limitada, devido à falta de
acessibilidade dos nós correspondentes aos elementos de memória (variáveis de estado).
Como se referiu, a solução gerada pelo Eng. Pedro Bento [9], de RD_ROC com BIST
funcional, não procura detectar faltas estruturais de hardware, porque o fabricante das FPGA’s é
que tem essa responsabilidade. Assim a sua solução baseia-se em identificar falhas de
funcionalidade. O auto-teste funcional utiliza 60 vectores determinísticos (padrão de teste T5),
optimizados para cobrir a funcionalidade descrita nos cenários de operação. Procurou-se avaliar
9
Ferramenta desenvolvida pelo Professor Marcelino Santos.
44
se este padrão de auto-teste funcional (padrão de teste T5) é eficaz na detecção de faltas
estruturais. Os resultados estão descritos na Figura 4. 30
L99 "./rd_roc_tb.v": $finish at simulation time 120000000
statistics
Untestable
Drop_detected
Detected
Potential
Undetected
Drop_potential
All
end_statistics
Total # Total % Prime # Prime %
720
720
46.8
2479
36.9
6063
0
0.0
0
0.0
0
0.0
0
0.0
5573
43.0
3100
46.1
1316
10.2
1142
17.0
12952
6721
361 warnings
4234 simulation events + 76769 accelerated events
CPU time: 0.1 secs to compile + 0.1 secs to link + 1.6 secs in simulation
End of VERIFAULT-XL 03.20-p003 Jul 22, 2006 23:10:17
Figura 4. 30 – Cobertura de faltas de RD_ROC com 60 vectores funcionais (T5) usados em FPGA
Como se observa, o valor de FC = 46,8% é muito reduzido, insuficiente para activar a
estrutura lógica e detectar possíveis faltas estruturais. Esse resultado é de esperar, para um
circuito sequencial e com um número tão reduzido de vectores de teste. Todavia, o circuito
RD_ROC possui um número elevado de entradas de dados. Assim, o teste funcional original
(T5), cobrindo toda a funcionalidade, pode ser repetido para muitos dados diferentes. Assim,
gerou-se um novo padrão de teste funcional (T6), baseado no padrão T5, mas em que o total de
vectores ascende agora a 10 000. Com os mesmos estímulos de controlo, utilizam-se agora
10.000 vectores distintos de dados (ver Figura 4. 31). Os vectores de controlo são repetidos a
cada 60 vectores. Os 10.000 vectores de dados foram gerados com a ferramenta rand.
45
L113 "./rd_roc_tb.v": $finish at simulation time 20000000000
statistics
Untestable
Drop_detected
Detected
Potential
Undetected
Drop_potential
All
end_statistics
Total #
720
8097
0
0
3527
1328
12952
Total % Prime #
720
62.5
3456
0.0
0
0.0
0
27.2
2117
10.3
1148
6721
Prime %
51.4
0.0
0.0
31.5
17.1
361 warnings
2030624 simulation events + 9953513 accelerated events
CPU time: 0.3 secs to compile + 0.4 secs to link + 244.0 secs in simulation
End of VERIFAULT-XL 2.50-s001 Sep 10, 2006 22:23:46
Figura 4. 31 – Cobertura de faltas de RD_ROC com vectores usados em FPGA, 10.000 vectores (T6)
Observa-se que a cobertura de faltas do teste funcional subiu de 46,8% (T5 – 60 vectores)
para 62,5% (T6 – 10 000 vectores). Comparando o resultado obtido, com o obtido anteriormente
para o teste (T4) com 10 000 vectores pseudo-aleatórios (Figura 4. 29), nota-se que o aumento de
cobertura de faltas com um teste funcional é de apenas 0.3%, relativamente ao teste pseudoaleatório.
Realizou-se ainda mais um teste funcional, utilizando o mesmo princípio (60 vectores,
repetindo-se com diferentes dados, mas com 1 000 000 vectores (padrão de teste T7)). O
resultado obtido foi FC = 62,9%, o que evidencia claramente que a assíntota de saturação da
curva FC(N), em que N é o número de vectores, se situa em cerca de 63% com o teste do circuito
RD_ROC mantendo a configuração sequencial. Conclui-se assim que os padrões de teste
funcional, utilizados na versão FPGA, não são uma mais valia para efeitos da cobertura de faltas
estruturais, relativamente a um padrão de teste pseudo-aleatório com o mesmo número de
vectores.
4.4.2. Cobertura de Faltas do Circuito RD_ROC com BIST Estrutural
Antes de analisar a cobertura de faltas obtida, vai-se avaliar o aumento de área do circuito.
Como se verificou anteriormente, no capítulo 4.3.7, a introdução de uma cadeia de scan levou ao
aumento de 6.7% do circuito RD_ROC. Em seguida apresenta-se duas figuras, nas quais se pode
46
analisar o valor de área do circuito com BIST (top_level) e a área de cada um dos blocos do
circuito, Figura 4. 32 e Figura 4. 33 respectivamente.
****************************************
Report : area
Design : top_level
Version: V-2004.06-SP1
Date
: Wed May 24 00:04:33 2006
****************************************
Library(s) Used:
cxx_HRDLIBL (File:
/soft/ams/3.7/synopsys/cxx_3.3V/cxx_HRDLIB
L.db)
cxx_HRDLIB (File:
/soft/ams/3.7/synopsys/cxx_3.3V/cxx_HRDLIB
.db)
cxx_IOLIB (File:
/soft/ams/3.7/synopsys/cxx_3.3V/cxx_IOLIB.
db)
Number
of ports:
348
Figura
4. 32 – Área do circuito com
BIST
Number of nets:
970
Number of cells:
5
Number of references:
5
Combinational area:
Noncombinational area:
Net Interconnect area:
1527257.750000
2495635.000000
8815.467773
Total cell area:
Total area:
4022872.500000
4031708.250000
***** End Of Report *****
47
****************************************
Report : reference
Design : top_level
Version: V-2004.06-SP1
Date
: Wed May 24 00:12:24 2006
****************************************
Attributes:
b - black box (unknown)
bo - allows boundary optimization
d - dont_touch
mo - map_only
h - hierarchical
n - noncombinational
r - removable
s - synthetic operator
u - contains unmapped logic
Reference
Library
Unit Area
Count
Total Area
Attributes
----------------------------------------------------------------------------Misr
321965.375000
1 321965.375000 h, n
TPG
1106229.625000
1 1106229.625000 h, n
control
406849.562500
1 406849.562500 h, n
mux275
321892.437500
1 321892.437500 h
rd_roc
1865935.500000
1 1865935.500000 h, n
----------------------------------------------------------------------------Total 5 references
4022872.500000
***** End Of Report *****
Figura 4. 33 – Área dos diferentes blocos do circuito RD_ROC com BIST estrutural
Como se observa, o aumento de área de implantação é muito elevado, da ordem dos
140%. Neste caso em que o CUT é de complexidade reduzida, a estrutura de BIST estrutural é
maior que a do circuito RD_ROC. Pela analise dos resultados ilustrados na Figura 4. 33 verificase que o problema se deve principalmente à dimensão do bloco TPG. Devido ao elevado número
de entradas do CUT, que conduziu a um bloco TPG com 373 Flip-Flop’s, o resultado penaliza
severamente a área final do circuito.
Antes de se pensar numa redução da área do circuito deve ser analisada a cobertura de
faltas, FC. Para efectuar a simulação de faltas foi feita uma nova test_bench que é aplicada ao
bloco top_level. Merece relevo o facto de que o tempo de teste, com a introdução e retirada de
palavras digitais da cadeia de scan, se torna agora muito mais elevada. Por exemplo, se se utilizar
os mesmos N’ = 10 000 vectores pseudo-aleatórios a aplicar ao RD_ROC, são agora precisos
(373+1)xN’ = 3 740 000 vectores (ou ciclos de relógio) para realizar a sessão de BIST. No anexo
BIST Test Bench pode-se verificar o código da nova test_bench. Esta simulação leva em media 3
dias (em que máquina?) e são necessárias máquinas com um considerável volume de memória
disponível para a sua realização (qual o espaço de memória da máquina utilizada?). O resultado
obtido para 10 mil vectores pseudo-aleatorios é apresentado na Figura 4. 34.
48
L111 "./bist10_tb.v": $finish at simulation time 8712091000000
statistics
Total # Total % Prime #
Untestable
46
46
86.8
7158
Drop_detected 15646
Detected
0
0.0
0
Potential
0
0.0
0
Undetected
1115
6.2
679
Drop_potential
1269
7.0
1177
All
18030
9014
end_statistics
Prime %
79.4
0.0
0.0
7.5
13.1
492 warnings
218948159 simulation events + 1899556331 accelerated events
CPU time: 0.1 secs to compile + 0.2 secs to link + 27528.8 secs in simulation
End of VERIFAULT-XL 03.20-p003 Jul 23, 2006 18:02:24
Figura 4. 34 – Cobertura de Faltas com BIST
Pode-se verificar pela figura que a cobertura de faltas subiu significativamente, sendo o
valor de FC = 86.8%. Este valor está ainda longe dos 95% desejados. Contudo, existem apenas
46 faltas que não são detectadas. De qualquer forma, pode concluir-se que a introdução da cadeia
de scan foi um sucesso, comparativamente ao caso anterior em que existiam 720 faltas não
detectáveis (Figura 4. 29). A obtenção de um valor mais elevado de FC com esta estrutura é
possível, introduzindo alguns (poucos) vectores determinísticos para cobrir as 46 faltas
remanescentes. Poder-se-ia repetir a simulação com diferentes vectores iniciais (sementes) no
bloco TPG, ou alterar o tamanho do polinómio (capítulo 4.3.1). Devido a problemas nos
computadores, licenças e configurações da Synopsys durante a realização do trabalho não foi
possível efectuar sínteses a partir desta altura sendo impossível alterar o bloco TPG e obter outros
resultados de cobertura de faltas. Estas experiências com a solução de BIST estrutural
demonstram que o aumento de acessibilidade das variáveis de estado garante a eficácia do autoteste estrutural.
A fim de avaliar a degradação de desempenho do circuito, devido a introdução do
hardware de BIST, fez-se uma simulação para avaliar a frequência máxima de funcionamento do
circuito. Para este teste foram usados os mesmos parâmetros, usados no teste apresentado na
Tabela 4. 4, de forma a comparar as duas soluções e avaliar o nível de degradação. Note-se que o
circuito em questão é o optimizado em área. O período de relógio mínimo obtido para a solução
com BIST, é de 24 ns, mais 2 ns que a solução sem BIST. À partida este valor parece ser
reduzido. Analisando o hardware introduzido, nota-se que os sinais não têm um caminho muito
mais longo a percorrer. Quando o circuito BIST funciona em modo normal, os sinais apenas tem
de atravessar o multiplexer, e obviamente o módulo RD_ROC. O atraso causado pelo multiplexer
49
é muito reduzido e as alterações no RD_ROC remetem-se a introdução da cadeia de scan, ou
seja, uma alteração nos Flip-Flop’s de modo a que estes aceitem entrada de dados pela cadeia.
Estas alterações a nível de caminho crítico são mínimas, dai os 2 ns de diferença. Deste modo,
pode concluir-se que a degradação de desempenho da solução BIST estrutural é, para este caso de
estudo, diminuta.
5. Conclusões
Como se referiu, este Trabalho Final de Curso tinha um objectivo duplo. Primeiro,
recorrendo-se a sistemas de projecto automático comerciais (Xilinx, Synopsys e Cadence), definir
o fluxo de projecto para uma inserção eficiente de BIST estrutural, tendo em consideração as
vantagens e limitações de cada solução BIST. Segundo, discutir a possibilidade de desenvolver
uma solução unificada de BIST para implementar o auto-teste funcional e estrutural.
O trabalho foi realizado utilizando um caso de estudo do mundo real, um controlador
(RD_ROC) de leitura de um sistema electrónico de aquisição de dados para imagiologia médica
(mamografia, com recurso a tecnologia PET). Nesta aplicação, existia previamente uma solução
de BIST funcional numa implementação em FPGA [9]. Neste TFC, desenvolveu-se um fluxo de
projecto para inserção de BIST estrutural com varrimento (test-per-scan) (baseada em
implementação ASIC) e comparam-se as duas soluções. A comparação tomou em consideração
diversas métricas de qualidade do teste, em particular a eficácia do teste, TE (medida pela
cobertura de faltas do tipo linha fixa a (LSA), FC), a sobrecarga do teste, TO (aferida pelo
aumento percentual de área estimada de silício e pela degradação percentual da máxima
frequência de operação) e o comprimento do teste, TL.
Demonstrou-se que a utilização dos estímulos de auto-teste funcional num CUT
sequencial como o do caso de estudo conduz a valores reduzidos da cobertura de faltas
estruturais. Com efeito, a definição do BIST funcional no RD_ROC determinou a utilização de
uma primeira sequência de 60 vectores (padrão T5), que cobrem a execução dos 5 cenários de
funcionamento do controlador e do sistema DAE. A aplicação desses 60 vectores conduziu a uma
cobertura de faltas, FC, de 42,5%. Uma vez que o CUT possui um número elevado de entradas de
dados (269), realizou-se um teste funcional com 10 000 vectores (padrão T6), em que a sequência
de 60 vectores é aplicada sucessivamente com valores diferentes (pseudo-aleatórios) das entradas
de dados. Nesse caso, obteve-se FC = 62,2%. Finalmente, repetiu-se a experiência com 1 000 000
de vectores (padrão T7), obtendo-se FC = 62,9 %. Este valor é ainda insuficiente para permitir
afirmar que um teste de BIST funcional conduz à detecção de praticamente todas as faltas LSA a
nível estrutural. Assim, confirma-se que o teste de um CUT sequencial, mesmo com escolha
criteriosa de vectores de controlo (os 60 vectores), não assegura um teste estrutural de qualidade.
Contudo, a circunstância de manter o carácter sequencial do CUT, não o reconfigurando em
modo de teste, permite aplicar o teste at-speed (isto é, à frequência nominal de trabalho) e
realizar uma sessão de auto-teste rápida com elevado número de vectores de entrada. A utilização
de padrões de teste funcional não conduziu a melhoria significativa na cobertura de faltas,
relativamente à utilização de padrões pseudo-aleatórios.
Contudo, se os estímulos de auto-teste funcional forem utilizados para verificar que a
funcionalidade é correcta, então as faltas associadas à estrutura que realiza a funcionalidade-alvo
da aplicação são detectadas por este padrão de teste funcional. Assim, para este objectivo, o teste
funcional pode ser reutilizado como teste estrutural parcial. Por outras palavras, se o circuito não
50
for de utilização geral, não planeada ou restrita pela projectista do sistema, mas for para ser
utilizado de forma recorrente e repetitiva num conjunto limitado de cenários de utilização, com
diversos dados, então o teste funcional proposto na versão FPGA é util para validar a parte da
estrutura que efectivamente é activada nesses cenários. As faltas não detectadas não afectam o
correcto funcionamento do circuito. Desse modo, o BIST funcional revela-se muito útil, não para
o teste de produção (validando a qualidade integral de cada componente fabricado), mas para o
teste durante a vida útil do componente (validando a funcionalidade correcta e a integridade física
da estrutura que suporta a funcionalidade-alvo).
Deste modo, se na especificação do teste de produção (por exemplo, um teste numa
implementação ASIC), se exigir um teste estrutural de qualidade, é necessário recorrer a técnicas
de DfT que aumentem a acessibilidade (controlabilidade e observabilidade) dos nós internos do
CUT, nomeadamente os associados aos elementos de memória (registos). É neste contexto que se
valorizou a solução de BIST estrutural, numa arquitectura de test-per-scan. O fluxo de projecto
desenvolvido, com recurso ao simulador ModelSim™ no ambiente Xilinx, ao sistema
Design_Vision™, da Synopsys, e às ferramentas Verilog™ e VeriFault™ da Cadence, permitiu a
geração a nível RTL da infra-estrutura de BIST (MUX, Controlador de BIST, TPG
(essencialmente, o LFSR) e Analisador de Assinatura (MISR)) e a síntese lógica conjunta com o
CUT, ao qual se inseriu a possibilidade de actuação com cadeia de scan, em modo de auto-teste.
Com uma sessão de 10 000 vectores pseudo-aleatórios (excepto o sinal de Reset), obteve-se FC =
86,8%, o que é significativamente melhor que a cobertura de faltas obtida com o BIST funcional.
É fácil de entender que é possível melhorar a cobertura de faltas do BIST estrutural, já que a
geração de vectores de teste (pseudo-aleatória) pode ser melhorada. Com efeito, é conhecido o
resultado que um auto-teste apenas com vectores pseudo-aleatórios pode não ser suficiente.
Assim, pode tornar-se necessário acrescentar vectores determinísticos, o que é facilitado pela
presença da cadeia de scan. Técnicas com as de bit-flipping, ou de bit-fixing podem ser utilizadas,
melhorando adicionalmente a qualidade do teste (maior FC), podendo ainda reduzir o
comprimento do teste, TL, já que a solução desenvolvida, com uma só cadeia de scan, de n
registos, conduz a TL = n . N (neste caso, N = 10000). No caso de estudo, N=373 e TL =
3740000 vectores de teste. Uma análise cuidada da estrutura do CUT com BIST estrutural pode
sugerir medidas adicionais. Por exemplo, o CUT possui dois contadores de 32 bit, o que, como se
sabe, são muito difíceis de testar; assim, poder-se-ia fraccionar, em modo de teste, este
contadores.
A complexidade reduzida do circuito ocasionou que a sobrecarga de teste, em termos de
área de silício, é muito elevada (cerca de 140%). A implantação do bloco TPG, com elevado
número de registos, é muito onerosa em termos de área. Ter-se-á de procurar soluções
alternativas, que mantenham o carácter pseudo-aleatório dos vectores de entrada.
Adicionalmente, o tempo de aplicação do teste é elevado, devido à presença da cadeia de
scan, que requer um elevado número de ciclos de relógio para o deslocamento de entrada e de
saída de dados. A fim de reduzir o tempo de teste, a solução para este problema passa por
fraccionar a cadeia de scan em varias cadeias mais curtas, que levam menos tempo a ser
preenchidas, com o inconveniente do aumento do número de entradas.
Também, é de esperar que a potência e energia consumidas para a realização da sessão de
BIST são significativas, devido ao maior número de portas lógicas e de ciclos de relógio. Este
ultimo aspecto é especialmente sério em equipamentos portáteis, já que reduzem a autonomia das
baterias. Um circuito que aumenta a sua complexidade para mais do dobro vai aumentar o seu
consumo de energia de uma forma bastante significativa. Uma forma de reduzir este consumo é
51
tornar latente (ou inactivo) as zonas do circuito que não estejam a ser utilizadas. Durante o
processo de BIST, todo o circuito está a ser utilizado. Consequentemente, durante a sessão de
auto-teste será a altura em que o consumo de potência será mais elevado. Contudo, durante o
funcionamento normal não é assim. Com efeito, quando o circuito funciona em modo normal, o
bloco de LFSR e o bloco MISR não necessitam de estar a funcionar. A introdução de uma linha
de Enable nestes blocos leva a um menor consumo.
52
6. Referências
[1] M.L. Bushnel, V.D. Agrawal, “Essentials of Electronic Testing for Digital Memory and Mixed-Signal VLSI
Circuits”, Kluwer Academic Publishers, 2000.
[2] Charles E. Stroud, “A Designer’s Guide to Built-In Self-Test”, Kluwer Academic Publishers, Boston,
United States of America, 2002.
[3] G. Hetherington, T. Fryars, N. Tamarapalli, M. Kassab, A. Hassan, J. Rajski, “Logic BIST for Large
Industrial Designs: Real Issues and Case Studies”, Proc. IEEE Int. Test Conf. (ITC), pp. 358-367, 1999.
[4] P. Lecoq and J. Varela, 2002 “Clear-PEM, A dedicated PET camera for mammography”, Nucl. Instrum.
Meth. vol. A 486, pp. 1-6, 2002.
[5] M.C. Abreu, J.D. Aguiar, F.G. Almeida, P. Almeida, P. Bento, B. Carriço, M. Ferreira, N.C. Ferreira, F.
Gonçalves, C. Leong, F. Lopes, P. Lousã, M.V. Martins, N. Matela, P.R. Mendes, R. Moura, J. Nobre, N.
Oliveira, C. Ortigão, L. Peralta, R. Pereira, J. Rego, R. Ribeiro, P. Rodrigues, J. Sampaio, A.I. Santos, L.
Silva, J.C. Silva, P. Sousa, I.C. Teixeira, J.P. Teixeira, A. Trindade, and J. Varela, “Design and Evaluation
of the Clear-PEM Scanner for Positron Emission Mammography”, IEEE Transactions on Nuclear Science,
vol.. 53, Nº. 1, pp. 71-76, February 2006.
[6] Tecmic, http://www.tecmic.pt/eng/index.html
[7] Scott Davidson, “ITC’99 Benchmark Circuits – Preliminary Results”, Proc. IEEE International Test Conf
(ITC), pp. 1125, 1999; benchmarks available at http://www.cerc.utexas.edu/itc99- benchmarks/bench.html
[8] C. Leong, P. Bento, P. Lousã, J. Nobre, J. Rego, P. Rodrigues, L. Silva, J.C. Silva, I.C. Teixeira, J.P.
Teixeira, A. Trindade, and J. Varela, “Design and Test Issues of an FPGA Based
Data Acquisition System for Medical Imaging using PEM”, IEEE Transactions on Nuclear Science, vol..
53, nº. 3, pp. 761-769, June 2006.
[9] P. Bento “Sistema Electrónico para Organização e Encaminhamento de Dados num Sistema de Detecção de
Cancro da Mama em Tecnologia PET” Dissertação para a Obtenção de Grau Mestre em Engenharia
Electrotécnica e de Computadores pelo Instituto Superior Técnico, Abril 2006.
[10] Nandu Tendolkar, Rick Woltenberg, Rajesh Raina, Xijiang Lin, Bruce Swanson, Greg Aldrich, “ScanBased At-Speed Testing for the Fastest Chip”, Mentor Graphics, June 2001.
[11] Nur A. Touba, “Synthesis Techniques for Pseudo-Random Built-In Self-Test”, Stanford University, June
1996.
[12] Chien-In Henry Chien, “Efficient Aproaches to Low-Cost High-Fault Coverage VLSI BIST Designs”, IEEE
Transactions on Aerospace and Electronic Systems, Vol. 34, No. 1, January 1998.
[13] Bernd Koenemann, Stephen Pateras, “Built-In Self-Test (BIST) in the Era of Sub-Micron Technology”,
LogicVision, California, USA.
[14] http://www.ui.savba.sk/diag/tools/bist/
[15] http://fidelio.inesc-id.pt/dft/
53
Anexos
54
RD_ROC Test Bench
`timescale 1ns/1ps
module rd_roc_tb;
/*parameters */
parameter Num_Inputs = 274;
parameter Num_Outputs = 68;
parameter Num_Vectores = 10000; /*número de vectores de teste*/
parameter CLKa
= 2000;
/*Aux vars*/
integer index;
real half_clk,quarter_clk;
reg [0:Num_Inputs-1] input_vec;
/*Regs for assigning test vectors to circuit inputs */
reg [0:Num_Inputs-1] inputs [0:Num_Vectores];
reg clk;
reg reset;
/* circuit inputs*/
wire onoff, int_req_onoff, empty_fout, int_readyerr, full_bbus;
wire [0:243] dout_fout;
wire [0:24] int_errcount;
/*assign "inputs" to circuit inputs */
assign { int_readyerr, full_bbus, onoff, int_req_onoff, empty_fout, dout_fout[0:243], int_errcount[0:24]} =
inputs [index];
/*wires for transferring results to output */
wire [0:Num_Outputs-1] outputs;
/* circuit outputs*/
wire rd_fout, int_doneerr, wr_bbus, dcc_busy;
wire [0:63] dout_bbus;
/* assign "outputs" to wire outputs */
assign outputs = {rd_fout, int_doneerr, dout_bbus[0:63], wr_bbus, dcc_busy};
/* CUT instantiation */
55
rd_roc TOP_inst
( .clk(clk), .reset(reset), .onoff(onoff), .int_req_onoff(int_req_onoff), .dout_fout(dout_fout),
.empty_fout(empty_fout),
.rd_fout(rd_fout), .int_readyerr(int_readyerr), .int_errcount(int_errcount), .int_doneerr(int_doneerr),
.dout_bbus(dout_bbus), .wr_bbus(wr_bbus), .full_bbus(full_bbus), .dcc_busy(dcc_busy));
initial
begin
$fs_add(rd_roc);
$fs_inject;
/*variable initialization*/
index=0;
clk=0;
reset=1;
half_clk = CLKa/2;
quarter_clk = half_clk/2;
/* Getting input vectors from file */
$readmemb("./estimulos.vec",inputs);
$display ("*****************************
***************************\n");
inicio
/* Executing Simulation */
while (index < Num_Vectores)
begin
input_vec = inputs[index];
$display ("***************************** vector %d
***************************\n",index+1);
$display ("entradas\ndout_fout %b\nempty_fout %b\nfull_bbus
%b\nint_errcount %b\nint_readyerr %b\nint_req_onoff %b\nonoff %b\nreset
%b\n",input_vec[6:249],input_vec[5],input_vec[2],input_vec[250:274],input_vec[1],input_vec[4],input_vec[3],input
_vec[0]);
#quarter_clk;
#half_clk;
$fs_strobe(rd_fout, int_doneerr, dout_bbus[0:63],wr_bbus, dcc_busy);
#quarter_clk;
$display ("saidas \ndcc_busy %b\ndout_bbus %b\nint_doneerr
%b\nrd_fout %b\nwr_bbus %b\n",outputs[67],outputs[2:65],outputs[1],outputs[0],outputs[66]);
index = index + 1;
$fs_strobe(rd_fout, int_doneerr,dout_bbus[0:63],wr_bbus, dcc_busy);
reset=0;
end
//$fs_strobe(rd_fout, int_doneerr, dout_bbus[0:63],wr_bbus, dcc_busy);
56
$finish;
end
always #half_clk clk = ~clk;
endmodule
57
PLI
/* filename: pli.c */
#include "acc_user.h"
#include "veriuser.h"
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <math.h>
const numSaidas = 68; //alterar também na estrutura em baixo
typedef struct vec{
char array[68];
}element;
element *estrutura=null;
double lastclock=0;
teste() //apenas o inicio do que vai ser feito
{
//argumentos do PLI que vem do testbench (por ordem)
int numVectores = acc_fetch_tfarg_int(1);
double clk_start = acc_fetch_tfarg(2);
double clk_real = acc_fetch_tfarg(3);
int index = acc_fetch_tfarg_int(5);
handle saida;
char *vector;
int i;
//instrucoes para transformar vector binario vindo do tesbench em string
saida = acc_handle_tfarg(4);
vector = acc_fetch_value(saida,"%b",null);
//alocacao da estrutura onde se guarda as referencias
if (clk_start == clk_real && index == 0) {
// io_printf("malloc\n");
estrutura = (element *) malloc( numVectores * sizeof( element) ); //malloc mal feito
}
if (clk_start == clk_real) { //guarda em memoria as primeiras iteracoes
58
// io_printf("inserir\n");
strncpy((estrutura+index)->array,vector,numSaidas);
// io_printf("inserir2\n");
}
else
// deteccao de erros nos vectores comparando-os com a referencia
if (strncmp((estrutura+index)->array,vector,numSaidas)!=0){ //11 corresponde ao número de bits de cada vector
io_printf("ERRO\n");
io_printf("o valor do clock anterior %f e do de erro %f\n",lastclock,clk_real);
exit(0);
}
// if (index==(numVectores-1))
// lastclock=clk_real;
//escrita na saída dos diferentes valores
//io_printf("Número de vectores de entrada: %d\n",numVectores);
//io_printf("valor do clock: %f\n",clk_real);
//io_printf("Valor da ultima saída: %s\n",vector);
//io_printf("Mais um: %s\n\n",*(estrutura+index));
}
59
Código VHDL dos Diferentes Blocos
Control
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;
---- Uncomment the following library declaration if instantiating
---- any Xilinx primitives in this code.
--library UNISIM;
--use UNISIM.VComponents.all;
entity control is
Port ( clk : in std_logic;
reset : in std_logic;
test_bist : in std_logic;
data : in std_logic_vector (67 downto 0);
scan_en : out std_logic;
reset_tpg : out std_logic;
reset_cut : out std_logic;
reset_misr : out std_logic;
enable_misr : out std_logic;
bist_done : out std_logic;
bist_result: out std_logic);
end control;
architecture Behavioral of control is
type estados is (INICIO,RESET_TPG_ST,FILL_SCAN,RESET_MISR_ST,EMPTY_SCAN,TEST,BIST_END);
signal estado,p_estado: estados;
signal vectores,contador,p_vectores,p_contador: integer;
begin
process (clk)
begin
if (reset='1') then
estado <= INICIO;
elsif rising_edge (clk) then --falling_
estado <= p_estado;
contador <= p_contador;
vectores <= p_vectores;
end if;
end process;
process (estado,p_estado,test_bist,contador,vectores,data,clk)
begin
case estado is
60
when INICIO =>
reset_tpg <='0';
if (reset='1') then
reset_cut <='1';
else
reset_cut <='0';
end if;
reset_misr<='0';
enable_misr<='0';
p_contador<=0;
p_vectores<=0;
scan_en<='0';
bist_done<='0';
bist_result<='0';
if (test_bist = '1') then
p_estado <=
RESET_TPG_ST;
else
p_estado <= INICIO;
end if;
when RESET_TPG_ST =>
reset_tpg <='1';
reset_cut <='1';
reset_misr<='0';
enable_misr<='0';
p_contador<=0;
p_vectores<=0;
scan_en<='0'; --faz tambem de enable da lfsr
bist_done<='0';
bist_result<='0';
if (test_bist = '0') then
p_estado <=
INICIO;
else
p_estado <= FILL_SCAN;
end if;
when FILL_SCAN =>
reset_tpg <='0';
reset_cut <='0';
reset_misr<='0';
enable_misr<='0';
p_contador<=contador+1;
p_vectores<=0;
scan_en<='1';
bist_done<='0';
bist_result<='0';
if (test_bist = '0') then
p_estado <=
INICIO;
elsif (contador=372) then
p_estado <= RESET_MISR_ST;
else
p_estado <= FILL_SCAN;
end if;
when RESET_MISR_ST =>
61
reset_tpg <='0';
reset_cut <='0';
reset_misr<='1';
enable_misr<='1';
p_contador<=0;
p_vectores<=1;
scan_en<='0';
bist_done<='0';
bist_result<='0';
if (test_bist = '0') then
p_estado <=
INICIO;
else
p_estado <= EMPTY_SCAN;
end if;
when EMPTY_SCAN =>
reset_tpg <='0';
reset_cut <='0';
reset_misr<='0';
enable_misr<='1';
p_contador<=contador+1;
p_vectores<=vectores;
scan_en<='1';
bist_done<='0';
if (test_bist = '0') then
p_estado <=
INICIO;
elsif (contador=372) then
p_estado <= TEST;
else
p_estado <= EMPTY_SCAN;
end if;
when TEST =>
reset_tpg <='0';
reset_cut <='0'; --arranjar maneira de fazer uns resets nesta zona a partir do
número de vectores, tipo, ao vector 200 fazer reset.
reset_misr<='0';
enable_misr<='1';
p_contador<=0;
p_vectores<=vectores+1;
scan_en<='0';
bist_done<='0';
bist_result<='0';
if (test_bist = '0') then
p_estado <=
INICIO;
elsif (vectores=10) then
p_estado <= BIST_END;
else
p_estado <= EMPTY_SCAN;
end if;
when BIST_END =>
reset_tpg <='0';
reset_cut <='0';
reset_misr<='0';
62
enable_misr<='0';
p_contador<=0;
p_vectores<=vectores;
scan_en<='0';
bist_done<='1';
if (data =
"10001011001000001000010000010011111101110010010101011100100111100010") then
bist_result<='1';
else
bist_result<='0';
end if;
if (test_bist='0') then
p_estado <= INICIO;
else
p_estado <= BIST_END;
end if;
when others =>
null;
end case;
end process;
end Behavioral;
63
LFSR
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;
entity TPG is
port( Clock: in std_logic;
Reset: in std_logic;
enable: in std_logic;
Data_out: out std_logic_vector(273 downto 0));
end TPG;
architecture Comportamento of TPG is
signal Qin: std_logic_vector(273 downto 0);
signal Qout: std_logic_vector(273 downto 0);
begin
Qin(0) <= Qout(19);
Qin(1) <= Qout(0);
Qin(2) <= Qout(1);
Qin(3) <= Qout(2);
Qin(4) <= Qout(3);
Qin(5) <= Qout(4);
Qin(6) <= Qout(5);
Qin(7) <= Qout(6);
Qin(8) <= Qout(7);
Qin(9) <= Qout(8);
Qin(10) <= Qout(9);
Qin(11) <= Qout(10);
Qin(12) <= Qout(11);
Qin(13) <= Qout(12);
Qin(14) <= Qout(13);
Qin(15) <= Qout(14);
Qin(16) <= Qout(15);
Qin(17) <= Qout(19) xor Qout(16);
Qin(18) <= Qout(17);
Qin(19) <= Qout(18);
Qin(20) <= Qout(19);
Qin(21) <= Qout(20);
Qin(22) <= Qout(21);
Qin(23) <= Qout(22);
Qin(24) <= Qout(23);
Qin(25) <= Qout(24);
Qin(26) <= Qout(25);
Qin(27) <= Qout(26);
Qin(28) <= Qout(27);
Qin(29) <= Qout(28);
Qin(30) <= Qout(29);
Qin(31) <= Qout(30);
Qin(32) <= Qout(31);
Qin(33) <= Qout(32);
64
Qin(34) <= Qout(33);
Qin(35) <= Qout(34);
Qin(36) <= Qout(35);
Qin(37) <= Qout(36);
Qin(38) <= Qout(37);
Qin(39) <= Qout(38);
Qin(40) <= Qout(39);
Qin(41) <= Qout(40);
Qin(42) <= Qout(41);
Qin(43) <= Qout(42);
Qin(44) <= Qout(43);
Qin(45) <= Qout(44);
Qin(46) <= Qout(45);
Qin(47) <= Qout(46);
Qin(48) <= Qout(47);
Qin(49) <= Qout(48);
Qin(50) <= Qout(49);
Qin(51) <= Qout(50);
Qin(52) <= Qout(51);
Qin(53) <= Qout(52);
Qin(54) <= Qout(53);
Qin(55) <= Qout(54);
Qin(56) <= Qout(55);
Qin(57) <= Qout(56);
Qin(58) <= Qout(57);
Qin(59) <= Qout(58);
Qin(60) <= Qout(59);
Qin(61) <= Qout(60);
Qin(62) <= Qout(61);
Qin(63) <= Qout(62);
Qin(64) <= Qout(63);
Qin(65) <= Qout(64);
Qin(66) <= Qout(65);
Qin(67) <= Qout(66);
Qin(68) <= Qout(67);
Qin(69) <= Qout(68);
Qin(70) <= Qout(69);
Qin(71) <= Qout(70);
Qin(72) <= Qout(71);
Qin(73) <= Qout(72);
Qin(74) <= Qout(73);
Qin(75) <= Qout(74);
Qin(76) <= Qout(75);
Qin(77) <= Qout(76);
Qin(78) <= Qout(77);
Qin(79) <= Qout(78);
Qin(80) <= Qout(79);
Qin(81) <= Qout(80);
Qin(82) <= Qout(81);
Qin(83) <= Qout(82);
Qin(84) <= Qout(83);
Qin(85) <= Qout(84);
Qin(86) <= Qout(85);
Qin(87) <= Qout(86);
Qin(88) <= Qout(87);
Qin(89) <= Qout(88);
65
Qin(90) <= Qout(89);
Qin(91) <= Qout(90);
Qin(92) <= Qout(91);
Qin(93) <= Qout(92);
Qin(94) <= Qout(93);
Qin(95) <= Qout(94);
Qin(96) <= Qout(95);
Qin(97) <= Qout(96);
Qin(98) <= Qout(97);
Qin(99) <= Qout(98);
Qin(100) <= Qout(99);
Qin(101) <= Qout(100);
Qin(102) <= Qout(101);
Qin(103) <= Qout(102);
Qin(104) <= Qout(103);
Qin(105) <= Qout(104);
Qin(106) <= Qout(105);
Qin(107) <= Qout(106);
Qin(108) <= Qout(107);
Qin(109) <= Qout(108);
Qin(110) <= Qout(109);
Qin(111) <= Qout(110);
Qin(112) <= Qout(111);
Qin(113) <= Qout(112);
Qin(114) <= Qout(113);
Qin(115) <= Qout(114);
Qin(116) <= Qout(115);
Qin(117) <= Qout(116);
Qin(118) <= Qout(117);
Qin(119) <= Qout(118);
Qin(120) <= Qout(119);
Qin(121) <= Qout(120);
Qin(122) <= Qout(121);
Qin(123) <= Qout(122);
Qin(124) <= Qout(123);
Qin(125) <= Qout(124);
Qin(126) <= Qout(125);
Qin(127) <= Qout(126);
Qin(128) <= Qout(127);
Qin(129) <= Qout(128);
Qin(130) <= Qout(129);
Qin(131) <= Qout(130);
Qin(132) <= Qout(131);
Qin(133) <= Qout(132);
Qin(134) <= Qout(133);
Qin(135) <= Qout(134);
Qin(136) <= Qout(135);
Qin(137) <= Qout(136);
Qin(138) <= Qout(137);
Qin(139) <= Qout(138);
Qin(140) <= Qout(139);
Qin(141) <= Qout(140);
Qin(142) <= Qout(141);
Qin(143) <= Qout(142);
Qin(144) <= Qout(143);
Qin(145) <= Qout(144);
66
Qin(146) <= Qout(145);
Qin(147) <= Qout(146);
Qin(148) <= Qout(147);
Qin(149) <= Qout(148);
Qin(150) <= Qout(149);
Qin(151) <= Qout(150);
Qin(152) <= Qout(151);
Qin(153) <= Qout(152);
Qin(154) <= Qout(153);
Qin(155) <= Qout(154);
Qin(156) <= Qout(155);
Qin(157) <= Qout(156);
Qin(158) <= Qout(157);
Qin(159) <= Qout(158);
Qin(160) <= Qout(159);
Qin(161) <= Qout(160);
Qin(162) <= Qout(161);
Qin(163) <= Qout(162);
Qin(164) <= Qout(163);
Qin(165) <= Qout(164);
Qin(166) <= Qout(165);
Qin(167) <= Qout(166);
Qin(168) <= Qout(167);
Qin(169) <= Qout(168);
Qin(170) <= Qout(169);
Qin(171) <= Qout(170);
Qin(172) <= Qout(171);
Qin(173) <= Qout(172);
Qin(174) <= Qout(173);
Qin(175) <= Qout(174);
Qin(176) <= Qout(175);
Qin(177) <= Qout(176);
Qin(178) <= Qout(177);
Qin(179) <= Qout(178);
Qin(180) <= Qout(179);
Qin(181) <= Qout(180);
Qin(182) <= Qout(181);
Qin(183) <= Qout(182);
Qin(184) <= Qout(183);
Qin(185) <= Qout(184);
Qin(186) <= Qout(185);
Qin(187) <= Qout(186);
Qin(188) <= Qout(187);
Qin(189) <= Qout(188);
Qin(190) <= Qout(189);
Qin(191) <= Qout(190);
Qin(192) <= Qout(191);
Qin(193) <= Qout(192);
Qin(194) <= Qout(193);
Qin(195) <= Qout(194);
Qin(196) <= Qout(195);
Qin(197) <= Qout(196);
Qin(198) <= Qout(197);
Qin(199) <= Qout(198);
Qin(200) <= Qout(199);
Qin(201) <= Qout(200);
67
Qin(202) <= Qout(201);
Qin(203) <= Qout(202);
Qin(204) <= Qout(203);
Qin(205) <= Qout(204);
Qin(206) <= Qout(205);
Qin(207) <= Qout(206);
Qin(208) <= Qout(207);
Qin(209) <= Qout(208);
Qin(210) <= Qout(209);
Qin(211) <= Qout(210);
Qin(212) <= Qout(211);
Qin(213) <= Qout(212);
Qin(214) <= Qout(213);
Qin(215) <= Qout(214);
Qin(216) <= Qout(215);
Qin(217) <= Qout(216);
Qin(218) <= Qout(217);
Qin(219) <= Qout(218);
Qin(220) <= Qout(219);
Qin(221) <= Qout(220);
Qin(222) <= Qout(221);
Qin(223) <= Qout(222);
Qin(224) <= Qout(223);
Qin(225) <= Qout(224);
Qin(226) <= Qout(225);
Qin(227) <= Qout(226);
Qin(228) <= Qout(227);
Qin(229) <= Qout(228);
Qin(230) <= Qout(229);
Qin(231) <= Qout(230);
Qin(232) <= Qout(231);
Qin(233) <= Qout(232);
Qin(234) <= Qout(233);
Qin(235) <= Qout(234);
Qin(236) <= Qout(235);
Qin(237) <= Qout(236);
Qin(238) <= Qout(237);
Qin(239) <= Qout(238);
Qin(240) <= Qout(239);
Qin(241) <= Qout(240);
Qin(242) <= Qout(241);
Qin(243) <= Qout(242);
Qin(244) <= Qout(243);
Qin(245) <= Qout(244);
Qin(246) <= Qout(245);
Qin(247) <= Qout(246);
Qin(248) <= Qout(247);
Qin(249) <= Qout(248);
Qin(250) <= Qout(249);
Qin(251) <= Qout(250);
Qin(252) <= Qout(251);
Qin(253) <= Qout(252);
Qin(254) <= Qout(253);
Qin(255) <= Qout(254);
Qin(256) <= Qout(255);
Qin(257) <= Qout(256);
68
Qin(258) <= Qout(257);
Qin(259) <= Qout(258);
Qin(260) <= Qout(259);
Qin(261) <= Qout(260);
Qin(262) <= Qout(261);
Qin(263) <= Qout(262);
Qin(264) <= Qout(263);
Qin(265) <= Qout(264);
Qin(266) <= Qout(265);
Qin(267) <= Qout(266);
Qin(268) <= Qout(267);
Qin(269) <= Qout(268);
Qin(270) <= Qout(269);
Qin(271) <= Qout(270);
Qin(272) <= Qout(271);
Qin(273) <= Qout(272);
sinc_TPG: process(Clock,Reset)
begin
if Reset = '1' then
Qout <=
"111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111
1111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111
111111111111111111111111111111111111111111111111111111111111111111111111111111111111111";
elsif Clock'event and Clock = '1' and enable = '1' then
Qout <= Qin;
end if;
end process;
Data_out <= Qout;
end Comportamento;
69
MISR
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;
entity Misr is
port( Data_in: in std_logic_vector(67 downto 0);
Clock: in std_logic;
Reset: in std_logic;
enable: in std_logic;
Data_out: out std_logic_vector(67 downto 0));
end Misr;
architecture Comportamento of Misr is
signal Qin: std_logic_vector(67 downto 0);
signal Qout: std_logic_vector(67 downto 0);
begin
Qin(0) <= Qout(67) xor Data_in(0);
Qin(1) <= Qout(0) xor Data_in(1);
Qin(2) <= Qout(1) xor Data_in(2);
Qin(3) <= Qout(2) xor Data_in(3);
Qin(4) <= Qout(3) xor Data_in(4);
Qin(5) <= Qout(4) xor Data_in(5);
Qin(6) <= Qout(5) xor Data_in(6);
Qin(7) <= Qout(6) xor Data_in(7);
Qin(8) <= Qout(7) xor Data_in(8);
Qin(9) <= Qout(8) xor Data_in(9) xor Qout(67);
Qin(10) <= Qout(9) xor Data_in(10);
Qin(11) <= Qout(10) xor Data_in(11);
Qin(12) <= Qout(11) xor Data_in(12);
Qin(13) <= Qout(12) xor Data_in(13);
Qin(14) <= Qout(13) xor Data_in(14);
Qin(15) <= Qout(14) xor Data_in(15);
Qin(16) <= Qout(15) xor Data_in(16);
Qin(17) <= Qout(16) xor Data_in(17);
Qin(18) <= Qout(17) xor Data_in(18);
Qin(19) <= Qout(18) xor Data_in(19);
Qin(20) <= Qout(19) xor Data_in(20);
Qin(21) <= Qout(20) xor Data_in(21);
Qin(22) <= Qout(21) xor Data_in(22);
Qin(23) <= Qout(22) xor Data_in(23);
Qin(24) <= Qout(23) xor Data_in(24);
70
Qin(25) <= Qout(24) xor Data_in(25);
Qin(26) <= Qout(25) xor Data_in(26);
Qin(27) <= Qout(26) xor Data_in(27);
Qin(28) <= Qout(27) xor Data_in(28);
Qin(29) <= Qout(28) xor Data_in(29);
Qin(30) <= Qout(29) xor Data_in(30);
Qin(31) <= Qout(30) xor Data_in(31);
Qin(32) <= Qout(31) xor Data_in(32);
Qin(33) <= Qout(32) xor Data_in(33);
Qin(34) <= Qout(33) xor Data_in(34);
Qin(35) <= Qout(34) xor Data_in(35);
Qin(36) <= Qout(35) xor Data_in(36);
Qin(37) <= Qout(36) xor Data_in(37);
Qin(38) <= Qout(37) xor Data_in(38);
Qin(39) <= Qout(38) xor Data_in(39);
Qin(40) <= Qout(39) xor Data_in(40);
Qin(41) <= Qout(40) xor Data_in(41);
Qin(42) <= Qout(41) xor Data_in(42);
Qin(43) <= Qout(42) xor Data_in(43);
Qin(44) <= Qout(43) xor Data_in(44);
Qin(45) <= Qout(44) xor Data_in(45);
Qin(46) <= Qout(45) xor Data_in(46);
Qin(47) <= Qout(46) xor Data_in(47);
Qin(48) <= Qout(47) xor Data_in(48);
Qin(49) <= Qout(48) xor Data_in(49);
Qin(50) <= Qout(49) xor Data_in(50);
Qin(51) <= Qout(50) xor Data_in(51);
Qin(52) <= Qout(51) xor Data_in(52);
Qin(53) <= Qout(52) xor Data_in(53);
Qin(54) <= Qout(53) xor Data_in(54);
Qin(55) <= Qout(54) xor Data_in(55);
Qin(56) <= Qout(55) xor Data_in(56);
Qin(57) <= Qout(56) xor Data_in(57);
Qin(58) <= Qout(57) xor Data_in(58);
Qin(59) <= Qout(58) xor Data_in(59);
Qin(60) <= Qout(59) xor Data_in(60);
Qin(61) <= Qout(60) xor Data_in(61);
Qin(62) <= Qout(61) xor Data_in(62);
Qin(63) <= Qout(62) xor Data_in(63);
Qin(64) <= Qout(63) xor Data_in(64);
Qin(65) <= Qout(64) xor Data_in(65);
Qin(66) <= Qout(65) xor Data_in(66);
Qin(67) <= Qout(66) xor Data_in(67);
sinc_TPG: process(Clock,Reset)
71
begin
if Reset = '1' then
Qout <=
"00000000000000000000000000000000000000000000000000000000000000000000";
elsif Clock'event and Clock = '1' and enable = '1' then
Qout <= Qin;
end if;
end process;
Data_out <= Qout;
end Comportamento;
72
MUX
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;
---- Uncomment the following library declaration if instantiating
---- any Xilinx primitives in this code.
--library UNISIM;
--use UNISIM.VComponents.all;
entity mux275 is
port( A:in std_logic_vector(274 downto 0);
B:in std_logic_vector(274 downto 0);
control:in std_logic;
C:out std_logic_vector(274 downto 0));
end mux275;
architecture Behavioral of mux275 is
begin
process (control,A,B)
begin
if control = '1' then
C <= B;
else
C <= A;
end if;
end process;
end Behavioral;
73
Top Level
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;
---- Uncomment the following library declaration if instantiating
---- any Xilinx primitives in this code.
--library UNISIM;
--use UNISIM.VComponents.all;
entity top_level is
port( clk: in std_logic;
reset: in std_logic;
data_in: in std_logic_vector (274 downto 0);
test_bist: in std_logic;
data_out: out std_logic_vector (67 downto 0);
bist_done: out std_logic;
bist_result: out std_logic); --Colocar a saida BIST_DONE,funçao k o bist result faz neste
momento
end top_level;
architecture Behavioral of top_level is
component Misr is
port( Data_in: in std_logic_vector(67 downto 0);
Clock: in std_logic;
Reset: in std_logic;
enable: in std_logic;
Data_out: out std_logic_vector(67 downto 0)
);
end component;
component mux275 is
port( A:in std_logic_vector(274 downto 0);
B:in std_logic_vector(274 downto 0);
control:in std_logic;
C:out std_logic_vector(274 downto 0));
end component;
component TPG is
port( Clock: in std_logic;
Reset: in std_logic;
enable: in std_logic;
Data_out: out std_logic_vector(273 downto 0));
end component;
component rd_roc is
port( clk: in std_logic;
reset: in std_logic;
onoff: in std_logic;
int_req_onoff: in std_logic;
dout_fout: in std_logic_vector (243 downto 0);
74
empty_fout: in std_logic;
int_readyerr: in std_logic;
int_errcount: in std_logic_vector (24 downto 0);
full_bbus: in std_logic;
test_se: in std_logic;
test_si: in std_logic;
dcc_busy: out std_logic;
dout_bbus: out std_logic_vector (63 downto 0);
int_doneerr: out std_logic;
rd_fout: out std_logic;
wr_bbus: out std_logic
);
end component;
component control is
Port ( clk : in std_logic;
reset : in std_logic;
test_bist : in std_logic;
data : in std_logic_vector (67 downto 0);
scan_en : out std_logic;
reset_tpg : out std_logic;
reset_cut : out std_logic;
reset_misr : out std_logic;
enable_misr : out std_logic;
bist_done : out std_logic;
bist_result: out std_logic);
end component;
signal tpg_out : std_logic_vector (273 downto 0);
signal mux_in,mux_out : std_logic_vector (274 downto 0);
signal rd_out,data_out_aux : std_logic_vector (67 downto 0);
signal scan_en,reset_tpg,reset_cut,reset_misr,enable_misr:std_logic;
begin
LFSR: TPG
port map( Clock => clk,
reset => reset_tpg,
enable => scan_en,
Data_out=> tpg_out
);
mux_in <= tpg_out & reset_cut;
mux : mux275
port map( A => Data_in,
B => mux_in,
Control => test_bist,
C => mux_out
);
--isto tem erro, atençao depois
circuito: rd_roc
port map( clk => clk,
reset => mux_out(0),
onoff => mux_out(1),
int_req_onoff => mux_out(2),
75
dout_fout => mux_out(249 downto 6),
empty_fout => mux_out(3),
int_readyerr => mux_out(4),
int_errcount => mux_out(274 downto 250),
full_bbus =>mux_out(5) ,
test_se => scan_en,
test_si =>mux_out(274) ,
dcc_busy => rd_out(67),
dout_bbus => rd_out(66 downto 3),
int_doneerr => rd_out(2),
rd_fout => rd_out(1),
wr_bbus => rd_out(0)
);
compactador : Misr
port map( Data_in =>rd_out ,
Clock => clk,
Reset => reset_misr,
enable => enable_misr,
Data_out => Data_out_aux
);
controlo: control
port map( clk => clk,
reset => reset,
test_bist => test_bist,
data => data_out_aux,
scan_en => scan_en,
reset_tpg => reset_tpg,
reset_cut => reset_cut,
reset_misr => reset_misr,
enable_misr => enable_misr,
bist_done => bist_done,
bist_result => bist_result
);
data_out <= data_out_aux;
end Behavioral;
76
BIST Test Bench
`timescale 1ns/1ps
module bist10_tb;
/*parameters */
parameter Num_Inputs = 275;
parameter Num_Outputs = 68;
parameter Num_Vectores = 44; /*número de vectores de teste*/
parameter CLKa
= 2000;
/*Aux vars*/
integer index;
real half_clk,quarter_clk;
integer contador;
/*Regs for assigning test vectors to circuit inputs */
reg [0:Num_Inputs-1] inputs [0:Num_Vectores];
reg clk;
reg reset;
reg test_bist;
/* circuit inputs*/
wire [0:274] data_in;
/*assign "inputs" to circuit inputs */
assign { data_in[0:274]} = inputs [index];
/*wires for transferring results to output */
wire [0:Num_Outputs-1] outputs;
wire bist_result;
wire bist_done;
/* circuit outputs*/
wire [0:67] data_out;
/* assign "outputs" to wire outputs */
assign outputs = {data_out[0:67]};
/* CUT instantiation */
top_level TOP_inst
(.clk(clk),.reset(reset),.data_in(data_in),.test_bist(test_bist),.data_out(data_out),.bist_done(bist_done),.bist_r
esult(bist_result));
77
initial
begin
$fs_add(top_level);
$fs_inject;
/* para verifault */
/*variable initialization*/
index=0;
clk=0;
reset=1;
half_clk = CLKa/2;
quarter_clk = half_clk/2;
test_bist = 0;
contador = 0;
/* Getting input vectors from file */
$readmemb("./estimulos.vec",inputs);
$display ("*****************************
***************************\n");
inicio
while (index < Num_Vectores)
begin
@(negedge clk)
/*
$display ("***************************** vector %d
***************************\n",index+1);
$display ("entradas\data_in %b\ntest_bist %b\nclk %b\n
",data_in[0:274],test_bist,clk);
*/
#half_clk;
$fs_strobe(data_out[0:67],bist_result,bist_done);
$display ("entradas\data_in %b\ntest_bist %b\nclk %b\n
/*
",data_in[0:274],test_bist,clk);*/
/*
$display ("saidas \ndata_out%b \nbist_result %b\nbist_done %b
\n",data_out[0:67],bist_result,bist_done);*/
if (contador > 99000)
begin
reset = 0;
index = index + 1;
contador = 0;
if (index > 5 )
begin
test_bist = 1;
end
$display ("saidas \ndata_out%b \nbist_result %b\nbist_done
%b \n",data_out[0:67],bist_result,bist_done);
end
contador = contador + 1;
end
78
$finish;
end
always #1000 clk = ~clk;
endmod
79