L’écriture précède la parole

Comumente, o fluxo de geração de padrões funcionais que rodam no testador começa com a criação do “testbench”. A partir dele é projetado e simulado cada um dos padrões, extraindo suas formas de onda. As formas de onda capturadas são codificadas em uma linguagem intermediária e depois é realizada uma resimulação, para ver que não foram perdidos e/ou adicionado dados que resultem em uma

-criar instancia do controlador de ativação com entradas FC_CLK e SIM_INI (reset)

-agregar flip-flop (registro de deslocamento 0) com sinal de set ligado ao SIM_INI, relógio ao FC_CLK e entrada de dados a zero

-Para cada item de @falhas

-porta=célula associada a $item - Se $item é sinal de entrada

-cortar sinal de $item

-conectar saída de elemento de falha com entrada de porta

-conectar antigo driver de porta com entrada de sinal de elemento de falha -senão

-cortar sinal de $item

-conectar entrada de sinal de elemento de falha com saída de porta -conectar saída de elemento de falha com drived sinal

-fim

-criar flip-flop em controlador de ativação ligando reset com sinal SIM_INI, relógio ao FC_CLK e entrada de dados à saída de ultimo flip-flop do controlador

-conectar saída de novo flip-flop com entrada de ativação do elemento de falha -fim

diferença no comportamento do circuito. Finalmente o resultado intermediário é convertido em uma linguagem que o testador entende, sofrendo uma ou várias transformações. Este processo se ilustra na Figura 7-3.

Figura 7-3: Fluxo de geração de padrões de teste

Da mesma forma foi idealizado um fluxo para a geração de vetores de teste para a co-emulação de falhas, com a diferença de que os vetores são extraídos diretamente da simulação, sem passar por nenhuma transformação e sem necessidade de resimulação. Salienta-se que os mesmos vetores podem ser transformados na linguagem do testador de forma direta, devido à maneira como são extraídos os dados. Isto resulta em uma vantagem para o método, já que não só se diminuem o número de passos para a extração de vetores de teste, como também se garante que tanto a co-emulação como o exercício do vetor no testador, trabalham com exatamente os mesmos dados.

Para facilitar o armazenamento e administração dos vetores foi definida a codificação ilustrada na Tabela 7-1. Cada palavra é constituída pelos quatro bits

R ep eti r p ar a ca d a p ad rã o Criação de testbench Criação de padrão

Extração de forma de onda da simulação

Resimulação do padrão com a forma de onda extraida

Transformação para linguagem do testador

mais significativos, que definem a função a aplicar, mais vinte e oito bits de dado. Desta forma, no caso de “single railed logic” é possível controlar vinte e oito sinais de entrada do DUT e observar vinte e oito saídas. Para dual railed logic este número se reduz para quatorze. Em caso de necessidade de mais entradas e/ou saídas se podem utilizar os seguintes quatro bits mais significativos para indicar o porto que se está controlando/observando.

Tabela 7-1: Codificação dos vetores de teste

Definiu-se que os sinais extraídos da simulação devem ser do tipo “Non Return to Zero” (NRZ) e que a comparação dos sinais monitorados deve ser feita no inicio de cada ciclo. Isto significa que o relógio de captura deve ser no máximo meio período do o mínimo relógio do DUT. Também, que o padrão deve ser projetado para realizar a comparação dos sinais monitorados em momentos onde se garanta o estado estável dos mesmos.

Para o “testbench” de simulação foram projetados três elementos sincronizados pelo relógio de captura: “Driver”, “Monitor” e Gerador de vetores. Um “driver” é instanciado para cada entrada do DUT. Ele se encarrega de enviar o sinal de controle para as entradas, sincronizando o dado de entrada com o relógio de simulação. Da mesma forma um monitor é instanciado para cada saída. Ele compara o dado esperado com o observado na saída, no momento em que o relógio de captura sobe. Caso exista diferença no cotejo, aponta o erro. Deve-se usar uma lógica „OU‟ entre todos os sinais de erro dos monitores, e no final da simulação

Código(4 MSB) Sinais(28 bits) Significado

0x0 0xXXXXXXX Exercita as entradas do DUT com o valor de sinal especificado 0xF 0x(máscara) Não compara saídas do DUT com bit de máscara 1

0x8 0xXXXXXXX Valor esperado nas saídas do DUT

0xC 0x(número) Repete instruções em loop "número" vezes 0xE 0x0000000 Fim de loop

0x1 0x(número) Mensagem para modelo comportamental "número" 0x2 0x(mensagem) Dados da mensagem

garantir que a sinalização de erro é zero, caso contrário deve-se realizar um ajuste no padrão e repetir a geração do vetor de teste. Quando o dado esperado é X não é feita comparação nenhuma para esse sinal monitorado, no ciclo especificado. O gerador de vetores captura as entradas e saídas, e gera um arquivo com a codificação do vetor de teste. Um ciclo de teste corresponde às sequências de entrada, mascara de saídas e saídas. Caso todas as saídas estejam mascaradas não se escreve no arquivo de teste a palavra de máscara nem a de saída. Um ciclo de teste é capturado para cada ciclo de relógio de captura. Cada palavra no arquivo resultante deve estar escrita usando a codificação anteriormente apresentada,