Atividade final da disciplina Introdução à Microeletrônica, do curso de Engenharia da Computação - UFPB.
Alunos: Giovanni Bruno Travassos de Carvalho; Rafael de Melo Oliveira
tags: microeletronics, microeletronica, geradornpa, PRNG, ufpb, LFSR
O objetivo desse repositório é mostrar o processo de desenvolvimento do projeto final da disciplina de Introdução à Microeletrônica no semestre 2023.1, que busca construir um gerador de números pseudo-aleatórios (PRNG, pseudorandom number generator) de 8 bits com realimentação linear. O trabalho começou com uma descrição comportamental em alto nível e uma geração de padrões de teste e passou por vários passos, que serão especificados, até chegar em um layout físico e uma simulação precisa da operação de geração dos números aleatórios. Todos os arquivos obtidos estarão anexados a esse repositório.
Para criação do gerador de números pseudo-aleatórios precisamos construir um registrador de deslocamento com realimentação linear (LFSR, linear feedback shift register), utilizando a função XOR. O LFSR é um registrador de deslocamento cujo bit de entrada é uma função linear de seu estado anterior. O valor inicial do LFSR é chamado de seed (semente) e, como a operação do registrador é determinística, o fluxo de valores produzido pelo registrador é completamente determinado pelo seu estado atual (ou anterior). Da mesma forma, como o registrador possui um número finito de estados possíveis, ele deverá eventualmente entrar em um ciclo de repetição. No entanto, um LFSR com uma função de feedback bem escolhida pode produzir uma sequência de bits que parece aleatória e tem um ciclo muito longo. O polinômio de realimentação usado para um registrador de 8 bits é definido por:
O gerador NPA construído funciona basicamente pegando um número binário de 8 bits como entrada e aplicando a função XOR em alguns de seus bits levando em consideração o polinômio escolhido, de maneira que o número não irá se repetir. Esse novo número gerado é usado como entrada de realimentação do mesmo circuito.
Figura 1: Ilustração do funcionamento do LFSR
Com o método de construção para o gerador estabelecido, antes de passar para o desenvolvimento de uma de linguagem de descrição de hardware, primeiro será obtido um padrão de testes para confirmar uma sequência de saídas esperadas pelo circuito. Por meio da biblioteca “genpat.h” é possível obter uma simulação de forma menos complexa para conseguir ter um parâmetro comparativo ao se criar o layout físico. Após compilar o código por meio do comando “alliance-genpat -v {nome do arquivo}” é gerado o arquivo .pat com as saídas processadas sendo possível agora utilizá-las para visualização e método de comparação. Utilizamos a abordagem Top-Down para concepção do circuito, então começamos com uma descrição em VHDL comportamental de alto nível, sem muita preocupação com a implementação, que será convertida para um circuito implementável em VHDL comportamental, e finalmente, criado o layout físico das células padrão. Com essa descrição comportamental do circuito feita, utilizamos a ferramenta vasy para convertê-la para um conjunto de VHDL implementável pelas demais ferramentas que serão utilizadas (“.vbe”). O arquivo .vbe obtido foi otimizado através da ferramenta boom, que otimiza uma descrição comportamental usando uma representação RBDD (Reduced Ordered Binary Decision Diagram) de sua função lógica. Além disso, provamos a equivalência entre os arquivos obtidos com a ferramenta proof.
Figura 2: Otimização e prova de equivalência
Após, usamos a ferramenta boog (Binding and Optimizing on Gates) para mapear uma descrição comportamental em uma biblioteca de células padrão predefinidas. Essa ferramenta constrói uma rede booleana equivalente à descrição otimizada obtida com boom. Então, para cada função booleana de cada nó da rede ele tenta encontrar uma célula ou conjunto de células que implemente aquela função. O resultado é um arquivo “.vst” que será uma descrição estrutural baseada nas células da biblioteca sxlib da Alliance. Em seguida otimizamos esse arquivo utilizando a ferramenta loon (Light Optimizing On Nets).
Figura 3: Resultados da otimização do atraso crítico
Podemos observar que a otimização aumentou a área, o não otimizado tem área de 74 mil lambda, já o otimizado tem área de 75 mil lambda, e o número de nós continua o mesmo. Porém o caminho crítico de dados diminui, de 274 ps no não otimizado passa para 66 ps no otimizado, ou seja, o atraso máximo é menor no otimizado. Isso acontece pois os componentes no caminho crítico são bufferizados ao aumentar a largura desses componentes.
Agora utilizamos a ferramenta alliance-ocp para posicionar as células padrão no circuito que será criado, e a ferramenta nero para rotear essas células, com isso obtemos um arquivo “.ap” e conseguimos visualizar o circuito gerado através da descrição comportamental utilizando o comando xsch.
Figura 4: Circuito obtido
Uma vez descrito o comportamento procedural e gerado o arquivo de padrão de testes com a biblioteca genpat.h, podemos visualizar esse padrão de testes gerado. O arquivo de padrão .pat é um arquivo de texto, mas com um formato rígido que pode ser usado para simulação e que pode ser visualizado graficamente com a ferramenta xpat.
Figura 5: Visualização dos padrões de teste
Figura 6: 'lfsr_sim.pat' gerado pelo _genpat.h_
O arquivo é uma série temporal, em que cada linha corresponde a um instante de tempo, e cada coluna contém os valores em cada instante de uma variável. Ao observarmos os padrões de teste gerados, podemos ver que o primeiro número se repete apenas após 255 números gerados, e nenhum outro número gerado se repete antes. Ou seja, o programa gerou 255 números aleatórios sem repetição. O arquivo com o padrão de testes pode ser usado para testar o funcionamento do circuito descrito em VHDL. Essa simulação é feita com a ferramenta asimut que faz uma comparação, lendo os valores dos dados de entrada e comparando com as saídas produzidas pelo circuito com aquelas prescritas no arquivo de padrão. O asimut produz um arquivo de padrão de teste com o resultado da comparação e indica a presença de erros. Porém precisamos tratar o atraso de propagação das portas lógicas, o mais preciso é simular com um atraso correto, tabelado nas células padrão. Para isso, ao invés de usar a descrição em VHDL criada no início, iremos usar o resultado do roteiro de obtenção do layout físico para extrair um modelo de descrição estrutural (.vst) com os atrasos realistas listados nos arquivos .vbe das instâncias componentes. Utilizamos a ferramenta cougar para extrair o modelo .vst do layout físico .ap que foi obtido após o asimut/nero. Esse modelo extraído é usado na simulação junto ao arquivo de padrões gerado pelo genpat.
Figura 7: Execução da simulação com asimut
Por fim, foi gerado um arquivo de padrões de teste final, que nos mostra que nenhum erro foi observado durante a simulação com atraso real tabelado. Conclui-se então que o layout físico gerado foi bem sucedido.
https://citeseerx.ist.psu.edu/document?repid=rep1&type=pdf&doi=76b0445329d967a5c564642232433203fe8357e8 https://en.wikipedia.org/wiki/Linear-feedback_shift_register https://edisciplinas.usp.br/pluginfile.php/5400280/mod_resource/content/1/SLIDES-Aula23-Parte-II-LinearFeedbackShiftRegisters-LFSRs-2020S1.pdf https://edisciplinas.usp.br/pluginfile.php/5391242/mod_resource/content/1/SLIDES-Aula23-Registradores%20%2B%20Contadores-2020.pdf https://www.eng.auburn.edu/~nelson/courses/elec4200/Slides/VHDL%203%20Sequential.pdf https://dcc.ufrj.br/~gabriel/circlog/VHDL-2.pdf