Uso de Controladores Internos para Teste de SoCs
Leandro Cassol
Érika Cota
Marcelo Lubaszewski
PPGEE – Depto. Engenharia Elétrica
PPGC- Instituto de Informática
UFRGS
UFRGS
Osvaldo Aranha, 103 Cep 90035-190
Caixa Postal 15064 – Cep 91501-970
Porto Alegre, RS – Brasil
Porto Alegre, RS – Brasil
Abstract
This paper discusses some aspects related to the use of an embedded test controller for systems-on-chip. Based on a dedicated architecture for a test controller, its insertion into the SoC as an additional core is evaluated in terms of area overhead, hardware reuse and required performan-ce. Then, the conditions for a successful utilization of this kind of test solution are outlined, along with criteria and usage requirements of the controller itself.
1. Introdução
Na era SoC (System on Chip), o teste se tornou um dos passos mais custosos no desenvolvimento de projetos de circuitos eletrônicos [1], [2]. De fato, os problemas relaci-onados às fases de teste de um SoC são bastante diferentes daqueles apresentados em metodologias tradicionais de projetos.
Dois problemas importantes relativos ao teste de SoCs são: o acesso aos núcleos de hardware, e a combinação da capacidade de teste e diagnóstico dos diferentes núcleos que integram o sistema [1]. Além disso, as exigências de teste devem ser atendidas dada uma quantidade limitada de recursos (geradores de padrões de teste, controladores BIST, pinos extras no chip, área extra em silício e tempo de teste, etc). O uso dos tradicionais equipamentos auto-máticos de teste (ATE - Automatic Tet Equipment) pode representar outra importante limitação devido à largura dos mecanismos de acesso aos núcleos (TAM – Test Ac-cess Mechanism) e da freqüência de relógio utilizada no teste. Normalmente, para TAMs com larguras grandes são utilizadas cadeias de varredura (scan), as quais limitam a velocidade do teste e também impõem restrições adicio-nais quanto ao número de vetores de teste.
A solução clássica empregada para suprir a limitação dos recursos de teste é o reuso de hardware [3], [4]. Por exemplo, testar mais de um núcleo de hardware utilizando o mesmo gerador de padrões de teste ou o mesmo
barra-mento são estratégias que foram propostas para reduzir área em silício [5].
Controladores de teste também devem ser considera-dos por ocasião da definição da estratégia de teste do sis-tema. Normalmente, esta tarefa é executada por um ATE. Porém, alguns autores têm sugerido o uso de processado-res e memórias disponíveis no próprio sistema [6], [7]. Em um ambiente SoC, esta é uma solução interessante, uma vez que, freqüentemente, estes circuitos possuem um ou mais processadores, além de núcleos de memória em abundância.
O uso de um processador dedicado para o teste é outra solução proposta para controladores integrados [8], [9], [10]. Estes processadores podem ser muito eficientes em termos de área e desempenho, já que, são dedicados e sintetizados com a mesma tecnologia do sistema sob teste. Assim, o controlador de teste é outro núcleo dentro do SoC. Mais uma vez, o reuso de hardware é conseguido através da utilização de memórias disponíveis no sistema para armazenar os padrões de teste.
Entretanto, critérios para a tomada de decisão quanto ao uso de controladores integrados ainda não foram obje-tivamente explorados na literatura. Alguns trabalhos suge-rem a substituição quase total dos equipamentos externos de teste por um controlador interno [6], [7]. Outros traba-lhos sugerem uma interação entre processadores internos e os ATEs. Questões cruciais para a definição das vantagens e condições de uso de tais controladores permanecem sem respostas: Se a memória interna não é grande o suficiente para o armazenamento de todos os vetores de teste, como os núcleos de hardware podem ser internamente controla-dos? De que maneira podemos assegurar o correto desem-penho do controlador de forma que os testes implementa-dos possam ser realizaimplementa-dos na freqüência de operação do sistema (at-speed) ?
Este artigo visa responder algumas destas perguntas, mostrando a complexidade e as diferentes possibilidades de uso de um controlador interno ao SoC e dedicado para o teste, através de exemplos. Alguns trabalhos relaciona-dos são apresentarelaciona-dos na seção 2. Na seção 3 um processa-dor dedicado para o teste [10] é descrito brevemente. A
seção 4 discute as diferentes possibilidades de inserção do MET em um SoC. As conclusões são apresentadas na seção 5 juntamente com trabalhos futuros.
2. Trabalhos Anteriores
A idéia de transferir parte das tarefas normalmente reali-zadas pelo ATE para um núcleo de teste do SoC já foi explorada em alguns situações. Em [9] um modelo de microcontrolador é usado para implementar uma estratégia BIST(Built-In Self-Test) de alto desempenho para testar memórias DRAMs embutidas. Uma estrutura do tipo pro-cessador busca e executa uma série de instruções de teste que formam um padrão a ser aplicado à memória sob teste. [8] sugere um modelo distribuído para controlador de teste, considerando o teste de tipo scan (total ou parcial) e BIST dos núcleos. Neste caso, cada núcleo tem uma interface lógica ad hoc para conexão com os dados de teste e o controle dos barramentos. Núcleos no mesmo nível de hierarquia são conectados no mesmo barramento de teste, formando uma topologia tipo anel. Um controla-dor dedicado testa este barramento e informações são transferidas entre os núcleos usando um protocolo. A interface entre o núcleo e o barramento de teste imple-menta um conjunto de comandos de teste que são gerados pelo processador de teste associado. O programa de teste inteiro é carregado por meio de uma porta TAP (Test Ac-cess Port) e distribuído para os vários proAc-cessadores de teste internos. Embora este esquema apresente alguma flexibilidade em termos de estratégias de teste em núcleos, o teste at-speed pode ser executado somente por núcleos com BIST autônomo, enquanto algumas capacidades de teste dos núcleos não são considerados para o teste do sistema como um todo.
[6] propõe o uso de um microprocessador disponível no sistema como um controlador de teste. Porém o micro-processador pode ser um dos núcleos mais complexos a serem testados dentro do sistema e ainda deve ser conside-rado como livre de falhas para que possa ser utilizado para testar outros núcleos integrados. Um estratégia de self-test para estes núcleos, ou mesmo uma estratégia de teste ex-terno, pode conduzir a custos extras elevados para o teste do sistema, além do microprocessador disponível no sis-tema não operar na velocidade exigida por alguns testes, como por exemplo, o teste de um filtro.
3. Processador Dedicado de Teste
Em [10], um processador integrado exclusivo é proposto para o controle e a manipulação dos dados de teste. A síntese resultante deste trabalho mostra que a área do processador pode ser ajustada de acordo com as restrições do sistema, uma vez que somente uma pequena parte do circuito é perene.
A arquitetura do processador proposta naquele traba-lho é baseada na existência de uma ferramenta de plane-jamento de teste que, a partir de combinações de teste para os núcleos, gera o sequenciamento de teste para o sistema, considerando as restrições relativas aos dados de teste. Esta estratégia pode ser então traduzida em um conjunto de instruções do processador. O conjunto de instruções inclui: a aplicação de vetores nos núcleos, a comparação de respostas do teste, a imposição de valores de entrada e saída às cadeias scan, e a habilitação de BIST autônomo.
A figura 1 mostra a arquitetura geral do controlador de teste. Memórias são necessárias para o armazenamento do programa e dos dados de teste. Estas memórias podem ser exclusivas ou podem ser memórias disponíveis no sistema.
Figura 1. Arquitetura do Controlador de Teste.
Uma informação importante a ser considerada pelo controlador de teste é o tempo relativo à aplicação dos dados de teste. A sincronização entre o controlador e o núcleo sob teste tem que garantir que cada vetor seja envi-ado no momento correto, e que as respostas dos núcleos sejam analisadas no tempo estimado. Para realizar esta sincronização um contador de eventos é utilizado. Este contador controla quando é o momento correto de enviar, habilitar um sinal, ou analisar uma resposta. Com a finali-dade de diminuir o tamanho do contador, foi implementa-do um passo, que é o máximo divisor comum entre os tempos associados aos vários padrões de teste. O passo é armazenado na primeira linha do conjunto de instruções que encontra-se armazenado na memória de programa, e quando o contador alcança um múltiplo deste a sua saída é atualizada e comparada com o tempo da próxima instru-ção. Quando os tempos são iguais a instrução é executa-da, caso contrário mantém-se o estado de espera até que os valores sejam iguais. Buscam-se as instruções e os dados de testes a serem enviados para o núcleo quando sinaliza-do que é tempo para realizar uma ação. Deste mosinaliza-do,
atra-sos relacionados com o controle do processador são evita-dos.
A arquitetura apresentada em [10] também baseia-se na existência de mecanismos de acesso que garantam a comunicação entre o controlador de teste e os diversos núcleos. A presença de uma interface configurável entre o controlador e os núcleos (definida para cada sistema de acordo com a TAM disponível) permite que diferentes larguras de TAMs possam ser utilizadas sem afetar a es-trutura de controle básico do processador.
O controle do processador de teste foi definido para ser o mais simples possível com a finalidade de alcançar um alto desempenho.
Este controlador embutido considera alguns níveis de re-configurabilidade na interface com o sistema e no con-junto de instruções. A idéia básica da arquitetura proposta foi favorecer o teste at-speed. Logo, fica implícito que somente um pequeno número de núcleos seriam controla-dos pelo processador dedicado e a memória disponível no sistema deveria ser suficiente para armazenar os padrões e as respostas do teste. Porém, devido à complexidade dos sistemas e das técnicas de teste atuais, a possibilidade de ampliar o número e os tipos de núcleos que seriam con-trolados por uma estrutura interna seria de grande utilida-de. Considerando que o controlador interno e as memórias já estejam disponíveis, resta o problema de como aperfei-çoar seu uso de forma que o custo de teste do sistema seja minimizado. Para responder a esta questão alguns experi-mentos foram elaborados utilizando uma versão melhora-da do controlador proposto em [8]. Estes experimentos são apresentados na próxima seção.
4. Avaliação do Controlador Interno em um
SoC
Considere o sistema arbitrário mostrado na figura 2. Este SoC será utilizado para fazer uma análise da aplicabilida-de e a proposta aplicabilida-de melhoramentos para o controlador apresentado em [10]. O sistema é composto por 7 núcleos formados por benchmarks ISCAS’85 e ISCAS’89. As co-nexões internas que ligam os núcleos foram determinadas aleatoriamente. As informações sobre o número de entra-das/saídas, número de cadeias scan internas (linhas trace-jadas no desenho) e também a quantidade mínima de ci-clos de teste para cada núcleo são mostradas na figura 2. As informações referentes aos ciclos de teste foram cal-culadas assumindo acesso exclusivo às cadeias scan e aos pinos de entrada/saída. Os dados utilizados para o cálculo foram obtidos a partir de [11].
Os seguintes experimentos foram realizados utilizando o sistema da figura 2:
1) Teste paralelo de todos os núcleos com acesso exclusivo por um ATE.
2) Teste serial dos núcleos com diferentes larguras de memórias utilizando um controlador interno.
3) Teste explorando paralelismo com diferentes lar-guras de memórias utilizando um controlador inter-no.
Figura 2. Sistema utilizado como exemplo.
Assumindo que o sistema avaliado não possui memó-rias e que um ATE está conectado por um acesso exclusi-vo a todos os núcleos do sistema, os testes de todos os módulos serão realizados em paralelo.
Considerando as entradas/saídas e acessos para as ca-deias scan internas de cada núcleo, seriam necessários 454 pinos extras no chip para realizar a comunicação entre os núcleos e o ATE. Também seria necessário um buffer de grande capacidade para enviar todos os estímulos necessá-rios e analisar as respostas fornecidas pelos núcleos. Em contrapartida, seriam necessários apenas 5723 ciclos de relógio para o término do teste total do sistema. Este tem-po correstem-ponde ao temtem-po de teste do núcleo mais lento. A tabela 1 mostra os valores de tempos, conexões e pinos extra para o teste descrito.
Tabela 1. Ciclos e hardware extra para uma conexão exclusiva com um ATE.
Núcleo Ciclos Conexões Internas Extras Pinos Extras 1 2507 37 37 2 4507 60 60 3 12 42 42 4 106 39 39 5 5723 30 30 6 3359 56 56 7 3656 190 190 Total →→ 5723 454 454
Realizando esta mesma análise considerando o con-trolador descrito em [10] seria necessária uma memória interna com uma largura de palavra de 631 bits, e cone-xões desta memória com os módulos. Esta estratégia leva-ria a uma grande quantidade de hardware extra, aumen-tando significativamente a área em silício. Esta área extra
pode ser equivalente ou até mesmo superior à área do próprio sistema.
No caso do sistema possuir uma ou mais memórias, estas podem ser utilizadas para armazenar os padrões de teste. É possível realizar o teste serial de cada núcleo ou, caso exista espaço disponível em memória, este espaço pode ser utilizado para armazenar dados de outros núcleos e realizar o teste de alguns módulos em paralelo. Caso o sistema possua várias memórias, estas podem ser configu-radas para formar uma única memória com uma largura de palavra maior. As figuras 3 e 4 mostram os resultados da análise feita para o teste de módulos com diferentes tama-nhos de memórias. 0 20000 40000 60000 80000 8 16 32 64 128
Tamanho da palavra de memória (bits)
Ciclos
Sem Paralelismo Com paralelismo
Figura 3. Variação do tempo de teste em função da largura de palavra da memória.
0 100 200 300
8 16 32 64 128
Tamanho da palavra de memória (bits)
Conexões
Sem paralelismo Com paralelismo
Figura 4. Variação na quantidade de conexões em função da largura da memória.
Esta análise mostra o teste sem paralelismo e explo-rando o paralelismo sempre que existe espaço disponível em memória. Na figura 3 mostra-se a variação da quanti-dade de ciclos necessários para o teste em função do ta-manho da palavra de memória. A figura 4 mostra a varia-ção do número de conexões internas. Para o cálculo das conexões foi considerado um barramento ligando a memó-ria com os núcleos.
A largura da memória é muito importante quando um controlador embutido é utilizado. As figuras 3 e 4 mos-tram que quanto maior a largura da memória, menores são os tempos para o teste. O paralelismo pode ser muito bem explorado de acordo com a largura da palavra e pode con-tribuir para um menor tempo de teste.
Alguns autores têm sugerido técnicas para gerar um plano de teste [12], [13], [14]. Em [12] é proposto um modelo de planejamento de teste em um ambiente SoC. O plano é gerado por um algoritmo a partir do modelamento
do sistema, considerando diferentes mecanismos de acesso utilizados para o teste. Ele gera um plano com máximo paralelismo e insere o menor número de pinos extra a partir da especificação do integrador do sistema. O plano gerado apresenta o menor tempo de teste dentro das diver-sas restrições de projeto. Na figura 5 mostra-se o plano de teste gerado para o sistema da figura 2 pela ferramenta descrita em [12]. Este plano foi gerado com o incremento de 94 pinos no chip, para fazer os acessos aos núcleos. A parte inicial do plano vista na figura 5, mostra que os núcleos 1, 6, 2, 5 e 7 podem ser testados em paralelo. Devido à limitação dos acessos aos núcleos, existem casos onde é preciso terminar o teste de um módulo antes de começar outro. Este é o caso dos núcleos 4 e 3 mostrados na figura 5. É importante notar que este plano de teste foi feito sem considerar a existência de memórias internas como fonte de vetores de teste. A idéia deste exemplo é mostrar como o controlador se adapta a um planejamento de teste já definido.
Figura 5. Plano para tempo de teste atendendo restri-ções de projeto
Suponhamos agora que o plano de teste mostrado na figura 5 deva ser controlado pela arquitetura descrita em [10]. Observa-se que é necessária uma grande quantidade de memória devido ao grande paralelismo. A exigência de uma memória com largura grande deve-se ao fato dos padrões de teste para estes núcleos serem muitos para atender grandes quantidades de cadeias scan e de entra-das/saídas. Utilizando uma memória interna, o teste pode ser realizado de acordo com o plano proposto, porém o tempo necessário para o teste aumenta em muito, isto porque é necessário um deslocamento serial dos padrões.
Em alguns casos utiliza-se o recurso de compactação de vetores para reduzir a quantidade de dados armazena-dos. Na tabela 2, mostra a quantidade mínima de padrões para a cobertura de falhas nos benchmarks utilizando o conjunto de testes [15]. Na tabela também são apresenta-dos os valores compactaapresenta-dos pelo método MinTest [11] e Golomb [16], [17].
Em [11] é utilizado um método de compactação dinâ-mica. Neste método, são encontrados valores redundantes nos padrões reduzindo a quantidade de padrões. A vanta-gem do método sugerido em [11] está nos valores gerados que não foram substituídos por palavras códigos. Assim,
não é necessário nenhum software ou hardware extra para descompactação.
Tabela 2. Padrões de teste sem compactação, com compactação MinTest e com compactação Golomb.
Núcleo No. Total de Bits (Hitec) No. Total de Bits (MinTest) No Total de Bits (Golomb) S9234 39273 25935 22250 s838 5025 5025 5025 S5378 23754 20758 14085 C6288 384 384 384 C1908 4587 3498 2876 S38417 164736 113152 92054 S15850 76986 57434 40717 Total →→ 314745 226186 177391
O algoritmo sugerido em [17] usa códigos de compres-são variable-to-variable-length, que substituem uma se-qüência de valores por uma palavra código. O inconveni-ente neste tipo de compressão é que existe um incremento de tempo e área devido ao hardware/software necessário para realizar a descompressão. Porém, em casos onde existe o limite físico das memórias utilizadas, eles se adaptam perfeitamente. A desvantagem do tempo extra necessário para a descompactação é minimizada, uma vez que os controladores dedicados podem trabalhar em um freqüência de relógio superior a freqüência do circuito que se deseja testar. Vários trabalhos na área de compactação de vetores de teste tem sido apresentados nos últimos anos. Os métodos apresentados aqui, foram utilizados apenas como ilustração para os casos onde exista falta de memória para armazenar os dados de teste.
A grande vantagem do uso de processadores embuti-dos específicos para o teste, está na sua freqüência de operação. Como estes circuitos são simples, eles podem trabalhar em freqüências superiores aos núcleos mais complexos que fazem parte do SoC. A tabela 3 mostra um comparativo de performance entre alguns núcleos e o processador de teste proposto em [10].
Tabela 3. Comparativo de área e performance entre núcleos.
Núcleo No. de Células Lógicas Freqüência (MHz) MET 257 34.24 8051 – 8 bits 680 3.19 BIST 8051 – 8 bits 2354 2.12 RISCO – 32 bits 1271 4.03 FemtoJava – 8 bits 991 7.97 LMS filter – 8 bits 286 10.71
Estes núcleos foram sintetizados em VHDL com o software Max+Plus II da Altera, onde obteve-se o número de células lógicas que compõem o núcleo e a máxima freqüência de operação. Essa capacidade de operação em uma freqüência maior, pelo processador de teste, pode ser utilizada para o preenchimento de um buffer. Este buffer teria largura da TAM e seria utilizado para carregar os vetores armazenados em uma memória de largura inferior a TAM. Este buffer pode ser construído dentro do SoC, através do reuso de registradores.
5. Conclusões e Trabalhos Futuros
Os exemplos exploraram situações extremas, pois a inten-ção era enfatizar algumas das dificuldades de teste. Em alguns sistemas reais, estas situações podem ocorrer. Nos dias atuais, não basta simplesmente colocar um ATE ou um controlador interno e esperar que o teste seja atendido satisfatoriamente. O controlador, sem dúvida, é um ele-mento de fundamental importância para o teste, mas al-guns aspectos devem ser considerados.
A ferramenta que gera o plano de teste deve considerar a presença do controlador, interno ou externo, e das me-mórias associadas ao processo.
O uso de memórias deve ser realizado da forma mais eficiente possível. Para a otimização do uso das memórias, o teste deve ser executado considerando a re-configurabilidade dos caminhos de acesso, de forma a utilizar a máxima largura de palavra sempre que possível.
A reconfiguração dos caminhos deve ser executada on-line durante o teste por meio da TAM [18], [19], [20], [21] e dos wrappers [22]. A medida que os núcleos são retira-dos ou colocaretira-dos no sistema, os wrappers são reconfigu-rados para melhorar os acessos. Os tempos de testes são alternados entre momentos onde o teste é feito de forma mais rápida e momentos onde é feito de forma mais lenta. Com esta estratégia o teste do sistema total tende a ser diminuído.
Também existem casos onde a quantidade de memória é restrita. Nestes, o controlador interno pode ser utilizado para realizar o controle do teste nos núcleos críticos, onde exista a necessidade de melhores performance durante o teste, deixando para o ATE os núcleos menos críticos e assim diminuindo a número de pinos para realizar a inter-face entre o SoC e o controlador.
O desenvolvimento de uma ferramenta que gere um controlador embutido a partir de parâmetros básicos é trabalho que pretendemos realizar no futuro. O plano de teste é proposto a partir do controlador gerado. Reuso de memória, TAM, posição do controlador no sistema e wra-ppers são considerados no plano de teste. Informações sobre os vetores e como eles devem ser montados nas memórias também devem ser considerados pela ferra-menta. Velocidade de operação do processador de teste e dos núcleos também devem ser considerados a fim de obter uma melhor performance.
6. Referencias
[1] Y. Zorian. Test Requirements for Embedded Core-Based Systems and IEEE P1500. In International Test Conference, pages 191-199. IEEE Computer Society, September 1997.
[2] Yervant Zorian, Erik Jan Marinissen, and Sujit Dey. Testing Embedded-Core Based System Chips. In Proc. IEEE International Test Conference (ITC), pages 130– 143, Washington, DC, October 1998. IEEE Computer Society Press.
[3] Prab Varma and Sandeep Bhatia. A Structured Test Re-Use Methodology for Core-Based System Chips. In Proc. IEEE International Test Conference (ITC), pages 294-302, Washington, DC, October 1998. IEEE Com-puter Society Press.
[4] Fidel Muradali, Rob Aitken, and Neal Jaarsma. System-Level-Integration Test Hardware and its Impact on Reuse and Design. In Digest of Papers of IEEE Interna-tional Workshop on Testing Embedded Core-Based Systems (TECS), pages 1.1-1-6, Dana Point, CA, April 1999.
[5] Vikram Iyengar and Krishnendu Chakrabarty.
Iterative Test Wrapper and Test Access Mecha-nism Co-Optimization. In Digest of Papers of IEEE International Workshop on Testing Embe-dded Core-Based Systems (TECS), pages 1.4-1-7, Marina del Rey, CA, May 2001.
[6] C. A. Papachristou, F. Martin, and M. Nourani.
Microprocessor Based Testing for Core-Based System on Chip. In ACM/IEEE Design Automati-on CAutomati-onference, pages 586–591. ACM, June 1999.
[7] Rajsuman, Testing a System on a Chip with Embedded Microprocessor, Proc. Of Int. Test Conf., 1999.
[8] Benso, S. Chiusano, S. D. Carlo, P. Prinetto, F. Ricciato, M. Spadari, and Y. Zorian. HD2BIST: a Hierarchical Framework for BIST Scheduling, Data Patterns Deliv-ering and Diagnosis in SoCs. In International Test Conference, pages 892–901. IEEE Computer Society, October 2000.
[9] J. Dreibelbis, J. Barth, and H. Kalter. Processor-Based Built- In Self-Test for Embedded DRAM. IEEE Journal of Solid- State Circuits, 33(11):1731–1740, November 1998.
[10] COTA, E.; BRISOLARA, L.; CARRO, L.; SUSIN, A.; LUBASZEWSKI, M. MET: An Embedded Processor for Test Controlling. In: 5th IEEE International Work-shop on Testing Embedded Core-based Systems (TECS 01)-Marina Beach Marriott – Marina del Rey, Los An-geles, CA May 2-3, 2001.
[11] K. Hamzaoglu and J. H. Patel, Test set compaction Algorithms for combinational circuits, Proc. Interna-tional Test Conference on CAD, pp. 283-289, 1998. [12] E. Cota, L. Carro, A. Orailoglu, M. Lubaszewski Test
Planning and Design Space Exploration. In a Core-based Environment Aceito para Design Automation and Test in Europe (DATE 2002) A ser realizado em Paris, FR, em março de 2002.
[13] K. Chakrabarty. Test scheduling for core-based systems using mixed-integer linear programming. IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems, 19(10):1163-1174, October 2000.
[14] Vikram Iyengar and Krishnendu Chakrabarty. Prece-dence-Based, Preemptive, and Power-Constrained Test Scheduling for System-on-a-Chip. In Proc. IEEE VLSI Test Symposium (VTS), pages 368-374, Marina del Rey, CA, May 2001. IEEE Computer Society Press.
[15] The University of Illinois, www.crhc.uiuc.edu/IGATE. [16] S. W. Golomb, Run-length encoding, IEEE Trans. Inf.
Theory, vol. IT-12, pages 399-401, 1966.
[17] Chandra and K. Chakrabarty, Test data compression for system-on-a-chip using Golomb codes, Proc. IEEE VLSI Test Symp., pages 113-120, 2000.
[18] E.J. Marinissen, R. Arendsen, G. Bos, H. Dingemanse, M. Lousberg, and C. Wouters. A structured and scalable mechanism for test access to embedded reus-able cores. In Proc. IEEE International Test Conference (ITC), pages 284-293, 1998.
[19] Nourani and C. Papachristou. Test access mechanism for core-based system-on-chip. In Proc. IEEE International Test Conference (ITC), pages 902-910, 2000.
[20] Nourani and C. Papachristou. Test access
mecha-nism for core-based system-on-chip. In Proc. IE-EE International Test Conference (ITC), pages 902-910, 2000.
[21] Sandeep Kumar Goel and Erik Jan Marinissen. TAM Architectures and Their Implication on Test Application Time. In Digest of Papers of IEEE International Workshop on Testing Embedded Core-Based Systems (TECS), pages 3.3–1–10, Marina del Rey, CA, May 2001.
[22] E.J. Marinissen, S.K. Goel, and M. Lousberg. Wrapper design for embedded core test. In Proc. IEEE International Test Conference (ITC), pages 911-920, 2000.
