MET: Um microprocessador para teste embarcado

MET: Um microprocessador para teste embarcado Lisane Brisolara [email protected]

Erika Cota [email protected]

Luigi Carro [email protected]

Altamiro Suzin [email protected]

UFRGS – Universidade Federal do Rio Grande do Sul GME - Grupo de Microeletrônica Caixa Postal 15064 – Porto Alegre, RS – 91501-970 - Brasil

Resumo No contexto do desenvolvimento de sistemas em silício com uso de núcleos de hardware que utilizam diferentes estratégias de teste, surge a necessidade de desenvolvimento de um controlador de teste, que execute as estratégias de teste implementadas pelos núcleos que fazem parte do sistema. Este controlador pode ser sintetizado juntamente com os núcleos, fazendo parte do sistema. O padrão P1500 define uma arquitetura escalonável para integração dos diversos núcleos e uma linguagem conhecida como CTL (Core Test Language). Esta linguagem é baseada na linguagem STIL (Standard Test Interface Language) [REF1] que é usada na área de teste há algum tempo e já se constitui no padrão IEEE 1450 [REF1]. A tendência é de que cada núcleo possua uma descrição CTL correspondente para o teste do mesmo. O Controlador de teste, portanto deve interpretar programas de teste descritos em CTL. Porém como CTL ainda não está totalmente definida, neste trabalho apresenta-se uma arquitetura capaz de executar comandos STIL, a qual implementa três estratégias de teste: o teste externo, boundary scan e o auto-teste. Palavras_Chaves: controlador de teste, teste, núcleos, sistemas embarcados.

Abstract In the context of System on Chip development with Cores, there are many different test strategies. There is the necessity of developing a test controller, which executes the test strategy implemented on the Cores that are part of the system. This controller can be synthesized with the core, making part of the System on Chip. The P1500 standard defines a scalable architecture for the integration of many cores and a language known as CTL. This language is based on the STIL language, which has been used in the test area for quite some time and already constitutes the IEEE 1450 standard. The tendency is for each core to have a CTL description corresponding to its test. The test controller therefore must interpret test programs described in CTL. But, as CTL has not been totally defined, this paper shows a architecture capable of executing STIL commands, which implements three test strategies: the external test, boundary scan and self-test. Keywords: test controller, test, cores, system-on-chip.

1. Introdução Durante o projeto de circuitos e sistemas integrados, é muito importante que haja uma preocupação com o teste dos mesmos, sendo que esta necessidade aumenta cada vez mais à medida em que a complexidade destes sistemas também aumenta. A integração de diversos sistemas em um único circuito integrado (CI) é uma tendência atual, o que se chama de SOC (system-on-chip) [PAP99]. O uso de blocos pré-projetados, chamados núcleos de hardware, no projeto de SOCs tem se tornado essencial para a construção de sistemas de alta complexidade em um curto espaço de tempo, de modo que este novo produto desenvolvido chegue ao mercado em tempo hábil para de ser competitivo [GUP97]. Estes núcleos são blocos distintos, cujas estratégias de teste são diversas (teste externo, boundary scan, autoteste, etc) tornando muito complexo o teste do sistema como um todo. Por isso, está sendo discutido e elaborado um padrão para o teste de SOCs, sendo este conhecido como P1500 [MAR 99]. Este padrão define, além de uma arquitetura escalonável para integração dos diversos núcleos, uma linguagem conhecida como CTL (Core Test Language). Esta linguagem é baseada na linguagem STIL (Standard Test Interface Language) [REF1] que é usada na área de teste há algum tempo e já se constitui no padrão IEEE 1450 [REF1]. No contexto do projeto de SOCs, seria muito interessante o desenvolvimento de um interpretador para a linguagem CTL, pois a tendência é que cada núcleo tenha um programa CTL associado que descreve seu teste. Este programa, em algum momento do teste do sistema, deverá ser executado. Porém, como CTL ainda não está totalmente definida, este trabalho apresenta a implementação de um interpretador para alguns comandos da linguagem STIL, já que CTL será uma extensão desta última. Este interpretador também pode ser visto como um controlador de teste que poderá ser sintetizado juntamente com o resto do sistema e, portanto como parte do SOC e será responsável pelo teste dos núcleos que compõem o sistema. Neste trabalho é apresentada uma arquitetura capaz de executar comandos STIL, a qual implementa três estratégias de teste: o teste externo, boundary scan e o auto-teste. Esta arquitetura foi descrita em VHDL, gerando assim, um interpretador STIL em hardware que pode ser considerado também como um microprocessador voltado para o teste de sistemas embarcados. Esta descrição, portanto, tem como objetivo a geração de um ASIC (Aplication Specific Integrated Circuit) que executa comandos da linguagem STIL e que pode ser facilmente extensível para a linguagem CTL. Deste modo, esta descrição pode ser utilizada em futuras implementações de ferramentas de automatização do teste de SOCs. O texto foi organizado da seguinte maneira. Nas primeiras duas seções do trabalho faz-se uma breve introdução à área de teste de circuitos eletrônicos e à linguagem STIL, com o intuito de facilitar a compreensão da arquitetura desenvolvida, que é o foco principal do trabalho. No capítulo 2 apresenta-se uma arquitetura que implementa apenas o teste externo, sendo que esta serviu como base para a implementação do BIST e do boundary scan que são apresentados nos capítulos 3 e 4 respectivamente. No capítulo 5 são apresentados os resultados de síntese das implementações realizadas no decorrer do desenvolvimento deste trabalho e estes são comparados com implementações de microcontroladores quanto a área e freqüência. Finalmente, no capítulo 6, apresentam-se as conclusões e faz-se referência a trabalhos futuros que podem ser desenvolvidos na área. 1.1 Teste de Circuitos Eletrônicos O teste de um circuito consiste na aplicação de vetores de dados nas entradas do mesmo, e na observação de suas saídas e comparação das mesmas com um valor pré-definido para este circuito. Porém, podem ser utilizadas diversas estratégias de teste diferentes entre si. Uma delas será chamada aqui de teste externo. Esta estratégia nem sempre requer um projeto visando teste (DFT, do inglês, Design For Test), e os vetores de teste são gerados externamente. As técnicas de DFT [ABR90] permitem uma maior controlabilidade e observabilidade de pontos internos do circuito e, portanto, aumenta a testabilidade do mesmo. Técnicas como boundary scan [BAC00][IEE90] e built-in self-testing (BIST) [McC85][COT99]têm seu uso definido durante o projeto e, portanto, implicam um DFT. No BIST, também conhecido como auto-teste, a geração de vetores de teste é feita internamente. Já no boundary scan os vetores são gerados externamente.

1.2 Linguagem STIL Esta linguagem foi desenvolvida, inicialmente, pelos fornecedores de equipamentos de teste externo, fabricantes de CIs e fornecedores de ferramentas de CAD, para facilitar a transferência dos dados entre o circuito e o equipamento de teste. Um programa STIL define as formas de onda dos sinais a serem enviados como estímulo ao circuito sob teste, contendo os tempos de envio e os valores envolvidos em cada sinal. O programa define, ainda, uma seqüência de vetores de teste que serão aplicados e os valores esperados como resposta ao teste. No contexto deste trabalho, esta linguagem será utilizada como um formato intermediário para um subsequente processamento destas informações pelo interpretador desenvolvido aqui. O programa de teste da figura 1, descreve o teste de um subconjunto do comportamento de um barramento de 8 bits (transceiver)[REF1], o qual será utilizado como exemplo neste artigo. STIL 0.0 Signals{ DIR In; OEM In; A0 In; A1 In;, A2 In; A3 In; A4 In; A5 In; A6 In; A7 In; B0 Out; B1 Out; B2 Out; B3 Out; B4 Out; B5 Out; B6 Out; B7 Out} Signals Groups{ ABUS ‘A7 + A6 + A5+ A4 + A3 + A2 + A1 + A0’; B BUS ‘B7 + B6 + B5+ B4 + B3 + B2 + B1 +B0’; ALL ‘DIR + OEM +ABUS + BBUS ’ } Timing “Hello tester timing” WaveFormTable one{ Period ‘500ns’ WaveForms{ DIR {01 { 0ns ForceDown/ForceUp} OEM {01 { 0ns ForceUp,; 200ns ForceDown/ForceUp; 300 ns ForceUp} ABUS {01 { 10 ns ForceDown/ForceUp}} BBUS {HLZ{0ns ForceZ; 0ns CompareUnknown, 260ns CompareHighWindow/ CompareLowwindow /CompareZWindow; 280ns CompareUnknown;}} } } // end WaveFormTable one } // end Timing “Hello tester timing” Pattern “hello tester burst” { “hello tester pattern”; } // end PatternBurst PatternExec { Timing “hello tester timing”; “hello tester burst”; }

// end PatternExec

Pattern “hello tester pattern” { W one; V {ALL= 0000000000LLLLLLLL} V{ALL= 0010000000HLLLLLLL} V{ALL= 0001000000LHLLLLLL} V{ALL= 0000100000LLHLLLLL} V{ALL= 0000010000LLLHLLLL} V{ALL= 0000001000LLLLHLLL} V{ALL= 0000000100LLLLLHLL} V{ALL= 0000000010LLLLLLHL} V{ALL= 0000000001LLLLLLLH} }

// end Pattern “helo tester pattern”

Figura 1: Exemplo de programa STIL

2. Proposta Inicial de Arquitetura Na execução do teste externo de um núcleo, o controlador de teste deve, portanto, gerar sinais de saída para estimular as entradas de um núcleo e verificar a saída do mesmo, comparando-a com um determinado valor esperado. Um programa de teste, neste caso, especifica vetores, ou seja formas de onda a serem aplicadas nas entradas do circuito e o valor esperado para as saídas do mesmo. Conforme mencionado, haverá um nível de compilação acima do interpretador que irá gerar os comandos para o MET(Microprocessor for embedded Test) ou seja, o compilador recebe o programa de teste, faz o cruzamento entre as formas de onda e os vetores de tempo e gera duas tabelas que são enviadas para o interpretador. Estas duas tabelas correspondem em nossa arquitetura a duas memórias ROM, as quais são chamadas memória de programa e memória de dados. A primeira armazenará as instruções, e o tempo de teste em que as mesmas devem ser executadas, sendo estas informações ordenadas pelo tempo dentro de cada vetor de teste. A segunda, por sua vez, informa os padrões a serem aplicados nas entradas do circuito, ou o valor a ser esperado para as saídas do mesmo. Com base nos exemplos de programas STIL analisados, definiu-se uma proposta de arquitetura para o interpretador STIL, chamado MET. Identificou-se primeiramente, a necessidade de duas instruções primárias: uma instrução de excitação (EXCITA) que permite a definição dos valores a serem aplicados no circuito sob teste; uma instrução de comparação (COMPARA) para leitura e comparação das saídas do mesmo com um valor esperado. Observou-se após, a necessidade de num mesmo instante de tempo definir um valor a ser aplicado nas entradas de um núcleo, e definir um valor para comparar com as saídas do mesmo núcleo. Assim, definiu-se uma instrução EXCITA/COMPARA. Além destas, mais duas instruções foram consideradas necessárias: uma instrução para definição do fim de um vetor de teste (FIM_VETOR) e uma instrução para definir o fim do teste (FIM_TESTE). A instrução de FIM_TESTE indica o término do teste, ou seja a máquina de controle fica num estado de espera, aguardando um novo teste. Neste momento, os resultados do teste anterior já estão disponíveis. A instrução de FIM_VETOR indica que um vetor de teste foi concluído. Portanto, a contagem do tempo de teste deve ser zerada e a máquina aguardará o tempo de envio do próximo vetor. A instrução de EXCITA indica que um padrão deve ser enviado ao núcleo, neste tempo de teste. Na memória de programa haverá, portanto, o código da instrução EXCITA e um tempo de teste correspondente para a mesma. Na memória de dados estão armazenados os valores a serem aplicados para os bits de entrada do núcleo naquele instante de tempo, obedecendo a uma determinada ordem pré-definida. Como já foi dito, o compilador determinará o conteúdo da memória de dados e de programa. A instrução de COMPARA indica que se deve comparar o valor lido da saída do núcleo, com um valor esperado. Na execução de uma instrução deste tipo tem-se na memória de programa o código de instrução e o tempo de teste correspondente a mesma. Na memória de dados, estarão armazenados os valores esperados para os bits de saída do núcleo naquele instante de tempo, também obedecendo uma determinada ordem pré-definida. O resultado desta comparação indica se houve erro ou não e, em caso de erro, incrementa-se um contador de erros. Utilizaram-se quatro bits para codificar as instruções desta arquitetura, embora três bits seriam suficientes para esta implementação. Essa decisão objetivou tornar mais flexível a arquitetura e facilitar a inserção de outras instruções que se fizessem necessárias para o desenvolvimento de outras estratégias de teste, ou ainda na adaptação desta arquitetura para a linguagem CTL. Instruções FIM_TESTE (FT) FIM_VETOR (FV) COMPARA (C) EXCITA (E) EXC/COMP (EC)

Código 0000 0001 0010 0011 0100

Tabela 1: Instruções da arquitetura Na figura 2 pode-se observar a arquitetura simplificada do microcontrolador de teste. Esta arquitetura é composta por cinco blocos principais, sendo eles: memória de programa, memória de dados, comparador, contador de eventos e controle. Além destes, alguns multiplexadores, registradores e uma unidade aritmética

fazem parte da arquitetura. Os valores de bits para os registradores e memórias foram definidos para a execução do teste do programa STIL dado como exemplo na figura 1 deste artigo. RESET

MEMÓRIA DE DADOS

EMD +1

CLK START_TESTE

PC

CONTROLE

MEMÓRIA DE PROGRAMA

12

18

4

INSTR PASSO

ZERA_CONT

10 C O M P A R A D O R

8 Reg. Data_ in

Reg. Data_ out

HAB_CONT

Reg. Comp.

CONTADOR DE EVENTOS

TEMPO ATUAL

TEMPO

+/FLAG_IGUAL

+/Erro

10 CORE

8

erros

NÚMEROS DE ERROS

Figura 2: Arquitetura do controlador de teste O compilador enviará os dados a serem armazenados na memória de programa, indicando a instrução e o tempo de teste em que a mesma deve ser executada. As instruções são armazenadas ordenadas de acordo com o tempo, sendo o tempo dado em passos do relógio. Optou-se por representar o tempo em passos múltiplos do relógio da máquina Assim, com um menor número de bits pode-se representar os tempos envolvidos nas formas de onda que compõem os vetores de teste. O passo deve ser definido no tempo de compilação, e será enviado ao contador de eventos. Da mesma forma, o compilador determinará o conteúdo da memória de dados, sendo que nesta serão armazenados os valores a serem aplicados ao circuito, e/ou os valores a serem esperados como resposta do mesmo. O conteúdo desta memória é ordenado de acordo com o programa contido na memória de programa. O valor para PC e EMD, apontadores de endereços das memórias de programa e de dados respectivamente, são controlados pela máquina de controle. O contador de eventos é o bloco responsável pela indicação do instante de tempo para o envio de um padrão nas entradas do núcleo sob teste ou observação das saídas do mesmo. Este contador serve de relógio para o controlador de teste. Este recebe do compilador o passo ou a base de tempo, em que o contador deve operar, sendo que este valor deve ser múltiplo do relógio da máquina e será armazenado no endereço 0 (zero) da memória de programa. No bloco comparador têm-se os registradores que fazem parte da interface com o núcleo, que armazenam os valores a serem enviados para o mesmo no caso da execução de uma instrução EXCITA e os valores a serem utilizados na comparação com a resposta vinda do núcleo na execução de uma instrução COMPARA. Além disso, devem estar presentes um registrador para armazenar a própria resposta do núcleo e um subtrator para fazer a comparação entre este valor e o valor esperado como resposta do núcleo. O bloco de controle é composto de uma máquina de estados finitos (FSM), a qual pode ser observada na figura 3. A máquina de controle gera os sinais para a escrita dos registradores da arquitetura, de seleção dos multiplexadores, para zerar o contador de eventos e para habilitar a contagem do mesmo.

Quando chega ao controlador de teste um sinal de início de teste, o controlador lê o endereço 0 (zero) da memória de programa, e neste endereço está o passo utilizado para o teste de um determinado núcleo, sendo que este valor deve ser passado para o contador de eventos. Após, incrementa-se o apontador da memória de programa (PC). Então lê-se a primeira instrução e o primeiro tempo de teste. Neste momento, inicia-se o contador de eventos e compara-se a contagem do mesmo com o tempo de teste. Quando estes forem iguais, deve-se verificar a instrução. Se a instrução for EXCITA, deve-se jogar um padrão nas entradas do núcleo, ou seja carregar um registrador de saída com o valor lido da memória de dados e incrementar o seu apontador de endereços. Se a instrução for COMPARA deve-se carregar o registrador de interface com o valor lido das saídas do núcleo e carregar um outro registrador com o valor esperado do núcleo e comparar os dois valores, incrementando um contador de erros sempre que estes valores forem diferentes. Quando a instrução é EXCITA/COMPARA, tanto o registrador envolvido nas instruções de excitação, como os registradores envolvidos nas instruções de comparação são alterados. Se a instrução for FIM_VETOR, deve-se zerar o contador de eventos, incrementar o PC e aguardar que a contagem do contador de eventos atinja o tempo de teste do próximo vetor. Se a instrução for FIM_TESTE deve-se zerar o contador e o controlador deve ficar aguardando por um sinal de início de outro teste. start=0

0 start=1

1 igual=1 and COMPARA or EXCITA

2 igual=0 3 5 instr=FIM_VETOR 4

instr=FIM_TESTE

Figura 3: Máquina de estados do Controle A máquina de controle sai do estado zero para o 1 quando o sinal de start é setado para ´1´. No estado 1, faz-se a gravação do passo do contador, sendo que este sempre está na posição zero da memória de programa. A máquina de controle fica num laço no estado 3 até que o valor da contagem do contador de eventos seja igual ao tempo de teste lido da memória de programa. No caso de uma instrução de FIM_TESTE, a máquina volta para o estado 4, e após volta para o estado 0. Já quando a instrução for FIM_VETOR, a máquina vai para o estado 5 e desde retorna para o estado 3. Para as demais instruções a máquina retorna ao estado 2. Nos estados 1, 2 e 5 o PC, apontador da memória de programa, é incrementado. O contador EMD, apontador de endereços da memória de dados, é incrementado no estado 2. Um programa de teste simples em STIL, possui uma tabela de formas de onda (waveforms) e uma lista de vetores. O cruzamento entre estas informações é tarefa do compilador.

3. Implementação do BIST Técnicas BIST (do inglês Built-in Self -test) provêem aos circuitos a capacidade de se auto-testarem. [ABR90]. Neste trabalho, para a implementação desta estratégia de teste, foi estudado uma implementação do 8051 auto-testável [COT99]. Algumas alterações foram realizadas na arquitetura do MET, de modo que esta suportasse núcleos auto-testáveis. O controlador de teste para testar um núcleo com BIST deve gerar um sinal

que habilite o auto-teste do mesmo e após, deve verificar o resultado do auto-teste no tempo indicado para término do mesmo, reportando este resultado para a saída. Na implementação do auto-teste não foi inserida nenhuma instrução especial e esta não acarretou em nenhuma alteração na máquina de controle do interpretador. Foram definidos mais dois bits na memória de dados: um bit para habilitar o auto-teste e outro para indicar que deve-se verificar o resultado do teste. O bit que habilita o auto-teste deve ser setado para um e permanecerá em um até o término do auto-teste. O valor destes bits são definidos a nível de compilação, de acordo com a informação de tempo de início do auto-teste e de duração do mesmo. Sendo assim, o compilador deve saber anteriormente o tempo gasto no auto-teste do núcleo. A figura 4 indica os bits usados para o BIST e pode-se observar como ficou a palavra da memória de dados após a inserção dos mesmos. Hab_auto_teste Hab_erro_BIST Valor EXCITA

Valor COMPARA

2 bits 10 bits

BIST

8 bits 20 bits

Figura 4: Palavra da Memória de dados

4. Implementação com Boundary scan Boundary scan (BS) é uma importante técnica de projeto visando teste. Para implementá-la neste trabalho foi estudado o padrão BS [IEE90] [BAC00] e um exemplo de programa de teste de uma descrição VHDL do 8051.Na figura 5 pode-se observar a arquitetura de um teste BS.

TCK TMS TDI

Controlador TAP

T D I

8051 com canal scan

TDO

T D O

Figura 5: Teste BS Primeiramente, fez-se uma análise de um programa de teste escrito para testar um pequeno bloco do microcontrolador 8051 com boundary scan, baseado na descrição desenvolvida no GME, através da qual se observou a necessidade de enviar para o controlador TAP, os valores de TMS, TDI e TCK. Para tal, inseriram-se algumas instruções na arquitetura inicial, estas podem ser observadas na tabela 2. Nota-se a presença de um controlador para o teste scan, este é conhecido como TAP (Test Access Port). Este controlador é uma máquina de controle que permite a carga de instruções e dados de teste para o circuito. Seu funcionamento é definido como parte do padrão boundary scan. Observa-se que um circuito cujo teste é feito através do BS tem como entradas os sinais TCK, TMS e TDI. O TCK define o relógio para o teste scan, o TMS define comandos para o controlador TAP e o TDI define o sinal a ser aplicado ao núcleo, que no exemplo é o 8051. O controlador tem como saída o sinal TDO que representa a saída do núcleo, ou seja a resposta do mesmo ao estímulo aplicado. Todos estes sinais são controlados e observados serialmente. Na implementação do interpretador que suportasse o teste SCAN, novamente algumas alterações na arquitetura do MET fizeram-se necessárias a fim de comportar a execução deste teste. As principais alterações ocorreram no bloco comparador e no controle da máquina.

A instrução de SC TMS, define valores apenas para o sinal TMS que é enviado à TAP do núcleo. A instrução de SC TMTI define valores tanto para TMS como para TDI. A instrução de TMTO, por sua vez, define valores para TMS e o valor esperado como resposta do núcleo, e compara o valor lido de suas saídas com este valor. Se estes forem diferentes, incrementa-se o contador de erros. A instrução SC TCK destina-se à sincronização do controlador de teste com a TAP e o núcleo em si, mas não foi implementada neste trabalho. Na memória de programa, tem-se a instrução de scan seguida do número de deslocamentos que devem ser realizados nos bits dos registradores que fazem parte da execução do teste com boundary scan, ao invés do tempo de ocorrência da instrução. No comparador foram inseridos alguns registradores que fazem parte da interface com o núcleo, estes registradores são TMS, TDI e TDO, além de um registrador que recebe o valor esperado para a resposta do circuito e compara com o valor do registrador TDO. O registrador TMS recebe o valor lido a memória quando da execução de uma instrução de SC TMS, ou SC TMTI, ou SC TMTO. O registrador TDI, quando a instrução for de TMTI. E o registrador TDO, quando a instrução for de TMTO. Na figura 6, pode-se observar essas alterações no bloco comparador. Os registradores TMS, TDI e TDO são registradores especiais, cujos valores sofrem deslocamentos controlados pela máquina de controle. O registrador TMS é carregado paralelamente com o valor lido da memória de dados e repassa este valor serialmente, bit a bit, para o núcleo, sendo seu valor deslocado para a direita uma posição a cada ciclo de relógio. O mesmo ocorre com o registrador TDI, este também tem seu valor deslocado e enviado serialmente para o núcleo. O registrador TDO, diferentemente dos demais registradores da arquitetura, é carregado serialmente mas sua leitura é paralela. O registrador TMS é de 18 bits, o TDI é de 9 bits, o registrador usado na comparação é de 8 bits, assim como o TDO. Estes valores foram definidos para a descrição original do MET, mas devem variar de acordo com o SOC que está sendo testado.

Instruções FIM_TESTE (FT) FIM_VETOR (FV) COMPARA (C) EXCITA (E) EXC/COMP (EC) SC TMS SC TMTI SC TMTO SC TCK

Código 0000 0001 0010 0011 0100 1000 1001 1010 1011

COMPARADOR

Reg_MD_ou t

Reg. Data_ Out

8

18

Memória de dados

TDI

Reg. Reg_ Resp Resp. M U X

Reg. Comp . Reg. Data _in

Tabela 2: Instruções da implementação com scan TMS

M U X

S U Erro B

Reg.

TDO Data _in

8

1

1

8

1

Figura 6: Bloco Comparador da arquitetura com scan Algumas alterações fizeram-se necessárias na máquina de estados do controle, a fim de permitir a execução das instruções envolvidas no teste com boundary scan. Foram inseridos dois estados na máquina de controle utilizada para esta implementação: os estados 6 e 7.Quando a instrução é de SCAN, o laço que testa o resultado da comparação do valor do contador de eventos com o valor lido da memória de programa, não ocorre no estado 3, e sim no estado 6, onde são gerados os sinais para a operação de deslocamento dos registradores envolvidos no teste SCAN. O estado 7 só é usado no caso de instruções SC TMTO, neste estado são gerados os sinais para o tratamento de erros.

O compilador indica o número de deslocamentos que devem ser feitos nos bits dos registradores utilizados no teste SCAN. Nesta implementação considera-se que o valor colocado na memória de programa, que será usado na comparação com a contagem do contador de eventos para indicar a saída do laço (estado 6), é uma unidade menor que o número de deslocamentos que devem ser realizados. Porque assim, pode-se diminuir o número de estados da máquina de controle, pois testa-se o resultado da comparação no mesmo estado em que habilita-se o deslocamento dos registradores envolvidos na instrução. É importante salientar aqui, que o passo do contador para um teste com boundary scan deve ser de 1, sendo este valor setado pelo compilador. Esta decisão foi tomada de forma a minimizar as alterações necessárias na máquina de controle a fim de suportar a execução do SCAN. Para não aumentar o tamanho da palavra da memória, que na implementação original era de 20 bits, optouse por não permitir a ocorrência de um teste de um núcleo com boundary scan, paralelamente à execução de um teste externo de um outro núcleo. Porém, o teste de um núcleo com BIST pode ocorrer paralelamente ao teste externo ou ao teste scan de um outro núcleo.

5. Resultados obtidos No contexto da diversidade de estratégias de teste implementadas nos núcleos que fazem parte de um sistema, identificou-se a necessidade da geração de uma arquitetura escalonável para o controle do teste destes núcleos, possibilitando o teste de circuitos com diferentes características, como número de entradas e saídas, estratégias de teste e diferentes relógios. Durante a descrição da arquitetura procurou-se torná-la o mais parametrizável possível de forma a facilitar futuras alterações. Por exemplo, no número de bits dos registradores ou da memória a fim de permitir o teste de núcleos com diferentes características. No momento da síntese, a máquina deve ser sintetizada com o número de bits necessários para o teste dos núcleos que fazem parte do sistema, sendo que o próprio controlador pode ser sintetizado junto com os núcleos e também fazer parte do sistema, isto em se tratando da implementação do mesmo através de um ASIC. As três implementações desenvolvidas no decorrer deste trabalho, foram sintetizadas utilizando a ferramenta ALTERA [ALT95]. Os resultados da síntese podem ser observados na tabela 3. Nesta tabela pode-se comparar os resultados da síntese MET com os resultados da síntese de outros microcontroladores. Microcontrolador 8051 – 8bits 8051_BIST -8 bits RISCO – 32 bits FentoJava – 8 bits MET MET_BIST MET_BIST_SCAN

Dispositivo EPF10K20TC144-3 EPF10K50RC240-3 EPF10K100GC503-3 EPF10K30RC204-4 EPF10K20TC144-3 EPF10K20TC144-3 EPF10K20TC144-3

N° de Células lógicas Perc. do dispositivo usado 680 59% 2354 81% 1271 25% 991 57% 170 14% 170 14% 257 22%

Freqüência (MHz) 3,19 2,12 4,03 7,97 36,76 37,31 34,24

Tabela 3: Comparação de Resultados de síntese Analisando-se os resultados obtidos na síntese das implementações do MET desenvolvidas, pode-se observar que estas ocupam uma área bem menor que as implementações do 8051 e RISCO, por exemplo. Além de possuírem uma freqüência até dez vezes mais alta que a apresentada pelo 8051, utilizando a mesma tecnologia e o mesmo dispositivo. Com isso, reforça-se a idéia de que este controlador de teste pode fazer parte de sistema embarcado, sem causar um overhead de área significativo, além do mesmo ser rápido o suficiente para testar vários circuitos que também podem fazer parte do mesmo sistema embarcado.

6.Conclusões e trabalhos Futuros Este trabalho apresenta uma arquitetura para um microprocessador voltado para o teste de sistemas embarcados, chamado MET (Microprocessor Embedded Test). Sobre a qual foram implementadas três estratégias de teste diferentes: o teste externo, o boundary scan e o auto-teste. Esta arquitetura baseou-se na linguagem STIL. Sendo assim, possivelmente algumas alterações terão de ser realizadas na mesma para estendêla para a linguagem CTL. As implementações desenvolvidas não obtiveram um desempenho muito alto, porém há uma classe grande de circuitos que rodam a freqüências mais baixas e que poderiam ser testados pelo MET, entre eles pode-se citar o RISCO e o próprio 8051, assim como ocupam muito mais área que o controlador de teste. Além disso, versões mais otimizadas do MET podem ser desenvolvidas e outras estratégias de teste podem ser implementadas.

Como trabalhos futuros, há também a necessidade de implementação do Compilador para a linguagem CTL. Este seria responsável pela tradução da linguagem STIL/CTL para as instruções desta arquitetura e pela verificação das informações contidas nos programas CTL para todos os núcleos do sistema. Não seria possível a implementação do system-on-chip com o controlador de teste interno baseado na arquitetura proposta aqui, sem o desenvolvimento desta etapa de compilação. Além disso, poderiam ser estudadas e implementadas algumas otimizações em cima desta arquitetura, ou ainda outras arquiteturas poderiam ser propostas. O desenvolvimento de uma descrição JAVA da arquitetura, com uso a ferramenta SASHIMI [ITO00], de forma a obter-se a geração de um ASIP (Application Specific Instruction Processor), um processador que executa CTL/STIL é outra tarefa importante. Isto possibilitaria a comparação entre as duas soluções para o interpretador, ASIC e ASIP, em termos de desempenho, facilidade de projeto e área ocupada. Na descrição de um teste com boundary scan deve ser especificado um relógio para sincronização, e portanto foi identificada neste trabalho a necessidade de inserção de uma instrução dedicada para esta função. Porém esta não foi implementada neste trabalho. Atualmente, o teste é realizado na mesma freqüência de operação do interpretador. Assim como qualquer outro circuito, o controlador de teste também é suscetível a falhas. Por isso, um outro trabalho importante a ser desenvolvido é tornar o MET auto-testável de forma a garantir a qualidade do teste.

Referências Bibliográficas [ABR90] ABRAMOVICI, M. BREUER, M. A.; FRIEDMAN, A.D.; Digital Systems Testing and Testing and Testable Design. 1990. New York: IEEE Press, 1990. 652p. [ALT95] ALTERA DATA BOOK. 1995. Altera Corporation, March, 1995. [BAC00] BACK, Eduardo S. Tecnologias Industriais de Teste: Um Estudo de Caso. Instituto de Infromática – UFRGS. Porto Alegre, abril, 2000. [COT99] COTA, E.; KRUG, M.; LUBASZEWISKI, M.; CARRO, L.; SUZIN, A.; Implementing a self-testing 8051 Microprocessor In Procedings XII Symposium on Integrated Circuits and Systems Design. September 29 to October 4, 1999. Natal, Brazil. [GUP97] GUPTA, R.K.; ZORIAN, Y. Introducing Core-Based System Design. IEEE Design & Test of Computers, Los Alamitos, v.14, n.4, p. 15-25, Oct.-Dec. 1997. [IEE90] IEEE Standard 1149.1 - 1990, IEEE Standard Test Access Port and Boundary Scan Architecture, IEEE Standards Board, 345 East47 th Street, New York, NY 10017-2394, USA, 1990. [ITO00] ITO, S. A., CARRO, L., JACOBI, R. P.. System design based on single language and single-chip java asip microcontroller. In: .DESIGN AUTOMATION AND TEST IN EUROPE, 2000, Paris. Proceedings of Date 2000. ACM, 2000. v.1. p.703-707. [ITO00] ITO S.; CARRO, L.. A Comparison of Microcontrollers targeted to FPGA-Based Embedded Applications. In Procedings XIII Symposium on Integrated Circuits and Systems Design. 18-24 September, 2000. Manaus, Brazil. [KEL99] KELLER, B.. IBM. Using STIL to Describe Embedded Núcleo Test Requeriments. ITC -99 [MAR99] MARININSSEN, E. J. et. al. Towards a Standard for Embedded Núcleo Test: An Example. In: IEEE International Test Conference, 1999, pp.616-627. [McC85] McCLUSKEY, E. J. Built-In Self-Test Techniques, IEEE Design and Test of Computers, Vol. 2 Nº. 2, abril 1985. [PAP99] PAPACHRISTOU, C. A.; MARTIN, F.; NOURANI, M. Microprocessor Based Testing for CoreBased System on Chip. In Procedings 36th Design Automation Conference. New Orleans, L. A. June 21-25, 1999. [PAR00] PARNAS, B. R. Doing it in STIL: Intelligent Conversion From STIL to na ATE Format. ITC 00. [REF1] http://commx.ltx-tr.com/STIL/ IEEE standard Test Interface Language (STIL) for Digital Test Vector Data - Draft Specification (IEEE Std 1450. May, 1996). Dezembro, 2000. [REF2] http://groupe.ieee.orggroups/ IEEE Standards Working Group Areas [REF3] Introduction STIL BNF. Document version 1.1, December 4, 1998.